1.什么是数据倾斜

数据倾斜指的是，并行处理的数据集中，某一部分（如Spark或Kafka的一个Partition）的数据显著多于其它部分，从而使得该部分的处理速度成为整个数据集处理的瓶颈。
数据倾斜在spark中将导致两个严重的后果：

数据倾斜直接会导致一种情况：Out Of Memory。
运行速度慢。
一个经验性的结论是：一般情况下，OOM的原因都是数据倾斜。

2.如何定位数据倾斜

数据倾斜一般会发生在Shuffle过程中，很大程度上是你使用了可能会触发Shuffle操作的算子：
distinct\ groupByKey \ reduceByKey \ aggregateByKey \ join \ cogroup \ repartition等。

某个task执行的特别慢的情况：通过history UI 来查看，任务-》查看stage-》查看代码。
某个task莫名其妙内存溢出的情况：多试几次，看是否能通过资源的调整来解决问题，并结合history UI 来进行查看和分析。
查看导致导致数据倾斜的key的数据分布情况：主要通过抽样的方式来获知目前key的分布情况，根据业务逻辑制定相应的解决fangan。

3.数据倾斜的几种典型情况

数据源中的数据分布不均匀，Spark需要频繁交互。
数据集中的不同key由于分区方式，导致数据倾斜。
JOIN操作中，一个数据集中的数据分布不均匀，另一个数据集较小。
聚合操作中，数据集中的数据分布不均匀。
JOIN操作中，两个数据集都比较大，其中只有几个key的数据分布不均匀。
JOIN操作中，两个数据集都比较大，有很多key的数据分布不均匀。
数据集中少数几个key数据量很大，不重要，其它数据均匀。

1.缓解数据倾斜-避免数据源的数据倾斜：

实现原理：
通过在Hive中对倾斜的数据进行预处理，以及在进行kafka数据分发时尽量进行平均分配。这种方案从根源上解决了数据倾斜，彻底避免了在spark中执行shuffle类算子，那么肯定就不会有数据倾斜的问题了。
方案优点：
实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，spark作业的性能会大幅度提升。
方案缺点：
治标不治本，Hive或Kafka中还是会发生数据倾斜。
适用情况：
在一些Java系统于Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜问题提前在上游的Hive ETL中进行处理，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用spark作业时，执行速度都会很快，能够提供更好的用户体验。

2.缓解数据倾斜-调整并行度：

实现原理：
增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。
方案优点：
实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。
方案缺点：
只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。
实践经验：
该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，那么无论你的task数量增加到多少，都无法处理。

3.缓解数据倾斜 -自定义Partitioner：

适用场景：
大量不同的Key被分配到了相同的Task造成该Task数据量过大。
解决方案：
使用自定义的Partitioner实现类代替默认的HashPartitioner，尽量将所有不同的Key均匀分配到不同的Task中。
优势：
不影响原有的并行度设计。如果改变并行度，后续Stage的并行度也会默认改变，可能会影响后续Stage。
劣势：
适用场景有限，只能将不同Key分散开，对于同一Key对应数据集非常大的场景不适用。效果与调整并行度类似，只能缓解数据倾斜而不能完全消除数据倾斜。而且需要根据数据特点自定义专用的Partitioner，不够灵活。

4.缓解数据倾斜 - Reduce side Join转变为Map side Join：

方案适用场景：
在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（比如几百M），比较适用此方案。
方案实现原理：
普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不会发生shuffle操作，也就不会发生数据倾斜。
方案优点：
对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。
方案缺点：
适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。

5.缓解数据倾斜 - 两阶段聚合（局部聚合+全局聚合）：

方案适用场景：
对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。
方案实现原理：
将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。
将相同key的数据分拆处理。
方案优点：
对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。
方案缺点：
仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案。

6.缓解数据倾斜 – 为倾斜key增加随机前/后缀：

适用场景：
两张表都比较大，无法使用Map则Join。其中一个RDD有少数几个Key的数据量过大，另外一个RDD的Key分布较为均匀。
解决方案：
将有数据倾斜的RDD中倾斜Key对应的数据集单独抽取出来加上随机前缀，另外一个RDD每条数据分别与随机前缀结合形成新的RDD（笛卡尔积，相当于将其数据增到到原来的N倍，N即为随机前缀的总个数），然后将二者Join后去掉前缀。然后将不包含倾斜Key的剩余数据进行Join。最后将两次Join的结果集通过union合并，即可得到全部Join结果。
优势：
相对于Map侧Join，更能适应大数据集的Join。如果资源充足，倾斜部分数据集与非倾斜部分数据集可并行进行，效率提升明显。且只针对倾斜部分的数据做数据扩展，增加的资源消耗有限。
劣势：
如果倾斜Key非常多，则另一侧数据膨胀非常大，此方案不适用。而且此时对倾斜Key与非倾斜Key分开处理，需要扫描数据集两遍，增加了开销。
分拆处理，采样确定Key的分布。

7.缓解数据倾斜 -随机前缀和扩容RDD进行join：

方案适用场景：
如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义。
方案实现思路：
将该RDD的每条数据都打上一个n以内的随机前缀。同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。最后将两个处理后的RDD进行join即可。和上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大；而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对内存资源要求很高。
方案优点：
对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。
方案缺点：
该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。
方案实践经验：
曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是60分钟左右；使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

8.缓解数据倾斜 – 过滤少数倾斜Key：

适用场景：
如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。
方案优点：
实现简单，而且效果也很好，可以完全规避掉数据倾斜。
方案缺点：
适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。
实践经验：
在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然OOM了，追查之后发现，是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几个key之后，直接在程序中将那些key给过滤掉。

spark-24.spark调优_2_spark的数据倾斜