- Lambda 架構
Lambda 架構由Storm的作者Nathan Marz提出，其設計目的在於提供一個能滿足大數據系統關鍵特性的架構，包括高容錯、低延遲、可擴展等。其整合離線計算與實時計算，融合不可變性、讀寫分離和複雜性隔離等原則，可集成Hadoop, Kafka, Spark，Storm等各類大數據組件。
Lambda 架構可分解爲三層Layer，即Batch Layer, Real-Time(Speed) Layer和Serving Layer。
- Batch Layer : 存儲數據集，在數據集上預先計算查詢函數，並構建查詢所對應的View。Batch Layer可以很好的處理離線數據，但有很多場景數據是不斷實時生成且需要實時查詢處理，對於這情況， Speed Layer更爲適合。
- Speed Layer : Batch Layer處理的是全體數據集，而Speed Layer處理的是最近的增量數據流。Speed Layer爲了效率，在接收到新的數據後會不斷更新Real-time View，而Batch Layer是根據全體離線數據集直接得到Batch View。
- Serving Layer : Serving Layer用於合併Batch View和Real-time View中的結果數據集到最終數據集。
一個典型的Lambda架構如下，
這種架構主要面向的場景是邏輯比較複雜同時又希望延遲比較低的異步處理程序，比如搜索引擎、推薦引擎等。
系統從一個流中讀取被我們定義爲不可變的數據，分別灌入實時系統如Storm和批處理系統如Hadoop，然後各自輸出自己的結果，這些結果會在查詢端進行合併。當然，這種系統也可有很多變種，比如上圖中的Kafka也可替換成其他的分佈式隊列，Storm也可以替換成其他的流式計算引擎。
- Kappa 架構
Kappa 架構是LinkedIn的Jay Kreps結合實際經驗和個人體會，針對Lambda架構進行深度剖析，分析其優缺點並採用的替代方案。Lambda 架構的一個很明顯的問題是需要維護兩套分別跑在批處理和實時計算系統上面的代碼，而且這兩套代碼得產出一模一樣的結果。因此對於設計這類系統的人來講，要面對的問題是：爲什麼我們不能改進流計算系統讓它能處理這些問題？爲什麼不能讓流系統來解決數據全量處理的問題？流計算天然的分佈式特性註定其擴展性比較好，能否加大併發量來處理海量的歷史數據？基於種種問題的考慮，Jay提出了Kappa這種替代方案。
那如何用流計算系統對全量數據進行重新計算，步驟如下：
1、用Kafka或類似的分佈式隊列保存數據，需要幾天數據量就保存幾天。
2、當需要全量計算時，重新起一個流計算實例，從頭開始讀取數據進行處理，並輸出到一個結果存儲中。
3、當新的實例完成後，停止老的流計算實例，並把老的一引起結果刪除。
一個典型的Kappa架構如下，
