4. Flink 时间语义与水位线：Event Time、Processing Time、Ingestion Time，Watermark 机制与乱序处理

做实时特征工程，绕不开一个核心问题：时间。

你想想看，特征天然带有时间属性。用户昨天点击了广告，今天才下单。这个“昨天”和“今天”怎么定义？是事件发生的时间，还是数据到达服务器的时间？

我刚开始做实时计算时，就踩过这个坑。当时用 Processing Time 做窗口聚合，结果数据一乱序，特征全对不上。后来才明白，时间语义选不对，特征工程就是空中楼阁。

4.1 三种时间语义：选对时钟，才能算对特征

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

时间语义	定义	典型场景	我个人的建议
Event Time	事件实际发生的时间，由业务系统在数据中携带	用户点击、交易下单、IoT 传感器读数	特征工程首选，能还原真实业务时序
Processing Time	数据到达 Flink 算子时的机器时间	实时监控、简单聚合、对延迟不敏感的场景	性能最好，但结果不稳定，慎用于特征
Ingestion Time	数据进入 Flink Source 的时间	介于 Event Time 和 Processing Time 之间	我很少用，除非上游数据没有时间戳

举个例子。用户凌晨 1 点下了单，系统凌晨 3 点才处理。如果用 Processing Time 做“最近 1 小时下单次数”的特征，这个特征会算到凌晨 3 点，完全错了。Event Time 才能正确归到凌晨 1 点。

4.2 Watermark 机制：给乱序数据一个“截止时间”

用 Event Time 有个麻烦：数据会乱序。

网络延迟、背压、重试，都会导致早发生的事件晚到。比如 10:00 的事件，可能 10:05 才到。窗口怎么关？

Flink 的答案是：Watermark。

Watermark 是什么？我习惯把它理解成“时间截止线”。

Watermark = 当前观察到的最大的 Event Time - 允许的最大乱序时间。

当 Watermark 流过某个窗口的结束时间时，Flink 就认为这个窗口的数据到齐了，可以触发计算。

4.2.1 Watermark 的两种生成方式

Flink 提供了两种 Watermark 生成策略。我直接给你代码，你拿去就能用。

方式一：周期性 Watermark（推荐）

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

这个策略每 N 毫秒生成一次 Watermark。我一般设 5 秒的乱序容忍，适合大部分在线特征场景。

方式二：标记式 Watermark（特殊场景）

DataStream<Event> stream = env
    .addSource(kafkaSource)
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<Event>forGenerator(ctx -> new MyPunctuatedWatermarkGenerator())
            .withTimestampAssigner((event, timestamp) -> event.getEventTime())
    );

这个策略每条数据都可能触发 Watermark 更新。我只有在数据流中有“心跳”或“对齐信号”时才用，比如金融交易中的结算标记。

4.3 乱序处理：迟到数据怎么办？

Watermark 只能“推测”数据到齐了，不能保证。总会有数据迟到。

Flink 给了三种处理方式。嗯，这里要注意，选错了特征就丢了。

策略	行为	适用场景	我踩过的坑
默认丢弃	Watermark 之后的数据直接扔掉	对时效性要求极高，允许少量特征丢失	曾经丢过 3% 的特征，模型 AUC 掉了 0.02
Allowed Lateness	窗口再等一段时间，迟到数据来了就重新触发计算	大部分特征工程场景，推荐使用	设了 1 分钟，效果很好，但要注意输出重复
Side Output	把迟到数据打到侧输出流，单独处理	需要补偿逻辑，比如更新数据库中的特征值	适合做“特征修正”，但会增加系统复杂度

4.3.1 实战代码：Allowed Lateness + Side Output

这是我做用户实时画像特征时的标准写法。你直接抄。

// 定义侧输出 Tag
OutputTag<Event> lateTag = new OutputTag<Event>("late-data") {};

// 主流程
SingleOutputStreamOperator<Feature> featureStream = stream
    .keyBy(event -> event.getUserId())
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .allowedLateness(Time.seconds(30))  // 等 30 秒
    .sideOutputLateData(lateTag)        // 超 30 秒的走侧输出
    .process(new FeatureAggregateFunction());

// 处理迟到数据
DataStream<Event> lateStream = featureStream.getSideOutput(lateTag);
lateStream.map(event -> {
    // 补偿逻辑：更新特征存储中的历史值
    featureStore.update(event.getUserId(), event.getFeature());
    return event;
});

这段代码做了三件事：

• 5 分钟的滚动窗口，计算用户特征
• 允许 30 秒的迟到数据，重新触发窗口
• 超过 30 秒的，走侧输出流，单独做补偿更新

4.4 知识体系总览：一张图看懂时间语义与水位线

下面这张图，是我做培训时必画的。它把整个章节的核心逻辑串起来了。

4.5 总结：我的三条实战铁律

做了这么多年实时特征，我总结了三句话。你记住就行。

1. 时间语义选 Event Time，除非你不在乎特征准确性。
2. Watermark 设 5-30 秒，太短丢数据，太长特征延迟高。
3. 迟到数据用 Allowed Lateness + Side Output，既保证时效性，又留了补偿通道。