这是我的第64个原件
数据倾斜是上帝对某台服务器的过度偏好。
数据倾斜的原因
上帝太喜欢某台服务器，给他分配了太多的任务，导致数据向这台服务器倾斜。
大数据场景中，无论是MapReduce还是Spark，都存在由于两个阶段之间的shuffle导致各服务器接收的数据导致处理量失衡的问题。 情况变得严重的话，数据就会倾斜。
之所以建立分布式环境，是因为通过将一个大任务划分为几个小任务，并在不同的服务器上运行，将总执行时间缩短了1/n。 理想状态的任务处理应该如下图所示。
本来，独立环境需要执行100秒的任务，如果5台服务器协同运行，而每台服务器运行20s，最终的总时间将远远超过独立环境的运行时间。 另外，通过持续增加服务器，也可以缩短总运行时间。 但是，经常会发生这种情况。
一台四台服务器很快就完成了任务，但其中一台服务器延迟无法完成，严重时可能会出现内存外(oom )。 其理由是，实际上如上所述，在分散处理的不同阶段之间存在洗牌的过程。
在Map或Spark的Stage1阶段，每个数据块的大小一致(默认值为128M )，因此在此阶段不会发生数据倾斜。 但是，如果对数据进行Shuffle，例如按商品类别进行分组后，在Reduce或Stage2阶段，数据会有很大的倾斜。 本来，每个服务只能处理三个数据，但在Shuffle之后，其中两个服务每个只能处理一个，其余服务必须运行八个数据。 三台服务器处理的数据量为7:1:1。 将数据倾斜到第一台服务器。 任务延迟，甚至OOM。
如何解决数据趋势呢？
三个级别：
1、预判-预防原始数据，保证原始数据不倾斜；
2、闪避-避免数据倾斜，尽量避免Shuffle；
3、刚硬-处理数据倾斜，无法避免Shuffle。 用多种方法优化Shuffle工艺。
预断
HDFS的数据均为128M，虽然从一开始数据就不会倾斜，但仍然存在以下情况。
1、数据压缩后，128M文件大小相同，但数据量不同；
2、有分不开的大文件；
3、流媒体数据。
这几种情况还是可能导致程度不同的数据倾斜。 需要简单处理：
1、数据压缩后，128M文件大小一样，但是数据量不一样；
解决方案：压缩前，保证每个文件的数据量基本匹配；
2、存在不可切分的大文件；
解决方案：生成数据时，尽量减少不可分割文件，并按照HDFS逻辑保存在可分割文件中； 或者，确保这些大文件的数据量基本匹配，可以独立处理。
3、流式数据；
解决方案： Kafka的partition实现建议使用随机、轮询等方法，尽可能平衡每个topic上每个partition的数据。
使远离
既然知道数据是倾斜的
的主要原因的shuffle导致的，那么我们首要的优化方向就是shuffle，能不用尽量不要用。有以下几种方法我们可以规避：4、ETL预处理
在面对无法避免的原始数据倾斜（Hive表中key分布不均匀、kafka中某topic的partititoner含有业务属性，天然不均匀等），我们可以通过前置ETL过程，进行预处理。
注意：这个方法只是将成本转嫁，并没有解决问题。适合削峰填谷类的操作，比如我们将数据预处理好，避免凌晨集中计算的时候处理时间过长，影响其他任务。
5、过滤不必要的key
很多数据分析师在单体数据库的时候，就有一个不好的习惯：总喜欢select *。在hive、spark等分布式环境中，就吃苦头了，经常遇到数据倾斜甚至OOM。有经验的数据分析师在写sql的时候，通常会先group by一下，看看数据的分布情况，然后再处理。
咱在分布式环境中也可以做类似的事情，就是采样。
离线环境可以用随机采样，实时环境可以用鱼塘采样。采样能够快速摸清楚各个key的大致分布。扫一眼数据量大的key，如果跟你的计算没啥关系，直接过滤就行。
比如上面举的例子，母婴品类占绝大多数，但是运营的要求是分析3C产品，那你过滤掉母婴产品，一则减少计算量，二则规避了数据倾斜的问题。
6、Reduce join 改为Map join
如果是大小表的join，比如订单表和订单类型、订单状态的join，如果使用reduce join的话，就非常容易在shuflle之后出现数据倾斜。建议的原则：只要一台服务器的内存能吃下这张小表（主要看服务器内存大小，建议2g以内，再大就影响服务器性能了），就建议用map join。这样join完之后，每份数据依然是基本均衡的，而且规避了shuffle导致数据倾斜的问题。
硬刚
上述几步，能做的都做了，还是不行，那就只能硬刚了。这时就只能八仙过海各显神通了。基本的逻辑还是一样的，就是能拆的尽量拆，不能拆的用空间换时间，或者自定义。
7、通用优化：shuffle并行度
spark的shuffle并行度默认值是200，建议根据服务器的情况进行调整。一般是集群cpu总和的2-3倍。当发生数据倾斜的时候，适当增大并行度，可以让任务和数据更均匀的分布在整个集群中。但是这个调优方法有些玄学成分在，因为你不知道他是咋分过去的。
并行度调整有三个方法：
●操作函数内设置
testRDD.groupByKey(200)
●代码中设置“spark.default.parallelism”
conf.set("spark.default.parallelism", 200)
●配置文件中设置“$SPARK_HOME/conf/spark-defaults.conf” 文件
spark.default.parallelism 200
8、拆分超大key
前面说过采样后过滤。如果采样之后发现这个key还是你需要的，无法怎么办？那就把超大数据量的key拆分出来，单独做成一个任务，这样超大数据量的key一个任务，其他中小数据量的key一个任务，两个任务分别做join啊什么的处理，最后把结果合并一下就行了。
为了避免超大数据量的key单独join的时候还是一个key一个任务，可以在key上加上随机数取模的前缀，这样就把数据分成了N份，然后再join。
9、阶段拆分-两阶段聚合
对于聚合类的操作，这种方式可以说是数据倾斜的大杀器。简单来说就是在需要聚合的key前加一个随机数取模的前缀，这样就能得到非常均匀的key，然后按这个加工之后的key进行第一次聚合之后，再对聚合的结果，按照原始key进行二次聚合，这样基本就不可能出现数据倾斜了。示意图如下：
对比之前的例子中，处理母婴的服务器和处理3c、图书的服务器任务量是7:1:1，这个方案的数据就非常均匀了。
10、任务拆分
很多时候数据情况会非常复杂，有null值、有超大数据量的key、还有各种需要过滤的数据，还有各种聚合和join。那这个时候就需要把任务再拆分。一部分用上面的key值过滤，一部分用Map Join，一部分用超大key单独处理。
11、随机前缀
前面说过小表join的时候可以用Map join。但是遇到zrdxsjoinzrdxs咋办？三个方法：1、zrdxs拆成小表，多次join；2、SortMergeJoin；3、位图法（详见《位图法搞定10亿用户量用户标签处理》）。
那zrdxs+中表，该咋处理？可以考虑用随机前缀+RDD扩容的方法解决join的问题。
如果你将要join的表不大不小，又不适合用上面大zrdxs的处理方法，那就可以用这个通用的join方法。简单来说，就是对A表中需要join的字段加上n以内的随机数前缀，然后再把B表中的数据复制N份，join的字段加上1-N的前缀，然后量表再join，就能解决数据倾斜的问题了。示意如下：
原始数据如下：
不经处理直接join是这样的，part1很明显比part2要多好几倍的数据：
我们对A表和B表进行随机前缀和RDD扩容处理之后：
然后再join，这样每个part的数据就非常均匀了：
这个方法比较坑的是B表这个RDD需要扩容，要复制N份，对内存要求比较高。但是这个方法可以说是通杀Join的数据倾斜问题。
12、自定义partitioner
上面说改spark的并行数也可以改善数据倾斜，但是有点玄学的意思满意的画板。其根本原因就是不管你怎么调优，计算引擎的分区都是按照固定的方法进行的，根本不会，也没办法考虑数据真实情况。
无论是二阶段聚合解决聚合的问题，还是随机前缀+RDD扩容解决join的问题，都是通用解决办法，而且还麻烦。其实最好的解决办法就是根据现在处理的这份数据，单独写一个适合的partitioner。比如现在是按省份进行汇总数据，如果只是简单的按省份去分（这并没有错），那么数据肯定会倾斜，因为各省的数据天然不一样。我们可以通过历史数据、抽样数据或者一些常识，对数据进行人工分区，让数据按照我们自定义的分区规则比较均匀的分配到不同的task中。
常见的分区方式：
随机分区：每个区域的数据基本均衡，简单易用，偶尔出现倾斜，但是特征同样也会随机打散。
轮询分区：绝对不会倾斜，但是需要提前预知分成若干份，进行轮询。
hash散列：可以针对某个特征进行hash散列，保证相同特征的数据在一个区，但是极容易出现数据倾斜。
范围分区：需要排序，临近的数据会被分在同一个区，可以控制分区数据均匀。
数据倾斜并不可怕，咱可以糙一些，也可以精致一些。但是建议还是糙一些，这样简单粗暴，多节省一些时间干（xue）点（dong）别（xi）的
往期精彩回顾
热文 | 当我们在刷抖音的时候，抖音在干什么？
干货 | 架构师带你细细的捋一遍MapReduce全流程
干货 | bitmap解决超zrdxsjoin实战案例
如果你觉得有用，就请帮忙分享一下，谢谢你了