Flink keyBy 热 key 导致单 subtask RocksDB 写入 QPS 是均值的 30 倍，不改业务逻辑如何量化并缓解倾斜？

【背景】 我负责一条实时用户行为聚合管道：Kafka 24 分区 → Flink 1.17（keyBy(user_id) + 滑动窗口 1min + UDAF 多指标聚合）→ 结果写 Redis Cluster。Flink 配置 8 个 subtask（1 个 TaskManager × 8 slot），RocksDB state backend，稳态 state 约 12GB。业务侧用户行为有显著头部效应：Top 1000 的 user_id 占总流量约 40%。

【现象】

• 8 个 subtask 的 RocksDB 写入 QPS 极不均匀：最热 subtask 写入 QPS 约 18k/s，最冷约 600/s，差距 ~30 倍；
• 热 subtask 的 RocksDB L0 文件数长期在 6~10，compaction 频率是冷 subtask 的 5~8 倍；
• 整体吞吐瓶颈卡在热 subtask 的 compaction stall 上：每次 stall 期间，其他 7 个 subtask 的 Kafka 消费被 barrier 对齐阻塞，全局 lag 从 0 涨到 5k~10k，持续 20~40 秒；
• 冷 subtask 的 CPU 利用率仅 8%~15%，存在大量闲置算力，但 Flink 的 slot 是静态绑定的，无法动态借用。

【已尝试的排查与调参】

1. 把 parallelism 从 8 提到 16：热 key 仍集中落在少数 subtask 上（hash 分布不变），问题从"8 个里 1 个热"变成"16 个里 1~2 个热"，stall 频率没降，冷 subtask 的闲置算力更多了但用不上；
2. 在 keyBy 之前加 salt（user_id + random(0,7)）打散热 key：聚合结果需下游二次合并（reduce），逻辑复杂度翻倍，且二次合并的窗口对齐问题（salt 后各分片窗口时间戳不一致）还没解决；
3. 用 Flink 1.15+ 的 LocalKeyBy 把 shuffle 从网络换成本地重分区：热 subtask 的写入 QPS 没变，只是省了网络序列化，compaction stall 依然存在；
4. 把热 key 的 UDAF 改成有界状态（只保留最近 5min 的 accumulator，过期后 reset）：state 从 12GB 降到 3.2GB，compaction 频率降了一半，但业务方不接受"过期后数据丢失"的语义。

【卡点 / 期望得到的答案形态】

• 倾斜度量的量化方法：除了看 subtask 间的 QPS 比值，有没有更精确的指标来衡量"倾斜对整体吞吐的边际损失"？比如：热 subtask 的 compaction stall 持续 30s 时，全局吞吐损失 = f(stall_duration, hot_subtask_share, parallelism, barrier_alignment_overhead)，这个 f 有没有解析解或经验公式？
• 不改业务逻辑的缓解手段：(a) Flink 1.18+ 的 adaptive scheduler 能不能动态把热 subtask 的 slot 迁移到 I/O 更强的机器上？(b) 有没有"软 salt"方案——Flink 内部做两阶段聚合（local aggregate → global aggregate），但保持 exactly-once 语义和窗口时间戳对齐？(c) 把热 key 拆到独立管道（side output），用不同 parallelism 和 state 策略处理，冷 key 走主路径——拆分的代价（运维复杂度、一致性窗口）和收益（热路径独立扩容）怎么算？
• 监控与告警：Flink metric 体系里，哪些指标能提前 5~10 分钟预警"热 subtask 即将进入 compaction stall"？比如 RocksDB 的 num-files-at-level[0] 趋势斜率 + compaction pending bytes 的组合告警，阈值怎么定？

希望回答能给出"怎么量化倾斜 → 量化结果怎么映射到调参/架构决策 → 各方案的 trade-off 矩阵"的完整推理链，最好附带 Flink metric 的 PromQL 查询命令和 RocksDB 的诊断命令（如 ROCKSDB_SSTABLES 的 level 分布）。