一、概要
數(shù)據(jù)倉庫概念是 Inmon 于 1990 年提出并給出了完整的建設(shè)方法妒牙。隨著互聯(lián)網(wǎng)時(shí)代來臨彼哼，數(shù)據(jù)量暴增，開始使用大數(shù)據(jù)工具來替代經(jīng)典數(shù)倉中的傳統(tǒng)工具湘今。此時(shí)僅僅是工具的取代敢朱，架構(gòu)上并沒有根本的區(qū)別，可以把這個(gè)架構(gòu)叫做離線大數(shù)據(jù)架構(gòu)摩瞎。后來隨著業(yè)務(wù)實(shí)時(shí)性要求的不斷提高拴签，人們開始在離線大數(shù)據(jù)架構(gòu)基礎(chǔ)上加了一個(gè)加速層，使用流處理技術(shù)直接完成那些實(shí)時(shí)性要求較高的指標(biāo)計(jì)算旗们，這便是 Lambda 架構(gòu)蚓哩。再后來，實(shí)時(shí)的業(yè)務(wù)越來越多上渴，事件化的數(shù)據(jù)源也越來越多岸梨，實(shí)時(shí)處理從次要部分變成了主要部分，架構(gòu)也做了相應(yīng)調(diào)整稠氮，出現(xiàn)了以實(shí)時(shí)事件處理為核心的 Kappa 架構(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ù)主題定義好事實(shí)與維度表渺蒿，保存最細(xì)粒度的事實(shí)數(shù)據(jù)痢士；
- DM，數(shù)據(jù)集市/輕度匯總層，在 DWD 層的基礎(chǔ)之上根據(jù)不同的業(yè)務(wù)需求做輕度匯總怠蹂；
典型的數(shù)倉存儲(chǔ)是 HDFS/Hive善延，ETL 可以是 MapReduce 腳本或 HiveSQL。
三城侧、Lambda 架構(gòu)
隨著大數(shù)據(jù)應(yīng)用的發(fā)展易遣，人們逐漸對系統(tǒng)的實(shí)時(shí)性提出了要求，為了計(jì)算一些實(shí)時(shí)指標(biāo)嫌佑，就在原來離線數(shù)倉的基礎(chǔ)上增加了一個(gè)實(shí)時(shí)計(jì)算的鏈路豆茫，并對數(shù)據(jù)源做流式改造（即把數(shù)據(jù)發(fā)送到消息隊(duì)列），實(shí)時(shí)計(jì)算去訂閱消息隊(duì)列屋摇，直接完成指標(biāo)增量的計(jì)算揩魂，推送到下游的數(shù)據(jù)服務(wù)中去，由數(shù)據(jù)服務(wù)層完成離線&實(shí)時(shí)結(jié)果的合并炮温。
注：流處理計(jì)算的指標(biāo)批處理依然計(jì)算火脉，最終以批處理為準(zhǔn)，即每次批處理計(jì)算后會(huì)覆蓋流處理的結(jié)果柒啤。（這僅僅是流處理引擎不完善做的折中）
Lambda 架構(gòu)問題：
- 同樣的需求需要開發(fā)兩套一樣的代碼：這是 Lambda 架構(gòu)最大的問題倦挂，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求，一個(gè)在批處理引擎上實(shí)現(xiàn)担巩，一個(gè)在流處理引擎上實(shí)現(xiàn)方援，還要分別構(gòu)造數(shù)據(jù)測試保證兩者結(jié)果一致），后期維護(hù)更加困難兵睛，比如需求變更后需要分別更改兩套代碼肯骇，獨(dú)立測試結(jié)果，且兩個(gè)作業(yè)需要同步上線祖很。
- 資源占用增多：同樣的邏輯計(jì)算兩次笛丙，整體資源占用會(huì)增多（多出實(shí)時(shí)計(jì)算這部分）
四、Kappa 架構(gòu)
Lambda 架構(gòu)雖然滿足了實(shí)時(shí)的需求假颇，但帶來了更多的開發(fā)與運(yùn)維工作胚鸯，其架構(gòu)背景是流處理引擎還不完善，流處理的結(jié)果只作為臨時(shí)的笨鸡、近似的值提供參考姜钳。后來隨著 Flink 等流處理引擎的出現(xiàn)，流處理技術(shù)很成熟了形耗，這時(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)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來彌補(bǔ)送滞。
Kappa 架構(gòu)的重新處理過程：重新處理是人們對 Kappa 架構(gòu)最擔(dān)心的點(diǎn)侠草，但實(shí)際上并不復(fù)雜：
- 選擇一個(gè)具有重放功能的、能夠保存歷史數(shù)據(jù)并支持多消費(fèi)者的消息隊(duì)列犁嗅，根據(jù)需求設(shè)置歷史數(shù)據(jù)保存的時(shí)長边涕，比如 Kafka，可以保存全部歷史數(shù)據(jù)褂微。
- 當(dāng)某個(gè)或某些指標(biāo)有重新處理的需求時(shí)功蜓，按照新邏輯寫一個(gè)新作業(yè)，然后從上游消息隊(duì)列的最開始重新消費(fèi)蕊梧，把結(jié)果寫到一個(gè)新的下游表中霞赫。
- 當(dāng)新作業(yè)趕上進(jìn)度后，應(yīng)用切換數(shù)據(jù)源肥矢，讀取 2 中產(chǎn)生的新結(jié)果表端衰。
停止老的作業(yè)，刪除老的結(jié)果表甘改。
五旅东、Lambda 架構(gòu)與 Kappa 架構(gòu)的對比
- 在真實(shí)的場景中，很多時(shí)候并不是完全規(guī)范的 Lambda 架構(gòu)或 Kappa 架構(gòu)十艾，可以是兩者的混合抵代，比如大部分實(shí)時(shí)指標(biāo)使用 Kappa 架構(gòu)完成計(jì)算，少量關(guān)鍵指標(biāo)（比如金額相關(guān)）使用 Lambda 架構(gòu)用批處理重新計(jì)算忘嫉，增加一次校對過程荤牍。
- Kappa 架構(gòu)并不是中間結(jié)果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機(jī)器學(xué)習(xí)（離線訓(xùn)練）庆冕，所以實(shí)時(shí)中間結(jié)果需要落地對應(yīng)的存儲(chǔ)引擎供機(jī)器學(xué)習(xí)使用康吵，另外有時(shí)候還需要對明細(xì)數(shù)據(jù)查詢，這種場景也需要把實(shí)時(shí)明細(xì)層寫出到對應(yīng)的引擎中访递。
- 另外晦嵌，隨著數(shù)據(jù)多樣性的發(fā)展，數(shù)據(jù)倉庫這種提前規(guī)定 schema 的模式顯得越來難以支持靈活的探索&分析需求拷姿，這時(shí)候便出現(xiàn)了一種數(shù)據(jù)湖技術(shù)惭载，即把原始數(shù)據(jù)全部緩存到某個(gè)大數(shù)據(jù)存儲(chǔ)上，后續(xù)分析時(shí)再根據(jù)需求去解析原始數(shù)據(jù)响巢。簡單的說描滔，數(shù)據(jù)倉庫模式是 schema on write，數(shù)據(jù)湖模式是 schema on read踪古。
參考資料
- 《實(shí)時(shí)數(shù)倉調(diào)研》--駒支
