Spark中Data skew(数据倾斜)Java+Python+Scala三种接口完整代码

起因

代码中shuffle的算子存在的地方，groupByKey、countByKey、reduceByKey、join等

判断一个算子是shuffle算子可以通过[20]

 

出现的问题有两种

①大部分task执行的很快,剩下几个task执行的特别特别慢
②JVM Out Of Memory

 

数据倾斜发生的原理[2]

数据倾斜的原理很简单：在进行shuffle的时候，
必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，
比如按照key进行聚合或join等操作。
此时如果某个key对应的数据量特别大的话，就会发生数据倾斜。
比如大部分key对应10条数据，但是个别key却对应了100万条数据，
那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；
但是个别task可能分配到了100万数据，要运行一两个小时。因此，整个Spark作业的运行进度是由运行时间最长的那个task决定的。
(自己总结:每个key负责处理的数据不一样，导致了木桶效应)
找出异常的key[3]
如果任务长时间卡在最后最后1个(几个)任务，首先要对key进行抽样分析，判断是哪些key造成的。

某个task执行特别慢的情况[2]
首先要看的，就是数据倾斜发生在第几个stage中。
如果是用yarn-client模式提交，那么本地是直接可以看到log的，可以在log中找到当前运行到了第几个stage；如果是用yarn-cluster模式提交，则可以通过Spark Web UI来查看当前运行到了第几个stage。

此外，无论是使用yarn-client模式还是yarn-cluster模式，我们都可以在Spark Web UI上深入看一下当前这个stage各个task分配的数据量，从而进一步确定是不是task分配的数据不均匀导致了数据倾斜。
比如下图中，倒数第三列显示了每个task的运行时间。

明显可以看到，有的task运行特别快，只需要几秒钟就可以运行完；而有的task运行特别慢，需要几分钟才能运行完，

此时单从运行时间上看就已经能够确定发生数据倾斜了。

此外，倒数第一列显示了每个task处理的数据量，明显可以看到，运行时间特别短的task只需要处理几百KB的数据即可，而运行时间特别长的task需要处理几千KB的数据，处理的数据量差了10倍。此时更加能够确定是发生了数据倾斜。

 

数据倾斜解决方案代码汇总

https://github.com/appleyuchi/spark_data_skew

Reference
[1]Spark项目实战-数据倾斜解决方案之原理以及现象分析(已经阅读)

[2]Spark性能优化指南——高级篇(代码不完整,Java的,[2]中内容已经涵盖[11])
[3]解决spark中遇到的数据倾斜问题（代码不完整）
[4]spark处理数据倾斜的案例（图示很清楚，但是代码非常不详细）
[5]Spark如何处理数据倾斜(代码完整,scala版本，可以美团的java版本弄完后再回来看)
[6]Spark--聚合性数据倾斜解决方案实例说明(代码很详细,但是没有数据集,主要技术就是key salting)
[7]解决spark数据倾斜(代码完整，scala版本)

[8]spark调优之数据倾斜(scala版本,部分参考美团的)

[9]最完整的数据倾斜解决方案(spark)

[10]Spark性能优化之道——解决Spark数据倾斜（Data Skew）的N种姿势
[11]面试必问&数据倾斜(已经阅读)
[12]Spark Shuffle Write 和Read(spark底层源码分析)
[13]Spark shuffle-write 和 shuffle-read 中对数据倾斜情况的处理(开头概念很清晰)
[14]彻底搞懂spark的shuffle过程（shuffle write）(讲解shuffle过程)

[15]Spark中RDD 持久化操作 cache与persist区别(cache与persist的区别)
[16]Spark性能优化：数据倾斜调优(转载的[2])

[17]Spark map-side-join 关联优化(代码完整,scala版本)

[18]spark join broadcast优化(代码不完整,scala版本)

[19]What are the Spark transformations that causes a Shuffle?

[20]判断一个算子是否会导致shuffle的方法

[21]Spark性能优化之道——解决Spark数据倾斜（Data Skew）的N种姿势