你的数据倾斜了吗？一文帮你数据处理再均衡

关注

原创最新推荐文章于 2026-09-27 10:37:14 发布 391 阅读 AI 写同款· GEO 优化 ›

大数据-数据仓库-数据倾斜什么是数据倾斜？ https://www.jianshu.com/p/42be5ca8b11d 产生数据倾斜的原因？ https://www.jianshu.com/p/ab08de658adc https://www.jianshu.com/p/18b7c3979879 https://www.jianshu.com/p/bde6525634da 如何避免数据倾斜？ ... 阅读详情

前言

此篇主要总结到Hive,Flink,Spark出现数据倾斜的表现，原因和解决办法。首先会让大家认识到不同框架或者计算引擎处理倾斜的方案。最后你会发现计算框架只是“异曲”，文末总结才是“同工之妙”。点击收藏与分享，工作和涨薪用得到！！！

数据倾斜

数据倾斜最笼统概念就是数据的分布不平衡，有些地方数据多，有些地方数据少。在计算过程中有些地方数据早早地处理完了，有些地方数据迟迟没有处理完成，造成整个处理流程迟迟没有结束，这就是最直接数据倾斜的表现。

Hive

Hive数据倾斜表现

就是单说hive自身的MR引擎：发现所有的map task全部完成，并且99%的reduce task完成，只剩下一个或者少数几个reduce task一直在执行，这种情况下一般都是发生了数据倾斜。说白了就是Hive的数据倾斜本质上是MapReduce的数据倾斜。

Hive数据倾斜的原因

在MapReduce编程模型中十分常见，大量相同的key被分配到一个reduce里，造成一个reduce任务累死，其他reduce任务闲死。查看任务进度，发现长时间停留在99%或100%，查看任务监控界面，只有少量的reduce子任务未完成。

key分布不均衡。
业务问题或者业务数据本身的问题，某些数据比较集中。

join小表：其中一个表是小表，但是key比较集中，导致的就是某些Reduce的值偏高。
空值或无意义值：如果缺失的项很多，在做join时这些空值就会非常集中，拖累进度。
group by：维度过小。
distinct：导致最终只有一个Reduce任务。

Hive数据倾斜解决

group by代替distinct 要统计某一列的去重数时，如果数据量很大，count(distinct)就会非常慢，原因与order by类似，count(distinct)逻辑导致最终只有一个Reduce任务。
对1再优化：group by配置调整

map端预聚合

group by时，combiner在map端做部分预聚合，可以有效减少shuffle数据量。

checkinterval：设置map端预聚合的行数阈值，超过该值就会分拆job。

hive.map.aggr=true //默认
hive.groupby.mapaggr.checkinterval=100000 // 默认

倾斜均衡配置 Hive自带了一个均衡数据倾斜的配置项。

其实现方法是在group by时启动两个MR job。第一个job会将map端数据随机输入reducer，每个reducer做部分聚合，相同的key就会分布在不同的reducer中。第二个job再将前面预处理过的数据按key聚合并输出结果，这样就起到了均衡的效果。

hive.groupby.skewindata=false // 默认

join基础优化

Hive在解析带join的SQL语句时，会默认将最后一个表作为大表，将前面的表作为小表，将它们读进内存。如果表顺序写反，如果大表在前面，引发OOM。不过现在hive自带优化。
map join:特别适合大小表join的情况，大小表join在map端直接完成join过程，没有reduce，效率很高。
多表join时key相同：会将多个join合并为一个MR job来处理，两个join的条件不相同，就会拆成多个MR job计算。

sort by代替order by

将结果按某字段全局排序，这会导致所有map端数据都进入一个reducer中，在数据量大时可能会长时间计算不完。使用sort by，那么还是会视情况启动多个reducer进行排序，并且保证每个reducer内局部有序。为了控制map端数据分配到reducer的key，往往还要配合distribute by一同使用。如果不加distribute by的话，map端数据就会随机分配到reducer。
单独处理倾斜key

一般来讲倾斜的key都很少，我们可以将它们抽样出来，对应的行单独存入临时表中，然后打上随机数前缀，最后再进行聚合。或者是先对key做一层hash，先将数据随机打散让它的并行度变大，再汇集。其实办法一样。

Flink

Flink数据倾斜的表现

Flink 任务出现数据倾斜的直观表现是任务节点频繁出现反压。
部分节点出现 OOM 异常，是因为大量的数据集中在某个节点上，导致该节点内存被爆，任务失败重启。

Flink数据倾斜的原因

代码KeyBy、GroupBy 等操作，错误的使用了分组 Key，产生数据热点。
业务上有严重的数据热点。

Flink如何定位数据倾斜

定位反压

Flink Web UI 自带的反压监控（直接方式）、Flink Task Metrics（间接方式）。通过监控反压的信息，可以获取到数据处理瓶颈的 Subtask。

确定数据倾斜

Flink Web UI 自带Subtask 接收和发送的数据量。当 Subtasks 之间处理的数据量有较大的差距，则该 Subtask 出现数据倾斜。

Flink数据倾斜的处理

数据源 source 消费不均匀

通过调整Flink并行度，解决数据源消费不均匀或者数据源反压的情况。我们常常例如kafka数据源，调整并行度的原则：Source并行度与 kafka分区数是一样的，或者 kafka 分区数是KafkaSource 并发度的整数倍。建议是并行度等于分区数。

key 分布不均匀

上游数据分布不均匀，使用keyBy来打散数据的时候出现倾斜。通过添加随机前缀，打散 key 的分布，使得数据不会集中在几个 Subtask。

两阶段聚合解决 KeyBy（加盐局部聚合+去盐全局聚合）

预聚合：加盐局部聚合，在原来的 key 上加随机的前缀或者后缀。

聚合：去盐全局聚合，删除预聚合添加的前缀或者后缀，然后进行聚合统计。

Spark

Spark数据倾斜的表现

Executor lost，OOM，Shuffle过程出错。
Driver OOM。
单个Executor执行时间特别久，整体任务卡在某个阶段不能结束。
正常运行的任务突然失败。

Spark定位数据倾斜

Spark数据倾斜只会发生在shuffle过程中。

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

出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。

Spark数据倾斜的解决方案

使用Hive ETL预处理数据

通过Hive来进行数据预处理（即通过Hive ETL预先对数据按照key进行聚合，或者是预先和其他表进行join），然后在Spark作业中针对的数据源就不是原来的Hive表了，而是预处理后的Hive表。此时由于数据已经预先进行过聚合或join操作了，那么在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。

适合场景

导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀（比如某个key对应了100万数据，其他key才对应了10条数据），而且业务场景需要频繁使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案。

过滤少数导致倾斜的key

如果我们判断那少数几个数据量特别多的key，对作业的执行和计算结果不是特别重要的话，那么干脆就直接过滤掉那少数几个key。

适合场景

如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。

提高shuffle操作的并行度

增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。

两阶段聚合（加盐局部聚合+去盐全局聚合）

预聚合：加盐局部聚合，在原来的 key 上加随机的前缀或者后缀。

聚合：去盐全局聚合，删除预聚合添加的前缀或者后缀，然后进行聚合统计。

适合场景