数据倾斜的定位方法：从现象到根因

说实话，很多同学一遇到 Spark 任务跑得慢，第一反应就是「加资源」。但资源加完了，该慢还是慢。我见过最夸张的一个案例——加了 3 倍 executor，任务反而更慢了。为什么？因为数据倾斜没解决，加再多资源也只是让那个倾斜的 task 死得更慢。

所以这一章，咱们就聊聊怎么精准定位数据倾斜。说白了，就是三招：看 UI、查日志、跑验证。

1. 通过 Spark UI 看 Stage 和 Task 指标

Spark UI 是定位倾斜的第一站。我个人习惯，任务一跑起来就先打开 4040 端口。你想想看，如果所有 task 都跑完了，唯独几个 task 还在那里转圈，那基本就是倾斜了。

关键指标怎么看？

Stage 页面怎么看？

点进某个 Stage，看「Summary Metrics」那栏。重点关注 Shuffle Read Size / Records 的 Max 和 Min。如果 Max / Min > 10，基本可以确认倾斜。

嗯，这里要注意：有时候 Shuffle Read Size 不大，但 Shuffle Write Size 差异很大。这说明倾斜发生在 map 端，也就是上游数据就已经歪了。

2. 通过日志定位倾斜 Key

UI 告诉你「有倾斜」，但没告诉你「哪个 key 在作怪」。这时候就得翻日志了。

我常用的方法：在 shuffle 读或写的地方，加一段自定义的 mapPartitions，把每个 partition 的数据量打出来。但说实话，生产环境不太方便改代码。那怎么办？

从 Spark 日志里捞线索

Spark 的日志里，如果某个 task 处理的数据量特别大，通常会有类似这样的 WARN 日志：

WARN TaskSetManager: Stage 3 contains a task of very large size (1234 MB).
The maximum recommended task size is 100 MB.

看到这个，直接定位到那个 Stage。然后去对应的 executor 日志里，搜 ShuffleBlockFetcherIterator 或者 ExternalSorter 的日志。有时候能看到类似：

INFO ExternalSorter: Thread 42 spilling in-memory map of 1.2 GB to disk (3 times so far)

这说明这个 partition 的数据量已经大到频繁溢写磁盘了。

3. 使用 countByKey 快速验证

UI 和日志都指向了某个 Stage，但具体是哪个 key 导致的？最直接的办法：countByKey。

怎么用？

假设你的 RDD 或 DataFrame 经过 groupBy 或 reduceByKey 后出现了倾斜，直接在倾斜前的 RDD 上跑：

// 假设 rdd 是 (key, value) 对
val keyCounts = rdd.map(_._1).countByKey()

// 按出现次数降序排列，取前 10
keyCounts.toSeq.sortBy(-_._2).take(10).foreach(println)

输出结果大概长这样：

(null, 12345678)
("", 5432109)
("hot_key_1", 2345678)
("hot_key_2", 1234567)
...

看到没？null 和空字符串经常是罪魁祸首。我遇到过好几次，业务数据里某个字段默认值是空字符串，结果 groupBy 的时候全聚到一个 partition 里了。

DataFrame 版本怎么搞？

如果你用的是 DataFrame，可以这样：

df.groupBy("key_column")
  .count()
  .orderBy(desc("count"))
  .show(10, false)

这样就能看到每个 key 的数据量分布。如果某个 key 的 count 是其他 key 的几百倍，那它就是倾斜的元凶。

rdd.sample(false, 0.1).map(_._1).countByKey()

知识体系总览

下面这张图，把定位数据倾斜的完整流程串起来了。你可以把它当作排查时的「检查清单」：

总结一下定位思路

定位数据倾斜，说白了就是三步走：

1. 看 UI：找到哪个 Stage 的 task 时间或数据量差异最大
2. 查日志：确认是哪个 partition 出了问题，排除代码逻辑错误
3. 跑验证：用 countByKey 或 groupBy count 揪出具体的倾斜 key

这三步走完，你基本就知道「谁在捣乱」了。下一章咱们就聊聊，知道了倾斜 key 之后，怎么对症下药。