發(fā)展
- 離線大數(shù)據(jù)架構(gòu)
數(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)。
- Lambda架構(gòu)
后來隨著業(yè)務(wù)實(shí)時(shí)性要求的不斷提高，人們開始在離線大數(shù)據(jù)架構(gòu)基礎(chǔ)上加了一個(gè)加速層，使用流處理技術(shù)直接完成那些實(shí)時(shí)性要求較高的指標(biāo)計(jì)算，這便是Lambda架構(gòu)。
- Kappa架構(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ā)展，人們逐漸對(duì)系統(tǒng)的實(shí)時(shí)性提出了要求，為了計(jì)算一些實(shí)時(shí)指標(biāo)，就在原來離線數(shù)倉的基礎(chǔ)上增加了一個(gè)實(shí)時(shí)計(jì)算的鏈路，并對(duì)數(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)問題
1.同樣的需求需要開發(fā)兩套一樣的代碼
這是Lambda架構(gòu)最大的問題，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求，一個(gè)在批處理引擎上實(shí)現(xiàn)，一個(gè)在流處理引擎上實(shí)現(xiàn)，還要分別構(gòu)造數(shù)據(jù)測(cè)試保證兩者結(jié)果一致），后期維護(hù)更加困難，比如需求變更后需要分別更改兩套代碼，獨(dú)立測(cè)試結(jié)果，且兩個(gè)作業(yè)需要同步上線。
2.資源占用增多
同樣的邏輯計(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)的簡(jiǎn)化版（只要移除lambda架構(gòu)中的批處理部分即可）。
在Kappa架構(gòu)中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成。
Kappa架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來彌補(bǔ)。
- Kappa架構(gòu)的重新處理過程
重新處理是人們對(duì)Kappa架構(gòu)最擔(dān)心的點(diǎn)，但實(shí)際上并不復(fù)雜：
1.選擇一個(gè)具有重放功能的、能夠保存歷史數(shù)據(jù)并支持多消費(fèi)者的消息隊(duì)列，根據(jù)需求設(shè)置歷史數(shù)據(jù)保存的時(shí)長，比如Kafka，可以保存全部歷史數(shù)據(jù)。
2.當(dāng)某個(gè)或某些指標(biāo)有重新處理的需求時(shí)，按照新邏輯寫一個(gè)新作業(yè)，然后從上游消息隊(duì)列的最開始重新消費(fèi)，把結(jié)果寫到一個(gè)新的下游表中。
3.當(dāng)新作業(yè)趕上進(jìn)度后，應(yīng)用切換數(shù)據(jù)源，讀取2中產(chǎn)生的新結(jié)果表。
4.停止老的作業(yè)，刪除老的結(jié)果表。
Lambda架構(gòu)與Kappa架構(gòu)的對(duì)比
在真實(shí)的場(chǎng)景中，很多時(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ì)算，增加一次校對(duì)過程。
1）Kappa架構(gòu)并不是中間結(jié)果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機(jī)器學(xué)習(xí)（離線訓(xùn)練），所以實(shí)時(shí)中間結(jié)果需要落地對(duì)應(yīng)的存儲(chǔ)引擎供機(jī)器學(xué)習(xí)使用，另外有時(shí)候還需要對(duì)明細(xì)數(shù)據(jù)查詢，這種場(chǎng)景也需要把實(shí)時(shí)明細(xì)層寫出到對(duì)應(yīng)的引擎中。
2）另外，隨著數(shù)據(jù)多樣性的發(fā)展，數(shù)據(jù)倉庫這種提前規(guī)定schema的模式顯得越來難以支持靈活的探索&分析需求，這時(shí)候便出現(xiàn)了一種數(shù)據(jù)湖技術(shù)，即把原始數(shù)據(jù)全部緩存到某個(gè)大數(shù)據(jù)存儲(chǔ)上，后續(xù)分析時(shí)再根據(jù)需求去解析原始數(shù)據(jù)。簡(jiǎn)單的說，數(shù)據(jù)倉庫模式是schema on write，數(shù)據(jù)湖模式是schema on read。
實(shí)時(shí)數(shù)倉與離線數(shù)倉的對(duì)比
從架構(gòu)上，實(shí)時(shí)數(shù)倉與離線數(shù)倉有比較明顯的區(qū)別，實(shí)時(shí)數(shù)倉以Kappa架構(gòu)為主，而離線數(shù)倉以傳統(tǒng)大數(shù)據(jù)架構(gòu)為主。Lambda架構(gòu)可以認(rèn)為是兩者的中間態(tài)。
從建設(shè)方法上，實(shí)時(shí)數(shù)倉和離線數(shù)倉基本還是沿用傳統(tǒng)的數(shù)倉主題建模理論，產(chǎn)出事實(shí)寬表。另外實(shí)時(shí)數(shù)倉中實(shí)時(shí)流數(shù)據(jù)的join有隱藏時(shí)間語義，在建設(shè)中需注意。
從數(shù)據(jù)保障看，實(shí)時(shí)數(shù)倉因?yàn)橐ＷC實(shí)時(shí)性，所以對(duì)數(shù)據(jù)量的變化較為敏感。在大促等場(chǎng)景下需要提前做好壓測(cè)和主備保障工作，這是與離線數(shù)據(jù)的一個(gè)較為明顯的區(qū)別。
【轉(zhuǎn)自知乎】
https://zhuanlan.zhihu.com/p/71969484?utm_source=wechat_session&utm_medium=social&utm_oi=75378873860096
