Streaming-大數據的將來

分享一篇關於實時流式計算的經典文章，這篇文章名爲Streaming 101: The world beyond batch

那麼流計算如何超越批處理呢？

從這幾個方面說明：實時流計算系統，數據處理模式，還有大數據的將來。

1、實時流式計算系統

實時流式計算的意義：

一、企業渴望得到更及時的數據，實時計算系統延遲更低。

二、數據量愈來愈大，而實時計算系統理論上是處理無界數據的。

三、在數據到達時處理數據，能夠更好的分擔負載，對於資源的消耗更容易預測。

什麼是Streaming？

有不少的定義，好比無界數據處理，近實時結果等，並不能說明Streaming的真正含義。Streaming應該是包含 無界數據 近實時 一致性 可重複結果 等等特徵的。 因此這裏給出Streaming的定義是：a type of data processing engine that is designed with infinite data sets in mind 一種考慮了無線數據集的數據處理引擎。

（這個定義包含了如今流行的真正的流式和微批）

Streaming常見的用法：

一、無限數據：一種不斷增加的，基本上無限的數據集。這些一般被稱爲「流式數據」。無限的流式數據集能夠稱爲無界數據，相對而言有限的批量數據就是有界數據。

二、無界數據處理：一種持續的數據處理模式，應用於上面的無界數據。批量處理數據（離線計算）也能夠重複運行來處理數據，可是會有性能的瓶頸。

三、低延遲，近實時的結果：相對於離線計算而言，離線計算並無考慮延遲的問題。

Streaming的侷限性：

Streaming長期以來一直和離線系統同時存在，也就是Lambda架構。

二者都執行基本相同的計算，Streaming系統爲您提供低延遲，不許確的結果，而且一段時間後批處理系統爲您提供正確的輸出。（由Twitter的Nathan Marz（Storm的創造者）提出），這樣咱們就須要維護兩個版本數據，最後再合併結果。

因此Kappa架構這種基於Kafka的可重複獲取消息的架構出現了，Streaming應該是超越批量計算，而且能包含批量計算。Flink正是接受了這個觀點。

那麼怎麼作到這樣呢？只須要兩件事：

一、正確性：有了這個，就和批量計算等價了。

Streaming須要能隨着時間的推移依然能計算必定時間窗口的數據。Spark Streaming經過微批的思想解決了這個問題，實時與離線系統進行了一致性的存儲，這一點在將來的實時計算系統中都應該知足。

二、推理時間的工具：這可讓咱們超越批量計算。

好的時間推理工具對於處理不一樣事件的無界無序數據相當重要。

這裏有兩種時間：事件時間和處理時間。

事件時間：事件實際發生的時間。

處理時間：系統中處理事件的時間。

固然，並非全部的業務都會關心時間的問題。理想中事件時間和處理時間老是相等的，事件在發生時當即處理。然而，現實並不是如此，事件時間和處理時間之間的誤差不只不是零，並且受硬件（特別是網絡），軟件，數據自己影響，會有很大的誤差。

圖一 時域映射 x軸爲事件時間 y軸爲處理時間 斜率爲1的黑色虛線表示理想值，其中處理時間和事件時間徹底相等; 紅線表明現實。理想線和紅線之間的水平距離是處理時間和事件時間之間的誤差。這種誤差本質上是處理流水線引入的延遲。

這個映射不是靜態的，因此只關心事件時間，就很難在時間窗口分析數據，而若是將事件時間窗口化，完整性會出問題。

因此必須用新的方案解決這個問題，咱們先來看一下現有的數據處理模式。

2、數據處理模式

這裏咱們將流式與微批處理放在一塊兒，他們的差別在這裏並不重要。

一、有界數據

圖二，左側的數據集充滿了熵，咱們經過mapreduce等批處理引擎，在右端使用具備更大內在價值的新結構化數據集。

固然，做爲該方案的一部分，您能夠實際計算的內容存在無限變化，但總體模型很是簡單。

二、無限數據-批量

批處理引擎雖然沒有明確考慮到無限數據，可是自從批量系統出現以來，它已被用於處理無界數據集。主要是將無界數據切割成適合批處理的有界數據集的集合。

固定窗口：

圖三 使用批處理引擎重複運行來處理無界數據集的最經常使用方法是將輸入數據窗口化爲固定大小的窗口，而後將每一個窗口做爲單獨的有界數據源處理。

會話：

圖四 增長批量，更復雜了

三、無限數據-Streaming

這種數據多是 時間無序的 事件處理時間有誤差

在處理這種數據時有幾種狀況：

不關心時間，近似算法，處理時間窗口化，事件時間窗口化。

不關心時間

這種是徹底不關心時間的狀況，咱們只須要完成對數據的處理就能夠，有如下幾種狀況：

過濾

好比web流量日誌，過濾掉某一個域名的流量。丟棄不須要的就能夠了。

圖五 過濾無界數據

內鏈接

還有就是鏈接兩個無界數據源的時候，沒有時間邏輯。

圖六 無界數據內鏈接

近似算法

比圖top-N K-means等算法，值得注意的是：這些算法在設計中一般會有一些時間元素，而且因爲它們在到達時處理

，所以該時間元素一般基於處理時間。這可能會影響計算的偏差，若是這些偏差範圍是以按順序到達的數據爲基礎的

，那麼這種數據並不可信。

圖七 無界數據近似值

處理時間窗口化

先介紹一下窗口，有三種窗口模式

圖八 三種窗口

固定窗口：固定窗口將時間切割成具備固定大小時間長度的段。

滑動窗口：固定窗口的升級，滑動窗口由固定長度和固定週期定義。週期小於長度，則窗口重疊。若是週期等於長度，有固 定的窗口。若是週期大於長度，則會有一個的採樣窗口，它只會隨着時間的推移查看數據的子集。

會話：動態的窗口，會話由一系列事件組成，這些事件會超時而終止。會話一般用於經過將一系列與時間相關的事件組合在一塊兒來分析用戶隨時間的行爲。長度並不固定。

下面先來討論處理時間窗口化：

當按處理時間窗口化時，系統基本上將輸入數據緩衝到一個窗口中，直到通過必定量的處理時間後再作處理。例如，在五分鐘固定窗口的狀況下，系統會將數據緩衝五分鐘的處理時間，以後它會將這五分鐘內觀察到的全部數據視爲一個窗口並將它們發送到下游進行處理。

圖九 處理時間窗口

處理時間窗口的優勢：

簡單：不用擔憂去改變數據。

窗口完整性：因爲系統徹底瞭解是否已經看到窗口的全部輸入，所以能夠完美的判斷窗口完整。

處理時推斷源的信息：好比監控系統。

可是處理時間窗口有一個很是大的缺點：若是數據有和他們關聯的事件時間，弱國處理時間窗口要反映實際上這些事件的實際狀況，那麼這些數據必須順序到達，但事實上大部分並不有序。

因此咱們須要的是一種對時間到達順序更穩的方式，也就是事件時間窗口。

事件時間窗口化

將無界數據化爲固定窗口。

圖10 將事件時間固定到固定窗口

圖中的實線白線表示兩個特別感興趣的數據。這兩個數據都到達處理時間窗口，這些時間窗口與它們所屬的事件時間窗口不匹配。所以，若是這些數據已被窗口化爲處理關注事件時間的處理時間窗口，則計算結果將是不正確的。因此事件時間窗口才是正確性的體現。

圖11 也能夠建立動態的窗口

事件時間窗口有兩個明顯的缺點，由於窗口必須更長。

緩衝：因爲延長了窗口的生命週期，所以須要更多的數據緩衝。這個問題能夠經過持久儲存和增量解決。

完整性：這個須要系統自己根據狀況作出估計。

3、將來

咱們定義了流的概念。正確性和推理時間的工具是關鍵。

經過分析事件時間和處理時間的差別，以及無界數據和有界數據，無界數據大體分爲：不關心時間，近似算法，處理時間窗口化，事件時間窗口化。

目前來看，時間問題多是咱們須要重點解決的問題，在102中介紹了一種實時流式處理模型，這也是將來實時計算領域的基石。

讓實時處理儘快融入到無限數據的系統中，爲用戶提供高延遲，高效率間的靈活選擇，纔是咱們將來努力的方向。

更多實時計算，Kafka等相關技術博文，歡迎關注實時流式計算