[[410881]]

本文轉(zhuǎn)載自微信公眾號「五分鐘學(xué)大數(shù)據(jù)」，作者園陌。轉(zhuǎn)載本文請聯(lián)系五分鐘學(xué)大數(shù)據(jù)公眾號。

本文目錄：

一. 實時計算初期

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

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

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

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

實時計算初期

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

早期實時計算

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

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

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

需求越來越多，有的需要明細(xì)數(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)然是可以的，但是細(xì)節(jié)上和離線的分層還是有一些不同，稍后會講到。

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

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

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

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

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

• 數(shù)據(jù)源：在數(shù)據(jù)源的層面，離線和實時在數(shù)據(jù)源是一致的，主要分為日志類和業(yè)務(wù)類，日志類又包括用戶日志，埋點(diǎn)日志以及服務(wù)器日志等。
• 實時明細(xì)層：在明細(xì)層，為了解決重復(fù)建設(shè)的問題，要進(jìn)行統(tǒng)一構(gòu)建，利用離線數(shù)倉的模式，建設(shè)統(tǒng)一的基礎(chǔ)明細(xì)數(shù)據(jù)層，按照主題進(jìn)行管理，明細(xì)層的目的是給下游提供直接可用的數(shù)據(jù)，因此要對基礎(chǔ)層進(jìn)行統(tǒng)一的加工，比如清洗、過濾、擴(kuò)維等。
• 匯總層：匯總層通過Flink的簡潔算子直接可以算出結(jié)果，并且形成匯總指標(biāo)池，所有的指標(biāo)都統(tǒng)一在匯總層加工，所有人按照統(tǒng)一的規(guī)范管理建設(shè)，形成可復(fù)用的匯總結(jié)果。

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

• 與離線數(shù)倉相比，實時數(shù)倉的層次更少一些：
  • 從目前建設(shè)離線數(shù)倉的經(jīng)驗來看，數(shù)倉的數(shù)據(jù)明細(xì)層內(nèi)容會非常豐富，處理明細(xì)數(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)全部接受到位了，再進(jìn)行統(tǒng)計。所以，匯總層的層次太多的話，就會更大的加重人為造成的數(shù)據(jù)延遲。
• 與離線數(shù)倉相比，實時數(shù)倉的數(shù)據(jù)源存儲不同：
  • 在建設(shè)離線數(shù)倉的時候，基本整個離線數(shù)倉都是建立在 Hive 表之上。但是，在建設(shè)實時數(shù)倉的時候，同一份表，會使用不同的方式進(jìn)行存儲。比如常見的情況下，明細(xì)數(shù)據(jù)或者匯總數(shù)據(jù)都會存在 Kafka 里面，但是像城市、渠道等維度信息需要借助 Hbase，MySQL 或者其他 KV 存儲等數(shù)據(jù)庫來進(jìn)行存儲。

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

Lambda和Kappa架構(gòu)的概念已在前文中解釋，不了解的小伙伴可點(diǎn)擊鏈接：一文讀懂大數(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)用層面進(jìn)行一個整合，雙路生產(chǎn)，各自獨(dú)立。這在業(yè)務(wù)應(yīng)用中也是順理成章采用的一種方式。

雙路生產(chǎn)會存在一些問題，比如加工邏輯double，開發(fā)運(yùn)維也會double，資源同樣會變成兩個資源鏈路。因為存在以上問題，所以又演進(jìn)了一個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ù)的同一份表，會使用不同的方式進(jìn)行存儲，這就導(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é)點(diǎn)重新開始消費(fèi)的。接著需要新起一個任務(wù)，從原來比較早的一個時間節(jié)點(diǎn)去消費(fèi) Kafka 上的數(shù)據(jù)，然后當(dāng)這個新的任務(wù)運(yùn)行的進(jìn)度已經(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ā)生了變化，多了數(shù)據(jù)湖 Iceberg 和 OLAP 引擎 Presto。Iceberg是介于上層計算引擎和底層存儲格式之間的一個中間層，我們可以把它定義成一種“數(shù)據(jù)組織格式”，底層存儲還是HDFS，Iceberg的ACID能力可以簡化整個流水線的設(shè)計，降低整個流水線的延遲，并且所具有的修改、刪除能力能夠有效地降低開銷，提升效率。Iceberg可以有效支持批處理的高吞吐數(shù)據(jù)掃描和流計算按分區(qū)粒度并發(fā)實時處理。OLAP查詢引擎使用Presto，Presto是一個分布式的采用MPP架構(gòu)的查詢引擎，本身并不存儲數(shù)據(jù)，但是可以接入多種數(shù)據(jù)源，并且支持跨數(shù)據(jù)源的級聯(lián)查詢。擅長對海量數(shù)據(jù)進(jìn)行復(fù)雜的分析。