一文了解基于Flink構(gòu)建全場(chǎng)景實(shí)時(shí)數(shù)倉(cāng)
本文目錄:
一. 實(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ù)雜的分析。
發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
最新活動(dòng)更多
-
10月31日立即下載>> 【限時(shí)免費(fèi)下載】TE暖通空調(diào)系統(tǒng)高效可靠的組件解決方案
-
即日-11.13立即報(bào)名>>> 【在線(xiàn)會(huì)議】多物理場(chǎng)仿真助跑新能源汽車(chē)
-
11月28日立即報(bào)名>>> 2024工程師系列—工業(yè)電子技術(shù)在線(xiàn)會(huì)議
-
12月19日立即報(bào)名>> 【線(xiàn)下會(huì)議】OFweek 2024(第九屆)物聯(lián)網(wǎng)產(chǎn)業(yè)大會(huì)
-
即日-12.26火熱報(bào)名中>> OFweek2024中國(guó)智造CIO在線(xiàn)峰會(huì)
-
即日-2025.8.1立即下載>> 《2024智能制造產(chǎn)業(yè)高端化、智能化、綠色化發(fā)展藍(lán)皮書(shū)》
推薦專(zhuān)題
- 1 【一周車(chē)話(huà)】沒(méi)有方向盤(pán)和踏板的車(chē),你敢坐嗎?
- 2 特斯拉發(fā)布無(wú)人駕駛車(chē),還未迎來(lái)“Chatgpt時(shí)刻”
- 3 特斯拉股價(jià)大跌15%:Robotaxi離落地還差一個(gè)蘿卜快跑
- 4 馬斯克給的“驚喜”夠嗎?
- 5 打完“價(jià)格戰(zhàn)”,大模型還要比什么?
- 6 馬斯克致敬“國(guó)產(chǎn)蘿卜”?
- 7 神經(jīng)網(wǎng)絡(luò),誰(shuí)是盈利最強(qiáng)企業(yè)?
- 8 比蘋(píng)果偉大100倍!真正改寫(xiě)人類(lèi)歷史的智能產(chǎn)品降臨
- 9 諾獎(jiǎng)進(jìn)入“AI時(shí)代”,人類(lèi)何去何從?
- 10 Open AI融資后成萬(wàn)億獨(dú)角獸,AI人才之爭(zhēng)開(kāi)啟
- 高級(jí)軟件工程師 廣東省/深圳市
- 自動(dòng)化高級(jí)工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷(xiāo)售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級(jí)銷(xiāo)售經(jīng)理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術(shù)專(zhuān)家 廣東省/江門(mén)市
- 封裝工程師 北京市/海淀區(qū)
- 結(jié)構(gòu)工程師 廣東省/深圳市