Spark之数据倾斜完美解决方案

前面给大家讲过MapReduce的数据倾斜解决方案以及优化，今天就给大家说下Spark的数据倾斜解决方案。

简单来说数据倾斜就是数据的 key 的分化严重不均，造成一部分数据很多，一部分数据很少的局面，即数据分布不均。如下图所示：

以 WordCount 为例，它的 map 阶段形成 （“xxxx”,1）的形式，然后在 reduce 阶段进行 value 相加，得出 “xxxx” 出现的次数。若进行 WordCount 的文本有100G，其中 80G 全部是 “xxxx”, 剩下 20G 是其余单词，那就会形成 80G 的数据量交给一个 reduce 进行相加，其余 20G 根据 key 不同分散到不同reduce 进行相加的情况。如此就造成了数据倾斜，临床反应就是 reduce 跑到99%然后一直在原地等着 那 80G 的 reduce 跑完。

为什么会出现数据倾斜

在执行shuffle操作的时候，是按照key，来进行values的数据的输出、拉取和聚合的。同一个key的values，一定是分配到一个reduce task进行处理的。多个key对应的values，比如一共是90万。可能某个key对应了88万数据，被分配到一个task上去面去执行。另外两个task，可能各分配到了1万数据，可能是数百个key，对应的1万条数据。这样就会出现数据倾斜问题。
想象一下，出现数据倾斜以后的运行的情况。
其中两个task，各分配到了1万数据，可能同时在10分钟内都运行完了。另外一个task有88万条，88 * 10 = 880分钟 = 14.5个小时。
大家看，本来另外两个task很快就运行完毕了（10分钟），但是由于一个拖后腿的家伙，第三个task，要14.5个小时才能运行完，就导致整个spark作业，也得14.5个小时才能运行完。这样就拖累了整个spark作业运行的时间，这样就很不划算了。

出现数据倾斜的现象

Spark数据倾斜，有两种表现：

1. 你的大部分的task，都执行的特别特别快，（你要用client模式，standalone client，yarn client，本地机器一执行spark-submit脚本，就会开始打印log），task175 finished，剩下几个task，执行的特别特别慢，前面的task，一般1s可以执行完5个，最后发现1000个task，998，999 task，要执行1个小时，2个小时才能执行完一个task。出现以上现象，就表明出现数据倾斜了。
   这样还算好的，因为虽然运行非常慢，但是至少还能跑完。

2. 另一种情况是，运行的时候，其他task都执行完了，也没什么特别的问题，但是有的task，就是会突然间报了一个OOM，JVM Out Of Memory，内存溢出了，task failed，task lost，resubmitting task。反复执行几次都到了某个task就是跑不通，最后就挂掉。
   某个task就直接OOM，那么基本上也是因为数据倾斜了，task分配的数量实在是太大了！所以内存放不下，然后你的task每处理一条数据，还要创建大量的对象，内存爆掉了。
   这样也表明出现数据倾斜了。
   这种就不太好了，因为你的程序如果不去解决数据倾斜的问题，压根儿就跑不出来。
   作业都跑不完，还谈什么性能调优这些东西？

定位导致数据倾斜的代码

根据log去定位
出现数据倾斜的原因，基本只可能是因为发生了shuffle操作，在shuffle的过程中，出现了数据倾斜的问题。因为某个或者某些key对应的数据，远远的高于其他的key。

这里给大家罗列一些常用的并且可能会触发 shuffle 操作的算子：
distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartitio