📚 课程目录第4章事件时间与处理时间

4. 事件时间与处理时间：水位线（Watermark）机制、乱序数据处理策略

做实时特征，最头疼的问题是什么？

我个人觉得，就是「时间」本身。你想想看，数据从业务发生到进入 Flink，中间要经过网络、消息队列、各种中间件。有的数据快，有的数据慢。如果你按数据到达的时间去算特征，那结果肯定不对——因为业务关心的是「事件发生的时间」，不是你系统收到的时间。

这就是事件时间和处理时间的核心矛盾。今天我们就来彻底聊透它。

4.1 事件时间 vs 处理时间：到底差在哪？

先看一个最简单的例子。用户下单，时间是 10:00:00。但这条消息因为网络抖动，10:00:03 才到 Flink。如果你用处理时间，那特征就打在 10:00:03 上。但业务窗口是 10:00:00 到 10:00:01 的。结果就是——这个事件被归到了错误的窗口，特征算出来也是错的。

说白了，事件时间才是业务真正关心的「时间戳」。处理时间只是系统当前的时间，它不可靠。

维度	事件时间	处理时间
定义	数据产生时的时间戳	数据到达算子时的时间
确定性	固定不变，但可能乱序	每次运行都可能不同
适用场景	需要精确统计、特征回溯	对时间不敏感、追求低延迟
乱序影响	需要水位线处理	天然有序，但结果不准

我在项目中遇到过很多次，业务方说「我要看用户过去 5 分钟的行为特征」。如果你用处理时间，那每次重跑结果都不一样。但用事件时间，只要数据源不变，结果就是确定的。这就是为什么实时特征生产，几乎都选事件时间。

4.2 水位线（Watermark）：乱序世界的「时钟」

事件时间好是好，但有个大问题：数据会乱序。比如 10:00:01 的数据，可能比 10:00:00 的数据还晚到。那窗口怎么关？什么时候触发计算？

这就是水位线的用武之地。

水位线，你可以把它理解成一个「声明」：到目前为止，所有时间戳小于等于这个值的事件，我都已经收到了。再来的，就是迟到数据。

嗯，这里要注意。水位线不是真实时间，它是你根据数据特征估算出来的一个「进度标记」。它告诉 Flink：可以触发窗口计算了。

核心公式：

Watermark = 当前观察到的事件时间 - 最大乱序容忍时间

比如你设置最大乱序为 5 秒，当前收到的事件时间最大是 10:00:10，那水位线就是 10:00:05。

为什么会这样？因为你要给迟到的数据留一个「缓冲期」。如果水位线设得太紧，很多正常数据会被当成迟到数据丢掉。设得太松，窗口迟迟不触发，延迟就高了。

4.3 乱序数据处理策略：三种常见方案

光有水位线还不够。数据真的迟到了怎么办？我总结了三种策略，你在项目中大概率都会用到。

4.3.1 策略一：允许迟到 + 侧输出流

这是最灵活的方式。窗口触发后，迟到的数据不会丢，而是被发送到侧输出流。你可以单独处理它们。

DataStream<Event> stream = env
  .addSource(kafkaSource)
  .assignTimestampsAndWatermarks(
    WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
      .withTimestampAssigner((event, timestamp) -> event.getEventTime())
  );

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

SingleOutputStreamOperator<Feature> result = stream
  .keyBy(Event::getUserId)
  .window(TumblingEventTimeWindows.of(Time.minutes(1)))
  .sideOutputLateData(lateTag)
  .process(new FeatureProcessFunction());

// 单独处理迟到数据
DataStream<Event> lateStream = result.getSideOutput(lateTag);
lateStream.addSink(new LateDataSink());

我曾经在一个风控项目里用过这个方案。当时业务要求「宁可多算，不能漏算」。侧输出流帮了大忙——迟到的数据我们单独存到一张 HBase 表里，每天凌晨再补算一次特征。

4.3.2 策略二：allowedLateness + 延迟触发

如果你不想用侧输出流，也可以让窗口「等一等」。Flink 提供了 allowedLateness 参数，窗口触发后不会立即销毁，而是再等一段时间。

stream
  .keyBy(Event::getUserId)
  .window(TumblingEventTimeWindows.of(Time.minutes(1)))
  .allowedLateness(Time.seconds(10))
  .process(new FeatureProcessFunction());

注意：allowedLateness 只对已经触发过的窗口有效。如果数据迟到太多，超过了 allowedLateness，它还是会被丢弃。

避坑指南：

我曾经在一个大促场景里，把 allowedLateness 设成了 5 分钟。结果窗口一直不销毁，状态越积越多，最后 OOM 了。后来我改成 10 秒 + 侧输出流，问题才解决。所以，allowedLateness 不要设太大，尤其是高并发场景。

4.3.3 策略三：直接丢弃

有些场景对延迟极度敏感，比如实时推荐。迟到的数据对推荐结果已经没有意义了。这时候直接丢弃是最简单的。

WatermarkStrategy
  .<Event>forBoundedOutOfOrderness(Duration.ofSeconds(2))
  .withTimestampAssigner(...)
  // 不设置侧输出流，迟到数据自动丢弃

嗯，这个方案我一般只在「延迟优先于准确」的场景用。比如实时大屏，数据晚到 5 秒，用户已经看到上一屏了，再更新也没意义。

4.4 水位线生成策略：三种主流方式

水位线怎么生成？Flink 提供了三种方式，我按推荐程度排个序。

策略	说明	适用场景
forBoundedOutOfOrderness	固定最大乱序时间	大部分场景，简单可靠
forMonotonousTimestamps	假设数据严格递增	数据源本身有序（如某些日志）
自定义 WatermarkGenerator	根据业务逻辑动态生成	复杂场景，比如根据用户等级调整乱序容忍

我个人习惯，90% 的场景用 forBoundedOutOfOrderness 就够了。设一个合理的乱序容忍时间，比如 5 秒或 10 秒。剩下的 10%，比如数据源本身就有序，用 forMonotonousTimestamps 性能更好。

小技巧：

如果你不确定乱序程度，可以先跑一个离线分析。统计一下数据到达延迟的 P99 是多少。然后把这个值作为乱序容忍时间。我一般设成 P99 的 1.5 倍，既不会丢太多数据，也不会延迟太高。

4.5 知识体系总览

下面这张图，把事件时间、处理时间、水位线、乱序策略的关系串起来了。你可以把它当成一个「决策地图」。

4.6 实战中的几个关键决策点

最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路。

水位线设多大？ 先跑数据看延迟分布。我一般设 P99 延迟的 1.5 倍。如果业务对延迟敏感，可以缩到 P95。
侧输出流还是 allowedLateness？ 如果迟到数据需要单独处理（比如补算、告警），用侧输出流。如果只是想让窗口多等一会儿，用 allowedLateness。但别设太大。
多并行度下的水位线：Flink 会取所有分片水位线的最小值。如果一个分片没数据，水位线就不动。这时候要用 idle source 机制，避免整个 job 卡住。

我曾经踩过的坑：

有一次，Kafka 的一个分区挂了，数据一直没来。结果整个 Flink 作业的水位线卡住了，所有窗口都不触发。后来我加了 withIdleness(Duration.ofSeconds(10))，10 秒没数据就标记为 idle，问题才解决。这个配置，建议你默认加上。

好了，事件时间和水位线的内容就聊到这里。记住一句话：没有完美的方案，只有最适合你业务的方案。 理解了水位线的本质，你就能在准确性和延迟之间找到那个平衡点。