流式聚合不慢才怪？窗口、触发器和内存这三板斧你真用对了吗

做流处理这些年，我发现一个特别有意思的现象：
👉大家都在写聚合，真正把“聚合性能”当回事的人并不多。

很多同学一上来就是：

keyBy
window
sum / reduce
跑起来能出数
线上一慢：加机器

直到有一天老板问一句：

“你这作业，为啥 1 分钟窗口，内存能涨到 20G？”

这时候，才意识到——
流式聚合这件事，真不是“会写 API 就行”。

今天我就从一个老流批（是的我自己 😂）的视角，聊聊：

流式聚合怎么做，才不至于把窗口、触发器和内存一起玩炸。

一、先说句大实话：90% 的流式 OOM，死在窗口上

我们先把一个误区说清楚：

窗口 ≠ 时间范围这么简单

窗口背后是状态（State），而状态 = 内存 / RocksDB / Checkpoint 成本。

1️⃣ 最常见的“作死写法”

stream.keyBy(Order::getUserId).timeWindow(Time.minutes(10)).sum("amount");

看着很干净，对吧？
但你想过三个问题没有：

10 分钟内有多少 key？
每个 key 状态多久才能被清？
下游真的需要 10 分钟后的最终结果吗？

很多业务其实只是假装需要大窗口。

二、窗口不是越大越高级，而是越大越危险

我常说一句话（很多人不爱听）：

窗口越大，说明你对业务越不自信。

举个真实的例子

风控同学说：

“我们要统计用户 30 分钟内的下单金额”

我一般会追问一句：

“你是要最终值，还是过程趋势？”

十有八九，答案是：

“其实 1 分钟一次也行，只要别太晚。”

这时候，大窗口 + 默认触发，就是浪费资源。

三、Trigger：真正被严重低估的性能武器

很多人写 Flink，一辈子没写过 Trigger。

但我想说：
👉Trigger 才是流式聚合的“节流阀”。

1️⃣ 默认 Trigger 的问题

只在窗口结束时触发
状态一直攒着
对内存极不友好

2️⃣ 自定义触发器，边算边吐

.window(TumblingEventTimeWindows.of(Time.minutes(10))).trigger(ContinuousEventTimeTrigger.of(Time.minutes(1))).reduce(newReduceFunction<Order>(){@OverridepublicOrderreduce(Ordero1,Ordero2){o1.setAmount(o1.getAmount()+o2.getAmount());returno1;}});

这段代码背后的思路很重要：

窗口 10 分钟（业务口径）
每 1 分钟就输出一次中间结果
状态不会无限膨胀
下游能提前看到趋势

窗口是口径，触发器是节奏。

很多人把这俩混成一个东西，结果性能就开始玄学了。

四、允许迟到 ≠ 无限留后门

再聊一个特别容易被滥用的东西：allowedLateness

.allowedLateness(Time.minutes(5))

这玩意本意是兜底迟到数据，
结果被不少人当成：

“数据乱就多给点时间”

真相是：

allowedLateness = 窗口状态延寿
延得越久，State 清得越慢
RocksDB 越来越大
Checkpoint 越来越慢

我的个人建议（很主观，但很实用）：

迟到数据，不要全靠窗口兜。

可以考虑：

主流：严格窗口
迟到：侧输出流补偿
或异步修正下游结果

OutputTag<Order>lateTag=newOutputTag<>("late-data");.window(...).allowedLateness(Time.minutes(1)).sideOutputLateData(lateTag);

窗口是算账的，不是擦屁股的。

五、State TTL：别指望系统帮你记一辈子

这是我见过最容易被忽略，却最救命的配置之一。

StateTtlConfigttlConfig=StateTtlConfig.newBuilder(Time.hours(1)).setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite).cleanupFullSnapshot().build();