流批一體：數(shù)據(jù)領(lǐng)域的熱門(mén)話(huà)題

流批一體是數(shù)據(jù)領(lǐng)域的熱門(mén)話(huà)題，隨著實(shí)時(shí)數(shù)據(jù)處理需求的不斷涌現(xiàn)和Flink等新興流計(jì)算技術(shù)的持續(xù)發(fā)展，流批一體正從技術(shù)愿景向具體的、適配不同行業(yè)特點(diǎn)的解決方案過(guò)渡。

個(gè)人認(rèn)為，流批一體解決方案的重點(diǎn)分為四個(gè)方面， 數(shù)據(jù)集成、存儲(chǔ)引擎、計(jì)算引擎、元數(shù)據(jù)管理 。

• 數(shù)據(jù)集成

傳統(tǒng)的批量數(shù)據(jù)集成方式是每日一次的批量數(shù)據(jù)傳輸，其載體是文件。實(shí)時(shí)數(shù)據(jù)集成方式則是通過(guò)CDC工具或者調(diào)用API接口推送的方式實(shí)時(shí)進(jìn)行數(shù)據(jù)傳輸，載體是消息，依賴(lài)Kafka等消息隊(duì)列。在Lambda架構(gòu)中，這兩者是同時(shí)存在的，是批量和實(shí)時(shí)兩條數(shù)據(jù)加工鏈條的起點(diǎn)。

從時(shí)效性上，實(shí)時(shí)方式有著顯著優(yōu)勢(shì)，數(shù)據(jù)延遲最快可以達(dá)到秒級(jí)甚至毫秒級(jí)，所以Kappa架構(gòu)倡導(dǎo)將兩者合一，全面采用實(shí)時(shí)數(shù)據(jù)集成方式。

在Kappa架構(gòu)提出多年后，這一設(shè)想并未被普遍采納，我認(rèn)為其中部分原因是，實(shí)時(shí)數(shù)據(jù)集成的穩(wěn)定性不足，以CDC工具和Kafka組成數(shù)據(jù)傳輸鏈路存在一定的數(shù)據(jù)丟失及重復(fù)的可能性。所以，在數(shù)據(jù)準(zhǔn)確性有嚴(yán)苛要求的場(chǎng)景并不適用，金融行業(yè)尤其如此。當(dāng)然，這種數(shù)據(jù)的偏差在其他行業(yè)或許無(wú)關(guān)緊要，比如統(tǒng)計(jì)實(shí)時(shí)交通情況，個(gè)別車(chē)輛信息的丟失并不會(huì)影響對(duì)道路擁堵情況的判斷。

除了準(zhǔn)確性，第二點(diǎn)是數(shù)據(jù)邊界問(wèn)題。實(shí)時(shí)數(shù)據(jù)是以流的概念來(lái)看待數(shù)據(jù)，數(shù)據(jù)就像河水一樣源源不斷，不存在明顯的數(shù)據(jù)邊界。但在金融場(chǎng)景中，因?yàn)闃I(yè)務(wù)原因，數(shù)據(jù)是存在邊界的。比較容易理解的例子是存款計(jì)息，總要有一個(gè)時(shí)點(diǎn)決定是否為用戶(hù)多計(jì)算1天的利息，這是所謂的業(yè)務(wù)日期翻牌。兩種對(duì)數(shù)據(jù)的不同理解，這有點(diǎn)像波粒二相性。

雖然有準(zhǔn)確性和數(shù)據(jù)邊界問(wèn)題，但不代表我們只能停留在Lambda架構(gòu)階段。

實(shí)時(shí)數(shù)據(jù)集成鏈路的技術(shù)在不斷發(fā)展，例如Kafka在0.11版本后增加了冪等性的支持，可以避免網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的消息重復(fù)寫(xiě)入。應(yīng)用層面也可以進(jìn)行彌補(bǔ)，比如在生產(chǎn)者一側(cè)對(duì)一段數(shù)據(jù)流增加數(shù)據(jù)摘要信息，這樣就可以在目標(biāo)端判斷數(shù)據(jù)完整性并做后續(xù)處理。我對(duì)實(shí)時(shí)鏈路的技術(shù)發(fā)展持樂(lè)觀態(tài)度，數(shù)據(jù)丟失和重復(fù)的問(wèn)題是可以被解決的，而且不需要太久。第二點(diǎn)，在金融行業(yè)數(shù)據(jù)邊界問(wèn)題雖然存在，但仍然有大量數(shù)據(jù)可以被看作流的形態(tài)。

如果對(duì)冪等性和數(shù)據(jù)摘要技術(shù)感興趣，可以翻看下我公眾號(hào)之前的文章。

小結(jié)一下，基于金融行業(yè)特點(diǎn)，階段性目標(biāo)是實(shí)時(shí)數(shù)據(jù)集成將會(huì)占據(jù)主導(dǎo)地位，批量集成模式因?yàn)閿?shù)據(jù)邊界問(wèn)題暫時(shí)還會(huì)存在，但可以壓縮到較低的占比。在達(dá)到這一目標(biāo)后，數(shù)據(jù)邊界問(wèn)題也有機(jī)會(huì)用技術(shù)手段實(shí)現(xiàn)，完全實(shí)時(shí)數(shù)據(jù)集成。

• 存儲(chǔ)引擎

存儲(chǔ)引擎可以展開(kāi)為三個(gè)層面，底層存儲(chǔ)、文件格式和表格式。

大數(shù)據(jù)架構(gòu)下HDFS仍然是主要的存儲(chǔ)方式，其設(shè)計(jì)目標(biāo)是為了適應(yīng)海量數(shù)據(jù)處理，默認(rèn)數(shù)據(jù)文件較大。例如，HDFS數(shù)據(jù)塊默認(rèn)大小是128M，顯著高于普通的文件系統(tǒng)。隨著，海量數(shù)據(jù)的真正到來(lái)，基于本地磁盤(pán)的HDFS也有顯著的成本壓力，而對(duì)象存儲(chǔ)因?yàn)槌杀緝?yōu)勢(shì)和對(duì)小文件的友好性，成為各個(gè)企業(yè)的重要選項(xiàng)。當(dāng)然，對(duì)象存儲(chǔ)在性能上的衰減還非常明顯的，所以現(xiàn)階段大多還是存儲(chǔ)容量上的補(bǔ)充手段。隨著冷熱數(shù)據(jù)自動(dòng)遷移技術(shù)的成熟，對(duì)象存儲(chǔ)的應(yīng)用將更加廣泛。同時(shí)，對(duì)象存儲(chǔ)也是存算分離議題的主角，值得探討的內(nèi)容很多，這里不再展開(kāi)，后續(xù)單獨(dú)討論。

文件格式層面，按照技術(shù)特征分為列式存儲(chǔ)和行式存儲(chǔ)兩種，前者的代表是Parquet和ORC，后者的代表是Avro，實(shí)時(shí)鏈路中數(shù)據(jù)是按照產(chǎn)生的次序進(jìn)行推送，所以在傳輸過(guò)程中多采用行式存儲(chǔ)格式進(jìn)行序列化（Avro也是一種序列化框架），而落地?cái)?shù)據(jù)往往采用Parquet等列式存儲(chǔ)更能提升處理性能。

在Hudi/Iceberg等技術(shù)出現(xiàn)后，表格式（table format）成為存儲(chǔ)引擎中的新成員，基于Hudi/Iceberg可以進(jìn)行數(shù)據(jù)update和delete操作，相對(duì)于之前只能采用全量覆蓋方式（overwrite），極大的改善了Hadoop體系下增量數(shù)據(jù)的處理效率，使得那些在MPP數(shù)據(jù)庫(kù)上積累的數(shù)據(jù)建模方法，可以更多的遷移到Hadoop體系。

小結(jié)一下，存儲(chǔ)引擎?zhèn)鹊闹匾�變革是表格式的引入，提供更高效的update和delete操作能力，所以無(wú)論是對(duì)實(shí)時(shí)數(shù)據(jù)處理還批量數(shù)據(jù)處理，都有顯著的幫助。

• 計(jì)算引擎

Hadoop生態(tài)體系中，Hive/Spark/Flink都是占有重要地位的計(jì)算引擎。嚴(yán)格來(lái)講Hive并不是計(jì)算引擎，通常是指代Hive+MapReduce，其中MapReduce才是Hadoop的初代計(jì)算引擎。但隨著技術(shù)發(fā)展，尤其是Hadoop主要供應(yīng)商Cloudera將產(chǎn)品升級(jí)到CDP后，默認(rèn)引擎從MapReduce切換為T(mén)ez，MapReduce已經(jīng)逐漸退出舞臺(tái)，只是作為遺留技術(shù)存在。Spark社區(qū)有著強(qiáng)大的生命力和廣泛的影響，在性能上較MapReduce有顯著優(yōu)勢(shì)，還適用于批量、流計(jì)算、AI等多種場(chǎng)景。Flink作為新興計(jì)算引擎，在產(chǎn)生之初就以實(shí)時(shí)計(jì)算為目標(biāo)場(chǎng)景，而后展露出更大的野心，將目標(biāo)鎖定為流批一體的計(jì)算引擎。同時(shí)，還衍生出配套的存儲(chǔ)開(kāi)源組件Paimon。

小結(jié)一下，Spark和Flink都有可能實(shí)現(xiàn)計(jì)算引擎層面的流批一體，而國(guó)內(nèi)程序員對(duì)Flink社區(qū)的參與度更高，這或許將成為Flink的一種優(yōu)勢(shì)，影響未來(lái)流批一體計(jì)算引擎的市場(chǎng)占有率。

• 元數(shù)據(jù)管理

元數(shù)據(jù)一直是數(shù)據(jù)領(lǐng)域必不可少，但又不溫不火的話(huà)題。元數(shù)據(jù)對(duì)于打造 自動(dòng)化數(shù)據(jù)流水線 至關(guān)重要。同時(shí)，元數(shù)據(jù)也是銜接流式數(shù)據(jù)和批量數(shù)據(jù)的重要紐帶。

Hadoop體系下，HMS（HiveMetaStore）是元數(shù)據(jù)管理的事實(shí)標(biāo)準(zhǔn)，雖然HMS誕生之初僅是Hive的附屬組件，但由于Hive曾經(jīng)巨大市場(chǎng)占有率，其他計(jì)算引擎要融入生態(tài)必須主動(dòng)適配HMS，得益于開(kāi)源的獨(dú)特優(yōu)勢(shì)，HMS也沒(méi)有禁止這種適配。由此，HMS逐漸被視為一種中立的元數(shù)據(jù)管理組件。所以，即使Hive會(huì)伴隨著MapReduce退出而逐漸衰落，但HMS仍然具有強(qiáng)大的、獨(dú)立的生命力。

流批一體的愿景下，元數(shù)據(jù)管理的提升目標(biāo)是彌補(bǔ)批量數(shù)據(jù)集成鏈路的天生缺陷，提升流批一體的自動(dòng)化能力和集成能力。傳統(tǒng)的批量數(shù)據(jù)集成，僅僅集成了數(shù)據(jù)本身，并沒(méi)有附帶元數(shù)據(jù)（如表結(jié)構(gòu)信息），元數(shù)據(jù)在源端和目標(biāo)端的一致性，完全依靠人工的線下溝通而后分別投產(chǎn)。這種人工機(jī)制的風(fēng)險(xiǎn)性不言而喻，在海量數(shù)據(jù)的背景下，引發(fā)問(wèn)題的絕對(duì)數(shù)量不會(huì)太小。

依托CDC工具的實(shí)時(shí)數(shù)據(jù)集成鏈路，有機(jī)會(huì)實(shí)現(xiàn)系統(tǒng)間的元數(shù)據(jù)自動(dòng)對(duì)接。事實(shí)上，OGG（Oracle Golden Gate）等工具已經(jīng)提供了實(shí)時(shí)推送表結(jié)構(gòu)變更的能力，可以通過(guò)SR（Schema Registry）接收，但SR與HMS之間的協(xié)同還需要進(jìn)一步處理。由此看來(lái)，HMS現(xiàn)階段提供的還是以批量場(chǎng)景為主的元數(shù)據(jù)管理能力。

基于我們?cè)跀?shù)據(jù)集成部分的結(jié)論，批量數(shù)據(jù)和流數(shù)據(jù)在相當(dāng)長(zhǎng)時(shí)間內(nèi)仍會(huì)并存，而這兩者在使用場(chǎng)景上又不是完全割裂的，所以元數(shù)據(jù)管理模塊要同時(shí)兼容這兩種形態(tài)的數(shù)據(jù)。

小結(jié)一下，HMS是元數(shù)據(jù)管理的事實(shí)標(biāo)準(zhǔn)，具有支撐流批一體架構(gòu)的能力，但在自動(dòng)化能力和集成能力等方面仍有提升空間，特別是對(duì)實(shí)時(shí)數(shù)據(jù)的元數(shù)據(jù)管理能力有待進(jìn)一步加強(qiáng)�；蛟S，其他元數(shù)據(jù)管理組件也會(huì)借此挑戰(zhàn)HMS的地位，比如Databricks今年開(kāi)源的Unity Catalog。

最后總結(jié)一下，本文中我們將流批一體分為數(shù)據(jù)集成、存儲(chǔ)引擎、計(jì)算引擎和元數(shù)據(jù)管理四個(gè)方面，其中元數(shù)據(jù)管理和存儲(chǔ)引擎的統(tǒng)一規(guī)范是強(qiáng)約束，技術(shù)產(chǎn)品是排他的；數(shù)據(jù)集成層面以實(shí)時(shí)鏈路為主，批量鏈路為輔；計(jì)算引擎則是可分可合，不一定是單一計(jì)算引擎通吃的局面，而Flink從社區(qū)參與者的角度看，相對(duì)更有優(yōu)勢(shì)。

一家之言，且從行業(yè)視角出發(fā)，難免有偏頗之處，歡迎留言批評(píng)指正。

• 《暗喻幻想：ReFantazio》尤法社群等級(jí)提升作用介紹
• 【長(zhǎng)城守望】新服開(kāi)啟！沖榜就送非遺城磚
• 《寶可夢(mèng)大集結(jié)》路卡利歐技能圖鑒
• 《塞爾達(dá)傳說(shuō) 智慧的再現(xiàn)》螺旋甜味冰沙怎么制作
• 《仙劍世界》黑蜘蛛森林寶箱開(kāi)啟方法