視窗操作會持續建立一些稱為“桶”的有限事件集合，並允許我們基於這些有限集進行計算。事件通常會根據時間或其他資料屬性分配到不同桶中。視窗的行為是由一系列策略定義的，這些視窗策略決定了什麼時間建立桶，事件如何分配到桶中以及桶內資料在什麼時間參與計算。我們可以基於時間（例如最近 5 秒鐘接收的事件）、數量 （例如最新 100 個事件）或其他資料屬性來定義視窗策略。
滾動視窗（Tumbling windows）：將事件分配到長度固定且互不重疊的桶中 。在視窗邊界通過後，所有事件會發送給計算函式進行處理。基於數量（Count-based）的滾動視窗定義了在觸發計算前需要集齊多少條事件。 圖1-1 是基於數量的滾動視窗將輸入流按每 4 個元素一組分配到不同的桶中。 基於時間（Time-based）的滾動視窗定義了在桶中緩衝資料的時間間隔。 圖1-2 是基於時間的滾動視窗將事件彙集到桶中，每 10 分鐘觸發一次計算。
圖1-1 基於數量的滾動視窗
圖1-2 基於時間的滾動視窗 •
滑動視窗（Sliding windows）將事件分配到大小固定且允許相互重疊的桶中，這意味著每個事件可能會同時屬於多個桶。我們透過指定長度和滑動間隔來定義滑動視窗。滑動間隔決定每隔多久生成一個新的桶。在圖1-3 中，基於數量的滑動視窗的長度為 4 個事件，滑動間隔為 3 個事件。
圖1-3 滑動視窗
會話視窗（Session windows ）在一些常見的真實場景中非常有用，這些場景既不適合用滾動視窗也不適合用滑動視窗。假設有一個應用要線上分析使用者行為，在該應用中我們要把事件按照使用者的同一活動或會話來源進行分組。例如，使用者瀏覽一連串新聞文章的互動過程可以看作一個會話。由於會話長度並非預先定義好，而是和實際資料有關，所以無論是滾動還是滑動視窗都無法用於該場景。而我們需要一個視窗操作，能將屬於同一會話的事件分配到相同桶中。會話視窗根據會話間隔（SessionGap）將事件分為不同的會話，該間隔值定義了會話在關閉前的非活動時間長度。圖1-4 展示了一個會話視窗。
圖1-4 會話視窗
如果你在收集來自不同感測器的測量值，那麼可能會想在應用視窗計算前按照感測器 ID 對資料流進行劃分。並行視窗中，每個資料分割槽所應用的視窗策略都相互獨立。圖1-5 展示了一個按事件顏色劃分、基於數量 2 的並行滾動視窗。
圖1-5 並行視窗
視窗操作與流處理中兩個核心概念密切相關：時間語義（time semantics）和狀態管理（state management）。時間可能是流處理中最重要的一個方面。當然，如果你的系統無法在故障時保護狀態，那一切都是空談。考慮到流式應用可能需要整日、甚至長年累月 地執行，因此必須保證出錯時其狀態能進行可靠的恢復，並且即使系統發生故障系統也能提供準確的結果。
