Maxcompute-Distributed MapJoin原理

 介绍

Distributed MapJoin是MapJoin的升级版，适用于大表Join中表的场景，二者的核心目的都是为了减少大表侧的Shuffle和排序。

注意事项

(1) Join两侧的表数据量要求不同，大表侧数据在10 TB以上，中表侧数据在[1 GB, 100 GB]范围内。

(2) 小表侧的数据需要均匀分布，没有明显的长尾，否则单个分片会产生过多的数据，导致OOM（Out Of Memory）及RPC（Remote Procedure Call）超时问题。

(3) SQL任务运行时间在20分钟以上，建议使用Distributed MapJoin进行优化。

(4) 由于在执行任务时，需要占用较多的资源，请避免在较小的Quota组运行。

使用方法

您需要在select语句中使用Hint提示/*+distmapjoin(<table_name>(shard_count=<n>,replica_count=<m>))*/才会执行distmapjoin。shard_count和replica_count共同决定任务运行的并发度，即并发度=shard_count * replica_count。

参数说明

table_name：目标表名。

shard_count=<n>：设置小表数据的分片数，小表数据分片会分布至各个计算节点处理。n即为分片数，一般按奇数设置。

说明

shard_count值建议手动指定，shard_count值可以根据小表数据量来大致估算，预估一个分片节点处理的数据量范围是[200 MB, 500 MB]。

shard_count设置过大，性能和稳定性会受影响；shard_count设置过小，会因内存使用过多而报错。

replica_count=<m>：设置小表数据的副本数。m即为副本数，默认为1。

为了减少访问压力以及避免单个节点失效导致整个任务失败，同一个分片的数据，可以有多个副本。当并发过多，或者环境不稳定导致运行节点频繁重启，可以适当提高replica_count，一般建议为2或3。

语法示例

-- 推荐，指定shard_count（replica_count默认为1）

/*+distmapjoin(a(shard_count=5))*/

-- 推荐，指定shard_count和replica_count

/*+distmapjoin(a(shard_count=5,replica_count=2))*/

-- distmapjoin多个小表

/*+distmapjoin(a(shard_count=5,replica_count=2),b(shard_count=5,replica_count=2)) */

-- distmapjoin和mapjoin混用

/*+distmapjoin(a(shard_count=5,replica_count=2)),mapjoin(b)*/

执行流程

左侧为原执行计划，M1是小表，右侧为使用Distributed MapJoin之后的Plan：

1．小表一侧分为M1，R2_1 两个Stage。
（1）M1阶段读表并进行shuffle，shuffle的过程将数据分片(shard)，使得具有相同hash value的数据分发到同一个worker。
（2）R2_1（HashTableBuilder1），server端。完成HashTable的构建并常驻内存，接受client端（DistributedMapJoin1）请求完成Lookup查询并返回values。多个shard共同组合成一个分布式的hash table services，shard数量可以手动调整。各shard的service一旦启动，需要等待client端（DistributedMapJoin1）完成所有的request请求后才stop。

2．大表一侧为Stage M3_2。
M3_2（DistributedMapJoin1），client端。通过网络传输方式将大表probe端的join keys，分batches往server端（HashTableBuilder1）发起request请求并获取返回values。由于server端的数据已经按照hash value分shard，client端可以根据数据的特征只请求特定的shard。

检查是否生效

通过logview查看任务运行情况：

（1）可以看到小表在Map job后会有一个Reduce job，并且Instance数量和shard_count数量相同；

（2）在同大表关联的时候stdout日志中可以看到distributeMapjoin的算子。