浅谈Hive中Map Join原理及场景

Hive中的Join可分为Common Join（Reduce阶段完成join）和Map Join（Map阶段完成join）

一、Map Join作用及原理

作用简单来说，在Map阶段进行join，而不是Common Join那样在Reduce阶段按照join列进行分发后在每个Reduce节点上进行join，一来省去Shuffle这个代价昂贵的阶段，二来不需要分发也就没有倾斜的问题。

ps：关于Shuffle的过程可读上篇文章：https://blog.csdn.net/rango_lhl/article/details/112780864

①、具体过程：

在Map 端进行join，其原理是broadcast join，即把小表作为一个完整的驱动表来进行join操作。通常情况下，要连接的各个表里面的数据会分布在不同的Map中进行处理。即同一个Key对应的Value可能存在不同的Map中。这样就必须等到 Reduce中去连接。要使MapJoin能够顺利进行，那就必须满足这样的条件：除了一份表的数据分布在不同的Map中外，其他连接的表的数据必须在每个Map中有完整的拷贝。Map Join会把小表全部读入内存中，在Map阶段直接拿另外一个表的数据和内存中表数据做匹配 (这时可以使用Distributed Cache将小表分发到各个节点上，以供Mapper加载使用)，由于在map时进行了join操作，省去了reduce运行的效率也会高很多。

②、拓展阅读：

早期版本中，当成千上万个 Mapper 同时从 HDFS 将小的连接表读入内存时，连接表很容易成为性能瓶颈，导致 Mapper 在读取操作期间超时。后期Hive优化思路是在原始 Join 的 MapReduce 任务之前创建一个新的 MapReduce 本地任务。这个新任务是将小表数据从 HDFS 上读取到内存中的哈希表中。读完后，将内存中的哈希表序列化为哈希表文件。在下一阶段，当 MapReduce 任务启动时，会将这个哈希表文件上传到 Hadoop 分布式缓存中，该缓存会将这些文件发送到每个 Mapper 的本地磁盘上。因此，所有 Mapper 都可以将此持久化的哈希表文件加载回内存，并像之前一样进行 Join。优化后，小表只需要读取一次。此外，如果多个 Mapper 在同一台机器上运行，则分布式缓存只需将哈希表文件的一个副本发送到这台机器上。（拓展部分拜读于该文http://cloud.tencent.com/developer/article/1481780）

二、应用场景

结合原理可知，Map Join的适用大表Join小表及不等值的链接操作。

• 关于小表的大小，由参数 hive.mapjoin.smalltable.filesize来决定，该参数表示小表的总大小，默认值为25000000字节，即25M。实际中此参数允许的最大值可以修改，但是一般最大不能超过1GB

• Hive0.7之前，需要使用hint提示/*+mapjoin(table)*/才会执行MapJoin,否则执行Common Join，但在0.7版本之后，默认自动会转换Map Join，由参数 hive.auto.convert.join来控制，默认为true。

---

学习交流，有任何问题还请随时评论指出交流。