Kappa 架構是由 LinkedIn 的前首席工程師傑伊·克雷普斯（Jay Kreps）提出的一種架構思想。克雷普斯是幾個著名開源項目（包括 Apache Kafka 和 Apache Samza 這樣的流處理系統）的作者之一。
Kreps 提出了一個改進 Lambda 架構的觀點：
- 通過改進 Lambda 架構中的Speed Layer，使它既能夠進行實時數據處理，同時也有能力在業務邏輯更新的情況下重新處理以前處理過的歷史數據
Kappa架構的原理就是：在Lambda 的基礎上進行了優化，刪除了 Batch Layer 的架構，將數據通道以消息隊列進行替代。因此對於Kappa架構來說，依舊以流處理為主，但是數據卻在數據湖層面進行了存儲，當需要進行離線分析或者再次計算的時候，則將數據湖的數據再次經過消息隊列重播一次則可。
kappa架構圖
Kappa 處理過程
以 Apache Kafka 為例來講述整個全新架構的過程：
- 部署 Apache Kafka，並設置數據日志的保留期（Retention Period）。這里的保留期指的是你希望能夠重新處理的歷史數據的時間區間
- 例如，如果你希望重新處理最多一年的歷史數據，那就可以把 Apache Kafka 中的保留期設置為 365 天。
- 如果你希望能夠處理所有的歷史數據，那就可以把 Apache Kafka 中的保留期設置為“永久（Forever）”
- 如果我們需要改進現有的邏輯算法，那就表示我們需要對歷史數據進行重新處理
- 我們需要做的就是重新啟動一個 Apache Kafka 作業實例（Instance）。這個作業實例將從頭開始，重新計算保留好的歷史數據，並將結果輸出到一個新的數據視圖中。
- 我們知道 Apache Kafka 的底層是使用 Log Offset 來判斷現在已經處理到哪個數據塊了，所以只需要將 Log Offset 設置為 0，新的作業實例就會從頭開始處理歷史數據。
- 當這個新的數據視圖處理過的數據進度趕上了舊的數據視圖時，我們的應用便可以切換到從新的數據視圖中讀取。
- 停止舊版本的作業實例，並刪除舊的數據視圖。
再增加一個示例圖說明：
Kappa問題
Kappa架構的優點在於將實時和離線代碼統一起來，方便維護而且統一了數據口徑的問題。而Kappa的缺點也很明顯：
- 消息中間件緩存的數據量和回溯數據有性能瓶頸。通常算法需要過去180天的數據，如果都存在消息中間件，無疑有非常大的壓力。同時，一次性回溯訂正180天級別的數據，對實時計算的資源消耗也非常大。
- 在實時數據處理時，遇到大量不同的實時流進行關聯時，非常依賴實時計算系統的能力，很可能因為數據流先后順序問題，導致數據丟失。
- Kappa在拋棄了離線數據處理模塊的時候，同時拋棄了離線計算更加穩定可靠的特點。Lambda雖然保證了離線計算的穩定性，但雙系統的維護成本高且兩套代碼帶來后期運維困難。
Lambda架構和Kappa架構的優缺點
混合分析系統的Kappa架構示例
Lambda 和 Kappa 架構都還有展示層的困難點，結果視圖如何支持ad-hoc查詢分析，一個解決方案是在Kappa基礎上衍生數據分析流程，如下圖，在基於使用Kafka + Flink構建Kappa流計算數據架構，針對Kappa架構分析能力不足的問題，再利用Kafka對接組合ElasticSearch實時分析引擎，部分彌補其數據分析能力。但是ElasticSearch也只適合對合理數據量級的熱數據進行索引，無法覆蓋所有批處理相關的分析需求，這種混合架構某種意義上屬於Kappa和Lambda間的折中方案。
參考資料