本文目錄:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實(shí)時(shí)明細(xì)層:在明細(xì)層,為了解決重復(fù)建設(shè)的問(wèn)題,要進(jìn)行統(tǒng)一構(gòu)建,利用離線(xiàn)數(shù)倉(cāng)的模式,建設(shè)統(tǒng)一的基礎(chǔ)明細(xì)數(shù)據(jù)層,按照主題進(jìn)行管理,明細(xì)層的目的是給下游提供直接可用的數(shù)據(jù),因此要對(duì)基礎(chǔ)層進(jìn)行統(tǒng)一的加工,比如清洗、過(guò)濾、擴(kuò)維等。

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

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

與離線(xiàn)數(shù)倉(cāng)相比,實(shí)時(shí)數(shù)倉(cāng)的層次更少一些:

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

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

匯總層少建的好處:在匯總統(tǒng)計(jì)的時(shí)候,往往為了容忍一部分?jǐn)?shù)據(jù)的延遲,可能會(huì)人為的制造一些延遲來(lái)保證數(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à),就會(huì)更大的加重人為造成的數(shù)據(jù)延遲。

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

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

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

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

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

Lambda架構(gòu)是比較經(jīng)典的架構(gòu),以前實(shí)時(shí)的場(chǎng)景不是很多,以離線(xiàn)為主,當(dāng)附加了實(shí)時(shí)場(chǎng)景后,由于離線(xiàn)和實(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ì)存在一些問(wèn)題,比如加工邏輯double,開(kāi)發(fā)運(yùn)維也會(huì)double,資源同樣會(huì)變成兩個(gè)資源鏈路。因?yàn)榇嬖谝陨蠁?wèn)題,所以又演進(jìn)了一個(gè)Kappa架構(gòu)。

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

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

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

Kappa架構(gòu)從架構(gòu)設(shè)計(jì)來(lái)講比較簡(jiǎn)單,生產(chǎn)統(tǒng)一,一套邏輯同時(shí)生產(chǎn)離線(xiàn)和實(shí)時(shí)。但是在實(shí)際應(yīng)用場(chǎ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)落地的案例不多見(jiàn),且場(chǎng)景比較單一。

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

Kappa 架構(gòu)在這一塊的思路是:首先要準(zhǔn)備好一個(gè)能夠存儲(chǔ)歷史數(shù)據(jù)的消息隊(duì)列,比如 Kafka,并且這個(gè)消息隊(duì)列是可以支持你從某個(gè)歷史的節(jié)點(diǎn)重新開(kāi)始消費(fèi)的。接著需要新起一個(gè)任務(wù),從原來(lái)比較早的一個(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ù)就可以停掉,并且原來(lái)產(chǎn)出的結(jié)果表也可以被刪掉。

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

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

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

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

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

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