六年前提起實時流式計算，熟悉的同學會想起Storm，三年前提起，大家應該會想到Spark Streaming，現在再提起那無疑是Flink了。可見開源世界技術的迭代是飛速的，稍不留神就落伍了，所以我們要不停地學習，跟著技術的浪潮上下翻滾，但是你學習的速度也無法總是跟得上技術的更替，所以年紀大了依舊可能被淘汰，前浪總是會拍打到沙灘上，“你有沒有這種感覺，好像一生都身不由己”。
好了先不思考人生了，言歸正傳。
我們先把 storm/spark/flink 這些花裡胡哨的技術都拋開，這些我之後的文章會詳細講，現在就說說實時流式計算本身。流式計算有什麼用呢？實際場景會告訴你：
1. 場景
流處理適用場景還是很豐富的，它最大的特點就是及時，試想一些，沒有下面的這些流式計算系統，公司會損失多少MONEY：
- 需要實時異常檢測的欺詐/風控等系統
- 需要實時檢視交易額的交易系統
- 需要實時計算點選/計算分成的廣告系統
- 需要實時更新使用者標籤的實時使用者畫像系統
- 需要實時根據使用者喜好推薦商品的實時推薦系統
2. 時間
時間對於批計算來說好像沒有什麼特別的，就是一個欄位而已，但是流式計算裡，除了欄位裡的那個時間（專業點，我們稱這個時間為事件時間event-time）還有一個資料到達的時間及處理系統的當前時間（處理時間process-time）。
那問題來了，為什麼要管這個處理時間？因為資料會有延遲，你處理的時間批次裡，可能會有很久之前的資料延遲到了現在，也有可能現在的資料沒有及時到達導致缺數。
不知道看到這裡大家會不會想到大資料比較常用的Lambda架構，先提供時效性高準確性較低的結果，然後對之前的資料做矯正，保證最終正確性（當然前提條件是批處理作業啟動時，需要的資料應該已經全部到達了）。對於這個問題的解決辦法其實是和Lambda架構類似的，後面我會細說。
看上面的文字描述可能會有點抽象，我們先來看看下面這幅圖，橫軸為事件時間，縱軸為處理時間，圈起來的數字代表真實的資料，它們分別都有事件時間和處理時間，在兩者相同的理想情況下，就如同下面淺色的虛線是一條直線，這樣是最好處理的，但是實際情況卻是很曲折的，如深色的虛線，我們把虛線稱為水位線，水位線是根據一定演算法根據最近處理的事件的事件時間估算出來的，可以作為事件的觸發的一個參考項。
3. 視窗
上面提到了事件時間和處理時間，寫過SparkStreaming的同學應該知道它有一個處理時間的視窗，就是說可以對某個時間視窗內的資料進行聚合或者其他操作，但是這個時間視窗的時間是基於處理時間的，同樣會有上面提到的問題，資料延遲了怎麼辦？
那麼理所當然會有人提出基於事件時間的視窗，這個處理方式就是《Google：DataFlow》中提出來的，spark和flink後來都有了相應的工程實現。
4. 觸發
所謂觸發（Triggers）即時間視窗結束後對資料的處理方式。我們直接來看《DataFlow》中的幾種觸發機制。
- 拋棄（discarding）:
觸發後，不會保留上次計算結果的資料，因為之後視窗計算的結果和之前的結果不存在相關性。當下遊的資料消費者（不管是資料處理管道的內部還是外部）希望觸發計算結果之間相互獨立（比如對插入的資料進行求和的場景），那麼這種情況就比較適用。 - 累積（accumulating）:
觸發後，視窗內容被完整保留住持久化的狀態中， 後面延遲的結果會對之前的結果進行矯正。這也是Lambda架構使用的方式，流處理管道產出低延遲的結果，之後被批處理管道的結果覆蓋掉 - 累計和撤回（retraction）:
觸發後，在進行累積語義的基礎上，計算結果的一份複製也被保留到持久化狀態中。當視窗將來再次觸發時，上一次的結果值先下發做撤回處理，然後新的結果作為正常資料下發。
撤回的操作適用於資料處理管道有多個序列的 GroupByKeyAndWindow 場景，撤回是必要的，因為同一個視窗的不同觸發計算結果可能在下游會被分組到不同鍵中去，這句話是關鍵，不知道大家有沒有理解，簡單地說就是，觸發時間的變化可能會導致這條延遲資料被分配到的組的變化，從而導致後續的聚合計算不準確，所以需要把之前的資料撤回，帶上這條資料一起再做一次GroupByKeyAndWindow。
5. 結語
這一篇提到的很多概念和名字很多同學可能一時會比較難消化，確實比較抽象，所以沒關係，後面講到flink的時候會舉具體的例子給大家看，這一篇只是和大家介紹下流式計算以及在流式計算中你需要重點關注的幾個點：時間/視窗/觸發，記住這三個詞也是一個收穫。
另外，大家有精力有時間有興趣的話，推薦大家好好看看Google在2015年釋出的一篇關於實時流式計算的論文，《The Dataflow Model》，這篇論文催生了spark的structed streaming以及給了當初默默無聞的flink成就現在輝煌的靈感。用詞好像有點浮誇了，但是它確實是在流式計算領域很有指導性意義的一篇論文。
覺得有價值請關注 ▼
