迟到数据处理：Watermark之后来的数据怎么办

Watermark到10:05 → 窗口[10:00,10:05)触发并输出
                 → 一条10:03的数据到达 → 迟到了！

// 允许5秒乱序 → Watermark = maxEventTime - 5s
WatermarkStrategy.forBoundedOutOfOrderness(Duration.ofSeconds(5))

// 数据到达顺序：10:03, 10:06, 10:04, 10:07
// maxEventTime推进：10:03, 10:06, 10:06, 10:07
// Watermark推进：     9:58, 10:01, 10:01, 10:02
// 10:04虽然晚到，但Watermark还没到10:05，所以不算迟到

stream.keyBy(...)
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .allowedLateness(Time.minutes(1))  // 窗口触发后再等1分钟
    .sum("amount");

// 窗口[10:00, 10:05)在Watermark=10:05时触发第一次计算
// 之后1分钟内如果还有迟到数据到达 → 重新触发计算、更新结果
// Watermark=10:06时窗口彻底关闭

第三层：侧输出流（Side Output）

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

SingleOutputStreamOperator<Result> result = stream
    .keyBy(...)
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .allowedLateness(Time.minutes(1))
    .sideOutputLateData(lateTag)  // 超过allowedLateness的数据输出到侧流
    .sum("amount");

// 获取迟到数据
DataStream<Event> lateStream = result.getSideOutput(lateTag);

// 迟到数据单独处理：写入Kafka/DB，后续离线修正
lateStream.addSink(new KafkaSink("late-data-topic"));

三层防线全景

数据到达
  ↓
第一层：Watermark延迟（如5秒）
  → 绝大部分乱序数据在这里就正常处理了
  ↓ 超过Watermark延迟的
第二层：allowedLateness（如1分钟）
  → 窗口再等1分钟，迟到数据触发更新
  ↓ 超过allowedLateness的
第三层：Side Output
  → 极端迟到数据收集到侧流，写入Kafka/DB
  → 后续离线任务做数据修正

我们出海业务的三层配置：Watermark延迟30秒（覆盖90%乱序）、allowedLateness 2分钟（覆盖99%迟到）、侧输出写Kafka（剩下1%离线修正）。实际运行下来侧输出的数据量不到总量的0.1%。

Flink SQL的迟到处理

-- SQL中通过TVF窗口 + allowedLateness
-- Flink SQL目前对allowedLateness支持有限
-- 主要靠Watermark延迟来处理乱序
-- 极端迟到场景建议用DataStream API

面试加分提示

💡 三层递进+实际数据：

「我们用三层防线处理迟到数据。第一层Watermark延迟30秒覆盖90%乱序。第二层allowedLateness 2分钟覆盖99%迟到数据，窗口重新触发更新结果。第三层Side Output把极端迟到数据写入Kafka，离线任务修正。

实际运行下来侧输出的数据不到0.1%。三层配合基本做到实时准确+事后兜底。」

📌 总结

记忆点	内容
迟到定义	Event Time早于当前Watermark的数据
第一层	Watermark延迟（乱序容忍）
第二层	allowedLateness（窗口再等一会）
第三层	Side Output（极端迟到收集到侧流）
注意	allowedLateness会导致窗口多次触发

▶ 下一篇预告：DAY 18 任务上线与运维

---

Wood聊大数据 | 9年大数据老兵，聊技术、聊职场、聊成长

---

小红书正文

Watermark之后来的数据就直接丢了？当然不是。Flink有三层防线。

第一层：Watermark延迟——设30秒乱序容忍，90%的乱序数据在这层解决。

第二层：allowedLateness——窗口触发后再等2分钟，迟到数据来了重新触发更新。覆盖99%。注意：下游要能处理更新。

第三层：Side Output——超过allowedLateness的极端迟到数据收集到侧流，写Kafka离线修正。

我们实际运行下来侧输出不到总量0.1%。三层配合=实时准确+事后兜底。