数据倾斜根因分析：四大元凶
数据倾斜，说白了就是数据分得不均匀。我做了这么多年大数据，见过太多团队一遇到任务卡死、OOM，就急着调参数、加资源。结果呢？治标不治本。今天咱们就把这四大根因掰开揉碎了讲清楚。
核心观点： 数据倾斜的本质是「少数分区扛了绝大多数计算量」。不找到根因，加再多机器也是白搭。
一、Key 分布不均：最经典的倾斜
这是最常见的情况。某个 Key 的数据量是其他 Key 的几十倍甚至上百倍。比如电商订单表里，某个大客户的订单量占了总量的 30%。
为什么会这样？数据本身的天然分布就不均匀。我遇到过最夸张的一次，某个省份的销售数据占了全国的 60%，那个分区跑了 3 个小时，其他分区 10 分钟就结束了。
诊断方法： 在 Spark 里用 df.groupBy("key").count().orderBy(desc("count")).show(10) 看一眼 Top 10 Key 的分布。如果最大 Key 的 count 是平均值的 5 倍以上，基本可以判定倾斜。
二、数据膨胀：Join 引发的灾难
数据膨胀往往发生在多表 Join 的场景。尤其是当两张表在 Join 键上存在一对多或多对多关系时，会产生笛卡尔积，数据量瞬间爆炸。
举个例子：用户表和订单表 Join，一个用户有 1000 个订单，这还算正常。但如果用户表和日志表 Join，一个用户产生了 10 万条日志，那结果集就是 10 万行。要是再跟另一个表 Join……嗯，你想想看，数据量会指数级增长。
我记得有一次，一个同事跑了一个三表 Join 的任务，输入数据只有 500GB，中间过程膨胀到了 5TB，最后直接 OOM 了。查了半天，发现是业务逻辑里有个一对多的关联没做去重。
避坑指南： 我曾经在优化一个报表任务时，发现数据膨胀了 20 倍。后来定位到是两张事实表直接 Join，没有先做聚合。记住：先聚合，再 Join，这是铁律。
三、Join 键空值过多：被忽视的陷阱
这个坑特别隐蔽。很多人在做 Join 时，根本没想过空值的问题。但空值在 Shuffle 过程中会被 Hash 到同一个分区——因为 null 的 Hash 值是一样的。
假设你的订单表里有 30% 的订单没有用户 ID（比如匿名下单），这些空值全部涌入同一个 Task。那个 Task 要处理 30% 的数据，其他 Task 分剩下的 70%。结果就是：一个 Task 累死，其他 Task 闲死。
| 空值比例 | 影响程度 | 典型场景 |
|---|---|---|
| < 5% | 轻微 | 少量数据缺失，影响不大 |
| 5% - 20% | 中等 | 单个 Task 负载明显偏高 |
| > 20% | 严重 | 空值分区成为瓶颈，任务可能失败 |
解决方案： 最简单的办法是给空值赋一个随机值。比如 COALESCE(join_key, CONCAT('null_', RAND()))，这样空值就能均匀分布到不同分区。
四、业务逻辑导致的热点 Key
这类问题最头疼。因为它是业务本身造成的，不是技术问题。比如秒杀场景下的商品 ID、热点新闻的 ID、大 V 的用户 ID。这些 Key 在短时间内被海量请求访问，任何计算引擎都扛不住。
我做过一个实时推荐系统的优化。某个爆款商品的 ID 在半小时内被 100 万用户访问，所有的 Join 操作都卡在这个 Key 上。加资源？没用。因为单机处理能力是有上限的。
怎么解决？核心思路是「打散热点」。把热点 Key 拆成多个子 Key，比如把商品 ID 拆成 product_1、product_2……product_N，然后在计算时做二次聚合。
实战案例： 我曾经优化过一个广告点击统计任务。某个广告 ID 的点击量是其他广告的 100 倍。我们把这个广告 ID 加盐拆成 100 个虚拟 Key，先做局部聚合，再合并结果。任务从 2 小时降到了 15 分钟。
如何快速定位根因？
说了这么多，你可能会问：我怎么知道当前倾斜属于哪种类型？我个人习惯用三步法：
- 看 Stage 耗时： 如果某个 Stage 的耗时是其他 Stage 的 3 倍以上，基本就是倾斜了。
- 看 Task 数据量： 在 Spark UI 里看 Shuffle Read 和 Write 的分布。如果某个 Task 的数据量是平均值的 5 倍以上，定位到具体 Key。
- 看业务语义： 拿到倾斜的 Key 后，结合业务逻辑判断是空值、热点还是数据膨胀。
注意： 不要一上来就调参数。先定位根因，再对症下药。否则你可能会发现：调了并行度，倾斜还在；加了内存，OOM 照旧。