時間窗口
剩下的兩種無界數據處理的方法都是時間窗口的變種。在介紹它們之前，我應該先明確時間窗口的含義。時間窗口就是將數據源（無界或者有界）沿着時間線劃分成有限的數據塊進行處理。下圖展示了三種不同的時間窗口模式：
圖8：窗口模式舉例。每種模式都展示了3個不同的 keys，來突出對齊窗口（應用到所有數據的窗口）和未對齊窗口（應用到數據子集的窗口）之間的區別。
-
固定窗口：固定窗口把時間劃分成固定時間長度的段。典型的（如圖8所示），固定窗口的段會覆蓋整個數據集，這是對齊窗口的一個例子。有些情況下，需要爲不同的數據子集（例如按 key）移動窗口，使得隨着時間的推移，窗口的完成負載會更均勻，這種情況就是未對齊窗口的例子了。
-
滑動窗口：固定窗口的一種廣義形式，滑動窗口通過一個固定長度和一個固定間隔來定義。如果間隔小於長度，則窗口之間會重疊。如果間隔等於長度，這就是固定窗口。如果間隔大於長度，則被稱爲取樣窗口，它只會查看一部分數據。與固定窗口一樣，滑動窗口一般都是對齊的，儘管在特定情況下會使用未對齊的作爲性能優化。注意圖8中的滑動窗口這樣畫是爲了展示一種滑動感，事實上，所有5個窗口都會應用到整個數據集上。
-
會話：會話是動態窗口的一種，它是由通過超過某個時長的非活躍間隙切分的事件序列組成。通過將一系列時間相關的事件劃分在一起，會話通常被用於分析用戶行爲。會話的長度無法提前定義，它們依賴實際的數據。由於對於不同的數據子集（例如不同的用戶）會話也不會相同，因此會話也是經典的未對齊窗口。
對於 processing time 和 event time 兩種時間概念，時間窗口都是適用的，所以我們會詳細的講解並查看它們的區別。由於 processing time 在現有的系統中更加普遍，我們先來介紹它。
基於 processing time 的時間窗口
圖9：基於 processing time 劃分的固定時間窗口。基於數據到達的順序劃分到窗口中。
當基於 processing time 創建時間窗口時，系統會將到來的數據緩存進窗口中直到超過了某段 processing time。例如，對於5分鐘固定窗口，系統會按 processing time 緩存5分鐘的數據，然後會把5分鐘內收到的所有數據封裝進一個窗口併發送給下游處理。
基於 processing time 的時間窗口有如下優點：
-
簡單。由於從來不需要關心根據時間來 shuffle 數據，所以它的實現是很簡單直接的。你只需要緩存到來的數據，當窗口關閉時把它們發送給下游即可。
-
很容易判斷窗口的完整性。由於系統完全知道某個窗口的輸入數據是否已經到達，所以它完全可以判斷某個窗口的數據是否完整。這意味着當基於 processing time 劃分窗口時完全不需要處理晚到數據。
-
適用於根據觀測推斷數據源相關信息的場景。許多監控場景都是這種類型。例如通過計算髮送給一個 Web 服務的每秒請求數來探測服務是否中斷。
不過基於 processing time 的窗口有一個非常大的缺點：如果需要 processing time 窗口反映事件真正發生的時間，那麼這些數據必須按 event time 有序到達。不幸的是，對於分佈式輸入源，按 event-time 有序的數據是幾乎不存在的。
舉個簡單例子，假設手機上的一個 app 會收集用戶統計信息。當手機未連接網絡時（例如乘飛機時使用飛行模式），這段時間收集的數據無法上傳直到手機再次連上網絡。這就意味着這些數據會比 event time 晚幾分鐘、幾小時、幾天、幾周甚至更長時間才能到達。當基於 processing time 劃分時間窗口時，不可能從這樣的數據上獲取任何有用的結論。
另一個例子，當整個系統健康運行時，許多分佈式輸入源可能看起來能夠提供按 event-time 有序的數據。不幸的是，健康狀態下 event-time skew 很低並不意味着一直能保持如此。假設有一個從各個大陸上收集數據的全球服務。如果網絡問題造成帶寬下降或者延遲增加，那麼可能會造成一部分輸入數據的 event-time skew 變大。如果是基於 processing time 劃分的窗口，那麼窗口將無法再表示數據真正產生的情況。相反，它們表示的是事件到達時的情況，是新舊數據混合在一起的。
這兩個例子其實都應該基於 event time 來劃分時間窗口。
基於 event time 的時間窗口
當你想反映事件真實發生的時間時需要使用基於 event time 的時間窗口。基於 event time 的時間窗口是窗口劃分的黃金標準。遺憾的是，如今使用的大部分數據處理系統對它缺少原生的支持。
下圖展示了基於 event time ，將無界數據劃分成1小時的固定時間窗口：
圖10：基於 event time 劃分成固定時間窗口。數據按照它們產生的時間被劃分進窗口中。白色箭頭示意數據所在的 processing time 窗口與 event time 窗口不同。
圖中的白色箭頭標識了兩個特殊的數據。這兩個數據所在的 processing time 窗口與 event time 窗口是不匹配的。因此，對於關心 event times 的情況，如果這些數據被劃分進 processing time 窗口，那麼計算結果就是錯誤的。由此可見，能夠提供 event time 的正確性是使用 event time 窗口的一大優勢。
基於 event time 的時間窗口的另一個優勢是它可以創建動態大小的窗口，例如會話，再不會發生像基於固定窗口生成的會話出現跨窗口的情況（正如在”無界數據 – 批量”章節看到的會話例子那樣）。
圖11：基於 event time 劃分成會話時間窗口。基於事件發生的時間，數據被劃分進會話時間窗口。白色箭頭標識了需要對數據進行基於時間的 shuffle 操作，來將其放入正確的 event-time 窗口位置。
Event time 窗口雖然強大，但其同樣也有缺點。由於窗口通常存在時間比窗口本身的長度要更長一些，event time 窗口具有兩個明顯的缺點：
-
緩存：由於延長了時間窗口的生命期，需要緩存更多的數據。慶幸的是，持久化存儲已經是大部分數據處理系統所依賴的最廉價的資源了（其它資源是 CPU、網絡帶寬、內存）。因此，當使用設計良好的帶有強一致持久化狀態和內存緩存層的數據處理系統時這個問題就不那麼重要了。而且，很多聚合操作不需要緩存完整的輸入數據（例如求和或者均值），相反可以遞增執行，只需要把更小的中間聚合狀態存儲在持久化狀態中。
-
完整性：由於我們通常都不知道某個時間窗口下的數據何時到齊，那麼我們如何知道何時開始處理這個窗口下的數據？事實上，我們無法得知。對於很多類型的輸入，系統可以通過像 MillWheel 的 watermarks 給出一個窗口完整性的啓發式評估。但是對於需要絕對正確性的場景（例如記賬），唯一的解決方法是提供一種方式能夠重新處理窗口中的數據從而不斷修正計算結果。
文章轉自