数据倾斜

1.1 数据倾斜优化
1.1.1为何要处理数据倾斜(Data Skew)
数据倾斜是能体现一 个spark大数据工程师水平的性能调优问题。

什么是数据倾斜?
...详见文档
数据倾斜指的是并行处理的数据集中,某一部分(如Spark或Kafka的一个Partition)的数据显著多于其他部分,从而使得
该部分的处理速度成为整个数据集处理的瓶颈.

数据倾斜两大直接致命后果:
1 Out Of Memory
2 运行速度慢,超级慢,极端的慢,不可接受的慢!!!

数据倾斜如何造成的
在shuffle阶段,同样Key的数据条数太多了,导致了某个Key(上图中的80亿条)所在的Task数据量太大了,远远超过其他Task
所处理的数据量

搞定数据倾斜需要:
1 搞定shuffle
2 搞定业务场景
3 搞定CPU core 的使用情况
4 搞定OOM的根本原因等

数据倾斜的原理:

在进行shuffle的时候,必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理,比如按照key进行聚合或join
等操作,此时如果某个key对应的数据量特别大的话,就会发生数据倾斜,比如大部分key对应10条数据,但是个别key却对应了100万
条数据,那么大部分task可能就只会分配到10条数据，然后 1秒钟就运行完了；但是个别task可能分配到了100万数据，要运行一
两个小时。因此，整个Spark作业的运行进度 是由运行时间长的那个task决定的。

定位导致数据倾斜的代码:

数据倾斜只会发生在shuffle过程中.一些常用的并且可能会触发shuffle操作的算子:distinct,groupByKey,reduceByKey,
aggregateByKey,join,cogroup,repartition等.出现数据倾斜时,可能就是代码中使用了这些算子中的某一个导致的.

某个task执行特别慢的情况:
首先看数据倾斜发生在第几个stage中.通过 Spark Web UI 来查看当前运行到了第几个stage,看一下当前这个stage
各个task分配的数据量，从而进一 步确定是不是task分配的数据不均匀导致了数据倾斜。

某个task莫名其妙溢出的情况:
直接看yarn-client模式下本地log的异常栈,或者通过yarn查看yarn-cluster模式下的log中的异常栈.一般来说,通过异常栈
信息就可以定位到你的代码中哪一行发生了内存溢出,然后在那行代码附近找找shuffle类算子,很可能就是算子导致数据倾斜.
当然,内存溢出也可能不是数据倾斜导致的,比如代码bug和偶然出现的数据异常.还是要通过Spark Web UI 查看.

查看导致数据倾斜的key的数据分布情况:
知道了数据倾斜发生在哪里后,通常要分析一下那个执行了shuffle操作并且导致了数据倾斜的RDD/Hive表,查看一下其中key的
分布情况,为之后选择哪一种技术提供依据.
查看key分布的方式:
1 如果是Spark SQL中的group by,join语句导致的倾斜,那么就查询一下sql中使用的表key分布情况
2 如果是对SparkRDD执行shuffle算子导致的数据倾斜,可以在作业中加入查看key分布的代码,比如 RDD.countByKey(),然后对
统计出来的各个key出现的次数,collect/take到客户端打印一下,就可以看到key分布了.
举例:单词计数程序中,如果确定了是stage1的reduceByKey算子导致了数据倾斜，那么就应该 看看进行reduceByKey操作的RDD
中的key分布情况，在这个例子中指的就是pairs RDD。如下示例，我们可以先 对pairs采样10%的样本数据，然后使用countByKey算
子统计出每个key出现的次数，后在客户端遍历和打印样本数据中各个key的出现次数。

val sampledPairs = pairs.sample(false, 0.1)
val sampledWordCounts = sampledPairs.countByKey()
sampledWordCounts.foreach(println(_))

1.1.3 如何缓解/消除数据倾斜
1.1.3.1 尽量避免数据源的数据倾斜

比如数据源是Kafka:
以Spark Stream通过DirectStream方式读取Kafka数据为例。由于Kafka的每一个Partition对应Spark的一个 Task（Partition),
所以Kafka内相关Topic的各Partition之间数据是否平衡，直接决定Spark处理该数据时是否会 产生数据倾斜。如果使用 随机Partitioner，
则每条消息会随机发送到一个Partition中，从而从概率上来讲，各Partition间的数据会达到平 衡。

比如数据源是Hive:
思路:
评估->通过hive数据预处理(通过ETL预先对数据按key聚合,或者和其他表join)->预处理后的hive表(spark中也就无需shuffle)
优点:
简单便捷,效果好,完全规避掉了数据倾斜,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倍以上。

1.1.3.2 调整并行度分散同一个Task的不同Key
适用场景:
如果我们必须要对数据倾斜迎难而上，那么建议优先使用这种方案，因为这是处理数据倾斜简单的一种方案。
实现思路:
在对RDD执行shuffle算子时,给shuffle算子传一个参数,比如reduceByKey(1000),该参数就设置了这个shuffle
算子时执行shuffle read task的数量.。对于Spark SQL中的shuffle类语句，比如group by、join 等，需要设置一个参数，
即spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，该值默认是 200，对于很多场景来说都有点过小。
实现原理:
增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个 task处理比原来更少的数据。
优点:
简单,可以有效缓解和减轻数据倾斜的影响
缺点:
只是缓解了数据倾斜而已,没有彻底根除问题,根据实践经验来看,其效果有限.
方案实践经验:
该方案无法彻底解决数据倾斜,比如极端情况:某个key对应超大数据量.
原理:
Spark在做Shuffle时,默认使用HashPartitioner(非Hash Shuffle)对数据进行分区,如果并行度设置的不合适，可能造成大量不
相同的Key对应的数据被分配到了同一个Task上，造成该Task所处理的数据远大于其它Task，从而 造成数据倾斜。
如果调整Shuffle时的并行度，使得原本被分配到同一Task的不同Key发配到不同Task上处理，则可降低原Task所需 处理的数据量，
从而缓解数据倾斜问题造成的短板效应。

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

1.1.3.4 将Reduce side Join转变为Map side Join
方案适用场景：
在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表 的数据量比较小
（比如几百M或者一两G），比较适用此方案。参与Join的一边数据集足够小，可被加载进Driver并通过Broadcast方法广播
到各个Executor中。
方案实现思路:
不使用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的全量数据.

通过Spark的Broadcast机制，将Reduce侧Join转化为Map侧Join，避免Shuffle从而完全消除Shuffle带来的数据倾斜。

1.1.3.5 两阶段聚合（局部聚合+全局聚合）
方案适用场景：
对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时,比较适用这种方案。
方案实现思路:
两阶段聚合.第一次是局部聚合,先给每个key都打上一个随机数,比如10以内的随机数,比如(hello, 1) (hello, 1)(hello, 1)
(hello, 1) 变为(1_hello,1)(1_hello,1)(1_hello,1)(1_hello,1),然后reduceByKey进行局部聚合(1_hello,2)(2_hello,2).
然后去掉key的前缀(hello,2)(hello,2),再次进行全局聚合,得到结果(hello,4)
方案实现原理:
相同key加随机前缀,变为不同key,让原本被一个task处理的数据分散到多个task上聚合,进而解决单个task处理的数据量过多的问
题.接着去掉随机前缀,再次进行全局聚合,就可以得到最终结果.
优点:
对聚合类的shuffle操作导致的数据倾斜,效果很好,通常都可以解决掉数据倾斜,至少大幅度缓解,将Spark作业的性能提升数倍以上.
缺点:
仅仅适用于聚合类shuffle操作,适用范围相对较窄.如果是join类的shuffle操作,还得用其他的解决方案.

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

1.1.3.7 使用随机前缀和扩容RDD进行join
方案适用场景：
如果在进行join操作时，RDD中有大量的key导致数据倾斜,那么进行分拆key也没什么意义，此时就只能使用后一种方案来解决问题了。
适用于一个数据集存在的倾斜key比较多,另外一个数据集分布比较均匀
方案实现思路:
首先查看RDD/Hive表的数据分布情况,找到那个造成数据倾斜的RDD/Hive表.
比如:
有多个key对应了超过一万条数据,然后将该RDD的每条数据都打上一个n以内的随机前缀.
同时对另外一个正常的RDD进行扩容,将每条数据都扩容成n条数据,扩容出来的每条数据都依次打上一个0-n的前缀
最后将两个处理后的RDD进行join即可.
方案实现原理://TODO
将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散 到多个task中去处理，
而不是让一个task处理大量的相同key。该方案与“解决方案六”的不同之处就在于，上一种方 案是尽量只对少数倾斜key
对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对 内存的占用并不大；而这一种方案是
针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能 对整个RDD进行数据扩容，对内存资源要求很高。

优点:
对join类型的数据倾斜基本都可以处理,而且效果相对显著,性能提升效果也不错.
缺点:
缓解，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。
方案实践经验：
曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是 60分钟左右；
使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

1.1.3.8 大表随机添加N种随机前缀，小表扩大N倍
原理
如果出现数据倾斜的Key比较多，上一种方法将这些大量的倾斜Key分拆出来，意义不大。此时更适合直接对存在 数据倾斜的数据集
全部加上随机前缀，然后对另外一个不存在严重数据倾斜的数据集整体与随机前缀集作笛卡尔乘 积（即将数据量扩大N倍）。
适用场景
一个数据集存在的倾斜Key比较多，另外一个数据集数据分布比较均匀。
优势
对大部分场景都适用，效果不错。
劣势
需要将一个数据集整体扩大N倍，会增加资源消耗。
总结
对于数据倾斜，并无一个统一的一劳永逸的方法。更多的时候，是结合数据特点（数据集大小，倾斜Key的多少 等）
综合使用上文所述的多种方法

1.1.3.9 采样倾斜key并分拆join操作

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

1.1.3.10 过滤少数导致倾斜的key
方案适用场景:
导致倾斜的key就少数几个,而且对计算本身影响不大,很适合用这种方案.
方案实现思路:
如果少数几个数据量特别多的key,对作业执行计算结果不是特别重要的话,就干脆直接过滤掉那少数几个key
比如在Spark SQL中用where字句过滤掉这些key,在Spark Core中对RDD执行filter算子过滤.
如果需要每次作业执行时，动态判定哪些key的数据量多然后再进行过 滤，那么可以使用sample算子对RDD进行采样，
然后计算出每个key的数量，取数据量多的key过滤掉即可。 方案实现原理：将导致数据倾斜的key给过滤掉之后，这些key
就不会参与计算了，自然不可能产生数据倾斜。
方案优点：
实现简单，而且效果也很好，可以完全规避掉数据倾斜。
方案缺点：
适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。
方案实践经验：
在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然 OOM了，追查之后发现，
是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进 行采样，计算出样本中数据量
大的几个key之后，直接在程序中将那些key给过滤掉。