今天我們聊聊 Apache Flink 的水位線。

一、為什么需要水位線？

Flink 流模式下處理的是源源不斷的數據流。這些數據通常帶有時間戳（比如事件發生的時間）。在實際系統中，由于網絡延遲、設備故障、重試機制等原因，數據到達 Flink 的順序可能和它們真實發生的時間順序不一致——這就是所謂的“亂序”。

舉個例子：

• 事件 A 發生在 10:00，但由于網絡卡頓，10:05 才到達 Flink。
• 事件 B 發生在 10:02，但網絡通暢，10:03 就到了。

Flink 先看到 B，后看到 A。如果直接按到達順序處理，就會誤以為 10:02 的事件比 10:00 的還早，這顯然不對。

那么問題來了：Flink 怎么知道“現在可以安全地認為不會再有更早時間的數據來了”，從而可以對某個時間段的數據做最終計算？

這就是水位線要解決的核心問題。

二、水位線到底是什么？

水位線（Watermark）是 Flink 引入的一種邏輯時鐘信號，用來告訴系統：“到目前為止，我認為所有時間戳小于等于這個值的事件都已經到達了，后續即使再有更小時間戳的數據，也屬于遲到數據。”

更正式地說：

• 水位線是一個單調遞增的時間戳（不能倒退）。
• 它代表的是“事件時間”的進度，而不是系統當前的真實時間。
• 當 Flink 看到一個水位線 W，就認為“所有時間戳 ≤ W 的事件已經全部到齊了”。

注意：水位線不是數據本身，而是一種元信息，隨著數據流一起傳播。

三、水位線怎么生成？

Flink 提供兩種主要方式生成水位線：

1. 周期性生成（Periodic Watermark）

Flink 每隔一段時間（比如 200 毫秒）自動調用一個函數，根據當前已收到數據的最大事件時間，減去一個“允許的最大延遲”（比如 5 秒），生成一個新的水位線。

公式：

Watermark = maxEventTimeSoFar - allowedLateness

例如：

• 已收到的最大事件時間是 10:10。
• 允許最大延遲是 5 秒。
• 那么當前水位線就是 10:05。

這意味著：Flink 認為 10:05 之前的所有事件都已到齊。

2. 按事件生成（Punctuated Watermark）

某些特殊事件本身就代表一個時間界限（比如日志中的“檢查點”記錄），遇到這種事件就立即發出一個水位線。

這種方式較少用，多數場景用周期性生成就夠了。

四、水位線的核心作用：判斷“何時可以觸發計算”

Flink 中很多操作依賴于“事件時間”（Event Time），而事件時間天然存在亂序問題。水位線的作用就是為基于事件時間的操作提供一個“進度參考”，讓系統知道“現在可以放心處理到哪個時間點了”。

最典型的例子是窗口計算：

• 假設你定義了一個 1 分鐘的滾動窗口：[10:00–10:01), [10:01–10:02)……
• 窗口 [10:00–10:01) 必須等到確認“10:01 之前的數據都到齊了”才能關閉并輸出結果。
• 這個“確認”的依據，就是水位線 ≥ 10:01。

所以，當水位線推進到 10:01，Flink 就會觸發該窗口的計算，并輸出結果。

如果沒有水位線，Flink 就不知道什么時候該關窗——永遠等下去？還是隨便關？都不合理。

五、水位線只用于窗口嗎？

不是！水位線不僅用于窗口，還用于所有基于事件時間的算子。

雖然窗口是最常見的使用場景，但水位線的作用范圍更廣。以下是幾個非窗口的例子：

1. ProcessFunction 中的定時器（Timer）

在 Flink 的底層 API（如 KeyedProcessFunction）中，你可以注冊一個基于事件時間的定時器：

ctx.timerService().registerEventTimeTimer(timestamp);

這個定時器什么時候觸發？只有當水位線 ≥ 注冊的時間戳時才會觸發。

比如你注冊了一個 10:05 的定時器，即使系統時間已經是 10:10，只要水位線還沒到 10:05，定時器就不會執行。這是為了保證事件時間語義的一致性。

2. CEP（復雜事件處理）

Flink CEP 用于檢測事件序列模式（比如“A 事件后 5 秒內出現 B 事件”）。這類時間約束也是基于事件時間的，因此同樣依賴水位線來判斷“5 秒是否已過”。

如果水位線沒推進到 A 的時間 + 5 秒，CEP 就不能確定是否匹配失敗，必須繼續等待。

3. Join 操作（如 Interval Join）

兩個流按事件時間進行區間連接（比如訂單流和支付流，要求支付發生在訂單后 1 小時內），也需要水位線來判斷哪些數據可以安全地進行匹配，哪些還需要等待。

4. 自定義狀態清理

如果你在狀態中緩存了某些事件，并希望在“事件時間過去很久后”自動清理狀態，也可以通過水位線驅動清理邏輯。

六、水位線與“遲到數據”的關系

水位線設定后，仍然可能有事件時間 < 當前水位線的數據到達——這就是“遲到數據”。

Flink 對遲到數據有三種處理策略：

• 丟棄（默認）：一旦窗口關閉，遲到數據直接忽略。
• 側輸出（Side Output）：把遲到數據單獨輸出到另一個流，供后續處理。
• 允許更新窗口結果：配合 allowedLateness 參數，窗口關閉后仍可接收一定時間內的遲到數據并重新計算。

但無論哪種策略，是否“遲到”的判斷標準，都是看事件時間是否 < 當前水位線。

七、水位線的局限性

• 水位線是估計值：它基于“最大事件時間 - 延遲容忍度”計算，無法 100% 保證不會有更早的數據到來。設置太激進（延遲容忍小），會導致大量數據被當作遲到；設置太保守（延遲容忍大），會導致結果延遲嚴重。
• 空閑源問題：如果某個數據源長時間沒有新數據，maxEventTime 不更新，水位線就卡住不動，導致整個作業“停滯”。Flink 提供 withIdleness 機制來緩解這個問題。
• 多流合并時的水位線對齊：當多個流 join 或 union 時，Flink 會取所有輸入流中最小的水位線作為當前算子的水位線，以保證時間語義一致。這可能導致快流被慢流拖慢。

八、總結：水位線的本質和適用范圍

本質：水位線是 Flink 在事件時間語義下，用來表示“數據進度”的一種機制。它告訴系統：“我認為到這個時間點為止的數據都到齊了。”

核心用途：驅動基于事件時間的操作（如窗口、定時器、CEP、Join 等）在合適的時間點觸發計算。

是否僅用于窗口？不是。 雖然窗口是最典型的應用，但任何依賴事件時間進度的功能都離不開水位線。它是 Flink 事件時間處理的基礎設施，就像操作系統里的時鐘中斷一樣，是整個時間語義體系的“心跳信號”。

九、一句話記住水位線

水位線不是數據，而是 Flink 用來判斷“事件時間走到哪了”的進度條；它決定了什么時候可以安全地做計算，而不僅僅是關窗口。