在介紹Lambda和Kappa架構之前，我們先回顧一下數據倉庫的發展歷程： 傳送門-數據倉庫發展歷程

寫在前面

咳，隨著數據量的暴增和數據實時性要求越來越高，以及大數據技術的發展驅動企業不斷升級迭代，數據倉庫架構方面也在不斷演進，分別經歷了以下過程：早期經典數倉架構 > 離線大數據架構 > Lambda > Kappa > 混合架構。

架構組成特點

經典數倉架構	關系型數據庫（mysql、oracle）為主	數據量小，實時性要求低
離線大數據架構	hive，spark為主	數據量大，實時性要求低
Lambda	hive，spark負責存量，strom/Flink負責實時計算	數據量大，實時性要求高
Kappa	kafka、strom、Flink	多業務，多數據源，事件型數據源
混合架構

ps.表中舉例若有不當，歡迎指正

Lambda

Lambda架構原理

Lambda架構的核心思想是把大數據系統拆分成三層：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer負責數據集存儲以及全量數據集的預查詢。Speed Layer主要負責對增量數據進行計算，生成Realtime Views。Serving Layer用于響應用戶的查詢請求，它將Batch Views和Realtime Views的結果進行合并，得到最后的結果，返回給用戶，如下圖

Lambda架構的缺點

Lambda架構解決了大數據量下實時計算的問題，但架構本身也存在一定缺點。

• 實時與批量計算結果不一致引起的數據口徑問題：因為批量和實時計算走的是兩個計算框架和計算程序，算出的結果往往不同，經常看到一個數字當天看是一個數據，第二天看昨天的數據反而發生了變化。
• 批量計算在計算窗口內無法完成：在IOT時代，數據量級越來越大，經常發現夜間只有4、5個小時的時間窗口，已經無法完成白天20多個小時累計的數據，保證早上上班前準時出數據已成為每個大數據團隊頭疼的問題。
• 開發和維護的復雜性問題：Lambda 架構需要在兩個不同的 API（application programming interface，應用程序編程接口）中對同樣的業務邏輯進行兩次編程：一次為批量計算的ETL系統，一次為流式計算的Streaming系統。針對同一個業務問題產生了兩個代碼庫，各有不同的漏洞。這種系統實際上非常難維護
• 服務器存儲大：數據倉庫的典型設計，會產生大量的中間結果表，造成數據急速膨脹，加大服務器存儲壓力。

Kappa

Kappa架構原理

Kappa架構的核心思想包括以下三點：

• 用Kafka或者類似的分布式隊列系統保存數據，你需要幾天的數據量就保存幾天。
• 當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數據進行處理，并輸出到一個新的結果存儲中。
• 當新的實例做完后，停止老的流計算實例，并把老的一些結果刪除。
  在Kappa架構下，只有在有必要的時候才會對歷史數據進行重復計算，并且實時計算和批處理過程使用的是同一份代碼。

Lambda架構和Kappa架構優缺點對比

項目LambdaKappa

數據處理能力	可以處理超大規模的歷史數據	歷史數據處理的能力有限
機器開銷	批處理和實時計算需一直運行，機器開銷大	必要時進行全量計算，機器開銷相對較小
存儲開銷	只需要保存一份查詢結果，存儲開銷較小	需要存儲新老實例結果，存儲開銷相對較大
開發、測試難度	實現兩套代碼，開發、測試難度較大	只需面對一個框架，開發、測試難度相對較小
運維成本	維護兩套系統，運維成本大	只需維護一個框架，運維成本小

小結

• Lambda 將全量歷史數據和實時增量數據合并輸出。
• Kappa 兩個流協作輸出，queries每次使用最新一個流處理結果

小編有話

目前很多準實時增量批處理方案也能滿足實時性需求，從穩定性和運維成本上也表現更佳。
比如kudu（存儲）+impala（計算）準實時方案，可以實現千萬級數據的增量更新和olap查詢，性能優異。

數倉系列傳送門：https://blog.csdn.net/weixin_39032019/category_8871528.html

總結

以上是生活随笔為你收集整理的一篇文章搞懂数据仓库：数据仓库架构-Lambda和Kappa对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。