定位原因与出现问题的位置:
根据log去定位
出现数据倾斜的原因，基本只可能是因为发生了shuffle操作，在shuffle的过程中，出现了数据倾斜的问题。
因为某个，或者某些key对应的数据，远远的高于其他的key。
1、你在自己的程序里面找找，哪些地方用了会产生shuffle的算子，groupByKey、countByKey、reduceByKey、join
2、看log
log一般会报是在你的哪一行代码，导致了OOM异常；或者呢，看log，看看是执行到了第几个stage！！！
我们这里不会去剖析stage的划分算法，spark代码，是怎么划分成一个一个的stage的。哪一个stage，task特别慢，就能够自己用肉眼去对你的spark代码进行stage的划分，就能够通过stage定位到你的代码，哪里发生了数据倾斜
去找找，代码那个地方，是哪个shuffle操作。
1.聚合源数据
第一种做法
咱们现在，做一些聚合的操作，groupByKey、reduceByKey；groupByKey，说白了，就是拿到每个key对应的values；reduceByKey，说白了，就是对每个key对应的values执行一定的计算。
现在这些操作，比如groupByKey和reduceByKey，包括之前说的join。都是在spark作业中执行的。
spark作业的数据来源，通常是哪里呢？90%的情况下，数据来源都是hive表（hdfs，大数据分布式存储系统）。hdfs上存储的大数据。hive表，hive表中的数据，通常是怎么出来的呢？有了spark以后，hive比较适合做什么事情？hive就是适合做离线的，晚上凌晨跑的，ETL（extract transform load，数据的采集、清洗、导入），hive sql，去做这些事情，从而去形成一个完整的hive中的数据仓库；说白了，数据仓库，就是一堆表。
spark作业的源表，hive表，其实通常情况下来说，也是通过某些hive etl生成的。hive etl可能是晚上凌晨在那儿跑。今天跑昨天的数九。
数据倾斜，某个key对应的80万数据，某些key对应几百条，某些key对应几十条；现在，咱们直接在生成hive表的hive etl中，对数据进行聚合。比如按key来分组，将key对应的所有的values，全部用一种特殊的格式，拼接到一个字符串里面去，比如“key=sessionid, value: action_seq=1|user_id=1|search_keyword=火锅|category_id=001;action_seq=2|user_id=1|search_keyword=涮肉|category_id=001”。
对key进行group，在spark中，拿到key=sessionid，values<Iterable>；hive etl中，直接对key进行了聚合。那么也就意味着，每个key就只对应一条数据。在spark中，就不需要再去执行groupByKey+map这种操作了。直接对每个key对应的values字符串，map操作，进行你需要的操作即可。key,values串。
spark中，可能对这个操作，就不需要执行shffule操作了，也就根本不可能导致数据倾斜。
或者是，对每个key在hive etl中进行聚合，对所有values聚合一下，不一定是拼接起来，可能是直接进行计算。reduceByKey，计算函数，应用在hive etl中，每个key的values。
第二种做法
你可能没有办法对每个key，就聚合出来一条数据；
那么也可以做一个妥协；对每个key对应的数据，10万条；有好几个粒度，比如10万条里面包含了几个城市、几天、几个地区的数据，现在放粗粒度；直接就按照城市粒度，做一下聚合，几个城市，几天、几个地区粒度的数据，都给聚合起来。比如说
city_id date area_id
select ... from ... group by city_id
尽量去聚合，减少每个key对应的数量，也许聚合到比较粗的粒度之后，原先有10万数据量的key，现在只有1万数据量。减轻数据倾斜的现象和问题。
2.过滤导致倾斜的key
第二个方案：过滤导致倾斜的key
如果你能够接受某些数据，在spark作业中直接就摒弃掉，不使用。比如说，总共有100万个key。只有2个key，是数据量达到10万的。其他所有的key，对应的数量都是几十。
这个时候，你自己可以去取舍，如果业务和需求可以理解和接受的话，在你从hive表查询源数据的时候，直接在sql中用where条件，过滤掉某几个key。
那么这几个原先有大量数据，会导致数据倾斜的key，被过滤掉之后，那么在你的spark作业中，自然就不会发生数据倾斜了。
3.提高shuffle操作reduce并行度.
spark.default.parallelism，100
4.使用随机key实现双重聚合
1. 第一次聚合的时候，在key中加入随机前缀，将相同可以的数据打散。
然后第二次聚合的时候，去掉随机前缀
2、使用场景
（1）groupByKey
（2）reduceByKey
5.将reduce join转换为map join
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中有数据倾斜的情况，大家尽量第一时间先考虑这种方式，效果非常好；如果某个RDD比较小的情况下。
不适合的情况：
两个RDD都比较大，那么这个时候，你去将其中一个RDD做成broadcast，就很笨拙了。很可能导致内存不足。最终导致内存溢出，程序挂掉。
而且其中某些key（或者是某个key），还发生了数据倾斜；此时可以采用最后两种方式。
6.sample采样倾斜key单独进行join
使用数据抽样，判断出 出现数据倾斜的key，将这个key单独放在一个rdd中进行数据处理，
rdd中只有一个key时，默认将数据打散进入不同的task
其实关键之处在于，将发生数据倾斜的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对应的数据量特别多。
此时可以采用咱们的这种方案，单拉出来那个最多的key；单独进行join，尽可能地将key分散到各个task上去进行join操作。
什么时候不适用呢？
如果一个RDD中，导致数据倾斜的key，特别多；那么此时，最好还是不要这样了；还是使用我们最后一个方案，终极的join
就是说，咱们单拉出来了，一个或者少数几个可能会产生数据倾斜的key，然后还可以进行更加优化的一个操作；
对于那个key，从另外一个要join的表中，也过滤出来一份数据，比如可能就只有一条数据。userid2infoRDD，一个userid key，就对应一条数据。
然后呢，采取对那个只有一条数据的RDD，进行flatMap操作，打上100个随机数，作为前缀，返回100条数据。
单独拉出来的可能产生数据倾斜的RDD，给每一条数据，都打上一个100以内的随机数，作为前缀。
再去进行join，是不是性能就更好了。肯定可以将数据进行打散，去进行join。join完以后，可以执行map操作，去将之前打上的随机数，给去掉，然后再和另外一个普通RDD join以后的结果，进行union操作。
7.使用随机数以及扩容表进行join
1、选择一个RDD，要用flatMap，进行扩容，将每条数据，映射为多条数据，每个映射出来的数据，都带了一个n以内的随机数，通常来说，会选择10。
2、将另外一个RDD，做普通的map映射操作，每条数据，都打上一个10以内的随机数。
3、最后，将两个处理后的RDD，进行join操作。
局限性：
1、因为你的两个RDD都很大，所以你没有办法去将某一个RDD扩的特别大，一般咱们就是10倍。
2、如果就是10倍的话，那么数据倾斜问题，的确是只能说是缓解和减轻，不能说彻底解决。
1、聚合源数据
2、过滤导致倾斜的key
3、提高shuffle并行度：spark.sql.shuffle.partitions
4、双重group by
5、reduce join转换为map join：spark.sql.autoBroadcastJoinThreshold
6、采样倾斜key并单独进行join
7、随机key与扩容表
由于Spark的这种都是基于RDD的特性；哪怕是Spark SQL，原本你是用纯的SQL来实现的；各位想一想，其实你用纯RDD，也能够实现一模一样的功能。
之前使用在Spark Core中的数据倾斜解决方案，全部都可以直接套用在Spark SQL上。
我们要讲一下，之前讲解的方案，如果是用纯的Spark SQL来实现，应该如何来实现。
1、聚合源数据：Spark Core和Spark SQL没有任何的区别
2、过滤导致倾斜的key：在sql中用where条件
3、提高shuffle并行度：groupByKey(1000)，spark.sql.shuffle.partitions（默认是200）
4、双重group by：改写SQL，两次group by
5、reduce join转换为map join：spark.sql.autoBroadcastJoinThreshold（默认是10485760 ）
你可以自己将表做成RDD，自己手动去实现map join
Spark SQL内置的map join，默认是如果有一个小表，是在10M以内，默认就会将该表进行broadcast，然后执行map join；调节这个阈值，比如调节到20M、50M、甚至1G。20 971 520
6、采样倾斜key并单独进行join：纯Spark Core的一种方式，sample、filter等算子
7、随机key与扩容表：Spark SQL+Spark Core
