1. 数据倾斜的本质

大家好，我是这次课程的主讲。在正式进入增量计算之前，咱们得先把一个最磨人的问题聊透——数据倾斜。

说实话，我做了快十年的大数据工程，踩过最大的坑、熬过最深的夜，十有八九都和它有关。你想想看，明明集群有几百台机器，结果活全让一两台干了，其他机器在那闲着。这不是资源浪费，这是赤裸裸的「劳役不均」。

什么是数据倾斜

数据倾斜，说白了就是数据分布不均匀。在分布式系统里，数据被分到不同的分区或节点上处理。理想情况下，每个节点分到的数据量差不多，大家齐头并进。但现实往往很骨感——某些 key 的数据量特别大，导致它所在的分区变成了「胖子节点」。

举个例子。假设我们要统计一个电商网站的订单量。大部分用户的订单数在 1-10 条之间，但有个大客户「企业采购部」一次性下了 100 万条订单。如果按用户 ID 哈希分片，这个「企业采购部」所在的分区就要处理 100 万条数据，而其他分区可能只处理几千条。这就是典型的数据倾斜。

我记得有一次，一个做用户画像的项目，跑一个简单的 group by 操作，正常情况下 5 分钟就能跑完。结果因为某个标签覆盖了 60% 的用户，那个 reduce 任务跑了整整 2 个小时还没结束。嗯，这就是数据倾斜的威力。

数据倾斜在增量计算中的危害

增量计算和批处理不一样。批处理你跑慢了，顶多就是多等一会儿。但增量计算讲究的是低延迟、实时性。数据倾斜在增量计算里，危害要大得多。

我归纳了三个最要命的危害：

危害	具体表现	后果
延迟飙升	倾斜分区的任务处理时间远大于其他分区	端到端延迟从秒级变成分钟级甚至小时级
资源浪费	大部分节点空闲，少数节点满载	集群利用率下降，成本浪费
稳定性下降	倾斜节点容易 OOM 或被打满	任务频繁失败，需要重试，甚至导致数据丢失

我曾经在一个实时推荐系统里遇到过这种情况。系统用的是 Flink，数据源是用户点击流。正常情况下，每条数据的处理延迟在 100 毫秒以内。但有一天，某个热门视频突然爆火，点击量暴增。那个视频 ID 对应的分区瞬间被打满，处理延迟直接飙到了 30 秒。更糟糕的是，因为背压机制，整个数据管道都堵住了，其他正常的数据也处理不了。

数据倾斜的常见表现

怎么判断你的系统是不是遇到了数据倾斜？我总结了几个典型症状：

• 任务进度条卡住：大部分任务都完成了，就剩一两个任务卡在 99% 不动。
• 部分节点 CPU/内存异常高：集群监控里，某些节点的资源使用率远高于其他节点。
• 数据延迟突然增大：原本秒级延迟的系统，突然变成分钟级甚至小时级。
• 频繁的 OOM 或 GC：倾斜节点因为要处理大量数据，内存压力巨大，频繁触发 Full GC。
• Shuffle 阶段特别慢：在 MapReduce 或 Spark 作业中，shuffle 阶段某个 reduce 任务迟迟不结束。

你想想看，如果你的系统出现了上面任何一种情况，大概率就是数据倾斜在作祟。

下面这张图可以帮你快速理解数据倾斜的整个脉络：