大表与大表join数据倾斜_12中方法，彻底搞定数据倾斜！

这是我的第64篇原创

数据倾斜是上帝对某个服务器的过于偏爱。

上帝太过于偏爱某个服务器&＃xff0c;因此给他分配了太多的任务&＃xff0c;导致数据都倾斜到这台服务器了。

在大数据场景中&＃xff0c;无论是MapReduce还是Spark&＃xff0c;都会因两阶段之间的shuffle导致各个服务器接受到的数据导致处理量失衡的问题。情况严重&＃xff0c;就变成数据倾斜了。

我们之所以创造分布式环境&＃xff0c;就是因为我们将一个巨大的任务拆解成若干个小任务&＃xff0c;给不同的服务器执行&＃xff0c;这样总执行时间就会减小至1/n。理想状态的任务处理情况应该如下图所示&＃xff1a;

原本单机环境需要执行100s的任务&＃xff0c;由5台服务器共同执行&＃xff0c;每台服务器执行20s&＃xff0c;最后总时间会远远大于单机环境的执行时间。而且我们还可以通过不断增加服务器&＃xff0c;来不断减少总运行时间。但是往往会出现这种情况&＃xff1a;

某4台服务器很快就执行完了任务&＃xff0c;但是其中有一台服务器的迟迟不能完成&＃xff0c;严重的时候甚至会OOM(Out Of Memory)。究其原因&＃xff0c;其实如同上面说过的&＃xff0c;在分布式处理的不同阶段之间会有一个混洗(shuffle)的过程&＃xff1a;

在Map或者Spark的Stage1阶段&＃xff0c;由于每个数据块的大小都是一致的(默认128M)&＃xff0c;所以在这个阶段是不会出现数据倾斜的。但是一旦我们对数据进行Shuffle&＃xff0c;比如按照商品品类进行分组之后&＃xff0c;在Reduce或Stage2阶段&＃xff0c;数据将会出现严重的倾斜&＃xff1a;原本每台服务器都只需要处理3条数据&＃xff0c;Shuffle之后&＃xff0c;其中两台服务器各只需处理1条&＃xff0c;而剩余的那台服务器则需要执行8条数据。三台服务器处理的数据量比为7&＃xff1a;1&＃xff1a;1。数据倾斜至第一台服务器。任务延迟&＃xff0c;甚至OOM。

如何解决数据倾斜呢&＃xff1a;

三个层面&＃xff1a;

1、预判-原始数据预防&＃xff0c;保证原始数据不倾斜&＃xff1b;

2、躲闪-规避数据倾斜&＃xff0c;尽量规避Shuffle&＃xff1b;

3、硬刚-处理数据倾斜&＃xff0c;无法规避Shuffle&＃xff0c;用各种办法优化Shuffle过程。

虽说HDFS的数据都是128M&＃xff0c;不会一开始就出现数据倾斜&＃xff0c;但是仍然有以下几种情况&＃xff1a;

1、数据压缩后&＃xff0c;128M文件大小一样&＃xff0c;但是数据量不一样&＃xff1b;

2、存在不可切分的大文件&＃xff1b;

3、流式数据。

这几种情况还是可能会导致程度不一的数据倾斜的。我们需要做一些简单的处理&＃xff1a;

1、数据压缩后&＃xff0c;128M文件大小一样&＃xff0c;但是数据量不一样&＃xff1b;

• 解决办法&＃xff1a;压缩前&＃xff0c;保证每个文件中的数据量基本一致&＃xff1b;

2、存在不可切分的大文件&＃xff1b;

• 解决办法&＃xff1a;生成数据时&＃xff0c;尽量减少不可切分的文件&＃xff0c;尽量按照HDFS的逻辑&＃xff0c;存成可切分的文件&＃xff1b;或者保证这些大文件中的数据量基本一致&＃xff0c;且单机可处理。

3、流式数据&＃xff1b;

• 解决办法&＃xff1a;Kafka的partition实现建议使用随机、轮询等方法&＃xff0c;尽量使各topic的各partition的数据尽量平衡。

既然我们知道数据倾斜的主要原因的shuffle导致的&＃xff0c;那么我们首要的优化方向就是shuffle&＃xff0c;能不用尽量不要用。有以下几种方法我们可以规避&＃xff1a;

4、ETL预处理

在面对无法避免的原始数据倾斜(Hive表中key分布不均匀、kafka中某topic的partititoner含有业务属性&＃xff0c;天然不均匀等)&＃xff0c;我们可以通过前置ETL过程&＃xff0c;进行预处理。

注意&＃xff1a;这个方法只是将成本转嫁&＃xff0c;并没有解决问题。适合削峰填谷类的操作&＃xff0c;比如我们将数据预处理好&＃xff0c;避免凌晨集中计算的时候处理时间过长&＃xff0c;影响其他任务。

5、过滤不必要的key

很多数据分析师在单体数据库的时候&＃xff0c;就有一个不好的习惯&＃xff1a;总喜欢select *。在hive、spark等分布式环境中&＃xff0c;就吃苦头了&＃xff0c;经常遇到数据倾斜甚至OOM。有经验的数据分析师在写sql的时候&＃xff0c;通常会先group by一下&＃xff0c;看看数据的分布情况&＃xff0c;然后再处理。

咱在分布式环境中也可以做类似的事情&＃xff0c;就是采样。

离线环境可以用随机采样&＃xff0c;实时环境可以用鱼塘采样。采样能够快速摸清楚各个key的大致分布。扫一眼数据量大的key&＃xff0c;如果跟你的计算没啥关系&＃xff0c;直接过滤就行。

比如上面举的例子&＃xff0c;母婴品类占绝大多数&＃xff0c;但是运营的要求是分析3C产品&＃xff0c;那你过滤掉母婴产品&＃xff0c;一则减少计算量&＃xff0c;二则规避了数据倾斜的问题。

6、Reduce join 改为Map join

如果是大小表的join&＃xff0c;比如订单表和订单类型、订单状态的join&＃xff0c;如果使用reduce join的话&＃xff0c;就非常容易在shuflle之后出现数据倾斜。建议的原则&＃xff1a;只要一台服务器的内存能吃下这张小表(主要看服务器内存大小&＃xff0c;建议2g以内&＃xff0c;再大就影响服务器性能了)&＃xff0c;就建议用map join。这样join完之后&＃xff0c;每份数据依然是基本均衡的&＃xff0c;而且规避了shuffle导致数据倾斜的问题。

上述几步&＃xff0c;能做的都做了&＃xff0c;还是不行&＃xff0c;那就只能硬刚了。这时就只能八仙过海各显神通了。基本的逻辑还是一样的&＃xff0c;就是能拆的尽量拆&＃xff0c;不能拆的用空间换时间&＃xff0c;或者自定义。

7、通用优化&＃xff1a;shuffle并行度

spark的shuffle并行度默认值是200&＃xff0c;建议根据服务器的情况进行调整。一般是集群cpu总和的2-3倍。当发生数据倾斜的时候&＃xff0c;适当增大并行度&＃xff0c;可以让任务和数据更均匀的分布在整个集群中。但是这个调优方法有些玄学成分在&＃xff0c;因为你不知道他是咋分过去的。

并行度调整有三个方法&＃xff1a;

●操作函数内设置

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还是你需要的&＃xff0c;无法怎么办&＃xff1f;那就把超大数据量的key拆分出来&＃xff0c;单独做成一个任务&＃xff0c;这样超大数据量的key一个任务&＃xff0c;其他中小数据量的key一个任务&＃xff0c;两个任务分别做join啊什么的处理&＃xff0c;最后把结果合并一下就行了。

为了避免超大数据量的key单独join的时候还是一个key一个任务&＃xff0c;可以在key上加上随机数取模的前缀&＃xff0c;这样就把数据分成了N份&＃xff0c;然后再join。

9、阶段拆分-两阶段聚合

对于聚合类的操作&＃xff0c;这种方式可以说是数据倾斜的大杀器。简单来说就是在需要聚合的key前加一个随机数取模的前缀&＃xff0c;这样就能得到非常均匀的key&＃xff0c;然后按这个加工之后的key进行第一次聚合之后&＃xff0c;再对聚合的结果&＃xff0c;按照原始key进行二次聚合&＃xff0c;这样基本就不可能出现数据倾斜了。示意图如下&＃xff1a;

对比之前的例子中&＃xff0c;处理母婴的服务器和处理3c、图书的服务器任务量是7:1:1&＃xff0c;这个方案的数据就非常均匀了。

10、任务拆分

很多时候数据情况会非常复杂&＃xff0c;有null值、有超大数据量的key、还有各种需要过滤的数据&＃xff0c;还有各种聚合和join。那这个时候就需要把任务再拆分。一部分用上面的key值过滤&＃xff0c;一部分用Map Join&＃xff0c;一部分用超大key单独处理。

11、随机前缀

前面说过小表join的时候可以用Map join。但是遇到大表join大表咋办&＃xff1f;三个方法&＃xff1a;1、大表拆成小表&＃xff0c;多次join&＃xff1b;2、SortMergeJoin&＃xff1b;3、位图法(详见《位图法搞定10亿用户量用户标签处理》)。

那大表&＃43;中表&＃xff0c;该咋处理&＃xff1f;可以考虑用随机前缀&＃43;RDD扩容的方法解决join的问题。

如果你将要join的表不大不小&＃xff0c;又不适合用上面大大表的处理方法&＃xff0c;那就可以用这个通用的join方法。简单来说&＃xff0c;就是对A表中需要join的字段加上n以内的随机数前缀&＃xff0c;然后再把B表中的数据复制N份&＃xff0c;join的字段加上1-N的前缀&＃xff0c;然后量表再join&＃xff0c;就能解决数据倾斜的问题了。示意如下&＃xff1a;

原始数据如下&＃xff1a;

不经处理直接join是这样的&＃xff0c;part1很明显比part2要多好几倍的数据&＃xff1a;

我们对A表和B表进行随机前缀和RDD扩容处理之后&＃xff1a;

然后再join&＃xff0c;这样每个part的数据就非常均匀了&＃xff1a;

这个方法比较坑的是B表这个RDD需要扩容&＃xff0c;要复制N份&＃xff0c;对内存要求比较高。但是这个方法可以说是通杀Join的数据倾斜问题。

12、自定义partitioner

上面说改spark的并行数也可以改善数据倾斜&＃xff0c;但是有点玄学的意思在里面。其根本原因就是不管你怎么调优&＃xff0c;计算引擎的分区都是按照固定的方法进行的&＃xff0c;根本不会&＃xff0c;也没办法考虑数据真实情况。

无论是二阶段聚合解决聚合的问题&＃xff0c;还是随机前缀&＃43;RDD扩容解决join的问题&＃xff0c;都是通用解决办法&＃xff0c;而且还麻烦。其实最好的解决办法就是根据现在处理的这份数据&＃xff0c;单独写一个适合的partitioner。比如现在是按省份进行汇总数据&＃xff0c;如果只是简单的按省份去分(这并没有错)&＃xff0c;那么数据肯定会倾斜&＃xff0c;因为各省的数据天然不一样。我们可以通过历史数据、抽样数据或者一些常识&＃xff0c;对数据进行人工分区&＃xff0c;让数据按照我们自定义的分区规则比较均匀的分配到不同的task中。

常见的分区方式&＃xff1a;

• 随机分区&＃xff1a;每个区域的数据基本均衡&＃xff0c;简单易用&＃xff0c;偶尔出现倾斜&＃xff0c;但是特征同样也会随机打散。

• 轮询分区&＃xff1a;绝对不会倾斜&＃xff0c;但是需要提前预知分成若干份&＃xff0c;进行轮询。

• hash散列&＃xff1a;可以针对某个特征进行hash散列&＃xff0c;保证相同特征的数据在一个区&＃xff0c;但是极容易出现数据倾斜。

• 范围分区&＃xff1a;需要排序&＃xff0c;临近的数据会被分在同一个区&＃xff0c;可以控制分区数据均匀。

数据倾斜并不可怕&＃xff0c;咱可以糙一些&＃xff0c;也可以精致一些。但是建议还是糙一些&＃xff0c;这样简单粗暴&＃xff0c;多节省一些时间干(xue)点(dong)别(xi)的

往期精彩回顾

热文 | 当我们在刷抖音的时候&＃xff0c;抖音在干什么&＃xff1f;

干货 | 架构师带你细细的捋一遍MapReduce全流程

干货 | bitmap解决超大表join实战案例