對于流處理引擎來說，處理延遲到達的事件是至關重要的功能。 解決這個問題的方法是加水位線的概念。 從Spark 2.1開始，結構化流API就支持它。

什么是水位線？

加水位線是一種有用的方法，可幫助流處理引擎處理延遲。 基本上，水印是一個閾值，用于指定系統等待延遲事件的時間。 如果到達事件位于水位線之內，它將用于更新查詢。 否則，如果它早于水位線，它將被丟棄，并且流引擎不會對其進行進一步處理。

> Flooding watermarks

如何使用它？

自Spark 2.1起，水位線被引入到結構化流API中。 您可以通過將withWatermark-Operator添加到查詢中來啟用它：

withWatermark（eventTime：String，delayThreshold：String）：數據集[T]

它需要兩個參數，a）一個事件時間列（必須與聚合正在處理的列相同）和b）一個閾值，用于指定應處理多長時間的延遲數據（以事件時間為單位）。 然后，Spark將維持聚合狀態，直到max eventTime — delayThreshold> T，其中max eventTime是引擎看到的最新事件時間，T是窗口的開始時間。 如果后期數據落入此閾值之內，則查詢將最終得到更新（下圖中的右圖）。 否則，它將被丟棄，并且不會觸發任何重新處理（下圖中的左圖）。

> Late donkey in structured word count: event dropped (left), event within watermark updates Window

值得一提的是，查詢的輸出模式必須設置為"追加"（默認）或"更新"。完全模式不能與設計中的水印結合使用，因為它需要所有 要保存的數據，用于將整個結果表輸出到接收器。

可以在這里找到如何在簡單的Spark結構化流應用程序中使用該概念的快速演示-它是字數統計（對NLP進行了一些小的增強），還有其他：D

但是，為什么我要關心？

在分布式和聯網的系統中，總會有中斷的機會-節點故障，傳感器丟失連接等等。 因此，不能保證數據將按創建順序到達流處理引擎。 為了容錯，因此有必要處理此類亂序數據。

為了解決此問題，必須保留聚合狀態。 如果發生延遲事件，則可以重新處理查詢。 但這意味著所有聚合的狀態必須無限期地保持，這也導致內存使用量也無限期地增長。 除非系統具有無限的資源（即無限的預算），否則在現實世界中這是不切實際的。 因此，加水位線是一個有用的概念，可以通過設計約束系統并防止其在運行時爆炸。