本文目錄:

一． 實時計算初期

二． 實時數(shù)倉建設

三． Lambda架構的實時數(shù)倉

四． Kappa架構的實時數(shù)倉

五． 流批結合的實時數(shù)倉

實時計算初期

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

早期實時計算

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

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

數(shù)據(jù)指標越來越多,“煙囪式”的開發(fā)導致代碼耦合問題嚴重。

需求越來越多,有的需要明細數(shù)據(jù),有的需要 OLAP 分析。單一的開發(fā)模式難以應付多種需求。

每個需求都要申請資源,導致資源成本急速膨脹,資源不能集約有效利用。

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

大家看實時數(shù)倉的發(fā)展和出現(xiàn)的問題,和離線數(shù)倉非常類似,后期數(shù)據(jù)量大了之后產生了各種問題,離線數(shù)倉當時是怎么解決的?離線數(shù)倉通過分層架構使數(shù)據(jù)解耦,多個業(yè)務可以共用數(shù)據(jù),實時數(shù)倉是否也可以用分層架構呢?當然是可以的,但是細節(jié)上和離線的分層還是有一些不同,稍后會講到。

實時數(shù)倉建設

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

實時數(shù)倉的架構如下圖:

實時數(shù)倉架構

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

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

實時明細層:在明細層,為了解決重復建設的問題,要進行統(tǒng)一構建,利用離線數(shù)倉的模式,建設統(tǒng)一的基礎明細數(shù)據(jù)層,按照主題進行管理,明細層的目的是給下游提供直接可用的數(shù)據(jù),因此要對基礎層進行統(tǒng)一的加工,比如清洗、過濾、擴維等。

匯總層:匯總層通過Flink的簡潔算子直接可以算出結果,并且形成匯總指標池,所有的指標都統(tǒng)一在匯總層加工,所有人按照統(tǒng)一的規(guī)范管理建設,形成可復用的匯總結果。

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

與離線數(shù)倉相比,實時數(shù)倉的層次更少一些:

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

應用層少建設的好處:實時處理數(shù)據(jù)的時候,每建一個層次,數(shù)據(jù)必然會產生一定的延遲。

匯總層少建的好處:在匯總統(tǒng)計的時候,往往為了容忍一部分數(shù)據(jù)的延遲,可能會人為的制造一些延遲來保證數(shù)據(jù)的準確。舉例,在統(tǒng)計跨天相關的訂單事件中的數(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ù)倉都是建立在 Hive 表之上。但是,在建設實時數(shù)倉的時候,同一份表,會使用不同的方式進行存儲。比如常見的情況下,明細數(shù)據(jù)或者匯總數(shù)據(jù)都會存在 Kafka 里面,但是像城市、渠道等維度信息需要借助 Hbase,MySQL 或者其他 KV 存儲等數(shù)據(jù)庫來進行存儲。Lambda架構的實時數(shù)倉

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

下圖是基于 Flink 和 Kafka 的 Lambda 架構的具體實踐,上層是實時計算,下層是離線計算,橫向是按計算引擎來分,縱向是按實時數(shù)倉來區(qū)分:

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

Lambda架構是比較經(jīng)典的架構,以前實時的場景不是很多,以離線為主,當附加了實時場景后,由于離線和實時的時效性不同,導致技術生態(tài)是不一樣的。Lambda架構相當于附加了一條實時生產鏈路,在應用層面進行一個整合,雙路生產,各自獨立。這在業(yè)務應用中也是順理成章采用的一種方式。

雙路生產會存在一些問題,比如加工邏輯double,開發(fā)運維也會double,資源同樣會變成兩個資源鏈路。因為存在以上問題,所以又演進了一個Kappa架構。

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

Kappa架構相當于去掉了離線計算部分的Lambda架構,具體如下圖所示:

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

Kappa架構從架構設計來講比較簡單,生產統(tǒng)一,一套邏輯同時生產離線和實時。但是在實際應用場景有比較大的局限性,因為實時數(shù)據(jù)的同一份表,會使用不同的方式進行存儲,這就導致關聯(lián)時需要跨數(shù)據(jù)源,操作數(shù)據(jù)有很大局限性,所以在業(yè)內直接用Kappa架構生產落地的案例不多見,且場景比較單一。

關于 Kappa 架構,熟悉實時數(shù)倉生產的同學,可能會有一個疑問。因為我們經(jīng)常會面臨業(yè)務變更,所以很多業(yè)務邏輯是需要去迭代的。之前產出的一些數(shù)據(jù),如果口徑變更了,就需要重算,甚至重刷歷史數(shù)據(jù)。對于實時數(shù)倉來說,怎么去解決數(shù)據(jù)重算問題?

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

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

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

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

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

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

我們看到流批結合的方式與上面幾種架構使用的組件發(fā)生了變化,多了數(shù)據(jù)湖 Iceberg 和 OLAP 引擎 Presto。Iceberg是介于上層計算引擎和底層存儲格式之間的一個中間層,我們可以把它定義成一種“數(shù)據(jù)組織格式”,底層存儲還是HDFS,Iceberg的ACID能力可以簡化整個流水線的設計,降低整個流水線的延遲,并且所具有的修改、刪除能力能夠有效地降低開銷,提升效率。Iceberg可以有效支持批處理的高吞吐數(shù)據(jù)掃描和流計算按分區(qū)粒度并發(fā)實時處理。OLAP查詢引擎使用Presto,Presto是一個分布式的采用MPP架構的查詢引擎,本身并不存儲數(shù)據(jù),但是可以接入多種數(shù)據(jù)源,并且支持跨數(shù)據(jù)源的級聯(lián)查詢。擅長對海量數(shù)據(jù)進行復雜的分析。