本文目錄:

一． 實(shí)時(shí)計(jì)算初期

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

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

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

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

實(shí)時(shí)計(jì)算初期

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

早期實(shí)時(shí)計(jì)算

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

應(yīng)用層少建設(shè)的好處:實(shí)時(shí)處理數(shù)據(jù)的時(shí)候,每建一個(gè)層次,數(shù)據(jù)必然會(huì)產(chǎn)生一定的延遲。

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

與離線數(shù)倉相比,實(shí)時(shí)數(shù)倉的數(shù)據(jù)源存儲(chǔ)不同:

在建設(shè)離線數(shù)倉的時(shí)候,基本整個(gè)離線數(shù)倉都是建立在 Hive 表之上。但是,在建設(shè)實(shí)時(shí)數(shù)倉的時(shí)候,同一份表,會(huì)使用不同的方式進(jìn)行存儲(chǔ)。比如常見的情況下,明細(xì)數(shù)據(jù)或者匯總數(shù)據(jù)都會(huì)存在 Kafka 里面,但是像城市、渠道等維度信息需要借助 Hbase,MySQL 或者其他 KV 存儲(chǔ)等數(shù)據(jù)庫來進(jìn)行存儲(chǔ)。Lambda架構(gòu)的實(shí)時(shí)數(shù)倉

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

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

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

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

雙路生產(chǎn)會(huì)存在一些問題,比如加工邏輯double,開發(fā)運(yùn)維也會(huì)double,資源同樣會(huì)變成兩個(gè)資源鏈路。因?yàn)榇嬖谝陨蠁栴},所以又演進(jìn)了一個(gè)Kappa架構(gòu)。

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

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

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

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

關(guān)于 Kappa 架構(gòu),熟悉實(shí)時(shí)數(shù)倉生產(chǎn)的同學(xué),可能會(huì)有一個(gè)疑問。因?yàn)槲覀兘?jīng)常會(huì)面臨業(yè)務(wù)變更,所以很多業(yè)務(wù)邏輯是需要去迭代的。之前產(chǎn)出的一些數(shù)據(jù),如果口徑變更了,就需要重算,甚至重刷歷史數(shù)據(jù)。對于實(shí)時(shí)數(shù)倉來說,怎么去解決數(shù)據(jù)重算問題?

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

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

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

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

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

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

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