目錄：

一. 實時計算初期

二. 實時數(shù)倉建設(shè)

三. Lambda架構(gòu)的實時數(shù)倉

四. Kappa架構(gòu)的實時數(shù)倉

五. 流批結(jié)合的實時數(shù)倉

一杀怠、實時計算初期

雖然實時計算在最近幾年才火起來，但是在早期也有部分公司有實時計算的需求吴菠，但是數(shù)據(jù)量比較少橄教，所以在實時方面形成不了完整的體系清寇，基本所有的開發(fā)都是具體問題具體分析，來一個需求做一個护蝶，基本不考慮它們之間的關(guān)系华烟，開發(fā)形式如下：

早期實時計算

如上圖所示，拿到數(shù)據(jù)源后持灰，會經(jīng)過數(shù)據(jù)清洗盔夜，擴維，通過Flink進行業(yè)務(wù)邏輯處理堤魁，最后直接進行業(yè)務(wù)輸出喂链。把這個環(huán)節(jié)拆開來看，數(shù)據(jù)源端會重復(fù)引用相同的數(shù)據(jù)源妥泉，后面進行清洗椭微、過濾、擴維等操作盲链，都要重復(fù)做一遍蝇率，唯一不同的是業(yè)務(wù)的代碼邏輯是不一樣的。

隨著產(chǎn)品和業(yè)務(wù)人員對實時數(shù)據(jù)需求的不斷增多刽沾，這種開發(fā)模式出現(xiàn)的問題越來越多：

數(shù)據(jù)指標(biāo)越來越多瓢剿，“煙囪式”的開發(fā)導(dǎo)致代碼耦合問題嚴(yán)重。

需求越來越多悠轩，有的需要明細數(shù)據(jù)间狂，有的需要 OLAP 分析。單一的開發(fā)模式難以應(yīng)付多種需求火架。

每個需求都要申請資源鉴象，導(dǎo)致資源成本急速膨脹，資源不能集約有效利用何鸡。

缺少完善的監(jiān)控系統(tǒng)纺弊，無法在對業(yè)務(wù)產(chǎn)生影響之前發(fā)現(xiàn)并修復(fù)問題。

大家看實時數(shù)倉的發(fā)展和出現(xiàn)的問題骡男，和離線數(shù)倉非常類似淆游，后期數(shù)據(jù)量大了之后產(chǎn)生了各種問題，離線數(shù)倉當(dāng)時是怎么解決的？離線數(shù)倉通過分層架構(gòu)使數(shù)據(jù)解耦犹菱，多個業(yè)務(wù)可以共用數(shù)據(jù)拾稳，實時數(shù)倉是否也可以用分層架構(gòu)呢？當(dāng)然是可以的腊脱，但是細節(jié)上和離線的分層還是有一些不同访得，稍后會講到。

二陕凹、實時數(shù)倉建設(shè)

從方法論來講悍抑，實時和離線是非常相似的，離線數(shù)倉早期的時候也是具體問題具體分析杜耙，當(dāng)數(shù)據(jù)規(guī)模漲到一定量的時候才會考慮如何治理搜骡。分層是一種非常有效的數(shù)據(jù)治理方式，所以在實時數(shù)倉如何進行管理的問題上佑女，首先考慮的也是分層的處理邏輯浆兰。

實時數(shù)倉的架構(gòu)如下圖：

實時數(shù)倉架構(gòu)

從上圖中我們具體分析下每層的作用：

數(shù)據(jù)源：在數(shù)據(jù)源的層面，離線和實時在數(shù)據(jù)源是一致的珊豹，主要分為日志類和業(yè)務(wù)類，日志類又包括用戶日志榕订，埋點日志以及服務(wù)器日志等店茶。

實時明細層：在明細層，為了解決重復(fù)建設(shè)的問題劫恒，要進行統(tǒng)一構(gòu)建贩幻，利用離線數(shù)倉的模式，建設(shè)統(tǒng)一的基礎(chǔ)明細數(shù)據(jù)層两嘴，按照主題進行管理丛楚，明細層的目的是給下游提供直接可用的數(shù)據(jù)，因此要對基礎(chǔ)層進行統(tǒng)一的加工憔辫，比如清洗趣些、過濾、擴維等贰您。

匯總層：匯總層通過Flink的簡潔算子直接可以算出結(jié)果坏平，并且形成匯總指標(biāo)池，所有的指標(biāo)都統(tǒng)一在匯總層加工锦亦，所有人按照統(tǒng)一的規(guī)范管理建設(shè)舶替，形成可復(fù)用的匯總結(jié)果。

我們可以看出杠园，實時數(shù)倉和離線數(shù)倉的分層非常類似顾瞪，比如 數(shù)據(jù)源層，明細層，匯總層陈醒，乃至應(yīng)用層惕橙，他們命名的模式可能都是一樣的。但仔細比較不難發(fā)現(xiàn)孵延，兩者有很多區(qū)別：

與離線數(shù)倉相比吕漂，實時數(shù)倉的層次更少一些：

從目前建設(shè)離線數(shù)倉的經(jīng)驗來看，數(shù)倉的數(shù)據(jù)明細層內(nèi)容會非常豐富尘应，處理明細數(shù)據(jù)外一般還會包含輕度匯總層的概念惶凝，另外離線數(shù)倉中應(yīng)用層數(shù)據(jù)在數(shù)倉內(nèi)部，但實時數(shù)倉中犬钢，app 應(yīng)用層數(shù)據(jù)已經(jīng)落入應(yīng)用系統(tǒng)的存儲介質(zhì)中苍鲜，可以把該層與數(shù)倉的表分離。

應(yīng)用層少建設(shè)的好處：實時處理數(shù)據(jù)的時候玷犹，每建一個層次混滔，數(shù)據(jù)必然會產(chǎn)生一定的延遲。

匯總層少建的好處：在匯總統(tǒng)計的時候歹颓，往往為了容忍一部分?jǐn)?shù)據(jù)的延遲坯屿，可能會人為的制造一些延遲來保證數(shù)據(jù)的準(zhǔn)確。舉例巍扛，在統(tǒng)計跨天相關(guān)的訂單事件中的數(shù)據(jù)時领跛，可能會等到 00:00:05 或者 00:00:10 再統(tǒng)計，確保 00:00 前的數(shù)據(jù)已經(jīng)全部接受到位了撤奸，再進行統(tǒng)計吠昭。所以，匯總層的層次太多的話胧瓜，就會更大的加重人為造成的數(shù)據(jù)延遲矢棚。

與離線數(shù)倉相比，實時數(shù)倉的數(shù)據(jù)源存儲不同：

在建設(shè)離線數(shù)倉的時候府喳，基本整個離線數(shù)倉都是建立在 Hive 表之上蒲肋。但是，在建設(shè)實時數(shù)倉的時候钝满，同一份表肉津，會使用不同的方式進行存儲。比如常見的情況下舱沧，明細數(shù)據(jù)或者匯總數(shù)據(jù)都會存在 Kafka 里面妹沙，但是像城市、渠道等維度信息需要借助 Hbase熟吏，MySQL 或者其他 KV 存儲等數(shù)據(jù)庫來進行存儲距糖。

三玄窝、Lambda架構(gòu)的實時數(shù)倉

Lambda和Kappa架構(gòu)的概念已在前文中解釋，不了解的小伙伴可點擊鏈接：一文讀懂大數(shù)據(jù)實時計算

下圖是基于 Flink 和 Kafka 的 Lambda 架構(gòu)的具體實踐悍引，上層是實時計算恩脂，下層是離線計算，橫向是按計算引擎來分趣斤，縱向是按實時數(shù)倉來區(qū)分：

Lambda架構(gòu)的實時數(shù)倉

Lambda架構(gòu)是比較經(jīng)典的架構(gòu)俩块，以前實時的場景不是很多，以離線為主浓领，當(dāng)附加了實時場景后玉凯，由于離線和實時的時效性不同，導(dǎo)致技術(shù)生態(tài)是不一樣的联贩。Lambda架構(gòu)相當(dāng)于附加了一條實時生產(chǎn)鏈路漫仆，在應(yīng)用層面進行一個整合，雙路生產(chǎn)泪幌，各自獨立盲厌。這在業(yè)務(wù)應(yīng)用中也是順理成章采用的一種方式。

雙路生產(chǎn)會存在一些問題祸泪，比如加工邏輯double吗浩，開發(fā)運維也會double，資源同樣會變成兩個資源鏈路没隘。因為存在以上問題懂扼，所以又演進了一個Kappa架構(gòu)。

四升略、Kappa架構(gòu)的實時數(shù)倉

Kappa架構(gòu)相當(dāng)于去掉了離線計算部分的Lambda架構(gòu)，具體如下圖所示：

Kappa架構(gòu)的實時數(shù)倉

Kappa架構(gòu)從架構(gòu)設(shè)計來講比較簡單屡限，生產(chǎn)統(tǒng)一品嚣，一套邏輯同時生產(chǎn)離線和實時。但是在實際應(yīng)用場景有比較大的局限性钧大，因為實時數(shù)據(jù)的同一份表翰撑，會使用不同的方式進行存儲，這就導(dǎo)致關(guān)聯(lián)時需要跨數(shù)據(jù)源啊央，操作數(shù)據(jù)有很大局限性眶诈，所以在業(yè)內(nèi)直接用Kappa架構(gòu)生產(chǎn)落地的案例不多見，且場景比較單一瓜饥。

關(guān)于 Kappa 架構(gòu)逝撬，熟悉實時數(shù)倉生產(chǎn)的同學(xué)，可能會有一個疑問乓土。因為我們經(jīng)常會面臨業(yè)務(wù)變更宪潮，所以很多業(yè)務(wù)邏輯是需要去迭代的溯警。之前產(chǎn)出的一些數(shù)據(jù)，如果口徑變更了狡相，就需要重算梯轻，甚至重刷歷史數(shù)據(jù)。對于實時數(shù)倉來說尽棕，怎么去解決數(shù)據(jù)重算問題喳挑？

Kappa 架構(gòu)在這一塊的思路是：首先要準(zhǔn)備好一個能夠存儲歷史數(shù)據(jù)的消息隊列，比如 Kafka滔悉，并且這個消息隊列是可以支持你從某個歷史的節(jié)點重新開始消費的伊诵。接著需要新起一個任務(wù)，從原來比較早的一個時間節(jié)點去消費 Kafka 上的數(shù)據(jù)氧敢，然后當(dāng)這個新的任務(wù)運行的進度已經(jīng)能夠和現(xiàn)在的正在跑的任務(wù)齊平的時候日戈，你就可以把現(xiàn)在任務(wù)的下游切換到新的任務(wù)上面，舊的任務(wù)就可以停掉孙乖，并且原來產(chǎn)出的結(jié)果表也可以被刪掉浙炼。

五、流批結(jié)合的實時數(shù)倉

隨著實時 OLAP 技術(shù)的發(fā)展唯袄，目前開源的OLAP引擎在性能弯屈，易用等方面有了很大的提升，如Doris恋拷、Presto等资厉，加上數(shù)據(jù)湖技術(shù)的迅速發(fā)展，使得流批結(jié)合的方式變得簡單蔬顾。

如下圖是流批結(jié)合的實時數(shù)倉：

流批結(jié)合的實時數(shù)倉

數(shù)據(jù)從日志統(tǒng)一采集到消息隊列宴偿，再到實時數(shù)倉，作為基礎(chǔ)數(shù)據(jù)流的建設(shè)是統(tǒng)一的诀豁。之后對于日志類實時特征窄刘，實時大屏類應(yīng)用走實時流計算。對于Binlog類業(yè)務(wù)分析走實時OLAP批處理舷胜。

我們看到流批結(jié)合的方式與上面幾種架構(gòu)的存儲方式發(fā)生了變化娩践，由Kafka換成了Iceberg，Iceberg是介于上層計算引擎和底層存儲格式之間的一個中間層烹骨，我們可以把它定義成一種“數(shù)據(jù)組織格式”翻伺，底層存儲還是HDFS，那么為什么加了中間層沮焕，就對流批結(jié)合處理的比較好了呢吨岭？Iceberg的ACID能力可以簡化整個流水線的設(shè)計，降低整個流水線的延遲峦树，并且所具有的修改未妹、刪除能力能夠有效地降低開銷簿废，提升效率。Iceberg可以有效支持批處理的高吞吐數(shù)據(jù)掃描和流計算按分區(qū)粒度并發(fā)實時處理络它。