這篇總結來自極客時間專欄《大規模數據處理實踐》的 10-11 節。
關于第八節 CAP 的內容可以參考之前總結的另一篇文章 分布式系統的一致性協議之 2PC 和 3PC，這里就不再詳述了。
關于 Lambda 架構和 Kappa 架構可以參考我之前總結的這篇文章 第一章 Streaming 101（里面有過簡單的介紹）.
Lambda 架構
Lambda 架構算是第一代大數據處理架構，提出之后在工業屆得到廣泛應用，其大概的架構如下所示：
Lambda 架構分為三層：
- Batch Layer：批處理層，存儲管理主數據集（不可變的數據集）和預先批處理計算好的視圖，批處理層使用可處理大量數據的分布式處理系統預先計算結果。它通過處理所有的已有歷史數據來實現數據的準確性。這意味著它是基于完整的數據集來重新計算的，能夠修復任何錯誤，然后更新現有的數據視圖（準確性有保證）；
- Speed Layer：速度處理層，主要是提供最新數據來減少延遲（偏實時/準實時計算）；
- Serving Layer：用于響應查詢的服務層，所有在前面兩層處理的數據都會存儲在服務層，服務層向外部提供查詢服務。
Lambda 架構可以做到實時分析，又能通過批計算保證過去數據的正確性，在實時計算還不很準確的時代，這種架構非常受歡迎。
Lambda 架構的問題是什么呢？
- 最主要的就是要維護兩套系統，當業務變得非常復雜時，這個維護成本是非常高的；
個人看法：就 Lambda 架構本身而言，其對業內的影響無疑是成功的，這種架構直到現在依然在廣泛應用，這種架構的提出也跟其特殊歷史背景有關。
Lambda 提出的時代，一說到流計算，大家的第一印象就是不準確、估計值等，當時 DataFlow 模型還沒出現，如果沒算錯，Spark Streaming 應該也沒出現，這時候業務既想通過 storm 去做實時分析又想使用批處理去做數據校準/或者是預分析歷史數據，Lambda 在那個時代給業內帶來了一個全新的思路，在大數據處理歷史上有跨時代的意義。
Kappa 架構
Kappa 架構是 Jay Kreps（Kafka 和 Samza 的作者之一）提出的一個種架構思想，架構框圖如下：
Kappa 架構思想主要是：讓速度處理層也可以做之前批處理層做的事情，這樣就不需要去維護兩套系統了。
那么，Kappa 的問題是什么？
- Kappa 架構只保留了速度層而缺少批處理層，在速度層上處理大規模數據可能會有數據更新出錯的情況發生（數據出錯的問題是非常難排查的）；
- Kappa 架構的批處理和流處理都放在了速度層上，這導致了這種架構是使用同一套代碼來處理算法邏輯的，所以 Kappa 架構并不適用于批處理和流處理代碼邏輯不一致的場景。
個人看法：Kappa 思想其實可以再進一步，就現在經常說的【批流統一】，批其實只是流的其中一種形態，這個就是后來 DataFlow 的主要思想。這些架構思想對業內的影響很大，基本上決定了這個領域的發展，不過比較可惜的是，這些牛逼的思路和想法現在還都是硅谷在引領，希望有一天國內能引領某些領域的發展。
有興趣的同學，可以通過下面的鏈接購買，會有一些優惠
