4. Flink 时间语义与 Watermark：EventTime、ProcessingTime、IngestionTime 区别，Watermark 生成策略与原理

在实时特征服务中，时间是数据处理的灵魂。Flink 提供了三种时间语义，分别对应不同的业务场景和延迟容忍度。理解它们的区别以及 Watermark 的生成机制，是构建正确、低延迟特征 pipeline 的前提。

4.1 三种时间语义对比

Flink 支持以下三种时间概念，用于决定何时触发窗口计算、如何对齐事件顺序。

4.2 EventTime 与 Watermark 的核心原理

EventTime 虽然准确，但数据在传输过程中可能发生乱序（例如网络延迟、重试）。Watermark 是 Flink 用来衡量 EventTime 进度的一种机制，它表示“当前时间之前的数据已经全部到达”。

• Watermark = 观察到的最大 EventTime – 允许的最大乱序时间
• 当 Watermark 超过窗口的结束时间时，触发该窗口的计算。
• Watermark 是单调递增的，不会回退。

4.3 Watermark 生成策略

Flink 提供了两种内置的 Watermark 生成方式，开发者也可以自定义策略。在特征服务中，通常使用 周期性生成 或 按特定标记生成。

4.3.1 周期性 Watermark（Periodic）

• 每隔 N 毫秒（默认 200ms）生成一次 Watermark。
• 适用于数据流相对均匀、乱序程度可控的场景。
• 需要实现 WatermarkGenerator 接口中的 onEvent() 和 onPeriodicEmit() 方法。

4.3.2 标记性 Watermark（Punctuated）

• 每当遇到某个特殊事件（如 ID 为 -1 的结束标记）时立即生成 Watermark。
• 适用于数据流中存在明确的分隔符或批次边界。
• 在特征服务中较少使用，因为特征流通常是连续无界的。

4.3.3 内置策略：BoundedOutOfOrderness

这是特征服务中最常用的策略。它假设数据最多乱序 maxOutOfOrderness 时间，并据此生成 Watermark。

// 允许最大乱序 5 秒
DataStream<Event> stream = env
    .addSource(kafkaSource)
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner((event, timestamp) -> event.getEventTime())
    );

4.4 迟到数据处理机制

即使设置了 Watermark，仍可能有数据在 Watermark 之后到达。Flink 提供了三种处理方式：

4.5 特征服务中的最佳实践

• 统一使用 EventTime： 所有特征计算任务都应基于 EventTime，避免因机器时钟不同步导致特征不一致。
• 合理设置乱序容忍度： 根据上游 Kafka 的延迟分布（如 P99 延迟）设定 maxOutOfOrderness，通常设置为 5~30 秒。
• 监控 Watermark 延迟： 通过 Flink Web UI 或 Metrics 观察 currentWatermark 与当前时间的差值，判断数据是否积压。
• 避免使用 IngestionTime： 在特征服务中，IngestionTime 无法保证与业务时间对齐，容易导致特征漂移。