出现数据倾斜问题,基本可能是因为shuffle操作,在shuffle过程中,出现了数据倾斜,某些key对应的数据,远远高于其他的key
1.定位问题所在
a. 在自己的程序里面寻找,看看哪些地方会产生shuffle的算子,groupby,countby,reduceby,join
b.看log 看看执行到第几个stage 报错内存溢出 jvm out of memory oom 




解决数据倾斜的方法
1.聚合源数据  


2.聚合源数据  比如现在的每个key对应10万条数据,有好几个粒度,包含几个城市,几天几个地区,现在放粗粒度,直接按照城市粒度,做一下聚合


3.过滤导致倾斜的key ,比如说，总共有100万个key。只有2个key，是数据量达到10万的。其他所有的key，对应的数量都是几十。这个时候，你自己可以去取舍，如果业务和需求可以理解和接受的话，在你从hive表查询源数据的时候，直接在sql中用where条件，过滤掉某几个key。那么这几个原先有大量数据，会导致数据倾斜的key，被过滤掉之后，那么在你的spark作业中，自然就不会发生数据倾斜了


4.提升shuffle reduce端并行度，怎么来操作？很简单，主要给我们所有的shuffle算子，比如groupByKey、countByKey、reduceByKey。在调用的时候，传入进去一个参数。一个数字。那个数字，就代表了那个shuffle操作的reduce端的并行度。那么在进行shuffle操作的时候，就会对应着创建指定数量的reduce task。这样的话，就可以让每个reduce task分配到更少的数据。基本可以缓解数据倾斜的问题。比如说，原本某个task分配数据特别多，直接OOM，内存溢出了，程序没法运行，直接挂掉。按照log，找到发生数据倾斜的shuffle操作，给它传入一个并行度数字，这样的话，原先那个task分配到的数据，肯定会变少。就至少可以避免OOM的情况，程序至少是可以跑的


5.使用随机key实现双重聚合
使用场景 groupbykey reducebykey
比较适合这种方式,join 
a.第一轮聚合的时候,最key进行打散,将原来的key进行打散,变成不一样的key,然后再对所有key进行聚合
对于groupbykey 和reducebykey有很好的效果


6.reduce join转换为map join，适合在什么样的情况下，可以来使用？如果两个RDD要进行join，其中一个RDD是比较小的。一个RDD是100万数据，一个RDD是1万数据。（一个RDD是1亿数据，一个RDD是100万数据）其中一个RDD必须是比较小的，broadcast出去那个小RDD的数据以后，就会在每个executor的block manager中都驻留一份。要确保你的内存足够存放那个小RDD中的数据这种方式下，根本不会发生shuffle操作，肯定也不会发生数据倾斜；从根本上杜绝了join操作可能导致的数据倾斜的问题；对于join中有数据倾斜的情况，大家尽量第一时间先考虑这种方式，效果非常好；