数据倾斜原因及其处理方式

前言
本文是介绍的是开发spark极其核心的地方，可以说懂得解决spark数据倾斜是区分一个spark工程师是否足够专业的标准，在面试

中以及实际开发中，几乎天天面临的都是这个问题。

原理以及现象
先来解释一下，出现什么现象的时候我们认定他为数据倾斜，以及他数据倾斜发生的原理是什么？

比如一个spark任务中，绝多数task任务运行速度很快，但是就是有那么几个task任务运行极其缓慢，慢慢的可能就接着报内存溢出的问题了，那么这个时候我们就可以认定他是数据倾斜了。

接下来说一下发生数据倾斜的底层理论，其实可以非常肯定的说，数据倾斜就是发生在shuffle类的算子中，在进行shuffle的时候，必须将各个节点的相同的key拉到某个节点上的一个task来进行处理，比如按照key进行聚合和join操作等，这个时候其中某一个key数量量特别大，于是就发生了数据倾斜了。

 

数据倾斜示意图

分组聚合

分组聚合逻辑中，需要把相同key的数据发往下游同一个task，如果某个或某几个key的数量特别大，则会导致下游的某个或某几个task所要处理的数据量特别大，也就是要处理的任务负载特别大

 

JOIN计算

join计算中，A表和B表中相同key的数据，需要发往下游同一个task，如果A表中或B表中，某个key或某几个key的数量特别大，则会导致下游的某个或某几个task所要处理的数据量特别大，也就是要处理的任务负载特别大

定位数据倾斜的代码

上面我们知道了数据倾斜的底层原理，那么就好定位代码了，所以我就可以改写这段代码，让spark任务来正常运行了。

我们知道了导致数据倾斜的问题就是shuffle算子，所以我们先去找到代码中的shuffle的算子，比如distinct、groupBYkey、reduceBykey、aggergateBykey、join、cogroup、repartition等，那么问题一定就出现在这里。

找到shuffle类的算子之后，我们知道一个application分为job，那么一个job又划分为多个stage，stage的划分就是根据shuffle类的算子，也可以说是宽依赖来划分的，所以这个时候我们在spark UI界面上点击查看stage，如下图
 

 

可以看到94这一行和91这一行，执行时间明显比其他的执行时间要长太多了，我们就可以肯定一定是这里发生了数据倾斜，然后我们就找到了发生数据倾斜的stage了，然后根据stage划分原理，我们就可以推算出来发生倾斜的那个stage对应的代码中的哪一部分了。

这个时候我们找到了数据倾斜发生的地方了，但是我们还需要知道到底是哪个key数据量特别大导致的数据倾斜，于是接下来来聊一聊这个问题。

找到这个key的算法，我们可以使用采样的方式，对，就是当初虐了我们千百遍的概率论与数理统计的课上讲的采样算法。

代码如下：
 

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

现在我来简单说一下他的原理，他就是从所有key中，把其中每一个key随机取出来一部分，然后进行一个百分比的推算，学过采样算法的都知道，这是用局部取推算整体，虽然有点不准确，但是在整体概率上来说，我们只需要大概之久可以定位那个最多的key了

解决数据倾斜的方案

 

解决方案一： 提高shuffle 的并行度。
他的原理很简单，我们知道在rduceBykey中有一个shuffle read task的值默认为200，也就是说用两百个task来处理任务，对于我们一个很大的集群来说，每个task的任务中需要处理的key也是比较多的，这个时候我们把这个数量给提高以爱，比如我么设置reduceBYkey（1000），这个时候task的数量就多了，然后分配到每个task中的key就少了，于是说并行度就提高了。但是总体来说，这种解决办法对于某一个数量特别大的key来说效果甚为，只能说key多的时候，我们可以有一定的程度上环境数据倾斜的问题，所以这种方法也不是我们要找到的最好的办法，他也是有一定的局限性。