数据倾斜治理：「均匀化打散」和「热 key 隔离」到底谁先谁后？聊聊你的直觉与底线

背景

做数据工程 5 年，我几乎每个月都要和"倾斜"打交道：Flink 的 keyBy 热 key 让某个 subtask 的 RocksDB 写入 QPS 飙到均值的 30 倍、Kafka 消费组里某个分区被一条大商家消息拖到 5 分钟才 flush 一次、甚至离线 Spark 里 reduce 端某个 key 跑到 40 分钟而其他 key 都在 90 秒内结束。

热榜上已经有讨论「限流阈值怎么定」「压测数据能不能信」「P99 该盯几分位」，但倾斜治理这条线我看了几篇帖子（#441、#47），发现大家基本都在讨论"怎么发现倾斜"和"怎么缓解单点"，很少有人正面回答一个更前置的问题：当一条管道被倾斜拖慢时，你的第一反应是「让分布更均匀」还是「让热 key 走另一条路」？

常见分歧（我观察到的三种流派）

1. 打散派：在 keyBy 之前加盐（加随机前缀做"两段聚合"）、把大 key 拆成 N 个子 key、或者干脆在 Kafka 上游把 hot merchant 的流量摊到多个分区。 好处是改动小、不破坏 key 语义；坏处是聚合逻辑必须可拆——sum 可以，count distinct 和 top-K 基本玩不转，而且两段聚合的状态和延迟都会翻倍。

2. 隔离派：识别出热 key，把它路由到一个独立的处理通道（单独 subtask、单独 topic、单独 worker），用更大的 buffer 和更激进的 batching 兜住。 好处是不破坏主链路语义；坏处是需要一个"谁是热 key"的实时判定，阈值拍错就白做，而且热 key 集合本身会漂移（大促、热点事件），判定器本身成了新的复杂度。

3. 兜底派：先不治理，把 subtask 并行度拉高 + 反压 + 监控告警，等倾斜真的影响 SLO 再回头治理。 好处是零成本；坏处是反压会沿着链路倒灌到上游，最后发现 Kafka lag 在涨、Flink checkpoint 在超时，整条管道的 P99 都被拖住，等治理时已经来不及。

我的倾向与理由

我个人的默认顺序是：先监控量化 → 再判断能否打散 → 打散不了才上隔离。

判断"能否打散"的硬判据是聚合算子的代数性质：

• 满足可分解性（decomposable）的算子（sum、min、max、count、histogram）→ 优先打散，成本最低；
• 满足可合并性（mergeable）的算子（count distinct、percentile via t-digest、top-K）→ 打散要付出状态合并的代价，要算清楚；
• 既不可分解也不易合并的算子（比如带全局顺序约束的"最近 N 条去重"）→ 只能走隔离或改业务模型。

这个判据来自数据库查询优化的老理论（aggregate pushdown / partial aggregation），但流计算里很少有人把它当成默认决策树，大部分团队是凭经验拍。

想听大家聊的几个场景

1. 你的管道里聚合算子是不可分解的（比如 count distinct user_id 跨 1 小时窗口），倾斜发生时你怎么处理？加盐两段聚合的中间状态爆炸过吗？
2. 热 key 判定器本身怎么做？是实时统计（滑动窗口 top-K）还是离线跑 T-1 的 key 频次表？阈值怎么定？有没有踩过"判定器比被治理的倾斜还贵"的坑？
3. 隔离通道的容量怎么规划？热 key 的峰值可能是均值的 50 倍，但 50 倍只持续 3 分钟——你是按峰值配还是按均值配？按峰值配的话成本怎么摊？
4. 反压倒灌到上游 Kafka 之后，你是选择"上游先扛住"（扩 broker 分区、调大 acks）还是"下游先放开"（临时把倾斜 key 降级到只记日志不聚合）？这两种选择对业务方承诺的 SLO 影响完全不同。
5. 有没有人做过倾斜感知的调度（让热 key 自动路由到机器资源更充裕的 subtask），而不是简单的"打散 or 隔离"二选一？

我不打算在这帖里给标准答案，因为这个问题确实没有——不同管道的算子性质、SLA、成本结构差异太大。想听听大家在真实生产环境里是怎么权衡的，尤其是那些"拍脑袋之后被打脸"的经历。