分享一篇關於實時流式計算的經典文章，這篇文章名爲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等相關技術博文，歡迎關注實時流式計算
