Flink 系列第6篇：Watermark 水印全解析（原理+实操+避坑）

juniperhan

墨衍会员 · AI 创作全网分发码龄1年

关注

原创最新推荐文章于 2026-07-12 13:43:18 发布 1k 阅读 AI 写同款· GEO 优化 ›

flink Watermark 水印原理 flink Watermark 源码分析阅读详情

专栏定位：聚焦 Flink Watermark（水印）核心原理、生成策略、实操代码，详解水印如何解决数据乱序、多流处理及空闲数据源问题，覆盖生产全场景避坑要点

适用人群：Flink 开发工程师、实时计算落地人员、大数据初学者，需掌握 Flink 事件时间（EventTime）及窗口基础

核心价值：吃透 Watermark 工作机制，熟练配置水印生成策略，解决生产中数据乱序、窗口触发异常、水印停滞等核心问题，保障实时计算的准确性与实时性

一、Watermark 核心介绍（EventTime 处理的关键）

1.1 Watermark 简介

Watermark（水印）本质上是一种单调递增的时间戳，是 Flink 为处理 EventTime 窗口计算而设计的核心机制，用于标记数据流的时间进度。

核心关联：仅针对 EventTime，与 ProcessingTime 无关，是 EventTime 窗口能够正确触发的核心前提。
生成方式：由 Flink Source 或自定义的 Watermark 生成器，以 Punctuated（标点式）或 Periodic（周期性）两种方式生成，属于系统事件。
核心语义：它表示“所有时间戳 ≤ Watermark 的数据都已经到达系统”，算子接收到水印后，会认为不会再有小于该水印时间戳的数据到来。
核心作用：告诉 Flink 数据流在时间维度上已处理到的位置，为窗口计算提供触发信号。

1.2 引入 Watermark 的必要性

在 EventTime 处理场景中，数据乱序和延迟计算是两大核心难题，Watermark 的引入正是为了解决这两个问题，平衡数据准确性与处理实时性。

1.2.1 解决的两大核心难题

数据乱序：数据到达 Flink 的顺序与事件实际发生的顺序不一致（常见于网络传输、分布式数据源）。
- 解决方案：设置允许延迟的阈值（如5秒），让系统多等待一段时间，接收延迟到达的乱序数据。
延迟计算：系统无法判断何时数据已全部到齐，无法安全触发窗口计算（如“9点到9点05分的窗口，数据是否已全部到达？”）。
- 解决方案：Watermark 提供明确的计算触发信号——“时间戳≤Watermark的数据已到齐，可以计算窗口结果！”

1.2.2 无 Watermark 的问题

若不使用 Watermark，EventTime 窗口计算会陷入两种极端，均无法满足生产需求：

窗口无限期等待：始终不确定是否还有延迟数据到来，无法输出计算结果；
窗口提前关闭：直接关闭窗口并输出结果，导致迟到数据被丢弃，计算结果不准确。

1.3 Watermark 的核心作用

控制事件时间进展：推动 Flink 内部的 EventTime 时钟向前推进；
判断迟到数据的标准：时间戳小于当前 Watermark 的数据，会被判定为迟到数据；
触发窗口计算：当 Watermark ≥ 窗口结束时间时，触发该窗口的聚合计算；
平衡延迟与准确性：通过设置延迟容忍度，在“等待更多延迟数据”和“及时输出结果”之间找到最优平衡。

1.4 核心原则：Watermark 必须单调递增

Watermark 的本质是 EventTime 的进展标记，其核心原则是：Watermark 的时间戳只能前进（或保持不变），绝不能后退。一旦 Watermark 后退，会导致窗口重复触发、数据重复计算等严重问题。

核心计算公式： $W a t er ma r k = ma x (历史最大 E v e n tT im e, 新数据 E v e n tT im e) - 延迟阈值$

实例解析（理解单调性原则）

场景：数据乱序到达，允许延迟5秒，数据及到达顺序如下：

事件时间轴：9:00   9:05   9:10   9:15                           9:20
数据到达：  [A]    [C]    [B]   (B的时间戳是9:08，但9:15才到)

Watermark 生成过程（关键关注乱序数据 B）：

收到 A（9:00）：历史最大 EventTime = 9:00 → Watermark = 9:00 - 5s = 8:55；
收到 C（9:10）：历史最大 EventTime = 9:10 → Watermark = 9:10 - 5s = 9:05；
收到 B（9:08）：新数据 EventTime = 9:08，历史最大 EventTime = 9:10 → 取 max(9:10, 9:08) = 9:10 → Watermark = 9:10 - 5s = 9:05（保持不变，不后退）。

关键说明：若直接用 B 的时间戳计算（9:08 - 5s = 9:03），会导致 Watermark 从 9:05 后退到 9:03，违反单调性原则。Flink 采用“取历史最大 EventTime 为基准”的策略，确保 Watermark 始终单调递增。

窗口触发时机：对于 [9:00-9:05] 的窗口，当 Watermark ≥ 9:05 时（即收到 C 之后），触发窗口计算。

二、Watermark 的使用方法（实操核心）

2.1 Watermark 的生成策略

Flink 提供两种核心水印生成方式，需根据业务场景选择，实际生产中以 Periodic 方式为主。

水印生成策略示意图：

2.1.1 两种生成方式对比

Punctuated（标点式）
- 生成逻辑：数据流中每一个递增的 EventTime 都会产生一个 Watermark；
- 优点：实时性极高，能第一时间反映数据的时间进度；
- 缺点：在 TPS 很高的场景下，会产生大量水印，增加下游算子压力；
- 适用场景：实时性要求极高（如毫秒级响应）的业务。
Periodic（周期性）
- 生成逻辑：周期性（按固定时间间隔、或达到一定记录条数）产生一个 Watermark；
- 优点：可控制水印生成频率，避免大量水印占用资源，性能更稳定；
- 缺点：实时性略低于 Punctuated 方式；
- 适用场景：绝大多数生产场景，需结合时间间隔和数据条数双重控制，避免极端情况下的延迟。

2.1.2 核心 API 调用

构建 DataStream 后，通过 assignTimestampsAndWatermarks() 方法配置水印，需传入 WatermarkStrategy 对象（水印策略），核心语法：

DataStream.assignTimestampsAndWatermarks(WatermarkStrategy<T>)

2.1.3 WatermarkStrategy 与 WatermarkGenerator

WatermarkStrategy 是水印策略的核心接口，提供静态方法和默认实现，核心是返回一个 WatermarkGenerator（水印生成器）。

WatermarkStrategy 核心方法（需实现）：

/**
  * 实例化水印生成器，根据策略生成水印
  */
@Override
WatermarkGenerator<T> createWatermarkGenerator(WatermarkGeneratorSupplier.Context context);

WatermarkGenerator 接口（水印生成器），核心有两个方法：

@Public
public interface WatermarkGenerator<T> {
    /**
  * 每处理一条数据都会调用，可记录事件时间戳，或基于数据发射水印
  */
    void onEvent(T event, long eventTimestamp, WatermarkOutput output);
    
    /**
  * 周期性调用，可选择发射水印（周期由 ExecutionConfig 配置）
  * 周期设置：env.getConfig().setAutoWatermarkInterval(5000L); // 5秒一次
  */
    void onPeriodicEmit(WatermarkOutput output);
}

onEvent：每条数据都会触发，可用于标点式水印生成；
onPeriodicEmit：周期性触发（默认周期100ms，可自定义），用于周期性水印生成。

2.2 内置水印生成策略（实操首选）

Flink 提供两种常用内置水印生成策略，无需自定义实现，直接调用即可满足大部分业务需求。

2.2.1 单调递增水印生成器（无乱序场景）

特点：数据时间戳严格递增，无乱序，无需设置延迟阈值；
核心方法：WatermarkStrategy.forMonotonousTimestamps();
生成逻辑： $W a t er ma r k = 当前最大时间戳 - 0 m s$ （无延迟）；
底层实现：AscendingTimestampsWatermarks，是 BoundedOutOfOrdernessWatermarks 的子类（延迟时间为0）；
实操代码：

// 数据源：DataStream<T>，数据时间戳严格递增
DataStream dataStream = ...... ;
// 配置单调递增水印
dataStream.assignTimestampsAndWatermarks(WatermarkStrategy.forMonotonousTimestamps());

2.2.2 固定延迟时间水印生成器（乱序场景）

特点：数据存在乱序，需设置最大允许延迟时间，平衡准确性与实时性；
核心方法：WatermarkStrategy.forBoundedOutOfOrderness(Duration.ofSeconds(10));（参数为最大允许延迟）；
生成逻辑： $W a t er ma r k = 当前最大时间戳 - 最大允许延迟$ ；
实操代码：

// 数据源：DataStream<Event>，Event 包含 timestamp 字段（事件时间戳）
DataStream<Event> stream = input
    .assignTimestampsAndWatermarks(
        WatermarkStrategy
            .<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5)) // 允许5秒延迟
            .withTimestampAssigner((event, timestamp) -> event.timestamp) // 提取EventTime
    );

关键说明：forBoundedOutOfOrderness(Duration) 用于设置最大允许延迟，延迟时间需根据业务实际乱序情况调整（如3秒、5秒、10秒）。

2.3 Watermark 单位与 EventTime 提取

2.3.1 Watermark 时间戳单位

Watermark 本质是时间戳，Flink 默认时间戳单位为毫秒（Unix 时间戳）。若数据中的时间戳为秒或微秒，需手动转换为毫秒。

// 示例：将秒级时间戳转换为毫秒级
.withTimestampAssigner((event, recordTimestamp) -> event.timestamp * 1000)

注意：时间戳字段可不为 Long 类型，但最终提取后的值必须是毫秒级时间戳。

2.3.2 提取 EventTime（TimestampAssigner）

水印生成依赖 EventTime，需从数据中提取 EventTime，这就需要用到 TimestampAssigner 接口（函数式接口），核心方法：

@Public
@FunctionalInterface
public interface TimestampAssigner<T> {
    long extractTimestamp(T element, long recordTimestamp);
}

实操示例（从 Tuple2 中提取 EventTime）：

DataStream dataStream = ...... ;
dataStream.assignTimestampsAndWatermarks(
    WatermarkStrategy
    .<Tuple2<String,Long>>forBoundedOutOfOrderness(Duration.ofSeconds(5))
    .withTimestampAssigner((event, timestamp)->event.f1) // 从第二个字段提取EventTime
);

2.4 水印使用最佳实践

生成位置尽量靠前：最佳实践是在尽量接近 Source 的地方生成水印，甚至在 SourceFunction 中直接生成，避免分区操作（如 keyBy）打乱水印顺序。
允许窄依赖预处理：在生成水印前，可对数据流进行 map、filter 等窄依赖操作（不改变数据分区），不影响水印准确性。
实操示例：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

// 设置时间特征为 EventTime（必须）
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);

DataStream<SensorReading> readings = env
  .addSource(new SensorSource) // 数据源
  .filter(r -> r.temperature > 25) // 窄依赖预处理（过滤）
  .assignTimestampsAndWatermarks(new MyAssigner()); // 生成水印

三、Watermark 如何解决乱序问题（核心场景）

3.1 问题描述（生产常见场景）

某数据源存在数据延迟（如网络原因），延迟时间约5秒，例如：EventTime 为11秒的数据，在实际时间16秒时才到达 Flink，此时如何确保窗口计算结果准确？

场景补充：使用5秒滚动窗口（Tumble Window），需确保 EventTime=11秒的数据被正确分配到 [10-15秒] 窗口，而非 [15-20秒] 窗口。

3.2 EventTime 窗口触发条件

EventTime 窗口的触发核心条件：当窗口的结束时间 ≤ 当前系统的 Watermark 时间戳时，触发窗口计算。

通过调整水印生成策略，可解决乱序数据导致的窗口计算不准确问题，以下是两种核心策略对比。

3.2.1 策略1：Watermark = EventTime（无延迟，不推荐用于乱序场景）

核心逻辑：水印时间戳等于当前最大 EventTime，无延迟等待，适用于无乱序数据场景。

对应的 DDL 配置（Flink SQL）：

CREATE TABLE source(
  ...,
  Event_time TimeStamp,   -- 事件时间字段
  WATERMARK wk1 FOR Event_time as withOffset(Event_time, 0) -- 水印无延迟
) with (
  ... -- 数据源配置
);

问题：延迟数据（如 EventTime=11秒，16秒到达）会被判定为迟到数据，无法进入对应窗口，导致计算结果不准确。

3.2.2 策略2：Watermark = EventTime - 5s（设置延迟，推荐用于乱序场景）

核心逻辑：设置5秒延迟，水印时间戳 = 当前最大 EventTime - 5s，给乱序数据留足到达时间。

对应的 DDL 配置（Flink SQL）：

CREATE TABLE source(
  ...,
  Event_time TimeStamp,  -- EventTime 字段
  WATERMARK wk1 FOR Event_time as withOffset(Event_time, 5000) -- 延迟5秒（5000毫秒）
) with (
  ... -- 数据源配置
);

优势：EventTime=11秒的数据（16秒到达），此时水印时间戳 = 16秒 - 5秒 = 11秒，满足“窗口结束时间（15秒）≥ 水印时间戳（11秒）”，数据可正确进入 [10-15秒] 窗口，确保计算结果准确。

核心原理：通过延迟触发窗口计算，正确处理 Late Event（迟到数据），平衡准确性与实时性。

四、多流的 Watermark 处理（生产避坑点）

4.1 多流汇聚的问题

当多个流通过 Union、GroupBy 等操作合并到同一个处理节点时，每个流会携带各自的 Watermark，此时可能出现“多流水印不单调递增”的问题，违反 Watermark 核心原则。

4.2 Flink 处理方案

Flink 为保证多流汇聚后 Watermark 的单调性，采用“木桶原理”处理：当多流汇聚时，Flink 会选择所有流入流的 Watermark 中最小的一个，作为下游的 Watermark 向下传递。

优势：确保下游接收的 Watermark 始终单调递增，避免窗口触发异常、数据重复计算等问题。

注意：若某一个流的 Watermark 停滞（如无数据），会导致全局 Watermark 被拖慢，需结合“空闲数据源”处理方案解决。

五、空闲数据源处理（生产关键避坑）

5.1 空闲数据源简介与典型场景

在 Flink Keyed 数据流中，空闲数据源指：某个 Key 的分区（partition）在一段时间内（如5分钟）没有任何数据到达，但其他 Key 的分区仍有数据持续流入。

典型场景：

多租户系统：某个用户突然停止产生数据；
多地区数据：某个地区的数据源暂时中断；
多设备监控：某个设备离线，停止上报数据。

5.2 空闲数据源的不良影响

核心问题是Watermark 停滞（全局进度阻塞），遵循“木桶原理”： $全局 W a t er ma r k = min (所有并行分区的 W a t er ma r k)$ ，进而引发一系列问题：

窗口无法触发：全局 Watermark 无法推进，依赖水印的窗口计算无法触发；
状态无限增长：窗口无法关闭，窗口状态、Timer 无法清理，导致内存泄漏；
实时性丧失：数据处理延迟从秒级退化为小时级，实时监控、告警失效。

5.3 处理方案（withIdleness 方法）

Flink 提供 withIdleness() 方法专门处理空闲数据源，允许将长时间无数据的分区标记为“空闲”，排除在全局 Watermark 计算之外，确保全局水印正常推进。

核心代码示例

WatermarkStrategy<Event> strategy = WatermarkStrategy
    .<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5)) // 允许5秒乱序延迟
    .withTimestampAssigner((event, ts) -> event.timestamp) // 提取EventTime
    .withIdleness(Duration.ofMinutes(5)); // 5分钟无数据，标记该分区为空闲

工作原理（4步闭环）

检测空闲：某个分区超过指定时间（如5分钟）无数据到达；
标记空闲：将该分区从全局 Watermark 计算中排除；
全局推进：全局 Watermark 基于剩余活跃分区的 Watermark 计算，继续向前推进；
恢复参与：当该分区再次有数据到达时，重新参与全局 Watermark 计算，恢复活跃状态。

进阶配置与监控

空闲时间调整：根据业务场景设置，实时业务可设较短时间（如5分钟），批量业务可设较长时间（如1小时）：
.withIdleness(Duration.ofMinutes(5)); // 实时业务（推荐） .withIdleness(Duration.ofHours(1)); // 批量业务
Watermark 停滞监控：在 ProcessFunction 中监控水印进展，触发告警：
// 在 KeyedProcessFunction 的 processElement 或 onTimer 方法中 long currentWatermark = ctx.timerService().currentWatermark(); // 若 Watermark 延迟超过1分钟，触发告警 if (currentWatermark < System.currentTimeMillis() - 60000) { alert("Watermark停滞可能！请检查数据源是否空闲或异常！"); }
多级超时策略：重要业务可结合双重机制，确保水印正常推进：
WatermarkStrategy .forBoundedOutOfOrderness(Duration.ofSeconds(30)) // 乱序延迟30秒 .withIdleness(Duration.ofMinutes(5)) // 第一级：标记空闲分区 .withTimeout(Duration.ofMinutes(30)); // 第二级：完全超时（按需配置）

六、全篇核心总结

Watermark 是 Flink EventTime 处理的核心，本质是单调递增的时间戳，用于标记数据时间进度、触发窗口计算、解决数据乱序问题。
核心原则：Watermark 必须单调递增，计算公式为 $W a t er ma r k = ma x (历史最大 E v e n tT im e, 新数据 E v e n tT im e) - 延迟阈值$ 。
生成策略：分为 Periodic（周期性，生产首选）和 Punctuated（标点式，高实时场景），内置两种生成器可满足大部分业务需求。
乱序处理：通过设置固定延迟水印（Watermark = EventTime - 延迟阈值），给乱序数据留足到达时间，确保窗口计算准确。
多流处理：多流汇聚时，Flink 取所有流入流水印的最小值作为下游水印，保证单调性。
空闲数据源：使用 withIdleness() 方法标记空闲分区，避免全局 Watermark 停滞，防止窗口无法触发、内存泄漏。
实操关键：水印生成位置尽量靠前，延迟阈值根据业务乱序情况调整，做好水印停滞监控，避免生产异常。