3. Flink时间语义与Watermark：迟到数据的处理艺术

时间，是流计算的核心。没有时间，流就是一锅粥。我刚开始接触Flink时，也被这三个时间概念绕得晕头转向。今天咱们就把它们彻底理清楚。

3.1 三种时间语义：你选哪个？

Flink提供了三种时间语义，说白了就是三种不同的“时钟”。

时间语义	定义	典型场景	我踩过的坑
EventTime	事件实际发生的时间，由数据本身携带	交易日志、用户点击、IoT传感器	数据乱序时，必须配合Watermark
IngestionTime	事件进入Flink Source的时间	对时间精度要求不高的场景	其实很少用，EventTime更灵活
ProcessingTime	算子处理当前事件时的系统时间	实时监控、简单聚合	结果不稳定，重跑数据结果不同

3.2 Watermark原理：流里的“水位线”

Watermark是什么？说白了就是一个“时间戳断言”。它告诉Flink：“到目前为止，所有时间戳小于等于这个值的事件，我都已经收到了。不会再有了。”

但现实是残酷的——数据总会迟到。网络延迟、背压、机器故障，都会导致数据乱序。Watermark就是用来处理这个问题的。

3.2.1 Watermark的生成策略

Flink提供了两种内置策略，我个人更常用第二种。

• 周期性生成（Periodic）：每隔N毫秒生成一次Watermark。适合数据量大的场景。
• 断点式生成（Punctuated）：每来一条数据就判断是否生成。适合对延迟敏感的场景。

来看一段我项目里用过的代码：

DataStream<SensorReading> stream = env
  .addSource(new SensorSource())
  .assignTimestampsAndWatermarks(
    WatermarkStrategy.<SensorReading>forBoundedOutOfOrderness(Duration.ofSeconds(5))
      .withTimestampAssigner((event, timestamp) -> event.getTimestamp())
  );

这里设置了5秒的乱序容忍度。为什么是5秒？我在实际项目中调过很多次，3秒太紧，10秒又太慢。5秒是个不错的起点，具体要根据你的网络状况来调。

3.3 Allowed Lateness：给迟到数据一个机会

Watermark触发窗口计算后，迟到的数据怎么办？直接丢弃？太浪费了。Flink提供了allowedLateness机制。

它的逻辑是：窗口计算完成后，再等一段时间。这段时间内来的迟到数据，会触发窗口的再次计算。

我曾经在一个电商大屏项目里用过这个特性。用户下单后，支付数据可能晚到几分钟。我设置了allowedLateness(1.minutes)，配合侧输出流，既保证了实时性，又没丢数据。

DataStream<OrderEvent> lateStream = stream
  .keyBy(order -> order.getUserId())
  .window(TumblingEventTimeWindows.of(Time.minutes(5)))
  .allowedLateness(Time.minutes(1))
  .sideOutputLateData(lateOutputTag)
  .process(new OrderProcessFunction());

3.4 Side Output：迟到数据的“收容所”

即使有了allowedLateness，还是会有数据迟到。这时候，侧输出流（Side Output）就是最后的兜底方案。

侧输出流就像一个“迟到数据收容所”。所有超过allowedLateness的数据，都会被发送到这里。你可以单独处理它们，比如写入日志、发送告警，或者存到数据库里后续补算。

3.5 完整流程图：时间语义与Watermark协作

下面这张图，是我自己总结的。它把EventTime、Watermark、窗口、迟到数据的关系画清楚了。

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

1. Watermark不推进：有一次我发现窗口一直不触发，查了半天，原来是Source里没有数据了。Watermark需要数据来推进，没数据它就卡在那。解决方案是设置withIdleness，让空闲分区自动推进Watermark。
2. allowedLateness设得太小：默认是0，意味着迟到数据直接进侧输出流。我建议至少设30秒，给网络抖动留点余地。
3. 侧输出流没人消费：侧输出流的数据如果不处理，会一直积压在内存里。我习惯在侧输出流后面接一个Sink，把迟到数据写到Kafka或HDFS，方便后续补算。