為了進一步探討這種批處理和實時處理有效整合在同一系統的架構，我們將在今天的文章中分析Lambda三層結構模型的適用場景，同時暴露出Lambda架構一個最明顯的問題：它需要維護兩套分別跑在批處理和實時計算系統上面的代碼，而且這兩套代碼需要產出一致的結果。根據對此缺點的分析，我們引出當時還在LinkedIn的大神Jay Kreps提出的Kappa架構，本文會對Kappa架構原理進行介紹，並討論兩個架構的優缺點，最后給出一個Kappa架構的案例分析。
Lambda架構回顧Lambda架構的核心思想是把大數據系統拆分成三層：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer負責數據集存儲以及全量數據集的預查詢。Speed Layer主要負責對增量數據進行計算，生成Realtime Views。Serving Layer用於響應用戶的查詢請求，它將Batch Views和Realtime Views的結果進行合並，得到最后的結果，返回給用戶。圖1給出了Lambda的整體架構圖：
Kappa架構上述提到，為了將批處理和實時處理相結合，Lambda設計了Batch Layer和Speed Layer兩層結構，分別用於批處理和實時計算，因此需要維護兩套分別跑在批處理和實時計算系統之上的代碼。面對這個問題，有人會有這樣的疑問，為什么不用流計算系統來進行全量數據處理從而去除Batch Layer這一層?
可能有這樣回答：流計算給人的印象是對一些流式的、臨時的數據進行計算，將結果保存后就將原始數據丟棄了，因此它不適合用來處理歷史數據。其實這種答案並不完全正確，對於基於Lambda架構實現的Storm框架確實是這樣的，但對於后來出現的Spark並不是。
Storm是在2011年7月開源的，Spark是在2012年之后逐漸為人們所知的，因此在Nathan Marz設計Lambda架構的時候，當時還並沒有一個框架既可以用於離線處理，又可以進行實時計算。但隨着Spark技術的發展，這一想法成為了可能，Spark本身可以用於批處理，而構建在Spark之上的Spark Streaming又可以用於實時計算，因此利用一套系統來應對批處理和實時計算相結合的業務完全是可行的。
Kappa架構的核心思想包括以下三點：
- 用Kafka或者類似的分布式隊列系統保存數據，你需要幾天的數據量就保存幾天。
- 當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數據進行處理，並輸出到一個新的結果存儲中。
- 當新的實例做完后，停止老的流計算實例，並把老的一些結果刪除。
Kappa的架構圖如圖2所示：
和Lambda架構相比，在Kappa架構下，只有在有必要的時候才會對歷史數據進行重復計算，並且實時計算和批處理過程使用的是同一份代碼。或許有些人會質疑流式處理對於歷史數據的高吞吐量會力不從心，但是這可以通過控制新實例的並發數進行改善。
上面架構圖中，新老實例使用了各自的結果存儲，這便於隨時進行回滾，更進一步，假如我們產出的是一些算法模型之類的數據，用戶還可以同時對新老兩份數據進行效果驗證，做一些A/B test或者使用bandit算法來最大限度的使用這些數據。
兩個架構的對比優缺點對比
如上表所示，Kappa架構相對來說有更多的優點，目前也被更多的廠商用於構建商業項目。
第一，Lambda架構不僅需要維護兩套分別跑在批處理和實時計算系統上面的代碼，還需要批處理和全量計算長時間保持運行;而Kappa架構只有在需要的時候才進行全量計算。
第二，Kappa架構下可以啟動很多個實例進行重復計算，因此在需要對一些算法模型進行調優時，Kappa架構下只需要更改一套系統的參數即可，並且允許對新老數據進行效果比對;但是在Lambda架構下，需要同時更改流計算系統算法模型和批處理系統算法模型，調參過程相對比較復雜。
第三，從用戶開發、測試和運維的角度來看，Kappa架構下，開發人員只需要面對一個框架，開發、測試和運維的難度都會相對較小，這是個非常重要的優點。
轉自：http://www.36dsj.com/archives/66641