第一章， Streaming 101（大學一般入門課程編號是101，所以這裡的101只是代表入門）
大數據處理中的流式數據處理日益盛行，究其原因主要有以下幾點
- 企業期望更加及時的洞察數據，因此切換到流式進行處理是一個降低延遲的更好選擇
- 當今商業環境更多大量，無邊的數據普遍出現，需要對應的系統來處理這樣的數據
- 數據到達即處理，可以更好的使用資源和保證資源的一致性
儘管商業上對於流失系統的需求很強量，但是長期而來，流式系統依舊不夠成熟，目前這一事情有所緩解，我認為主要是我的流式101和102兩篇博客的刺激，目前工業界有很多人期望看到流式的蓬勃發展，也有很多同僚熱衷於此
儘管在前期的戰鬥中有一些收貨，但是我依舊會強調一下在101中的一些概念，避免很多讀者並不知道這個前置信息
開始之前，我們先確定一個專有概念和背景信息
Terminology: What Is Streaming?
先明確一下，什麼是streaming？streaming現在含義眾多，而且容易讓人誤入歧途，所以期望進行重新定義什麼是streaming。
關鍵問題是，過去更多的時候我們用how來描述streaming，更多的時候其實應該用what來描述。由於缺少這些精確的定義。導致流式系統長期依賴代表不精確和推測的結果。
一個精心設計的流式系統應該可以如批量系統一下產出，正確的，一致的，可復現的結果。我傾向於給“streaming”一個特殊的定義
流式系統
一類處理引擎用來處理無限數據
假如我來說低延遲，粗略，或者推測的結果我會直接使用這些名詞，而不是簡單的說他們是“streaming”
在我們討論不同類型的數據的時候，精確的術語也是很重要的，會有兩個維度來定義一個數據集，基數和數據模型（原文是constitution，由於後面描述constitution有table和stream兩種形式，所以乾脆翻譯成數據模型），基數決定數據集的大小，用兩個概念來粗略的描述基數大小有限數據
一類數據有限的大小
無限制數據
理論上的一類數據有無限的大小
基數比較重要，因為無邊際的特性導致數據的處理面臨更多的挑戰，更多的細節後面講進行討論。
另一方面，數據模型描述了對於數據的抽象，並且決定了數據的交互形式，目前不深入介紹，在第六章，將給深入的介紹，目前給出兩個重要的構成，
Table
在某一時刻對於數據的歷史表現，傳統方法使用SQL來處理
Stream
一個接一個的元素，MR這些書序的數據處理系統傳統意義上來處理流式
在6，8，9章中，講更加深入的介紹streams and tables 之間的關係
On the Greatly Exaggerated Limitations of Streaming
接下來讓我們明確一下流系統可以做什麼和不能做什麼 從歷史上看，流媒體系統一直侷限於提供低延遲，不準確或推測性結果的小眾市場，通常與功能更強大的批處理系統結合使用，以提供最終正確的結果。 換句話說，就是Lambda架構。
Lambda架構的基本思想是運行兩套系統，一套是流式的，一套是批量的，做同樣的計算和處理，流式系統給一個低延遲的，但是不精確的結果。正確的結果，需要批量系統後續給出。這個概念最初由Twitter的Nathan Marz提出。在當時的場景下這樣一個概念十分受到歡迎。但是Lambda也存在明顯的問題，同時維護兩套系統的代價和成本都很高，而且還要最終合併兩條數據鏈路的結果。
本人一直比較支持強一致的流式系統，同樣比較贊成jay kreps的文章“questioning the lambda Architecture“，他提出了kappa架構，利用單個系統來實現需求，而不是利用流式和批量兩套系統。
閱讀更多 北京IT民工 的文章
