一、数据倾斜危害

  • 耗时远高于其他任务，轻则造成系统资源的浪费，不能充分发挥分布式系统并行计算的优势。
  • 造成内存不足使得当前任务失败，引发重试，多次重试仍不正常，导致整个应用失败。

二、数据倾斜原因

  • Map Task 输入端数据文件导致的数据倾斜
    • 不可切分的压缩算法
    • 数据文件大小不一致
  • Reduce Task数据倾斜（最常见）
    • 数据中有很多空值，被分配到同一分区
    • shuffle+key分布不均（主要原因）

在进行shuffle的时候，必须将各个节点上相同的Key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或者join操作。如果某个key对应的数据量特别大的话，会发生数据倾斜。比如大部分key对应的10条数据，但个别key却对应了100万条数据，那么大部分task会只分配到10条数据，而个别task可能会分配了100万数据。整个spark作业的运行进度是由运行时间最长的那个task决定的。
因此出现数据倾斜的时候，spark作业看起来会运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致OOM。
[

](https://blog.csdn.net/weixin_35353187/article/details/84303518)

三、对症下药

消除map端数据倾斜

消除reduce端的数据倾斜

  • 过滤数据（如null值、无效的、无业务意义的），解决异常数据带来的数据倾斜
  • 消除shuffle
  • 改变Reduce的并行度
  • 加盐，给key添加随机数强行打散数据

解决方案
1、增加jvm内存，这适用于第一种情况(唯一值非常少，极少数值有非常多的记录值(唯一值少于几千))，这种情况下，往往只能通过硬件的手段来进行调优，增加jvm内存可以显著的提高运行效率。

2、增加reduce的个数，这适用于第二种情况(唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一)，我们知道,这种情况下，最容易造成的结果就是大量相同key被partition到一个分区，从而一个reduce执行了大量的工作，而如果我们增加了reduce的个数，这种情况相对来说会减轻很多，毕竟计算的节点多了，就算工作量还是不均匀的，那也要小很多。

3、自定义分区，这需要用户自己继承partition类,指定分区策略，这种方式效果比较显著。

4、重新设计key，有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率)，待到reduce后再把随机数去掉即可。

5、使用combinner合并，combinner是在map阶段，reduce之前的一个中间阶段，在这个阶段可以选择性的把大量的相同key数据先进行一个合并，可以看做是local reduce，然后再交给reduce来处理，这样做的好处很多，即减轻了map端向reduce端发送的数据量(减轻了网络带宽)，也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率)，推荐使用这种方法。

四、数据特征分析

  • 数据的整体规模
    • 数据规模有多大、文件有多少、每个文件的大小
    • 预估资源的开销
  • 数据的存储格式
    • 普通文件格式、列式存储的文件格式
    • 文件是否压缩、压缩格式是什么
  • 数据列值的分布
    • 每一列有值的行数、每个值的行数分布（特别是key相关的列）
    • 分析列值分布可以通过数据采样完成

五、数据倾斜判定条件

外在表象：

  • Executor lost、OOM、Shuffle过程频繁出现错误信息
  • 单个Executor执行时间特别久、整体任务卡在某个阶段不能结束
  • 正常运行的任务突然失败大多数Task运行正常，个别Task运行缓慢或发生OOM

根本原因：个别task处理的数据量远多于其他task，每个task的拥有资源是相同的，处理大数据量的task的所需的时间自然远多于其他task。

六、如何定位数据倾斜

1、数据倾斜只会发生在shuffle中，下面是常用的可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。出现数据倾斜时，可能就是代码中使用了这些算子的原因。

2、通过观察spark UI的节目定位数据倾斜发生在第几个stage中，如果是用yarn-client模式提交，那么本地是可以直接看到log的，可以在log中找到当前运行到了第几个stage；如果用yarn-cluster模式提交，可以通过Spark Web UI 来查看当前运行到了第几个stage。此外，无论是使用了yarn-client模式还是yarn-cluster模式，我们都可以在Spark Web UI 上深入看一下当前这个stage各个task分配的数据量，从而进一步确定是不是task分配的数据不均匀导致了数据倾斜。

3、根据之前学的stage的划分算法定位到极有可能发生数据倾斜的代码，借助Spark UI 定位shuffle算子
image.png
查看导致数据倾斜的key的分布情况
1. 如果是Spark SQL中的group by、join语句导致的数据倾斜，那么就查询一下SQL中使用的表的key分布情况。
2. 如果是对Spark RDD执行shuffle算子导致的数据倾斜，那么可以在Spark作业中加入查看key分布的代码，比如RDD.countByKey()。然后对统计出来的各个key出现的次数，collect/take到客户端打印一下，就可以看到key的分布情况。

七、数据倾斜详细解决方案

7.1、使用Hive ETL(提取、转换和加载) 预处理数据

方案使用场景：
导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀，而且业务场景需要频繁的使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案。
思路：
此时可以评估，是否可以通过Hive来进行数据预处理。即通过Hive ETL 预先对数据按照Key进行聚合，或者是预先和其他表进行join，然后再Spark作业中针对的数据源就是预处理后的Hive表。此时由于数据已经预先进行过聚合或者join操作了，那么在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。
原理：
从根源上解决了数据倾斜，因为彻底避免了在Spark中执行shuffle类算子。
但是因为毕竟数据本身就存在分布不均匀的问题，所以在Hive ETL中进行groubBy或者join等shuffle操作时，还是会发生数据倾斜，导致Hive ETL速度很慢。只是避免了Spark程序发生数据倾斜。
经验：
在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。

7.2、过滤少数导致倾斜的key

方案使用场景：
若发现导致倾斜的key就少数几个，并且对计算本身的影响并不大。比如99%的key对应10条数据，但只有一个key对应100万数据。
思路：
若判断少数几个数据量特别多的key对作业的执行和计算结果不是那么特别重要，可以直接过滤掉那几个key。如在Spark SQL中就可以使用where子句过滤掉这些key,或者在Spark Core 中对RDD执行filter算子过滤掉这些key。如果需要每次作业执行时，动态判定哪些key的数据量最多然后过滤，可以使用sample算子对RDD进行采样，然后计算每个key的数量，取数据量最多的key过滤即可。
缺点：
适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。

7.3、提高shuffle操作的并行度

方案使用场景：
若我们必须要面对数据倾斜问题，要这么使用。
思路：
在对RDD执行shuffle算子时，给shuffle算子传入一个参数，如reduceByKey（1000），该参数设置了这个shuffle算子执行时shuffle read task 的数量。对于Spark SQL中的shuffle类语句，如 groupBy 、join 等需要设置一个参数，即spark.sql.shuffle.partitions。该参数代表了shuffle read task 的并行度，默认值是200。
原理：
增加shuffle read task 的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。
17、数据倾斜 - 图2
实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。
只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。
spark.sql.shuffle.partitions ：参数，默认值是200

7.4、两阶段聚合（局部聚合+全局聚合）

方案使用场景：
对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。
思路：
这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合，先给每个key都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)。接着对打上随机数后的数据，执行reduceByKey等聚合操作，进行局部聚合，那么局部聚合结果，就会变成了(1_hello, 2) (2_hello, 2)。然后将各个key的前缀给去掉，就会变成(hello,2)(hello,2)，再次进行全局聚合操作，就可以得到最终结果了，比如(hello, 4)。
17、数据倾斜 - 图3方案优点：
对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。
方案缺点：
仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案。
[

](https://blog.csdn.net/weixin_35353187/article/details/84303518)

7.5、将reduce join 转为map join

方案使用场景：
在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（几百M或者一两G）。
实现思路：
不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作，进而完全规避掉shuffle类操作，彻底避免数据倾斜的发生和出现。将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量；接着对另外RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD 的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式连接起来。
实现原理：
普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join ，而此时不会发生shuffle操作，也就不会发生数据倾斜。
方案优点：
对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。
方案缺点：
适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。毕竟我们需要将小表进行广播，此时会比较消耗内存资源，driver和每个Executor内存中都会驻留一份小RDD的全量数据。如果我们广播出去的RDD数据比较大，比如10G以上，那么就可能发生内存溢出了。因此并不适合两个都是大表的情况。

  1. -- big_table 表是大表，数据量是百万级别
  2. -- small_table 表是小表，数据量在百级别
  3. -- 特别说明：mapjion括号中的small_table就是指定哪张表为小表
  4.  select 
  5.     /*+mapjoin(small_table)*/
  6.     big_table.a, small_table.b
  7. from big_table left join small_table
  8.     on big_table.a = small_table.a;
  9. -- 参与连接的小表的行数，以不超过2万条为宜，大小不超过25M.
  11. Hive v0.7之后的版本已经不需要给出MapJoin的指示就进行优化。它是通过如下配置参数来控制的：
  12. hive> set hive.auto.convert.join=true;
  13. Hive 还提供另外一个参数，就是：表文件的大小作为开启和关闭MapJoin的阈值。
  14. hive> set hive.mapjoin.smalltable.filesize=25000000 即25M

7.6、采样倾斜key并分拆join操作

方案使用场景:
两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用上第五点解决方案，那么此时可以看一下两个RDD/Hive表中key的分布情况，若出现数据倾斜，是因为其中某一个RDD/Hive表中的少数几个key的数据量过大，而另一个中的所有key都分布比较均匀，那么采用这个解决方案是比较合适的。
实现思路:
对包含少数几个数据量过大的key的那个RDD，通过sample算子采样出一份样本来，然后统计一下每个key的数据量，计算出数据量最大的是哪几个key。
然后将这几个key对应数据从原来的RDD中拆分出来，形成一个单独的RDD，并给每个key打上n以内的随机数作为前缀，而不会导致倾斜的大部分key形成另外一个RDD。
接着将需要join的另一个RDD，也就是过滤出来的那几个倾斜key对应的数据并形成一个单独的RDD，将每条数据膨胀成n条数据，这n条数据都按顺序附加一个0~n的前缀，不会导致倾斜的大部分key也形成另外一个RDD
（此时一共生存了四个RDD：两个key有倾斜的RDD，两个正常RDD）
再将附加了随机前缀的独立RDD与另一个膨胀n倍的独立RDD进行join，此时就可以将原先相同的key打散成n份，分散到多个task中去进行join。
而另外两普通的RDD就照常join即可。
最后将两次join的结果使用union算子合并起来即可。
17、数据倾斜 - 图4
原理：
对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key拆分为独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对于的数据就不会集中在少数几个task上，而是分散到多个task进行join。
优点:
对于join导致的数据倾斜，如果只是某几个key导致了倾斜，此方法可以用最有效的方式打散key进行join，且只需要针对少数倾斜的key对应的数据进行扩容n倍，不需要对全量数据进行扩容，避免占用过多内存。
缺点:
若key特别多，则不合适，而且毕竟复杂。
[

](https://blog.csdn.net/weixin_35353187/article/details/84303518)

7.7、使用随机前缀和扩容RDD进行join

方案使用场景:
若在进行join操作时，RDD中有大量的key导致数据倾斜的时候。
思路:
首先查看RDD／Hive表中的数据分布情况，找到造成数据倾斜的RDD/Hive表，比如有多个key都对应了超过千万条数据。
然后将该RDD 的每条数据都打上一个n以内的随即前缀。
同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀
最后将两个处理后的RDD进行join即可。
原理:
将原先一样的key通过附加前缀变成不一样的key，然后就看可以将这些处理后的“不同的key”分散到多个task中那个去处理，而不是让一个task去处理大量相同的key。此方法与方法六的区别在于，有大量倾斜key的情况，没法将部分key拆分出来单独处理，因此只能对整个RDD 进行数据扩容，对资源要求很高。
缺点:
更多的是缓解数据倾斜，而不是彻底避免，而且需要对整个RDD进行扩容，对内存资源要求较高。
[

](https://blog.csdn.net/weixin_35353187/article/details/84303518)