分享一篇關於實時流式計算的經典文章，這篇文章名為Streaming 101: The world beyond batch 那麼流計算如何超越批處理呢？ 從這幾個方面說明：實時流計算系統，數據處理模式，還有大數據的未來。 一、實時流式計算系統 實時流式計算的意義： 1、企業渴望獲得更及時的數據，實時 ...
分享一篇關於實時流式計算的經典文章，這篇文章名為Streaming 101: The world beyond batch
那麼流計算如何超越批處理呢？
從這幾個方面說明：實時流計算系統，數據處理模式，還有大數據的未來。
一、實時流式計算系統
實時流式計算的意義：
1、企業渴望獲得更及時的數據，實時計算系統延遲更低。
2、數據量越來越大，而實時計算系統理論上是處理無界數據的。
3、在數據到達時處理數據，可以更好的分擔負載，對於資源的消耗更容易預測。
什麼是Streaming？
有很多的定義，比如無界數據處理，近實時結果等，並不能說明Streaming的真正含義。Streaming應該是包含 無界數據 近實時 一致性 可重覆結果 等等特征的。 所以這裡給出Streaming的定義是：a type of data processing engine that is designed with infinite data sets in mind 一種考慮了無線數據集的數據處理引擎。
（這個定義包含了現在流行的真正的流式和微批）
Streaming常見的用法：
1、無限數據：一種不斷增長的，基本上無限的數據集。這些通常被稱為“流式數據”。無限的流式數據集可以稱為無界數據，相對而言有限的批量數據就是有界數據。
2、無界數據處理：一種持續的數據處理模式，應用於上面的無界數據。批量處理數據（離線計算）也可以重覆運行來處理數據，但是會有性能的瓶頸。
3、低延遲，近實時的結果：相對於離線計算而言，離線計算並沒有考慮延遲的問題。
Streaming的局限性：
Streaming長期以來一直和離線系統同時存在，也就是Lambda架構。
兩者都執行基本相同的計算，Streaming系統為您提供低延遲，不准確的結果，並且一段時間後批處理系統為您提供正確的輸出。（由Twitter的Nathan Marz（Storm的創造者）提出），這樣我們就需要維護兩個版本數據，最後再合併結果。
所以Kappa架構這種基於Kafka的可重覆獲取消息的架構出現了，Streaming應該是超越批量計算，並且能包含批量計算。Flink正是接受了這個觀點。
那麼怎麼做到這樣呢？只需要兩件事：
1、正確性：有了這個，就和批量計算等價了。
Streaming需要能隨著時間的推移依然能計算一定時間視窗的數據。Spark Streaming通過微批的思想解決了這個問題，實時與離線系統進行了一致性的存儲，這一點在未來的實時計算系統中都應該滿足。
2、推理時間的工具：這可以讓我們超越批量計算。
好的時間推理工具對於處理不同事件的無界無序數據至關重要。
這裡有兩種時間：事件時間和處理時間。
事件時間：事件實際發生的時間。
處理時間：系統中處理事件的時間。
當然，並不是所有的業務都會關心時間的問題。理想中事件時間和處理時間總是相等的，事件在發生時立即處理。然而，現實並非如此，事件時間和處理時間之間的偏差不僅不是零，而且受硬體（特別是網路），軟體，數據本身影響，會有很大的偏差。
圖一 時域映射 x軸為事件時間 y軸為處理時間 斜率為1的黑色虛線表示理想值，其中處理時間和事件時間完全相等; 紅線代表現實。理想線和紅線之間的水平距離是處理時間和事件時間之間的偏差。這種偏差本質上是處理流水線引入的延遲。
這個映射不是靜態的，所以只關心事件時間，就很難在時間視窗分析數據，而如果將事件時間視窗化，完整性會出問題。
所以必須用新的方案解決這個問題，我們先來看一下現有的數據處理模式。
二、數據處理模式
這裡我們將流式與微批處理放在一起，他們的差異在這裡並不重要。
1、有界數據
圖二，左側的數據集充滿了熵，我們通過mapreduce等批處理引擎，在右端使用具有更大內在價值的新結構化數據集。
當然，作為該方案的一部分，您可以實際計算的內容存在無限變化，但整體模型非常簡單。
2、無限數據-批量
批處理引擎雖然沒有明確考慮到無限數據，但是自從批量系統出現以來，它已被用於處理無界數據集。主要是將無界數據切割成適合批處理的有界數據集的集合。
固定視窗：
圖三 使用批處理引擎重覆運行來處理無界數據集的最常用方法是將輸入數據視窗化為固定大小的視窗，然後將每個視窗作為單獨的有界數據源處理。
會話：
圖四 增加批量，更複雜了
3、無限數據-Streaming
這種數據可能是 時間無序的 事件處理時間有偏差
在處理這種數據時有幾種情況：
不關心時間，近似演算法，處理時間視窗化，事件時間視窗化。
不關心時間
這種是完全不關心時間的情況，我們只需要完成對數據的處理就可以，有以下幾種情況：
過濾
比如web流量日誌，過濾掉某一個功能變數名稱的流量。丟棄不需要的就可以了。
圖五 過濾無界數據
內連接
還有就是連接兩個無界數據源的時候，沒有時間邏輯。
圖六 無界數據內連接
近似演算法
比圖top-N K-means等演算法，值得註意的是：這些演算法在設計中通常會有一些時間元素，並且由於它們在到達時處理
，因此該時間元素通常基於處理時間。這可能會影響計算的誤差，如果這些誤差範圍是以按順序到達的數據為基礎的
，那麼這種數據並不可信。
圖七 無界數據近似值
處理時間視窗化
先介紹一下視窗，有三種視窗模式
圖八 三種視窗
固定視窗：固定視窗將時間切割成具有固定大小時間長度的段。
滑動視窗：固定視窗的升級，滑動視窗由固定長度和固定周期定義。周期小於長度，則視窗重疊。如果周期等於長度，有固 定的視窗。如果周期大於長度，則會有一個的採樣視窗，它只會隨著時間的推移查看數據的子集。
會話：動態的視窗，會話由一系列事件組成，這些事件會超時而終止。會話通常用於通過將一系列與時間相關的事件組合在一起來分析用戶隨時間的行為。長度並不固定。
下麵先來討論處理時間視窗化：
當按處理時間視窗化時，系統基本上將輸入數據緩衝到一個視窗中，直到經過一定量的處理時間後再做處理。例如，在五分鐘固定視窗的情況下，系統會將數據緩衝五分鐘的處理時間，之後它會將這五分鐘內觀察到的所有數據視為一個視窗並將它們發送到下游進行處理。
圖九 處理時間視窗
處理時間視窗的優點：
簡單：不用擔心去改變數據。
視窗完整性：由於系統完全瞭解是否已經看到視窗的所有輸入，因此可以完美的判斷視窗完整。
處理時推斷源的信息：比如監控系統。
但是處理時間視窗有一個非常大的缺點：如果數據有和他們關聯的事件時間，弱國處理時間視窗要反映實際上這些事件的實際情況，那麼這些數據必須順序到達，但事實上大部分並不有序。
所以我們需要的是一種對時間到達順序更穩的方式，也就是事件時間視窗。
事件時間視窗化
將無界數據化為固定視窗。
圖10 將事件時間固定到固定視窗
圖中的實線白線表示兩個特別感興趣的數據。這兩個數據都到達處理時間視窗，這些時間視窗與它們所屬的事件時間視窗不匹配。因此，如果這些數據已被視窗化為處理關註事件時間的處理時間視窗，則計算結果將是不正確的。所以事件時間視窗才是正確性的體現。
圖11 也可以創建動態的視窗
事件時間視窗有兩個明顯的缺點，因為視窗必須更長。
緩衝：由於延長了視窗的生命周期，因此需要更多的數據緩衝。這個問題可以通過持久儲存和增量解決。
完整性：這個需要系統本身根據情況做出估計。
三、未來
我們定義了流的概念。正確性和推理時間的工具是關鍵。
通過分析事件時間和處理時間的差異，以及無界數據和有界數據，無界數據大致分為：不關心時間，近似演算法，處理時間視窗化，事件時間視窗化。
目前來看，時間問題可能是我們需要重點解決的問題，在102中介紹了一種實時流式處理模型，這也是未來實時計算領域的基石。
讓實時處理儘快融入到無限數據的系統中，為用戶提供高延遲，高效率間的靈活選擇，才是我們未來努力的方向。
更多實時計算，Kafka等相關技術博文，歡迎關註實時流式計算
