[Spark]Join的三种实现原理

Hash Join

先来看看这样一条SQL语句：select * from order,item where item.id = order.i_id，参与join的两张表是order和item，join key分别是item.id以及order.i_id。现在假设Join采用的是hash join算法，整个过程会经历三步：

• 确定Build Table以及Probe Table：这个概念比较重要，Build Table会被构建成以join key为key的hash table，而Probe Table使用join key在这张hash table表中寻找符合条件的行，然后进行join链接。Build表和Probe表是Spark决定的。通常情况下，小表会被作为Build Table，较大的表会被作为Probe Table。
• 构建Hash Table：依次读取Build Table(item)的数据，对于每一条数据根据Join Key(item.id)进行hash，hash到对应的bucket中(类似于HashMap的原理)，最后会生成一张HashTable，HashTable会缓存在内存中，如果内存放不下会dump到磁盘中。
• 匹配：生成Hash Table后，在依次扫描Probe Table(order)的数据，使用相同的hash函数(在spark中，实际上就是要使用相同的partitioner)在Hash Table中寻找hash(join key)相同的值，如果匹配成功就将两者join在一起。

两点补充：

1 hash join的性能。从上面的原理图可以看出，hash join对两张表基本只扫描一次，算法效率是o(a+b)，比起蛮力的笛卡尔积算法的a*b快了很多数量级。

2 为什么说Build Table要尽量选择小表呢？从原理上也看到了，构建的Hash Table是需要被频繁访问的，所以Hash Table最好能全部加载到内存里，这也决定了hash join只适合至少一个小表join的场景。

看完了hash join的内核，我们来看一下这种单机的算法，在大数据分布式情况下，应该如何去做。目前成熟的有两套算法：broadcast hash join和shuffler hash join。

Broadcast Hash Join

broadcast hash join是将其中一张小表广播分发到另一张大表所在的分区节点上，分别并发地与其上的分区记录进行hash join。broadcast适用于小表很小，可以直接广播的场景。

在执行上，主要可以分为以下两步：

1. broadcast阶段：将小表广播分发到大表所在的所有主机。分发方式可以有driver分发，或者采用p2p方式。

2. hash join阶段：在每个executor上执行单机版hash join，小表映射，大表试探；

需要注意的是，Spark中对于可以广播的小表，默认限制是10M以下。（参数是spark.sql.autoBroadcastJoinThreshold）

Shuffle Hash Join

当join的一张表很小的时候，使用broadcast hash join，无疑效率最高。但是随着小表逐渐变大，广播所需内存、带宽等资源必然就会太大，所以才会有默认10M的资源限制。

所以，当小表逐渐变大时，就需要采用另一种Hash Join来处理：Shuffle Hash Join。

Shuffle Hash Join按照join key进行分区，根据key相同必然分区相同的原理，将大表join分而治之，划分为小表的join，充分利用集群资源并行化执行。

在执行上，主要可以分为以下两步：

1. shuffle阶段：分别将两个表按照join key进行分区，将相同join key的记录重分布到同一节点，两张表的数据会被重分布到集群中所有节点。

2. hash join阶段：每个分区节点上的数据单独执行单机hash join算法。

刚才也说过，Hash Join适合至少有一个小表的情况，那如果两个大表需要Join呢？这时候就需要Sort-Merge Join了。

Sort-Merge Join

SparkSQL对两张大表join采用了全新的算法－sort-merge join，整个过程分为三个步骤：

1. shuffle阶段：将两张大表根据join key进行重新分区，两张表数据会分布到整个集群，以便分布式并行处理

2. sort阶段：对单个分区节点的两表数据，分别进行排序

3. merge阶段：对排好序的两张分区表数据执行join操作。join操作很简单，分别遍历两个有序序列，碰到相同join key就merge输出，否则继续取更小一边的key。

仔细分析的话会发现，sort-merge join的代价并不比shuffle hash join小，反而是多了很多。那为什么SparkSQL还会在两张大表的场景下选择使用sort-merge join算法呢？

这和Spark的shuffle实现有关，目前spark的shuffle实现都适用sort-based shuffle算法，因此在经过shuffle之后partition数据都是按照key排序的。因此理论上可以认为数据经过shuffle之后是不需要sort的，可以直接merge。

结论：如何优化

经过上文的分析，可以明确每种Join算法都有自己的适用场景。在优化的时候，除了要根据业务场景选择合适的join算法之外，还要注意以下几点：

1 数据仓库设计时最好避免大表与大表的join查询。

2 SparkSQL也可以根据内存资源、带宽资源适量将参数spark.sql.autoBroadcastJoinThreshold调大，让更多join实际执行为broadcast hash join。