一、 Lambda架構
Storm的創始人Nathan Marz提出的Lambda架構是現在進行實時處理的常見架構。它設計的目的是以低延遲處理和更新數據、支持線性擴展和容錯機制。速度層可以直接消費kafka中的數據，也可以對數據進行分層再消費都可以。如下圖：
優點：
穩定，對於實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰
分開，這種架構支撐了數據行業的早期發展，但是它也有一些致命缺點，並在大數據3.0時代越來越不適應數據分析業務的需求
缺點：
● 實時與批量計算結果不一致引起的數據口徑問題：因為批量和實時計算走的是兩個計算框架和計算程序，算出的結果往往
不同，經常看到一個數字當天看是一個數據，第二天看昨天的數據反而發生了變化。
● 批量計算在計算窗口內無法完成：在IOT時代，數據量級越來越大，經常發現夜間只有4、5個小時的時間窗口，已經無法完成
白天20多個小時累計的數據，保證早上上班前准時出數據已成為每個大數據團隊頭疼的問題。
●數據源變化都要重新開發，開發周期長：每次數據源的格式變化，業務的邏輯變化都需要針對ETL和Streaming做開發修改，
整體開發周期很長，業務反應不夠迅速。
● 服務器存儲大：數據倉庫的典型設計，會產生大量的中間結果表，造成數據急速膨脹，加大服務器存儲壓力。
● 離線和實時數據計算結果的merge成本比較大，比如離線的數據在數據倉庫Hive，就算是通過sqoop導進了mysql，
實時的在hbase、redis等，兩個數據打通融合展示，都是問題。
二、 Kappa架構
LinkedIn的Jay Kreps結合實際經驗和個人體會提出了Kappa架構。Kappa架構的核心思想是通過改進流計算系統來解決數據全量處理的問題，使得實時計算和批處理過程使用同一套代碼。此外Kappa架構認為只有在有必要的時候才會對歷史數據進行重復計算，而如果需要重復計算時，Kappa架構下可以啟動很多個實例進行重復計算。
如下圖：
Kappa架構只關注流式計算，並不是取代Lambda架構，除非完全滿足你的使用案例。對於這種架構，數據以流的方式
被采集過來，實時層(Real-time Layer)將計算結果放入服務層(Serving Layer)以供查詢。
核心思想，主要包括以下三點：
1.用Kafka或者類似MQ隊列系統收集各種各樣的數據，你需要幾天的數據量就保存幾天。
2.當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數據進行處理，並輸出到一個新的結果存儲中。
3.當新的實例做完后，停止老的流計算實例，並把老的一些結果刪除。
優點：
將實時和離線代碼統一起來，方便維護而且統一了數據口徑的問題。
缺點：
● 流式處理對於歷史數據的高吞吐量力不從心：所有的數據都通過流式計算，即便通過加大並發實例數亦很難適應IOT時代
對數據查詢響應的即時性要求。
● 開發周期長：此外Kappa架構下由於采集的數據格式的不統一，每次都需要開發不同的Streaming程序，導致開發周期長。
● 服務器成本浪費：Kappa架構的核心原理依賴於外部高性能存儲redis,hbase服務。但是這2種系統組件，又並非設計來滿足
全量數據存儲設計，對服務器成本嚴重浪費。
三、對比總結
許多實時案例適用於Lambda架構，同樣kappa也有適用領域。如果流處理與批處理分析流程比較統一，用Kappa比較合適。然而在其他一些場景中，需要對整個數據集進行批量處理而且優化空間較低，使用Lambda架構性能會更好，實現也更簡單。
還有一些比較復雜的場景，批處理與流處理產生不同的結果（使用不同的機器學習模型，專家系統，或者實時計算難以處理的復雜計算），可能更適合Lambda架構。