1. 从一次任务卡死说起数据倾斜到底是什么先说个我自己的真实经历。有次线上跑一个实时指标计算任务数据量一天也就几亿条并行度开到32结果每天到了晚高峰整条链路就开始疯狂反压Kafka消费Lag飙到几百万任务重启了好几次都没用。打开Flink Web UI一看某个Subtask的忙率直接拉到100%而旁边的几个Subtask忙率只有10%左右CPU根本没跑满。当时我就知道这又是数据倾斜在作妖。数据倾斜这个坑做大数据的人基本都踩过。简单说就是明明给了你32个并行度但数据就是不均匀地挤到了某个Task上导致那个Task成为整个链路的短板。尤其是Flink这种实时计算引擎处理的是无界流一旦某个并行子任务因为数据量大而处理不过来背压就会顺着算子一路往上传递最终把整条链路堵死。那篇文章要解决的核心问题就两个怎么定位数据倾斜以及怎么治理数据倾斜。这篇文章我会从定位手段、常见场景、不同阶段的改造方案、Sink端写入保障这几个维度把我在实战里用过、验证过、踩过坑之后沉淀下来的方法论完整梳理出来。不管你是在用Flink同步MySQL数据到ClickHouse还是用SpringBoot整合Flink做实时任务开发只要你的任务里存在KeyBy、窗口聚合、双流Join这些算子这篇内容都值得完整看一遍。先说清楚一件事数据倾斜没有一个“万能解药”。它是分场景的同样的倾斜现象可能来自Key分布、Join字段选择、窗口策略也可能是下游写入导致的背压假象。所以这篇内容不适合当字典查更适合按顺序读一遍建立一个完整的排查思路。2. 三招定位数据倾斜别再靠猜2.1 从Web UI的忙率和积压数据量判断很多同学一上来就喜欢看日志、翻异常其实数据倾斜的特征非常明显根本不用猜。打开Flink Web UI的Task Manager页面重点看两个指标忙率busy%和积压记录数backPressure。正常情况下各并行子任务的忙率应该是大致均匀的差异通常在10%以内。如果有某个子任务的忙率长期在90%以上而其他子任务只有20%、30%并且该算子的输出缓冲区积压数据不断上涨那基本可以断定这个子任务就是热点Task。注意忙率低不一定是没有倾斜也可能是子任务在等待下游比如等待Join的另一条流这时候要结合recordIn/recordOut的速率来综合判断。最稳妥的办法是把Web UI的指标面板切到Chart模式观察10分钟以上的趋势图别只看瞬时值。2.2 从日志和反压监控里寻找热点算子如果任务已经卡死或者Lag报警了说明问题已经很严重这时候不要再等Web UI慢慢加载了直接看反压监控。Flink的BackPressure监控从1.5版本之后就内置了但它的采样周期默认是100次采样每次间隔50ms对于瞬时倾斜可能不够敏感。我更推荐的做法是检查Task Manager日志里是否有频繁的“Buffer pool exhausted”记录检查Kafka Topic的消费者Lag如果某个Partition的Lag明显高于其他Partition说明问题已经回溯到源头用curl命令直接拉取JobManager的REST API实时看每个Subtask的busyTimePerSecond指标我个人的判断标准是某个Subtask的忙率持续3分钟以上超过其他Subtask两倍以上并且该算子的numRecordsInPerSecond远高于均值那基本就可以确定为数据倾斜不需要再做其他复杂的分析了。2.3 解析上游数据分布确认根因定位到热点算子之后还需要搞清楚“倾倒是怎么形成的”。这一步很多人会跳过但恰恰是关键所在。数据倾斜的根因说白了只有三类Key分布不均匀比如按用户ID分桶1%的大用户贡献了90%的数据量数据膨胀Join时一对多关联某条大Key对应的关联数据特别多计算本身存在集中性比如窗口结束时的集中触发或者全局聚合点确认根因的方法也不复杂在热点算子上游加一个临时Sink把数据按Key做一次count统计10分钟就能看到Top N的Key分布情况。如果Top 10 Key贡献的数据量超过总量的50%那这就是典型的Key倾斜。3. 定位之后怎么办分场景的改造方案3.1 KeyBy重分区核心思想是打散和二次聚合定位到Key倾斜最常见的解决手段就是给Key“加盐”。我没法给你一个“使用什么加盐策略最好”这种一刀切的答案因为加盐方案跟业务语义是强绑定的关键在于你的下游聚合能不能接受“先局部聚合、再全量聚合”的结果。我的常规做法是分两步走第一步局部聚合。给Key加一个随机后缀比如userId变成userId _ random.nextInt(10)把大Key的数据打散到多个子任务上做第一轮聚合。这一步能有效降低单点的处理压力。第二步全量聚合。去掉随机后缀只保留原始Key开一个窗口或者直接做KeyBy聚合把局部聚合的结果再做一次合并。这里要说清楚一个关键问题加盐能解决的是“大Key导致单点压力”的场景但有一个前提——业务上必须接受一定程度的延迟。如果你加了10个盐第一轮聚合意味着有10个并行子任务在同时处理同一个大Key的数据这会引入额外的合并开销和网络传输如果任务本身的时延要求非常苛刻那么加盐方案就不适用。3.2 Join场景倾斜处理思路完全不同很多人在做双流Join时遇到倾斜第一反应也是给Key加盐。但我必须说一句在Join场景里加盐往往会带来严重的正确性问题。因为Join的语义要求同一Key的数据必须同时到达同一个子任务才算精准匹配加盐之后直接相当于把左流和右流拆到了两个不同的子任务上结果就是大量关联不上的数据被丢弃。这种情况下更实用的方案是维表场景优先用广播代替普通Join把维表做成Async I/O的异步查询或者用广播状态加载到每个子任务本地避免数据Shuffle大表和小表Join如果关联的数据量本身差异巨大可以考虑把大表按业务维度裁剪再用广播方式处理数据膨胀场景分析关联字段如果一条A表记录对应了B表的几十万条记录这时候无论怎么并行都没用必须从源头上压缩数据量比如提前在内层做过滤group或在扩容前先做pre-aggregation要说清楚的是不是所有Join场景都能靠Flink层面解决。有些关联膨胀是业务模型本身的问题你就得回到上游SQL、回到数据同步链路去改。这种问题属于“即使并行度拉到512也没救”的情况等到Web UI已经卡得没法看再排查等于是在给死亡任务做临终关怀。3.3 大Key场景的特殊处理拆分算子和局部缓存还有一种倾斜不太容易被定位到因为它不是发生在KeyBy阶段而是发生在状态读写阶段——大Key对应的状态太大导致RocksDB读写都卡在同一个Task上。这个场景在Flink里极其隐蔽因为Web UI上看忙率分布是均匀的但整体吞吐就是上不去。我实战中用过的有效方案是把大Key对应的数据源单独拆出来用一条独立的Flink任务链路去处理和普通Key的任务链路分开跑。比如一个大商户贡献了90%的交易量那就给这个商户单独映射一个分桶把它路由到独立的子任务上配合单独的并行度资源配置。另一个思路是用旁路缓存。把大Key的内容存到Redis里窗口计算时不走状态读写直接从Redis里读取历史数据做合并计算。这个方案适用于场景本身允许数据有秒级延迟的情况好处是绕开了RocksDB状态读写的单点瓶颈。4. 直接从源头优化两阶段聚合改造实战4.1 第一阶段窗口前先做一次分区聚合上一节讲的都是“倾斜已经发生之后怎么治”但更高级的做法是提前做好架构设计在一开始就让倾斜发生的概率降到最低。我做过一个典型的实时大屏任务场景是统计各省份每分钟的订单金额。最初的实现是直接按省份ID做KeyBy结果某个电商大省在晚间高峰期的数据量能占到全平台40%以上那个省份对应的子任务每个月都要宕几次。改造方案就是两阶段聚合第一步先做分区内预聚合即按“省份 随机后缀”的方式打散窗口内部先做一轮计算把结果量从千万级压缩到百级别第二步再按真实省份ID做汇总。代码实现并不算复杂核心逻辑大致是这样// 第一阶段加盐打散局部聚合 DataStreamOrderRecord keyedStream source .keyBy(order - order.getProvinceId() _ ThreadLocalRandom.current().nextInt(10)) .window(TumblingProcessingTimeWindows.of(Time.seconds(10))) .aggregate(new ProvinceAggFunction()); // 第二阶段按真实省份聚合 DataStreamProvinceMetric resultStream keyedStream .keyBy(metric - metric.getProvinceId()) .window(TumblingProcessingTimeWindows.of(Time.seconds(10))) .aggregate(new MergeProvinceAggFunction());两阶段聚合的效果立竿见影同一条链路改造前热点Task的忙率是95%改造后Top Task忙率降到50%左右整条链路的吞吐量直接翻了一倍。不过要提醒的是两个窗口会带来额外的延迟如果业务要求的延迟是秒级以内的这个方案就要再斟酌了。4.2 添加盐的粒度怎么定参考QPS和状态规模加盐粒度的选择是最容易被人忽略的细节。盐加少了热点Task可能还是吃不下盐加多了第二阶段合并的开销又上来了。我个人的经验公式是盐的个数 热点Key的数据量 / 单个子任务可承载的QPS。假设某个大省高峰期的数据量是每秒12万条单个并行子任务稳定处理大概是每秒2万条那么盐的个数取6到8个比较合适。注意这里是“并行度 × 盐个数”对应的整体处理能力要能覆盖峰值并且最好留30%的余量因为Flink的窗口触发、序列化开销都会挤占一部分处理能力。还有一个容易被忽略的点加盐切分的逻辑最好放在最上游的Source端。如果把加盐逻辑放在KeyBy之前等于先做了一次全量Shuffle再打散这样虽然热点子任务被分担了但Shuffle本身可能成为新的瓶颈。4.3 从源头pre-aggregation彻底绕开倾斜算子最近Flink社区里很火的一个话题是把倾斜治理的思路往前移到“源端”而不是“算子端”。比如你用Flink做MySQL同步到ClickHouse其实就可以利用Flink CDC里的shuffle优化策略直接在Source阶段根据表结构提前做一次数据合并然后再往下游分发。SpringBoot整合Flink做实时任务时我也踩过一个类似的坑把Kafka的数据直接接入Flink不加任何预处理结果一个按订单ID分桶的KeyBy算子每天固定倾斜。后来我在接入层加了一个轻量的内存聚合结构把1秒内的相同订单ID数据先合并成一条再进入主链路倾斜问题不治而愈。这个思路其实值得我们反思很多倾斜不是Key分布造成的而是上游数据本身存在冗余。如果每条数据都足够“瘦”就算某个Key的数据量大处理压力也会小很多。所以在设计数据入链路的阶段就做好压缩和预聚合比在链路内部想各种办法去打散更高效。5. Sink端写入的“背压假象”JDBC连接器异常深度排查5.1 Sink背压和数据倾斜的区别先看队列堆积方向在大部分Flink任务里数据倾斜的锅都让上游的KeyBy算子背了但实际上有相当一部分情况真正的瓶颈发生在Sink端。尤其是做MySQL同步到ClickHouse、用JDBC连接器做批量写入的任务Sink的写入能力跟不上就会在上游算子形成反压表现看起来跟数据倾斜一模一样。我排查过的案例里最典型的是这样的情况Web UI显示的瓶颈在Map算子忙率很高但Map算子的逻辑只是做一行格式转换根本不可能成为瓶颈。后来一查Sink端发现是JDBC连接器批量写入超时疯狂报错每一条失败的数据都会重试重试期间阻塞了后面的数据反压一路传到了上游。判断究竟是倾斜还是Sink背压一个很简单的方法看队列堆积方向。倾斜导致的堆积是“某些Subtask输入堆积”而Sink背压导致的堆积是“所有上游Subtask输出堆积”后者的分布是均匀的。如果你看到全体Subtask都在堆积且瓶颈算子的聚合指标没有明显的“高个子”那一定是下游反压别再花时间怀疑倾斜了。5.2 JDBC连接器写不动的三个隐藏原因说到JDBC连接器很多做了很久的工程师都会栽在这里。我梳理一下三个最隐蔽的原因第一个是批量大小配置不当。Flink JDBC Sink默认的批量写入大小是batchSize1000、batchIntervalMs1000如果你的每次写入涉及的数据比较大比如一条记录就有几KB的JSON字段那一次写1000条就会导致网络包过大、数据库锁竞争加剧频繁超时。这种场景调小batchSize反而更高效我一般会先压到100试试效果再逐步往上调。第二个是事务隔离级别冲突。Flink的JDBC Sink在开启setAutoCommit(false)之后如果目标ClickHouse或MySQL本身的隔离级别和连接池配置不匹配会导致写入失败。这类报错有时候是间歇性的网络热词里的“flink的jdbc连接器异常”很大程度上就是这类问题。排查手段是打印连接获取的Detail日志看哪个环节耗时最长。第三个是并发写同一个表时的行锁竞争。如果你的Sink并行度和目标表的写入热点冲突比如多个Subtask同时写同一个范围的主键WAL日志会疯狂等待体现出来就是背压。解决思路是把写入层的并行度适当调低或者落库之前先做一次按目标表主键的排序。5.3 解决Sink反压的落地配置从超时到批次下面给出一套我调优过多次的JDBC Sink参数模板可直接参考参数项推荐值说明sink.buffer-flush.max-rows100-500按单条体积灵活调整大对象字段取小值sink.buffer-flush.interval1s-2s放宽一点可以帮助批量提交合并sink.max-retries5重试次数太多反而加剧背压jdbc.fetch-size500避免单次拉取过大内存溢出connector.write.flush.interval1s适用ClickHouse连接器sink.parallelism实测后调低目标是让每个分片单次写入的数据量稳定重要提示调低Sink并行度听起来违背直觉但很多时候确实有效。因为目标数据库能承受的总事务/秒是有限的并行度太高会导致大量请求同时打过去数据库反而疲于处理冲突和锁等待。一个比较稳的做法是先测目标库当前能承受的写入TPS再反推Flink Sink应该开多少并行度。5.4 MySQL同步到ClickHouse场景的写入倾斜把MySQL的数据实时同步到ClickHouse也是Flink JDBC连接器使用最热的场景之一。我做过一个电商订单同步任务源库的单表数据按订单时间增长如果直接开KeyBy订单ID再写入ClickHouse的Distributed表置换逻辑会经常出问题。这个场景的倾斜往往不在Key算子而在ClickHouse的MergeTree表引擎层。ClickHouse在建表时如果分了3天、7天的分区数据写入会发生写倾斜最新分区的写入量很大而历史分区几乎不写入。这时候Flink Sink再开高并行度只是想当然的配置实际反而会加剧写入冲突。实操建议是ClickHouse表的分区键尽量选择成本更低的维度比如日期或者哈希字段。如果实在要按业务主键做分区那么Sink端要开启“固定字段路由”尽量让同一分区的数据都落到同一个或少数几个子任务上连续写入避免频繁切换分区导致的锁等待和文件碎片。6. 我被问最多的问题列个排查速查表6.1 为什么明明加了盐倾斜还是没缓解先说结论大概率是盐加在了不该加的位置。很多人的实现是keyBy(order - order.getUserId() new Random().nextInt(10))把加盐逻辑写在了KeyBy算子内部这样带来的效果是同一个用户的同一条数据每次进来随机盐都不同下游的窗口聚合就会把数据打散到10个临时窗口里。表面看倾斜没了但第二阶段合并时由于每个临时窗口里都各自维护了一份状态本身就把计算量放大了好几倍。正确的做法是给每个窗口内的Key固定盐而不是每条记录随机盐。典型写法是带时间或窗口ID的确定性加盐keyBy(order - order.getUserId() _ order.getWindowStartTime() % 10)这样才能做到“同一批窗口数据固定在一个子任务上做局部聚合”而不同窗口之间打散到不同子任务。6.2 窗口聚合倾斜和普通KeyBy倾斜有什么不同窗口聚合倾斜指的是在窗口计算结束时所有属于同一个窗口的数据瞬间集中到同一个算子做计算。这种倾斜跟Key分布关系不大而跟窗口的设计关系大。常见于事件时间窗口结束后有大量的Trigger和定时器在同一个瞬间触发。排查此类问题不要盯着Key看要先观察是否有明显的时间周期规律比如每整点、每整分钟固定卡一下。如果确实存在这种规律可以考虑把窗口切割成更小的粒度从1小时切成15分钟或者把每个窗口的任务Schedule错开避免同一时间点所有窗口同时触发大规模计算。6.3 状态很大的Key倾斜如何判断是RocksDB问题RocksDB的状态后端本身是没有并行度概念的它归属于某个具体的Keyed State。所以当一个Key长期占用巨大的状态量比如几GB甚至几十GBRocksDB的找表、Compaction都会卡在这个Key上。判断方法很简单检查Task Manager指标中的rocksdb.cur-size-all-mem-tables。如果一个Task的值远超其他Task且数字持续升高不下降那基本就是大Key状态膨胀导致的单点问题。这个问题靠加盐是救不了命的方法是把状态清理逻辑加好或者调整状态TTL把不常用的历史状态尽早淘汰。7. 聊几点工程落地的经验心得7.1 并行度不是越多越好先定Sink容量再往上推很多团队在做Flink性能调优时第一个动作就是把并行度往大了调仿佛并行度是万能的。但我的经验是并行度是结果不是原因。你要先根据最下游的承载能力比如目标ClickHouse、MySQL、Kafka分片数推断出Sink的合理并行度再逆向推导上游算子的并行度。如果下游根本接不住上游开再多的并行度也只是把压力堆积在反压链路上没有实际意义。举个很简单的例子Kafka某个Topic一共12个分区那Source端的并行度开到12就够了。你开24个并行度多出来的12个分区根本拿不到数据反而多了一堆空闲的Task。同理下游数据库承受能力是5000 TPSFlink全链路能处理5万 TPS那瓶颈就是下游你花再多精力调上游也没用。先把短板找到才能谈优化。7.2 用好Source端的慢启动消费策略Flink在对接Kafka做实时聚合时有可能会遇到一种奇怪的现象任务启动的前10分钟运行正常之后突然积压Lag。这种情况往往是Kafka的分区数据不均衡某个分区的历史数据量特别大而Flink的消费逻辑是全速消费的就导致消费慢的分区成了瓶颈。解决思路是开启Source端的有限制消费比如设置startup-mode配合一个启动期的限速策略让任务在启动阶段先以较低速度消费等State恢复稳定后再逐渐放开。这个槽位配置看起来不起眼但在SpringBoot整合Flink做在线任务的场景里真的能避免很多无谓的“任务重启-重复消费-再倾斜”的恶性循环。7.3 混沌测试给任务注入故障看看它的抗性最后讲一个很多人忽略的环节上线前的“故障注入测试”。我在处理过很多次线上倾斜问题之后形成的一个固定习惯是每次新任务上线前都会特意调一个上游Topic的某几个分区的数据量人为制造出5倍以上的流量差异然后观察任务的表现。如果任务在人为注入的倾斜下还能保持20%以内的忙率波动说明架构的拆解是健康的。如果忙率直接飙到90%那就说明当前的设计还扛不住极端情况。这个做法的价值在于把排查从“事后救火”变成了“事前预防”成本比线上加急处理低太多了。8. 最后说几句实在话做了这么多年的实时计算处理过数不清的倾斜问题我的一个体会是数据倾斜是统计规律不是Bug。只要有分布式、有数据分布就一定会有倾斜。与其花大量时间找一个“彻底消灭倾斜”的银弹不如建立一套完整的定位手段和治理预案把每次倾斜变成一次可复用的经验。这个内容如果你完整读下来了大概率对下面几件事有了一个系统的认知怎么从Web UI和监控指标中精准定位热点算子什么样的倾斜场景适合加盐、什么样的场景不能加盐Sink端反压和上游倾斜怎么区分以及最关键的——在设计任务之初就通过两阶段聚合、分桶策略和容量规划来规避倾斜。我希望你把这些方法拿回自己的业务里去试试过之后你可能会发现那些让你熬夜排查的“疑难杂症”其实在架构层面很早就写下了答案。最后再分享一个小技巧每次碰到倾斜问题先不要急着改代码问自己三个问题——这个倾斜是不是真的发生在计算层上游能不能做预聚合下游Sink能不能接住全量计算的结果把这三个问题想清楚大部分倾斜问题其实已经解决了一半。