在介紹Lambda和Kappa架構(gòu)之前，我們先回顧一下數(shù)據(jù)倉庫的發(fā)展歷程： 傳送門-數(shù)據(jù)倉庫發(fā)展歷程

寫在前面

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

架構(gòu)組成特點

經(jīng)典數(shù)倉架構(gòu)	關(guān)系型數(shù)據(jù)庫（mysql、oracle）為主	數(shù)據(jù)量小，實時性要求低
離線大數(shù)據(jù)架構(gòu)	hive，spark為主	數(shù)據(jù)量大，實時性要求低
Lambda	hive，spark負責(zé)存量，strom/Flink負責(zé)實時計算	數(shù)據(jù)量大，實時性要求高
Kappa	kafka、strom、Flink	多業(yè)務(wù)，多數(shù)據(jù)源，事件型數(shù)據(jù)源
混合架構(gòu)

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

Lambda

Lambda架構(gòu)原理

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

Lambda架構(gòu)的缺點

Lambda架構(gòu)解決了大數(shù)據(jù)量下實時計算的問題，但架構(gòu)本身也存在一定缺點。

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

Kappa

Kappa架構(gòu)原理

Kappa架構(gòu)的核心思想包括以下三點：

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

Lambda架構(gòu)和Kappa架構(gòu)優(yōu)缺點對比

項目LambdaKappa

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

小結(jié)

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

小編有話

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。