8.3 数据倾斜处理：给热键做结构手术

8.3 数据倾斜处理：给热键做结构手术

本节摘要：数据倾斜是 keyed 计算的头号性能杀手：少数键把少数子任务压垮，全作业陪跑。本节讲清倾斜的两种脸型与鉴别方法，给出打散加盐与两阶段聚合的完整实现，并说明为什么倾斜问题"参数调不掉，只能改结构"。读完你应能独立完成一次热键的手术方案设计。

为什么资源救不了倾斜

先回答章标题埋下的问题：为什么加资源治不了倾斜？回到第 2.2 节的分区机制——keyBy 按键的哈希把数据路由到固定子任务，这是键控状态得以本地化的根基。倾斜的实质是业务分布天然不均（头部商户的交易量百倍于均值），而分区机制把这种不均原样搬进了计算层：热键所在子任务处理百倍数据、维护百倍状态，其余实例喝西北风。此时给集群加资源，等于给全队发同样的饭——饿的照样饿，饱的照样饱。倾斜是结构问题：谁跟谁分到一组的问题。解法必须改结构，不能改预算。

两种脸型与鉴别

实战里两种情况都被叫"倾斜"，鉴别很重要。脸型一：键倾斜。反压视图里少数子任务繁忙、多数空闲，繁忙实例的键分布统计高度集中（头部键流量超均值十倍以上）。它是真倾斜，走本节的手术流程。脸型二：热点算子。所有子任务都忙、没有闲忙分化——这不是倾斜，是 6.4 节处理过的"慢调用"或资源不足，走资源诊断的路。两种脸型看一眼吞吐分布就能分辨：分化是倾斜，齐忙是瓶颈。

// 两阶段聚合的骨架：打散 + 局部聚合 + 去盐 + 全局聚合
DataStream<Order> orders = env.addSource(kafkaSource);

// 阶段一：加盐打散，把热键的流量摊到 N 个逻辑键上
int saltCount = 16;
DataStream<Tuple2<String, Long>> pre = orders
    .map(o -> Tuple2.of(
        o.getShopId() + "#" + ThreadLocalRandom.current().nextInt(saltCount),  // 加盐
        o.getAmount()))
    .returns(Types.TUPLE(Types.STRING, Types.LONG));

// 局部聚合：每个加盐键各自累计
DataStream<Tuple2<String, Long>> localSum = pre
    .keyBy(t -> t.f0)
    .window(TumblingEventTimeWindows.of(Time.minutes(1)))
    .sum(1);

// 阶段二：去盐还原，按商户做全局归并——此时每个商户的数据量已缩为 N 分之一
DataStream<ShopStat> final_ = localSum
    .map(t -> Tuple2.of(t.f0.split("#")[0], t.f1))
    .returns(Types.TUPLE(Types.STRING, Types.LONG))
    .keyBy(t -> t.f0)
    .window(TumblingEventTimeWindows.of(Time.minutes(1)))
    .sum(1)
    .map(t -> new ShopStat(t.f0, t.f1));
​

这段骨架值得逐行读懂再套用。加盐把"一个商户"拆成十六个逻辑键，流量均匀摊开，任何子任务都不再被百倍流量压垮；局部聚合先把量做小（每个逻辑键内先累计），去盐后的全局聚合只处理十六个中间结果而不是全量明细——两阶段的本质是"先分散缩小体积，再集中做归并"。窗口语义保持不变：两层窗口用同样的时间参数，结果与单层聚合一致。

SQL 里的等价武器

SQL 用户不用手写打散：优化器内置了局部全局聚合的自动改写——满足条件（普通聚合、非窗口上再聚合的场景）时，引擎自动加一层局部预聚合，等价于上面的两阶段。开关一行配置，效果立竿见影：

# 开启 mini-batch 后，优化器才会自动启用局部全局聚合改写（普通 GROUP BY 的倾斜自动缓解）
table.exec.mini-batch.enabled: true
table.exec.mini-batch.allow-latency: 5 s     # 允许聚合器攒批的最大延迟
table.exec.mini-batch.size: 5000             # 攒批的最大条数
table.optimizer.agg-phase-strategy: AUTO     # 让优化器自动选择聚合阶段
​

join 的倾斜是另一个战区：热键导致某侧 join 的部分实例被灌爆。SQL 的处理思路是过滤拆分——把热键从主流里筛出来单独广播维表处理，冷键正常 join，结果再并回去。这条手法的代码骨架在各大实时数仓项目里都有成熟范式，结构上依旧是"改分组结构"而非"加预算"。

手术后的验证

改结构必须验证三件事。其一：闲忙收敛。反压视图里各实例的吞吐分布应从"陡崖"变"缓坡"。其二：结果一致。两阶段聚合与原口径对账——窗口参数一致时结果应分毫不差；有差异先查去盐是否漏了加盐后缀、窗口是否两层同参。其三：心跳复绿。倾斜解除后，4.2 节的对齐耗时应明显回落（原本就是热键拖屏障的因果链）。三验齐过，手术才算成功。

💡 关键直觉：打散的代价是中间结果翻倍（N 个盐值就是 N 份局部状态），所以盐值个数不是越多越好——盖过头部键的流量倍数即可（头部百倍就取十六到三十二），盲目打大会让全局聚合层反过来成为新瓶颈。

本节要点

• 倾斜的实质是业务分布与分区结构的矛盾，参数与预算治不了，只有改结构一条路。
• 鉴别口诀：吞吐分布"分化是倾斜，齐忙是瓶颈"；先分辨脸型再选武器。
• 两阶段聚合三步：加盐打散、局部聚合缩小体积、去盐全局归并；窗口两层同参保证口径一致。
• SQL 用户优先用优化器的局部全局改写；join 倾斜走过滤拆分广播。
• 盐值个数盖过流量倍数即可，打太大反而制造新的全局聚合瓶颈。

性能三板斧收齐。距离总装验收还差两站：上线前的门禁规范，以及全册知识的最终合龙——大屏任务全程复盘。