Spark之数据倾斜（三）

数据倾斜解决方案：

（六）将reduce join转换为map join

对于join这种操作，不光是考虑数据倾斜的问题；即使是没有数据倾斜问题，也完全可以优先考虑。将reduce join转map join的技术，牺牲一点内存资源，不会发生shuffle操作，从根源上避免数据倾斜。  如果两个RDD要进行join，其中一个RDD必须是比较小的，broadcast出去那个小RDD的数据以后，就会在每个executor的block manager中都驻留一份。要确保你的内存足够存放那个小RDD中的数据 。

不适合的情况： 两个RDD都比较大，那么这个时候，你去将其中一个RDD做成broadcast，就很笨拙了。很可能导致内存不足。最终导致内存溢出，程序挂掉。 而且其中某些key（或者是某个key），还发生了数据倾斜；此时可以采用最后两种方式。
（七）sample采样倾斜key进行两次join

这个方案的实现思路，跟大家解析一下：其实关键之处在于，将发生数据倾斜的key，单独拉出来，放到一个RDD中去；用这个原本会倾斜的key RDD跟其他RDD单独去join一下，这个时候，key对应的数据，可能就会分散到多个task中去进行join操作。 就不至于说是，这个key跟之前其他的key混合在一个RDD中时，肯定是会导致一个key对应的所有数据，都到一个task中去，就会导致数据倾斜。

这种方案什么时候适合使用？  对于join，肯定是优先采用reduce join转换map join的方式来处理，但两个RDD数据都比较大，那么就不要那么搞了。 针对你的RDD的数据，你可以自己把它转换成一个中间表，或者是直接用countByKey()的方式，你可以看一下这个RDD各个key对应的数据量；此时如果你发现整个RDD就一个，或者少数几个key，它对应的数据量特别多，此时可以采用这种方案，拉出来那个最多的key，单独进行join，尽可能地将key分散到各个task上去进行join操作。 什么时候不适用呢？ 如果一个RDD中，导致数据倾斜的key特别多，那么此时，这种方法也不再适用，还是使用终极的数据倾斜解决方案---加资源！！！

                                                             

                                                                                                                                                                                                      完。