数据倾斜解决方案：
（四）提高shuffle操作的reduce并行度
一个简单的方法，可以一定程度的缓解数据倾斜，但是，它治标不治本。将reduce task的数量变多，可以让每个reduce task分配到更少的数据量，这样的话，也许就可以缓解或者甚至是基本解决掉数据倾斜的问题。这种方案实施也简单，调用shuffle算子，比如groupByKey、countByKey、reduceByKey的时候，最后一个参数是并行度，传入一个int数值，那个数字，就代表了那个shuffle操作的reduce端的并行度，那么在进行shuffle操作的时候，就会对应着创建指定数量的reduce task。这样的话，就可以让每个reduce task分配到更少的数据，至少可以避免OOM的情况，程序至少是可以跑的，基本可以缓解数据倾斜的问题。
这种方法只是尽可能地去缓解和减轻shuffle reduce task的数据压力以及数据倾斜的问题，没有从根本上改变数据倾斜的本质和问题，在实际生产中基本会有两种结果：1.如果最理想的情况下，提升并行度以后，减轻了数据倾斜的问题，或者甚至可以让数据倾斜的现象忽略不计，那么就最好。就不用做其他的数据倾斜解决方案了。 2。不太理想的情况下，就是比如之前某个task运行特别慢，要5个小时，现在稍微快了一点，变成了4个小时；或者是原先运行到某个task，直接OOM，现在至少不会OOM了，但是那个task运行特别慢，要5个小时才能跑完。
如果生产环境中遇到第二种情况，那么就需要其他的方法来解决数据倾斜的问题，而不能就这么止步于缓解。
（五）使用随机key实现双重聚合
原理
使用场景 (1)groupByKey (2)reduceByKey
第一轮聚合的时候，对key进行打散，将原先一样的key，变成不一样的key，相当于是将每个key分为多组； 先针对多个组，进行key的局部聚合；接着，再去除掉每个key的前缀，然后对所有的key，进行全局的聚合。 对groupByKey、reduceByKey造成的数据倾斜，有比较好的效果。 如果说，之前的第一、第二、第三种方案，都没法解决数据倾斜的问题，那么就只能依靠这一种方式了。
这种方式比较适合join造成的数据倾斜。
未完......
