版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/Anbang713/article/details/82858417
对于之前说的《Spark项目实战-数据倾斜解决方案之聚合源数据》都不适合做，那么第三个方案：提高shuffle操作的reduce并行度。将reduce task的数量变多，就可以让每个reduce task分配到更少的数据量，这样的话也许就可以缓解或者甚至是基本解决掉数据倾斜的问题。
问题1：如何提高reduce的并行度？
很简单，主要给我们所有的shuffle算子，比如groupByKey、countByKey、reduceByKey。在调用的时候传入进去一个参数，一个数字。那个数字就代表了那个shuffle操作的reduce端的并行度。那么在进行shuffle操作的时候，就会对应着创建指定数量的reduce task。
问题2：提升shuffle reduce并行度的缺陷。
治标不治本的意思，因为它没有从根本上改变数据倾斜的本质和问题。这种方案只是说尽可能地去缓解和减轻shuffle reduce task的数据压力，以及数据倾斜的问题。
实际生产环境中的经验：
1、如果最理想的情况下，提升并行度以后，减轻了数据倾斜的问题，或者甚至可以让数据倾斜的现象忽略不计，那么就最好。就不用做其他的数据倾斜解决方案了。
2、不太理想的情况下，就是比如之前某个task运行特别慢要5个小时，现在稍微快了一点变成了4个小时，或者是原先运行到某个task，直接OOM现在至少不会OOM了，但是那个task运行特别慢，要5个小时才能跑完。 那么如果出现第二种情况的话，个人觉得可以舍弃这种方案了。