一个Task跑了40分钟，其他Task早就结束了——什么是数据倾斜？

-- 发现倾斜前，先看数据分布
SELECT
  device_id,
  COUNT(*) AS event_count,
  COUNT(*) * 100.0 / SUM(COUNT(*)) OVER() AS pct  -- 占总量百分比
FROM device_events
GROUP BY device_id
ORDER BY event_count DESC
LIMIT 20;
 
-- 如果TOP 5的device_id占了总量60%以上，基本可以确认倾斜
-- 我们当时发现3个测试设备device_id占了总数据的32%

# 打开Spark UI（默认端口4040，集群模式看YARN UI）
# 路径：Jobs → 点进慢的Job → 点进慢的Stage → Tasks列表
 
# 重点关注以下指标：
# 1. Duration列：Task执行时间是否有极端值
# 2. Input Size列：各Task读取的数据量是否差异巨大
# 3. Shuffle Read Size列：各Task的Shuffle Read量差异
# 4. GC Time列：GC时间长说明内存撑满了，间接证明数据量大
 
# 判断倾斜的经验标准：
# - 最慢Task的时间 > 平均时间 × 5倍 → 轻度倾斜
# - 最慢Task的时间 > 平均时间 × 10倍 → 严重倾斜
# - 最大Task的数据量 > 平均数据量 × 10倍 → 严重倾斜

有一个误区要注意：Task执行时间长，不一定就是数据倾斜。也可能是某个Task所在的Executor遇到了GC风暴，或者该节点磁盘IO慢。区别方法：如果是倾斜，Task处理的数据量（Input Size / Shuffle Read Size）也会很大；如果是机器问题，数据量正常但时间很长。

数据倾斜 vs 资源不足——怎么区分？

很多人一看作业慢就加资源（加Executor个数、加内存），但如果根本原因是数据倾斜，加资源完全没用。区分标准：

现象	数据倾斜	资源不足
Task完成时间	大部分快完成，少数极慢	所有Task都慢，差异不大
Spark UI	Task数据量差异极大	Task数据量相对均匀
作业Hang住	最后1-2个Task一直跑	整个Stage都慢
加资源效果	没用，倾斜Task还是慢	有效，整体加速
GC情况	倾斜Task的GC时间超长	所有Executor GC都多

记住这个口诀：大部分Task快，少数Task卡，一定先查数据分布，别急着加资源。

面试高频追问

追问一：数据倾斜为什么会导致OOM？

因为同一个key的所有数据必须被同一个Task处理，而这些数据在聚合或JOIN之前要先放在内存里（Shuffle Read阶段）。如果某个key的数据量超大，单个Executor的内存放不下，就会触发OOM。这就是为什么数据倾斜有时候不只是慢，而是直接报错。我在某元宇宙社交应用做实时数仓时，有个按user_id做聚合的Flink作业，某个压测账号产生了海量数据，直接导致对应的Slot OOM，作业崩了。

追问二：什么情况下数据倾斜是「无解」的？

业务逻辑要求把某个超大key的所有数据放在一起处理时，比如统计某个全局热门商品的所有用户行为，这个商品就是一个超大key。这种情况下我们没办法拆分数据，只能：1）提前过滤掉这个key做特殊处理；2）把这个key单独拉出来用另一条链路处理；3）重新思考业务需求，是否真的需要精确计算。面试时能说出「无解的倾斜要从业务需求层面重新思考」，会让面试官觉得你有架构全局观，不只是个调参侠。

追问三：Flink里有数据倾斜吗？和Spark的倾斜有什么区别？

有。Flink里按key分区做keyBy之后，同样会导致数据量大的key对应的SubTask数据量超大。区别在于：Spark是批处理，一个Stage里所有Task并行跑完才继续，倾斜的Task会拖慢整个Stage；Flink是流处理，倾斜的SubTask会持续高负载，导致反压，最终影响整个流水线的吞吐，严重时触发Checkpoint超时作业崩溃。处理思路类似，但Flink更多用两阶段聚合（局部聚合+全局聚合）来解决。

实战踩坑

我在某出海硬件品牌做EMR到Databricks迁移时，迁移完一批作业后发现有一个设备激活报表作业，在EMR上跑30分钟，迁到Databricks上反而跑了40分钟。我第一反应是Spark版本差异导致的，调了一堆配置参数都没用。

最后还是去Spark UI仔细看，发现有3个Task的执行时间是其他Task的20倍，而这3个Task的Shuffle Read数据量是其他Task的400倍。再查数据分布，发现是3个测试设备的device_id造成的倾斜——在EMR上这个倾斜也存在，但由于EMR的机器配置更高（更多内存），倾斜Task虽然慢但能撑住；到了Databricks的标准配置机器上，内存小了，倾斜Task开始频繁GC，反而更慢了。

-- 排查后，针对测试设备做过滤处理
-- 方案：把测试设备单独识别出来，主链路过滤掉
SELECT
  d.device_id,
  d.device_type,
  COUNT(e.event_id) AS event_count
FROM device_events e
JOIN device_meta d ON e.device_id = d.device_id
WHERE d.is_test_device = 0  -- 过滤掉测试设备，消除倾斜源
  AND e.event_date = '2023-06-01'
GROUP BY d.device_id, d.device_type;
 
-- 处理后：作业从40分钟降到8分钟
-- 测试设备数据单独走另一条链路统计（不影响业务指标）

教训：迁移作业时不要假设「在A环境能跑，到B环境也一样」。应该先做作业画像——记录每个作业在原环境的Task分布、数据量分布、慢Task比例，迁移后对比差异，才能快速定位问题。

总结

数据倾斜的本质是Shuffle按key分发数据，导致key分布不均时某些Task数据量暴增。判断倾斜去Spark UI看Task的Duration和数据量分布，大多数快少数慢才是倾斜，所有都慢是资源不足。面试时能把「倾斜的本质→触发Shuffle操作→判断方法→和资源不足的区别」说清楚，基础分就稳了。

下一篇聊最经典的倾斜场景——GROUP BY倾斜：为什么COUNT(DISTINCT)特别容易倾斜？有什么专属解法？

你们生产环境遇到过最严重的数据倾斜是什么场景？Task时间差了多少倍？评论区分享一下～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长