一、概要

數(shù)據(jù)倉庫概念是 Inmon 于 1990 年提出并給出了完整的建設(shè)方法。隨著互聯(lián)網(wǎng)時代來臨，數(shù)據(jù)量暴增，開始使用大數(shù)據(jù)工具來替代經(jīng)典數(shù)倉中的傳統(tǒng)工具。此時僅僅是工具的取代，架構(gòu)上并沒有根本的區(qū)別，可以把這個架構(gòu)叫做離線大數(shù)據(jù)架構(gòu)。后來隨著業(yè)務(wù)實時性要求的不斷提高，人們開始在離線大數(shù)據(jù)架構(gòu)基礎(chǔ)上加了一個加速層，使用流處理技術(shù)直接完成那些實時性要求較高的指標(biāo)計算，這便是 Lambda 架構(gòu)。再后來，實時的業(yè)務(wù)越來越多，事件化的數(shù)據(jù)源也越來越多，實時處理從次要部分變成了主要部分，架構(gòu)也做了相應(yīng)調(diào)整，出現(xiàn)了以實時事件處理為核心的 Kappa 架構(gòu)。

數(shù)倉架構(gòu)演變

二、離線大數(shù)據(jù)架構(gòu)

離線大數(shù)據(jù)架構(gòu)

數(shù)據(jù)源通過離線的方式導(dǎo)入到離線數(shù)倉中。下游應(yīng)用根據(jù)業(yè)務(wù)需求選擇直接讀取 DM 或加一層數(shù)據(jù)服務(wù)，比如 MySQL 或 Redis。數(shù)據(jù)倉庫從模型層面分為三層：

• ODS，操作數(shù)據(jù)層，保存原始數(shù)據(jù)；
• DWD，數(shù)據(jù)倉庫明細(xì)層，根據(jù)主題定義好事實與維度表，保存最細(xì)粒度的事實數(shù)據(jù)；
• DM，數(shù)據(jù)集市/輕度匯總層，在 DWD 層的基礎(chǔ)之上根據(jù)不同的業(yè)務(wù)需求做輕度匯總；
  典型的數(shù)倉存儲是 HDFS/Hive，ETL 可以是 MapReduce 腳本或 HiveSQL。

三、Lambda 架構(gòu)

隨著大數(shù)據(jù)應(yīng)用的發(fā)展，人們逐漸對系統(tǒng)的實時性提出了要求，為了計算一些實時指標(biāo)，就在原來離線數(shù)倉的基礎(chǔ)上增加了一個實時計算的鏈路，并對數(shù)據(jù)源做流式改造（即把數(shù)據(jù)發(fā)送到消息隊列），實時計算去訂閱消息隊列，直接完成指標(biāo)增量的計算，推送到下游的數(shù)據(jù)服務(wù)中去，由數(shù)據(jù)服務(wù)層完成離線&實時結(jié)果的合并。

注：流處理計算的指標(biāo)批處理依然計算，最終以批處理為準(zhǔn)，即每次批處理計算后會覆蓋流處理的結(jié)果。（這僅僅是流處理引擎不完善做的折中）

Lambda 架構(gòu)問題：

• 同樣的需求需要開發(fā)兩套一樣的代碼：這是 Lambda 架構(gòu)最大的問題，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求，一個在批處理引擎上實現(xiàn)，一個在流處理引擎上實現(xiàn)，還要分別構(gòu)造數(shù)據(jù)測試保證兩者結(jié)果一致），后期維護更加困難，比如需求變更后需要分別更改兩套代碼，獨立測試結(jié)果，且兩個作業(yè)需要同步上線。
• 資源占用增多：同樣的邏輯計算兩次，整體資源占用會增多（多出實時計算這部分）

Lambda 架構(gòu)

四、Kappa 架構(gòu)

Lambda 架構(gòu)雖然滿足了實時的需求，但帶來了更多的開發(fā)與運維工作，其架構(gòu)背景是流處理引擎還不完善，流處理的結(jié)果只作為臨時的、近似的值提供參考。后來隨著 Flink 等流處理引擎的出現(xiàn)，流處理技術(shù)很成熟了，這時為了解決兩套代碼的問題，LickedIn 的 Jay Kreps 提出了 Kappa 架構(gòu)。

• Kappa 架構(gòu)可以認(rèn)為是 Lambda 架構(gòu)的簡化版（只要移除 lambda 架構(gòu)中的批處理部分即可）。
• 在 Kappa 架構(gòu)中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成。
• Kappa 架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會低于批處理，但這個可以通過增加計算資源來彌補。

Kappa 架構(gòu)

Kappa 架構(gòu)的重新處理過程：重新處理是人們對 Kappa 架構(gòu)最擔(dān)心的點，但實際上并不復(fù)雜：

• 選擇一個具有重放功能的、能夠保存歷史數(shù)據(jù)并支持多消費者的消息隊列，根據(jù)需求設(shè)置歷史數(shù)據(jù)保存的時長，比如 Kafka，可以保存全部歷史數(shù)據(jù)。
• 當(dāng)某個或某些指標(biāo)有重新處理的需求時，按照新邏輯寫一個新作業(yè)，然后從上游消息隊列的最開始重新消費，把結(jié)果寫到一個新的下游表中。
• 當(dāng)新作業(yè)趕上進度后，應(yīng)用切換數(shù)據(jù)源，讀取 2 中產(chǎn)生的新結(jié)果表。
  停止老的作業(yè)，刪除老的結(jié)果表。

Kappa 架構(gòu)的重新處理過程

五、Lambda 架構(gòu)與 Kappa 架構(gòu)的對比

對比

• 在真實的場景中，很多時候并不是完全規(guī)范的 Lambda 架構(gòu)或 Kappa 架構(gòu)，可以是兩者的混合，比如大部分實時指標(biāo)使用 Kappa 架構(gòu)完成計算，少量關(guān)鍵指標(biāo)（比如金額相關(guān)）使用 Lambda 架構(gòu)用批處理重新計算，增加一次校對過程。
• Kappa 架構(gòu)并不是中間結(jié)果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機器學(xué)習(xí)（離線訓(xùn)練），所以實時中間結(jié)果需要落地對應(yīng)的存儲引擎供機器學(xué)習(xí)使用，另外有時候還需要對明細(xì)數(shù)據(jù)查詢，這種場景也需要把實時明細(xì)層寫出到對應(yīng)的引擎中。
• 另外，隨著數(shù)據(jù)多樣性的發(fā)展，數(shù)據(jù)倉庫這種提前規(guī)定 schema 的模式顯得越來難以支持靈活的探索&分析需求，這時候便出現(xiàn)了一種數(shù)據(jù)湖技術(shù)，即把原始數(shù)據(jù)全部緩存到某個大數(shù)據(jù)存儲上，后續(xù)分析時再根據(jù)需求去解析原始數(shù)據(jù)。簡單的說，數(shù)據(jù)倉庫模式是 schema on write，數(shù)據(jù)湖模式是 schema on read。

混合架構(gòu)

參考資料

• 《實時數(shù)倉調(diào)研》--駒支