数据倾斜处理

数据倾斜

----------------------

数据倾斜的处理思路

1. 数据倾斜产生原因

做数据运算的时候会涉及到，count distinct、group by、join on等操作，这些都会触发Shuffle动作。一旦触发Shuffle，所有相同key的值就会被拉到一个或几个Reducer节点上，容易发生单点计算问题，导致数据倾斜。

1.key分布不均匀

2.建表时考虑不周

关联字段的 数据规范不一致：①类型不一致 ②默认值不一致

例：假设我们有两张表：
user（用户信息表）：userid，register_ip
ip（IP表）：ip，register_user_cnt
这可能是两个不同的人开发的数据表。如果我们的数据规范不一致的话，会出现一种情况：
user表中的register_ip字段，如果获取不到这个信息，我们默认为null；
但是在ip表中，我们在统计这个值的时候，为了方便，我们把获取不到ip的用户，统一认为他们的ip为0。
两边其实都没有错的，但是一旦我们做关联了，这个任务会在做关联的阶段，也就是sql的on的阶段卡死。

3.业务数据激增

热门业务数据量巨增，导致整体group by的时候导致数据倾斜

例：北上深在11.11的时候的销售额巨增，如果直接group by可能导致数据倾斜

2.解决数据倾斜思路

很多数据倾斜的问题，都可以用和平台无关的方式解决，比如更好的数据预处理，异常值的过滤等。因此，解决数据倾斜的重点在于对数据设计和业务的理解，这两个搞清楚了，数据倾斜就解决了大部分了。

1.业务逻辑

从业务逻辑的层面上来优化数据倾斜：单独对Key进行处理(二次聚合) + 整合

11.11导致三个城市数据量激增的例子，我们可以单独对这三个城市来做count，单独做时可用两次MR，第一次打散计算，第二次再最终聚合计算。完成后和其它城市做整合。

2.程序层面

比如说在Hive中，经常遇到count(distinct)操作，这样会导致最终只有一个Reduce任务。

我们可以先group by，再在外面包一层count，就可以了。比如计算按用户名去重后的总用户量：

（1）优化前 只有一个reduce，先去重再count负担比较大：
select name,count(distinct name)from user;
​
（2）优化后
// 设置该任务的每个job的reducer个数为3个。Hive默认-1，自动推断。
set mapred.reduce.tasks=3;
// 启动两个job，一个负责子查询(可以有多个reduce)，另一个负责count(1)：
select count(1) from (select name from user group by name) tmp;

3.调参方面

Hadoop和Flink都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。

4.***从业务和数据上解决数据倾斜

很多数据倾斜都是在数据的使用上造成的。我们举几个场景，并分别给出它们的解决方案。

1 有损的方法：找到异常数据，比如ip为0的数据，过滤掉
2 无损的方法：对分布不均匀的数据，单独计算
3 先对key做一层hash，先将数据随机打散让它的并行度变大，再汇集
4 数据预处理

----------------------

数据倾斜处理方案

1.使用Hive ETL预处理数据

(提前数据倾斜)

适用场景

导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀
（比如某个key对应了100万数据，其他key才对应了10条数据），
​
而且业务场景需要频繁使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案

实现思路

此时可以评估一下，是否可以通过Hive来进行数据预处理
（即通过Hive ETL预先对数据按照key进行聚合，或者是预先和其他表进行join），
​
然后在其他作业中针对的数据源就不是原来的Hive表了，而是预处理后的Hive表。
​
此时由于数据已经预先进行过聚合或join操作了，那么在其他作业中也就不需要使用原先的shuffle类算子/聚合等 这类操作了。

方案实现原理

其实在Hive ETL中进行group by或者join等shuffle操作时，还是会出现数据倾斜，导致Hive ETL的速度很慢。
​
​
我们只是把数据倾斜的发生提前到了Hive ETL中，避免Spark程序发生数据倾斜而已

方案优缺点

优点：实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。
​
缺点：治标不治本，Hive ETL中还是会发生数据倾斜。

方案实践经验

在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，
而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。
​
将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，
而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。

项目实践经验

在美团·点评的交互式用户行为分析系统中使用了这种方案
​
该系统主要是允许用户通过Java Web系统提交数据分析统计任务，后端通过Java提交Spark作业进行数据分析统计。
要求Spark作业速度必须要快，尽量在10分钟以内，否则速度太慢，用户体验会很差。所以我们将有些Spark作业的shuffle操作提前到了Hive ETL中，从而让Spark直接使用预处理的Hive中间表，尽可能地减少Spark的shuffle操作，大幅度提升了性能，将部分作业的性能提升了6倍以上。

2.过滤少数导致倾斜的key

方案适用场景

如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。
​
比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。

方案实现思路

如果我们判断那少数几个数据量特别多的key，对作业的执行和计算结果不是特别重要的话，那么干脆就直接过滤掉那少数几个key。
​
如果需要每次作业执行时，动态判定哪些key的数据量最多然后再进行过滤，那么可以使用sample算子对RDD进行采样，然后计算出每个key的数量，取数据量最多的key过滤掉即可。

方案实现原理

将导致数据倾斜的key给过滤掉之后，这些key就不会参与计算了，自然不可能产生数据倾斜。

方案优缺点

优点：实现简单，而且效果也很好，可以完全规避掉数据倾斜。
​
缺点：适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。

方案实践经验

在项目中我们也采用过这种方案解决数据倾斜。
​
有一次发现某一天作业在运行的时候突然OOM了，追查之后发现，是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几个key之后，直接在程序中将那些key给过滤掉。

3.提高Shuffle算子的并行度

方案适用场景

如果我们必须要对数据倾斜迎难而上，那么建议优先使用这种方案，因为这是处理数据倾斜最简单的一种方案。

方案实现思路

在对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如reduceByKey(1000)，该参数就设置了这个shuffle算子执行时shuffle read task的数量，即spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，默认是200，对于很多场景来说都有点过小。
​
Flink的聚合算子都会有可以设置其 算子并行度：sum() .setParallelism(xxx)

方案实现原理

增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。
​
而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。
​
增加了并行度，使得 KeyBy时候的双重hash的时候进入到不同的并行度的概率加大

方案优缺点

优点：实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。
​
缺点：只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。

方案实践经验

该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，
那么无论你的task/并行度数量增加到多少，这个对应着100万数据的key肯定还是会分配到一个task/并行度中去处理，因此注定还是会发生数据倾斜的。
​
所以这种方案只能说是在发现数据倾斜时尝试使用的第一种手段，尝试去用最简单的方法缓解数据倾斜而已，
或者是和其他方案结合起来使用。

4.**二次聚合（局部聚合+全局聚合）

方案适用场景

对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。
​
对flink中的keyedProcess处理的算子有效

方案实现思路

这个方案的核心实现思路就是进行两阶段聚合：

第一次是局部聚合，先给每个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)。

方案实现原理

将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task/并行度处理的数据分散到多个task/并行度上去做局部聚合，进而解决单个task/并行度处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。

方案优缺点

优点
对于聚合类的shuffle操作/groupby导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将性能提升数倍以上。
​
缺点
仅仅适用于聚合类的shuffle/groupby操作，适用范围相对较窄。如果是join类的操作，还得用其他的解决方案。

5.将reduce join转为map join

6.** 采样倾斜key并分拆join操作

方案适用场景

两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用“解决方案五”，那么此时可以看一下两个RDD/Hive表中的key分布情况。
​
如果出现数据倾斜，是因为其中某一个RDD/Hive表中的少数几个key的数据量过大，而另一个RDD/Hive表中的所有key都分布比较均匀，那么采用这个解决方案是比较合适的。

方案实现思路

对包含少数几个数据量过大的key，通过count(distinct key) / 二次group by统计出数据量大的key
​
然后将这几个key对应的数据从原来的表数据中拆分出来，形成一个单独的表，然后使用二次聚合处理即可

方案实现原理

对于join导致的数据倾斜，如果只是某几个key导致了倾斜，
可以将少数几个key分拆成独立数据，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会数据倾斜

方案优缺点

优点：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，采用该方式可以用最有效的方式打散key进行join。而且只需要针对少数倾斜key对应的数据进行扩容n倍，不需要对全量数据进行扩容。避免了占用过多内存。
​
缺点：如果导致倾斜的key特别多的话，比如成千上万个key都导致数据倾斜，那么这种方式也不适合。

7.使用随机前缀和扩容RDD进行join

方案适用场景

如果在进行join操作时，RDD中有大量的key导致数据倾斜，
那么进行分拆key也没什么意义，此时就只能使用最后一种方案来解决问题了。

方案实现思路

该方案的实现思路基本和“解决方案六”类似，首先查看RDD/Hive表中的数据分布情况，找到那个造成数据倾斜的RDD/Hive表，比如有多个key都对应了超过1万条数据。
​
然后将每条数据都打上一个n以内的随机前缀。
​
同时对另外一个正常的表数据进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。
进行join即可

方案实现原理

将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散到多个task/reduce中去处理，而不是让一个task/reduce处理大量的相同key。
​
该方案与“解决方案六”的不同之处就在于，上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD/表，因此上一种方案扩容RDD/表后对内存的占用并不大；
​
而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD/表进行数据扩容，对内存资源要求很高。

方案优缺点

优点：对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。
​
缺点：该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD/表进行扩容，对内存资源要求很高。

方案实践经验

曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。
优化之前，作业的执行时间大约是60分钟左右；
使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

8.多种方案组合使用

在实践中发现，很多情况下，如果只是处理较为简单的数据倾斜场景，那么使用上述方案中的某一种基本就可以解决。但是如果要处理一个较为复杂的数据倾斜场景，那么可能需要将多种方案组合起来使用。
​
比如说，我们针对出现了多个数据倾斜环节的Spark作业，可以先运用解决方案一HiveETL预处理和过滤少数导致倾斜的k，预处理一部分数据，并过滤一部分数据来缓解；
​
其次可以对某些shuffle操作提升并行度，优化其性能；
​
最后还可以针对不同的聚合或join操作，选择一种方案来优化其性能。
​
当对这些方案的思路和原理都透彻理解之后，在实践中根据各种不同的情况，灵活运用多种方案，来解决自己的数据倾斜问题。

----------------------

HIve

理论：hive中数据倾斜排查的方式：

hive中数据倾斜的原因和处理方式：
1.定位SQL语句，判断数据倾斜可能的原因：①null空值 ②关联字段类型不匹配
3.根据SQL判断可能是哪种SQL原因产生的数据倾斜：
①group by类型的数据倾斜 
    单key：加随机数,双重聚合，配置参数,双重聚合 set hive.groupby.skewindata = true;
          过滤出这个Key单独处理
    多key：增加Reducer个数,一定程度上解决问题
          自定义分区器
          加随机数,双重聚合，配置参数,双重聚合 set hive.groupby.skewindata = true;         
②join on关联产生的数据倾斜
    大表JOIN小表   mapJoin     避免了Reducer
    大表JOIN大表   A表加随机数   B表扩容随机数的个数倍  聚合
        A   concat(id,'_',随机数[1,2,3]) 加随机数
        B                               扩容随机数的个数倍
                concat(id,'_',1)
                union all
                concat(id,'_',2)
                union all
                concat(id,'_',3)
​

实际遇见hive数据倾斜处理方式：

1.对表的数据的key进行 null值诊断  count(distinct keyxxx),如果null空值过多，
        采取 ①直接删除 null值 ②添加随机数打散
2.定位日志查询以及Yarn查询 Reduce个数，适当增加 Reduce个数
3.(join on关联类型)数据倾斜时进行负载均衡：set hive.groupby.skewindata = true
4.将关联条件处 字段进行检查是否需要强转，cast(xxx as yyy)
5.可能是 字段类型的数值超限，例：bigint的最大存储范围为：-2^63 到 2^63-1 
    如果数据量大的时候进行join，可能产生 亿*亿*亿*... 超出字段类型范围
    解决方式：将bigint类型转换为string类型进行 join =》 cast(xx as string)

----------------------

Sqoop

数据倾斜可调整参数

Sqoop在导入数据的时候数据倾斜时，可通过调整的参数：
    ①Sqoop参数： split-by：按照自增主键来切分表的工作单元。
    ②num-mappers：启动N个map来并行导入数据，默认4个；

处理：

①split-by指定按照自增主键切分数据
②通过num-mappers增加map个数

----------------------

hadoop

hadoop中的数据倾斜表现：

1.有一个多几个Reduce卡住，卡在99.99%，一直不能结束。
2.各种container报错OOM
3.异常的Reducer读写的数据量极大，至少远远超过其它正常的Reducer
4.伴随着数据倾斜，会出现任务被kill等各种诡异的表现。

----------------------

Flink

keyedProcess算子容易发生数据倾斜

原因：(keyby:双重hash)keyProcess的分区策略：

 KeyGroupRangeAssignment的assignToKeyGroup 这个api决定的分区策略。
 简而言之：你的key，经过hash再hash之后，除以分区数取余得到数据的分区号。
 所以如果你的key本身分布就不是均匀的，那么大概率会出现倾斜问题。

1.影响

（1）单点问题
   数据集中在某些分区上（Subtask），导致数据严重不平衡。
​
（2）GC 频繁
   过多的数据集中在某些 JVM（TaskManager），使得JVM 的内存资源短缺，导致频繁 GC。
​
（3）吞吐下降、延迟增大
   数据单点和频繁 GC 导致吞吐下降、延迟增大。
​
（4）系统崩溃
   严重情况下，过长的 GC 导致 TaskManager 失联，系统崩溃

2.Flink 定位数据倾斜

步骤1：定位反压

定位反压有2种方式：Flink Web UI 自带的反压监控（直接方式）、Flink Task Metrics（间接方式）。

通过监控反压的信息，(主要观察keyedProcess算子)可以获取到数据处理瓶颈的 Subtask。

步骤2：确定数据倾斜

Flink Web UI 自带Subtask 接收和发送的数据量。当 Subtasks 之间处理的数据量有较大的差距，则该 Subtask 出现数据倾斜。

3.Flink 处理数据倾斜

从source -> transform -> sink寻找原因和解决方法

场景一：数据源 source 消费不均匀

解决思路：通过调整并发度，解决数据源消费不均匀或者数据源反压的情况。
例如kafka数据源，可以调整 KafkaSource 的并发度解决消费不均匀。
调整并发度的原则：KafkaSource 并发度与 kafka 分区数是一样的，或者 kafka 分区数是KafkaSource 并发度的整数倍。

场景二：key 分布不均匀

key 分布不均匀的无统计场景，例如上游数据分布不均匀，使用keyBy来打散数据。

解决思路：

1.keyProcess的分区数选择为质数，因为质数取余更均匀。
​
2.二次聚合：通过添加随机前缀，打散 key 的分布，使得数据不会集中在几个 Subtask。
​
！！！最优的解决方案，是你按权重去对key进行分配，这种方案需要你对key的权重比较了解，再针对性使用例如switch这种方式去给对应的权重数据分配指定的key。

flinkSQL的二次聚合实现：(rand()函数使用见HiveFuncion.md)

SELECT id,sum(sum_level) sumLevel
FROM
(
    SELECT nk,sum(`level`) sum_level,id FROM 
    (
    select id,`level`,concat(id,'-',ROUND(10*RAND(),0)) nk
    FROM
    test
    ) t1
    GROUP BY id，nk
) t2
GROUP BY id