無界資料：流式傳輸與大多數基於批處理的無界資料處理方法的臨時性質相反，流式系統是針對無界資料構建的。正如我們之前所討論的，對於許多真實的分散式輸入源，您不僅會發現自己處理無界資料，還會處理以下資料：事件時間高度無序，這意味著您需要某種時間 如果要在發生它們的上下文中分析資料，則在管道中進行基於shuffle。 在不同的事件時間偏差中，意味著你不能只假設你總是會在某個恆定的時間ε中看到給定事件時間X的大部分資料。 在處理具有這些特徵的資料時，您可以採取一些方法。 我通常將這些方法分為四組：時間不可知，近似，按處理時間加窗，以及按事件時間加窗。 現在讓我們花一點時間來研究這些方法。

1.時間不可知 時間不可知處理用於時間基本無關的情況;也就是說，所有相關邏輯都是資料驅動的。因為有關此類用例的所有內容都是由更多資料的到來決定的，所以除了基本資料傳輸之外，流引擎實際上沒有什麼特別需要支援的。因此，基本上所有流式傳輸系統都支援開箱即用的時間不可用的用例（當然，如果你關心正確性，模組系統到系統的一致性保證差異）。通過簡單地將無界源切割成有界資料集的任意序列並獨立處理這些資料集，批處理系統也非常適合無界資料來源的時間不可知處理。我們在本節中看一些具體的例子，但考慮到處理與時間無關的處理的直接性（至少從時間角度來看），除此之外我們不會花太多時間在它上面。 過濾一種非常基本的時間不可知處理形式是過濾，其示例如圖1-5所示。

想象一下，您正在處理網路流量日誌，並且您希望過濾掉所有不是來自特定域的流量。你會看到每個記錄到達時，檢視它是否屬於感興趣的域，如果沒有則刪除它。因為這種事情在任何時候都只依賴於單個元素，所以資料來源是無界的，無序的，並且具有不同的事件時間偏差這一事實是無關緊要的。

圖1-5。過濾無限資料。從不同型別的資料集合（從左到右流動）被過濾成包含單一型別的同類集合。

內連線 另一個與時間無關的例子是內連線，如圖1-6所示。

當連線兩個無界資料來源時，如果您只關心來自兩個源的元素到達時的連線結果，則邏輯中沒有時間元素。在看到來自一個源的值後，您可以簡單地將其緩衝為持久狀態;只有在來自其他源的第二個值到達之後，才需要發出連線記錄。 （事實上​​，你可能想要某種垃圾收集策略用於未經許可的部分連線，這可能是基於時間的。但是對於很少或沒有未完成連線的用例，這樣的事情可能不是問題。）

將語義切換到某種外連線會引入我們所討論的資料完整性問題：在您看到連線的一側之後，您如何知道另一方是否會到達？ 說實話，你沒有，所以你需要引入一些超時的概念，這會引入一個時間元素。時間元素本質上是一種視窗形式，我們將在一瞬間更加密切地關注它。

2.近似演算法

第二類主要方法是近似演算法，例如近似Top-N，流k-means等。它們採用無限的輸入源並提供輸出資料，如果你眯著眼睛看，它們或多或少看起來像你希望得到的那樣，如圖1-7所示。 近似演算法的優點在於，通過設計，它們的開銷很低，並且設計用於無界資料。缺點是它們存在有限的一組，演算法本身往往很複雜（這使得很難想出新的演算法），它們的近似性質限制了它們的效用。

圖1-7。計算無界資料的近似值。資料通過複雜的演算法執行，產生的輸出資料或多或少與另一側的預期結果相似。

值得注意的是，這些演算法通常在其設計中確實存在一些時間因素（例如，某種內建衰變）。並且因為它們在到達時處理元素，所以該時間元素通常基於處理時間。這對於在其近似上提供某種可證明的誤差界限的演算法尤其重要。如果這些誤差範圍是以按順序到達的資料為基礎的，那麼當您向演算法提供具有不同事件時間偏差的無序資料時，它們基本上沒有任何意義。要記住的事情。 近似演算法本身是一個引人入勝的主題，但由於它們本質上是時間不可知處理的另一個例子（以演算法本身的時間特徵為模），因此我們可以非常直接地使用它們，因此，鑑於我們目前的重點，它們不值得進一步關注。 視窗化無限資料處理的其餘兩種方法都是視窗的變化。在深入研究它們之間的差異之前，我應該清楚地說明視窗的確切含義，因為我們只是在上一節中簡要介紹了它。視窗化只是獲取資料來源（無界或有界）的概念，並沿著時間邊界將其切割成有限的塊以進行處理。圖1-8顯示了三種不同的視窗模式。

圖1-8。 視窗策略。 每個示例都顯示三個不同的鍵，突出顯示對齊視窗（適用於所有資料）和未對齊視窗（適用於資料子集）之間的差異。

讓我們仔細看看每個策略：固定視窗（又名翻滾視窗）我們之前討論過固定視窗。固定視窗將時間切片為具有固定大小的時間長度的片段。通常（如圖1-9所示），固定視窗的分段均勻地應用於整個資料集，這是對齊視窗的示例。在某些情況下，希望對不同資料子集（例如，每個鍵）的視窗進行相移以隨時間更均勻地擴充套件視窗完成負載，而這是未對齊視窗的示例，因為它們在資料上變化。 滑動視窗（又稱跳躍視窗）固定視窗的推廣，滑動視窗由固定長度和固定週期定義。如果週期小於長度，則視窗重疊。如果週期等於長度，則您有固定的視窗。如果週期大於長度，則會有一個奇怪的取樣視窗，該視窗僅檢視資料的子集隨時間的變化。 與固定視窗一樣，滑動視窗通常是對齊的，但在某些用例中它們可以不對齊作為效能優化。 請注意，圖1-8中的滑動視窗是按原樣繪製的，以提供滑動感;實際上，所有五個視窗都將應用於整個資料集。 會話動態視窗的一個示例，會話由一系列事件組成，這些事件由不活動的間隙大於某個超時而終止。 會話通常用於通過將一系列時間相關事件（例如，在一次觀看中觀看的一系列視訊）分組在一起來分析使用者隨時間的行為。會話很有意思，因為它們的長度不能先驗地定義;它們取決於所涉及的實際資料。它們也是未對齊視窗的規範示例，因為會話實際上從不相同的不同子集6從精細資料庫（例如，不同的使用者）下載。

我們之前討論的兩個時間域（處理時間和事件時間）基本上是我們關心的兩個。視窗化在兩個域都有意義，所以讓我們詳細看看每個視窗，看看它們有何不同。因為處理時間視窗在歷史上比較常見，所以我們將從那裡開始。 通過處理時間進行視窗化當按處理時間視窗化時，系統實質上將輸入資料緩衝到視窗中，直到經過一定量的處理時間。例如，在五分鐘固定視窗的情況下，系統會將資料緩衝五分鐘的處理時間，之後它會將在這五分鐘內觀察到的所有資料視為一個視窗並將它們傳送到下游進行處理。

圖1-9。通過處理時間視窗進入固定視窗。資料根據它們到達管道的順序收集到視窗中。

處理時間視窗有一些很好的屬性：它很簡單。實現非常簡單，因為您從不擔心在一段時間內對資料進行混洗。你只需在它們到達時緩衝它們並在視窗關閉時將它們傳送到下游。

判斷視窗的完整性很簡單。由於系統完全瞭解是否已經看到視窗的所有輸入，因此可以就給定視窗是否完整做出完美的決定。這意味著當按處理時間進行視窗化時，無需以任何方式處理“延遲”資料。

如果您想要在觀察時推斷出有關源的資訊，那麼處理時間視窗正是您想要的。 許多監測方案都屬於這一類。想象一下，跟蹤傳送到全球規模Web服務的每秒請求數。 為了檢測中斷而計算這些請求的速率是處理時間視窗的完美使用。 除了優點之外，處理時間視窗有一個非常大的缺點：如果有問題的資料具有與它們相關聯的事件時間，那麼如果處理時間視窗要反映實際時間，則這些資料必須按事件時間順序到達那些事件確實發生了。不幸的是，在許多真實的分散式輸入源中，事件時序資料並不常見。 舉一個簡單的例子，想象一下任何收集使用統計資料以供以後處理的移動應用程式。對於特定移動裝置在任何時間內離線（短暫的連線丟失，飛越全國的飛機模式等）的情況，在此期間記錄的資料將不會上傳，直到裝置再次聯機。這意味著資料可能會以分鐘，小時，天，周或更長的事件時間偏差到達。當處理時間視窗化時，從這樣的資料集中繪製任何型別的有用推論基本上是不可能的。 作為另一個例子，當整個系統健康時，許多分散式輸入源似乎可以提供事件時間有序（或非常接近）的資料。不幸的是，健康時事件時間偏差對於輸入源來說是低的這一事實並不意味著它總會保持這種狀態。考慮一個處理在多個大洲收集的資料的全球服務。如果網路問題跨越頻寬受限的跨大陸線（遺憾的是，這種情況非常普遍）會進一步降低頻寬和/或增加延遲，突然一部分輸入資料可能會以比以前更大的偏差開始到達。如果您通過處理時間來處理這些資料，那麼您的視窗將不再代表其中實際發生的資料;相反，當事件到達處理管道時，它們代表時間視窗，這是舊資料和當前資料的任意混合。

我們在這兩種情況下真正想要的是以一種對事件到達順序穩健的方式按事件時間視窗資料。我們真正想要的是事件時間視窗。

按事件時間視窗事件 時間視窗是當您需要觀察有限塊中反映事件實際發生時間的資料來源時使用的視窗。這是開窗的黃金標準。在2016年之前，大多數使用中的資料處理系統缺乏本機支援（儘管任何具有良好一致性模型的系統，如Hadoop或Spark Streaming 1.x，都可以作為構建這種視窗系統的合理基礎）。我很高興地說今天的世界看起來非常不同，有多個系統，從Flink到Spark，Storm到Apex，本身支援某種事件時間視窗。 圖1-10顯示了將無界源視窗化為一個固定視窗的示例。 圖1-10。按事件時間視窗固定視窗。資料根據它們發生的時間收集到視窗中。黑色箭頭表示到達處理時間視窗的示例資料，這些資料與它們所屬的事件時間視窗不同。

圖1-10中的黑色箭頭表示兩個特別有趣的資料。每個到達的處理時間視窗與每個資料位所屬的事件時間視窗不匹配。因此，如果這些資料已被視窗化為關注事件時間的用例的處理時間視窗，則計算結果將是不正確的。 正如您所料，事件時間的正確性是使用事件時間視窗的一個好處.

關於無界資料來源的事件時間視窗的另一個好處是，您可以建立動態大小的視窗，例如會話，而不會在通過固定視窗生成會話時觀察到任意分割（正如我們之前在“無界資料”中的會話示例中看到的那樣） ：Streaming“），如圖1-11所示。

圖1-11。按事件時間視窗進入會話視窗。資料被收集到會話視窗中，根據相應事件發生的時間捕獲活動突發。黑色箭頭再次調出將資料放入正確的事件時間位置所需的時間改組。 當然，強大的語義很少是免費的，事件時間視窗也不例外。事件時間視窗有兩個明顯的缺點，因為視窗必須經常比視窗本身的實際長度更長（處理時間）：緩衝由於延長視窗壽命，需要更多的資料緩衝。 值得慶幸的是，持久儲存通常是大多數資料處理系統所依賴的資源型別中最便宜的（其他型別主要是CPU，網路頻寬和RAM）。因此，當使用任何設計良好的資料處理系統具有強一致的持久狀態和體面的記憶體快取層時，這個問題通常不像您想象的那麼令人擔憂。而且，許多有用的聚合不要求整個輸入集被緩衝（例如，總和或平均），而是可以遞增地執行，其中儲存在持久狀態中的小得多的中間聚合。 完整性鑑於我們通常沒有很好的方法知道我們何時看到給定視窗的所有資料，我們如何知道視窗的結果何時可以實現？事實上，我們根本就沒有。對於許多型別的輸入，系統可以通過諸如MillWheel，Cloud Dataflow和Flink（我們在第3章和第4章中討論的更多）中的水印之類的東西給出視窗完成的合理準確的啟發式估計。但是對於絕對正確性至關重要的情況（再次考慮計費），唯一真正的選擇是為管道構建者提供一種方式來表達何時需要實現視窗的結果以及如何隨時間推移這些結果。

處理視窗完整性（或缺少視窗完整性）是一個引人入勝的主題，但最好在具體示例的背景下進行探討，我們將在下面進行討論。 在本章中，我們已經完成了以下內容：明確的術語，將“流式傳輸”的定義集中在指代以無限資料為基礎構建的系統，同時使用更多描述性術語，如近似/推測結果，通常歸類於“流媒體“傘。 此外，我們

1.強調了大規模資料集的兩個重要維度：基數（即有界與無界）和編碼（即表與流），後者將消耗本書後半部分的大部分內容。 2.評估精心設計的批處理和流媒體系統的相對功能，定位流實際上是批處理的嚴格超集，並且像流媒體不如批處理的Lambda架構這樣的概念註定要在流媒體系統成熟時退休。 3.提出了流式系統所需的兩個高階概念，分別是趕上並最終超越批次，分別是正確性和推理時間的工具。 4.確定了事件時間和處理時間之間的重要差異，描述了這些差異在分析資料時的差異所帶來的困難，並提出了從完整性概念轉向簡單適應資料隨時間變化的方法。 5.通過批處理和流引擎，檢視有界和無界資料的常用主要資料處理方法，大致將無界方法分類為：時間不可知，近似，處理時間視窗和事件時間視窗。

接下來，我們深入研究樑模型的細節，從概念上看看我們如何分解四個相關軸上的資料處理概念：什麼，何地，何時以及如何。我們還詳細研究了在多個場景中處理一個簡單，具體的示例資料集，突出了樑模型啟用的多個用例，以及一些具體的API，以實現我們的基礎。這些示例將有助於推動本章介紹的事件時間和處理時間的概念，同時另外探索水印等新概念。 為了完整起見，也許值得一提的是，這個定義既包括真正的流媒體實現，也包括微生物實現。對於那些不熟悉微型分析系統的人來說，他們是流式系統，它使用批處理引擎的重複執行來處理無界資料。 Spark Streaming是業界的典範。 熟悉我原來的“Streaming 101”文章的讀者可能會記得，在引用資料集時，我更加強調鼓勵放棄術語“流”。從未流行過，我最初認為這是由於它的吸引力和普遍的現有用法。然而，回想起來，我認為我完全錯了。實際上，區分兩種不同型別的資料集結構有很大的價值：表和流。實際上，本書的後半部分大部分都致力於理解這兩者之間的關係。

如果你在我說完一次時你不熟悉我的意思，它指的是某些資料處理框架提供的特定型別的一致性保證。一致性保證通常分為三大類：最多一次處理，至少一次處理和完全處理。

請注意，此處使用的名稱是指在管道生成的輸出中觀察到的有效語義，而不是管道可能處理（或嘗試處理）任何給定記錄的實際次數。出於這個原因，有時使用一次有效一次而不是一次，因為它更能代表事物的潛在本質。 Reuven在第5章中更詳細地介紹了這些概念。 自從“Streaming 101”的最初出版以來，許多人向我指出，將處理時間放在x軸上並將事件時間放在y軸上會更直觀。我同意交換兩個軸最初會感覺更自然，因為事件時間似乎是處理時間的自變數的因變數。 然而，因為兩個變數都是單調的並且密切相關，所以它們是有效的相互依賴的變數。所以我認為從技術角度來看你只需選擇一個軸並堅持下去。數學令人困惑（特別是在北美之外，它突然變成了複數並且在你身上團結起來）。 這個結果真的不應該是令人驚訝的（但對我而言，因此我指出它為什麼），因為我們在測量兩種型別的偏斜/滯後時有效地建立了具有理想線的直角三角形。數學很酷。 我們將在第2章詳細介紹對齊的固定視窗，在第4章中檢視未對齊的固定視窗。 如果你在學術文獻或基於SQL的流媒體系統中搜索得足夠多，你還會遇到第三個視窗時間域：基於元組的視窗（即，視窗的大小以元素數量計算）。然而，基於元組的視窗本質上是處理時視窗的一種形式，其中元素在到達系統時被分配單調增加的時間戳。因此，我們不會進一步詳細討論基於元組的視窗。