📚 课程目录第4章 Flink时间语义

4. Flink 时间语义：Event Time、Processing Time、Ingestion Time、Watermark 机制

时间，是流计算的核心。你想想看，没有时间维度，数据流就是一锅粥。Flink 提供了三种时间语义，很多人刚接触时容易混淆。我刚开始带团队做实时项目时，也在这上面栽过跟头。

今天咱们就把时间语义和 Watermark 彻底讲透。这部分内容，是 Flink 实时数据交换体系的基石。

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

Flink 定义了三种时间概念。说白了，就是数据从产生到被处理的三个时间戳。

时间语义	定义	典型场景
Event Time	事件实际发生的时间，由数据源携带	日志分析、交易统计、IoT 传感器
Processing Time	数据到达 Flink 算子的本地机器时间	实时监控、简单聚合、性能测试
Ingestion Time	数据进入 Flink Source 的时间	介于两者之间，自动分配时间戳

核心原则：如果你的业务对数据顺序敏感，或者数据可能延迟到达，请务必使用 Event Time。Processing Time 只适合对结果精度要求不高的场景。

我个人习惯，在生产环境中 90% 的场景都用 Event Time。为什么？因为数据乱序和延迟是常态。Processing Time 虽然简单，但结果不可复现。你想想看，同一个数据流跑两次，结果不一样，这谁能接受？

4.1.1 Event Time：最真实的时间

Event Time 是数据自带的属性。比如用户点击网页的时间、传感器采集数据的时间。Flink 需要从数据中提取这个时间戳。

// 设置 Event Time 语义
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);

// 提取时间戳和生成 Watermark
DataStream<MyEvent> stream = env
    .addSource(new FlinkKafkaConsumer011<>(...))
    .assignTimestampsAndWatermarks(
        new BoundedOutOfOrdernessTimestampExtractor<MyEvent>(Time.seconds(5)) {
            @Override
            public long extractTimestamp(MyEvent element) {
                return element.getEventTime();
            }
        }
    );

嗯，这里要注意。时间戳必须是毫秒级的 long 类型。我见过有人传了秒级的时间戳，结果窗口永远不触发。排查了半天才发现是单位搞错了。

4.1.2 Processing Time：最简单，但最不靠谱

Processing Time 就是当前机器的系统时间。Flink 默认就是这种语义。好处是快，不需要等待乱序数据。坏处是结果不确定。

我记得有一次做压测，用 Processing Time 统计 QPS。结果每次跑出来的数据都不一样。后来换成 Event Time，结果就稳定了。所以，不要在生产环境的核心业务上用 Processing Time。

4.1.3 Ingestion Time：折中方案

Ingestion Time 是数据进入 Flink 时自动分配的时间。它介于 Event Time 和 Processing Time 之间。Flink 会自动为每条数据分配时间戳，并生成 Watermark。

这个语义用得不多。我个人觉得它有点鸡肋。既然数据本身有时间，为什么不直接用 Event Time？如果数据没有时间，那 Ingestion Time 和 Processing Time 也没太大区别。

4.2 Watermark 机制：解决乱序问题的关键

乱序数据，是实时计算的噩梦。比如，一个传感器先发了 10:00:05 的数据，后发了 10:00:03 的数据。如果你按 Event Time 做窗口统计，10:00:00-10:00:05 这个窗口什么时候才能关闭？

Watermark 就是用来解决这个问题的。它像一个「截止时间戳」，告诉 Flink：在这个时间戳之前的数据，应该都到了。如果没到，那就当它丢了。

我的理解：Watermark 不是数据，而是一个全局的进度标记。它表示「当前 Event Time 的进度到了哪里」。

4.2.1 Watermark 的工作原理

Watermark 的公式很简单：Watermark = 当前最大 Event Time - 允许的最大延迟时间。

举个例子。你设置最大延迟为 5 秒。当前处理到的最大的 Event Time 是 10:00:10。那么 Watermark 就是 10:00:05。这意味着，所有 Event Time 小于等于 10:00:05 的数据，都应该到了。Flink 可以放心地关闭 [10:00:00, 10:00:05) 这个窗口。

// 自定义 Watermark 生成器
DataStream<MyEvent> stream = env
    .addSource(...)
    .assignTimestampsAndWatermarks(
        new AssignerWithPeriodicWatermarks<MyEvent>() {
            private long currentMaxTimestamp = 0L;
            private final long maxOutOfOrderness = 5000L; // 5秒

            @Override
            public long extractTimestamp(MyEvent element, long previousElementTimestamp) {
                long timestamp = element.getEventTime();
                currentMaxTimestamp = Math.max(timestamp, currentMaxTimestamp);
                return timestamp;
            }

            @Override
            public Watermark getCurrentWatermark() {
                return new Watermark(currentMaxTimestamp - maxOutOfOrderness);
            }
        }
    );

避坑指南：我曾经遇到过一个坑。Watermark 生成器默认是周期性调用的，默认周期是 200 毫秒。如果你的数据流很稀疏，200 毫秒内没有新数据，Watermark 就不会更新。这会导致窗口迟迟不触发。解决方案是：要么降低周期，要么使用 Punctuated Watermark（每条数据都更新）。

4.2.2 两种 Watermark 生成方式

生成方式	特点	适用场景
Periodic	周期性生成，默认 200ms	数据量较大，对延迟不敏感
Punctuated	每条数据都可能触发生成	数据量小，或需要精确控制

我个人更推荐用 Periodic。Punctuated 虽然精确，但性能开销大。除非你的业务对延迟要求极高，否则没必要。

4.3 时间语义与 Watermark 的协同工作

下面这张图，展示了 Event Time、Watermark 和窗口之间的关系。我画了很多次，每次讲课时都会拿出来。

你看这张图。数据 A、B、C、D 是按顺序到达的。但数据 E 是乱序的，它的事件时间是 10:00:03，却比数据 C 还晚到。Watermark 一直在推进。当 Watermark 达到 10:00:10 时，窗口 [10:00:00, 10:00:05) 就会被触发计算。数据 E 虽然晚到了，但只要在 Watermark 之前，它还能被包含在窗口内。

4.4 如何处理迟到数据？

即使有 Watermark，也不能保证所有数据都能准时到达。总有一些数据会迟到。Flink 提供了三种处理方式：

丢弃：默认行为，迟到数据直接被忽略。
侧输出：将迟到数据发送到侧输出流，单独处理。
允许延迟：设置 allowedLateness，窗口会等待一段时间再关闭。

// 侧输出迟到数据
OutputTag<MyEvent> lateOutputTag = new OutputTag<MyEvent>("late-data") {};

DataStream<MyEvent> mainStream = stream
    .keyBy(...)
    .window(TumblingEventTimeWindows.of(Time.seconds(10)))
    .sideOutputLateData(lateOutputTag)
    .process(...);

DataStream<MyEvent> lateStream = mainStream.getSideOutput(lateOutputTag);
lateStream.print(); // 单独处理迟到数据

我的建议：不要轻易丢弃迟到数据。用侧输出把它们收集起来，做补偿计算或者日志记录。我曾经在一个金融项目中，就是靠侧输出发现了数据源的时钟偏移问题。

4.5 时间语义的选择策略

最后，我总结一下我的选择策略。你可以直接拿来用：

数据自带时间戳，且对准确性要求高 → 用 Event Time + Watermark。这是最通用的方案。
数据没有时间戳，或者对准确性不敏感 → 用 Processing Time。比如实时大屏的粗略统计。
数据没有时间戳，但希望按到达时间排序 → 用 Ingestion Time。不过我个人很少用。

嗯，时间语义和 Watermark 就讲到这里。这部分内容，是 Flink 实时数据交换体系的核心。你理解了它，后面的窗口计算、状态管理、容错机制，都会变得顺理成章。