水位线与窗口：水位线如何触发窗口计算、迟到数据如何处理

好，咱们接着聊。前面我们把事件时间、水位线、窗口这三个概念拆开讲了，现在该把它们串起来了。说白了，这一章要解决两个核心问题：水位线到底怎么触发窗口计算？迟到的数据来了怎么办？

我在项目中见过不少同学，窗口算子的代码写得很溜，但一问到「窗口什么时候触发计算」，就支支吾吾了。嗯，这其实是个很关键的细节，搞不清楚的话，线上出问题你都不知道怎么排查。

水位线触发窗口计算的底层逻辑

先想一个问题：Flink 怎么知道某个窗口的数据都到齐了？

答案是——它不知道。分布式环境下，你永远无法保证所有数据都准时到达。所以 Flink 用了一个聪明的办法：用水位线来「猜测」数据是否到齐。

具体规则是这样的：

• 每个窗口都有一个结束时间，比如 [10:00, 10:10) 这个窗口，结束时间是 10:10:00
• 当水位线 大于等于 窗口的结束时间时，这个窗口就会被触发计算
• 举个例子：水位线到达 10:10:00，那么 [10:00, 10:10) 窗口就开始计算了

你想想看，这个设计其实很巧妙。水位线代表「我认为在这个时间之前的数据都已经到了」，所以当水位线越过窗口边界时，Flink 就认为这个窗口的数据收齐了，可以开始算了。

我个人习惯把水位线想象成一把「剪刀」。它一路往前剪，每剪到一个窗口的边界，就把那个窗口「剪下来」送去计算。嗯，这个比喻虽然不太严谨，但好理解。

一个完整的触发示例

咱们看个具体例子。假设窗口大小是 5 秒，水位线延迟是 2 秒：

时间点	事件时间	水位线	触发的窗口
T1	10:01	09:59	无
T2	10:03	10:01	无
T3	10:07	10:05	[10:00, 10:05)
T4	10:12	10:10	[10:05, 10:10)

看到了吗？在 T3 时刻，水位线到达 10:05，正好等于 [10:00, 10:05) 窗口的结束时间，所以这个窗口被触发了。T4 时刻同理。

迟到数据：Flink 的三种处理策略

现实总是很骨感。不管你水位线设得多大，总会有数据迟到。我在做电商实时大屏的时候就遇到过，用户下单后网络延迟，数据过了 10 分钟才到。那这些迟到的数据怎么处理？

Flink 给了我们三种选择：

1. 默认行为：直接丢弃

如果你什么都不配，迟到数据来了就直接扔掉。这是最省事的做法，但也是最危险的。我曾经在一个日志分析任务中用了默认配置，结果发现数据对不上，排查了半天才发现是迟到数据被丢了。

2. 允许迟到：allowedLateness

这个参数的意思是：窗口触发计算后，再等一会儿。在这段时间内来的迟到数据，还能被窗口接收，并触发再次计算。

DataStream<Event> stream = env
    .addSource(kafkaSource)
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner((event, timestamp) -> event.getTimestamp())
    )
    .keyBy(Event::getUserId)
    .window(TumblingEventTimeWindows.of(Time.seconds(10)))
    .allowedLateness(Time.seconds(3))  // 允许迟到 3 秒
    .process(new MyProcessWindowFunction());

这段代码的意思是：窗口正常触发后，再等 3 秒。这 3 秒内来的迟到数据，会触发窗口的增量计算。注意，是增量计算，不是从头算起。Flink 会保留窗口的中间状态，新数据来了直接合并进去。

我个人习惯把 allowedLateness 设成水位线延迟的 1.5 到 2 倍。比如水位线延迟 5 秒，我就设 8 秒。这样既能处理大部分迟到数据，又不会让状态膨胀得太厉害。

3. 侧输出：sideOutputLateData

有些数据实在太晚了，allowedLateness 也救不了它。这时候可以用侧输出，把迟到数据单独收集起来，后续再处理。

OutputTag<Event> lateOutputTag = new OutputTag<Event>("late-data") {};

SingleOutputStreamOperator<Event> result = stream
    .keyBy(Event::getUserId)
    .window(TumblingEventTimeWindows.of(Time.seconds(10)))
    .allowedLateness(Time.seconds(3))
    .sideOutputLateData(lateOutputTag)  // 超迟到数据进侧输出
    .process(new MyProcessWindowFunction());

// 获取迟到数据
DataStream<Event> lateStream = result.getSideOutput(lateOutputTag);
lateStream.addSink(new LateDataSink());

侧输出的好处是：数据不会丢，你可以单独处理。比如写到一个专门的 Kafka Topic 里，或者存到 HDFS 做离线分析。

三种策略的对比

策略	适用场景	优点	缺点
直接丢弃	对数据完整性要求不高	简单、性能好	数据丢失
allowedLateness	大部分迟到数据可接受	数据完整、实时性好	占用状态、延迟结果
侧输出	需要兜底处理	数据不丢、灵活	需要额外处理逻辑

一张图看懂整体流程

说了这么多，咱们用一张图把水位线、窗口、迟到数据的关系串起来：

这张图展示的是水位线到达 10:10 时的状态。可以看到：

• [10:05, 10:10) 窗口被触发计算
• 一个事件时间为 10:08 的数据迟到了，它会被 allowedLateness 处理，或者进入侧输出
• 水位线还在继续前进，准备触发下一个窗口

避坑指南：我踩过的三个坑

最后，分享几个我在实战中踩过的坑，希望能帮你少走弯路：

1. 水位线设得太小：我曾经把水位线延迟设成 1 秒，结果线上数据延迟普遍在 3-5 秒，导致窗口频繁被提前触发，结果一塌糊涂。后来我改成根据业务峰值延迟来设，才稳定下来。
2. allowedLateness 设得太大：有一次我设了 10 分钟的 allowedLateness，结果窗口状态一直不释放，内存直接爆了。记住，allowedLateness 越大，状态保留时间越长，内存压力越大。
3. 忘了处理侧输出：侧输出的数据如果不处理，就会一直积压在 Flink 的内部队列里，最终导致背压。我建议侧输出一定要配一个独立的 Sink，哪怕只是打印日志也好。

好了，水位线和窗口的配合就讲到这里。记住一句话：水位线是窗口的触发器，allowedLateness 是窗口的宽容度，侧输出是最后的保险。把这三点搞明白，事件时间处理你就掌握了七八成。