【使用场景】
对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（例如几百MB或者1~2GB），比较适用此方案。。
【解决方案】
小表join大表转为小表broadcast+map大表实现。具体为：
普通的join是会shuffle的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join，此时如果发生数据倾斜，影响处理性能，而此时恰好一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，因为这样不会发生shuffle，也就不会发生数据倾斜。
也就是说，不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作，进而完全规避掉shuffle类的操作，彻底避免数据倾斜的发生和出现。将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量；接着对另外一个RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据需要的方式连接起来。
【方案优点】
对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜，是一种治标治本的解决方案。
【方案局限】
这个方案只适用于一个大表和一个小表join的情况。因为解决方案是需要将小表进行广播，此时会比较消耗内存资源，driver和每个Executor内存中都会驻留一份小RDD的全量数据。如果广播出去的RDD数据比较大，比如10G以上，那么就可能发生内存溢出了。因此并不适合两个都是大表的情况。
【代码实现】
我对上述方案做了代码实现，见我的github：https://github.com/wwcom614/Spark
下一篇：