流批一體是數(shù)據(jù)領域的熱門話題，隨著實時數(shù)據(jù)處理需求的不斷涌現(xiàn)和Flink等新興流計算技術的持續(xù)發(fā)展，流批一體正從技術愿景向具體的、適配不同行業(yè)特點的解決方案過渡。 個人認為，流批一體解決方案的重點分為四個方面，數(shù)據(jù)集成、存儲引擎、計算引擎、元數(shù)據(jù)管理。 數(shù)據(jù)集成 傳統(tǒng)的批量數(shù)據(jù)集成方式是每日一次的批
流批一體是數(shù)據(jù)領域的熱門話題，隨著實時數(shù)據(jù)處理需求的不斷涌現(xiàn)和Flink等新興流計算技術的持續(xù)發(fā)展，流批一體正從技術愿景向具體的、適配不同行業(yè)特點的解決方案過渡。
個人認為，流批一體解決方案的重點分為四個方面， 數(shù)據(jù)集成、存儲引擎、計算引擎、元數(shù)據(jù)管理 。
傳統(tǒng)的批量數(shù)據(jù)集成方式是每日一次的批量數(shù)據(jù)傳輸，其載體是文件。實時數(shù)據(jù)集成方式則是通過CDC工具或者調用API接口推送的方式實時進行數(shù)據(jù)傳輸，載體是消息，依賴Kafka等消息隊列。在Lambda架構中，這兩者是同時存在的，是批量和實時兩條數(shù)據(jù)加工鏈條的起點。
從時效性上，實時方式有著顯著優(yōu)勢，數(shù)據(jù)延遲最快可以達到秒級甚至毫秒級，所以Kappa架構倡導將兩者合一，全面采用實時數(shù)據(jù)集成方式。
在Kappa架構提出多年后，這一設想并未被普遍采納，我認為其中部分原因是，實時數(shù)據(jù)集成的穩(wěn)定性不足，以CDC工具和Kafka組成數(shù)據(jù)傳輸鏈路存在一定的數(shù)據(jù)丟失及重復的可能性。所以，在數(shù)據(jù)準確性有嚴苛要求的場景并不適用，金融行業(yè)尤其如此。當然，這種數(shù)據(jù)的偏差在其他行業(yè)或許無關緊要，比如統(tǒng)計實時交通情況，個別車輛信息的丟失并不會影響對道路擁堵情況的判斷。
除了準確性，第二點是數(shù)據(jù)邊界問題。實時數(shù)據(jù)是以流的概念來看待數(shù)據(jù)，數(shù)據(jù)就像河水一樣源源不斷，不存在明顯的數(shù)據(jù)邊界。但在金融場景中，因為業(yè)務原因，數(shù)據(jù)是存在邊界的。比較容易理解的例子是存款計息，總要有一個時點決定是否為用戶多計算1天的利息，這是所謂的業(yè)務日期翻牌。兩種對數(shù)據(jù)的不同理解，這有點像波粒二相性。
雖然有準確性和數(shù)據(jù)邊界問題，但不代表我們只能停留在Lambda架構階段。
實時數(shù)據(jù)集成鏈路的技術在不斷發(fā)展，例如Kafka在0.11版本后增加了冪等性的支持，可以避免網絡抖動導致的消息重復寫入。應用層面也可以進行彌補，比如在生產者一側對一段數(shù)據(jù)流增加數(shù)據(jù)摘要信息，這樣就可以在目標端判斷數(shù)據(jù)完整性并做后續(xù)處理。我對實時鏈路的技術發(fā)展持樂觀態(tài)度，數(shù)據(jù)丟失和重復的問題是可以被解決的，而且不需要太久。第二點，在金融行業(yè)數(shù)據(jù)邊界問題雖然存在，但仍然有大量數(shù)據(jù)可以被看作流的形態(tài)。
如果對冪等性和數(shù)據(jù)摘要技術感興趣，可以翻看下我公眾號之前的文章。
小結一下，基于金融行業(yè)特點，階段性目標是實時數(shù)據(jù)集成將會占據(jù)主導地位，批量集成模式因為數(shù)據(jù)邊界問題暫時還會存在，但可以壓縮到較低的占比。在達到這一目標后，數(shù)據(jù)邊界問題也有機會用技術手段實現(xiàn)，完全實時數(shù)據(jù)集成。
存儲引擎可以展開為三個層面，底層存儲、文件格式和表格式。
大數(shù)據(jù)架構下HDFS仍然是主要的存儲方式，其設計目標是為了適應海量數(shù)據(jù)處理，默認數(shù)據(jù)文件較大。例如，HDFS數(shù)據(jù)塊默認大小是128M，顯著高于普通的文件系統(tǒng)。隨著，海量數(shù)據(jù)的真正到來，基于本地磁盤的HDFS也有顯著的成本壓力，而對象存儲因為成本優(yōu)勢和對小文件的友好性，成為各個企業(yè)的重要選項。當然，對象存儲在性能上的衰減還非常明顯的，所以現(xiàn)階段大多還是存儲容量上的補充手段。隨著冷熱數(shù)據(jù)自動遷移技術的成熟，對象存儲的應用將更加廣泛。同時，對象存儲也是存算分離議題的主角，值得探討的內容很多，這里不再展開，后續(xù)單獨討論。
文件格式層面，按照技術特征分為列式存儲和行式存儲兩種，前者的代表是Parquet和ORC，后者的代表是Avro，實時鏈路中數(shù)據(jù)是按照產生的次序進行推送，所以在傳輸過程中多采用行式存儲格式進行序列化（Avro也是一種序列化框架），而落地數(shù)據(jù)往往采用Parquet等列式存儲更能提升處理性能。
在Hudi/Iceberg等技術出現(xiàn)后，表格式（table format）成為存儲引擎中的新成員，基于Hudi/Iceberg可以進行數(shù)據(jù)update和delete操作，相對于之前只能采用全量覆蓋方式（overwrite），極大的改善了Hadoop體系下增量數(shù)據(jù)的處理效率，使得那些在MPP數(shù)據(jù)庫上積累的數(shù)據(jù)建模方法，可以更多的遷移到Hadoop體系。
小結一下，存儲引擎?zhèn)鹊闹匾兏锸潜砀袷降囊�，提供更高效的update和delete操作能力，所以無論是對實時數(shù)據(jù)處理還批量數(shù)據(jù)處理，都有顯著的幫助。
Hadoop生態(tài)體系中，Hive/Spark/Flink都是占有重要地位的計算引擎。嚴格來講Hive并不是計算引擎，通常是指代Hive+MapReduce，其中MapReduce才是Hadoop的初代計算引擎。但隨著技術發(fā)展，尤其是Hadoop主要供應商Cloudera將產品升級到CDP后，默認引擎從MapReduce切換為Tez，MapReduce已經逐漸退出舞臺，只是作為遺留技術存在。Spark社區(qū)有著強大的生命力和廣泛的影響，在性能上較MapReduce有顯著優(yōu)勢，還適用于批量、流計算、AI等多種場景。Flink作為新興計算引擎，在產生之初就以實時計算為目標場景，而后展露出更大的野心，將目標鎖定為流批一體的計算引擎。同時，還衍生出配套的存儲開源組件Paimon。
小結一下，Spark和Flink都有可能實現(xiàn)計算引擎層面的流批一體，而國內程序員對Flink社區(qū)的參與度更高，這或許將成為Flink的一種優(yōu)勢，影響未來流批一體計算引擎的市場占有率。
元數(shù)據(jù)一直是數(shù)據(jù)領域必不可少，但又不溫不火的話題。元數(shù)據(jù)對于打造 自動化數(shù)據(jù)流水線 至關重要。同時，元數(shù)據(jù)也是銜接流式數(shù)據(jù)和批量數(shù)據(jù)的重要紐帶。
Hadoop體系下，HMS（HiveMetaStore）是元數(shù)據(jù)管理的事實標準，雖然HMS誕生之初僅是Hive的附屬組件，但由于Hive曾經巨大市場占有率，其他計算引擎要融入生態(tài)必須主動適配HMS，得益于開源的獨特優(yōu)勢，HMS也沒有禁止這種適配。由此，HMS逐漸被視為一種中立的元數(shù)據(jù)管理組件。所以，即使Hive會伴隨著MapReduce退出而逐漸衰落，但HMS仍然具有強大的、獨立的生命力。
流批一體的愿景下，元數(shù)據(jù)管理的提升目標是彌補批量數(shù)據(jù)集成鏈路的天生缺陷，提升流批一體的自動化能力和集成能力。傳統(tǒng)的批量數(shù)據(jù)集成，僅僅集成了數(shù)據(jù)本身，并沒有附帶元數(shù)據(jù)（如表結構信息），元數(shù)據(jù)在源端和目標端的一致性，完全依靠人工的線下溝通而后分別投產。這種人工機制的風險性不言而喻，在海量數(shù)據(jù)的背景下，引發(fā)問題的絕對數(shù)量不會太小。
依托CDC工具的實時數(shù)據(jù)集成鏈路，有機會實現(xiàn)系統(tǒng)間的元數(shù)據(jù)自動對接。事實上，OGG（Oracle Golden Gate）等工具已經提供了實時推送表結構變更的能力，可以通過SR（Schema Registry）接收，但SR與HMS之間的協(xié)同還需要進一步處理。由此看來，HMS現(xiàn)階段提供的還是以批量場景為主的元數(shù)據(jù)管理能力。
基于我們在數(shù)據(jù)集成部分的結論，批量數(shù)據(jù)和流數(shù)據(jù)在相當長時間內仍會并存，而這兩者在使用場景上又不是完全割裂的，所以元數(shù)據(jù)管理模塊要同時兼容這兩種形態(tài)的數(shù)據(jù)。
小結一下，HMS是元數(shù)據(jù)管理的事實標準，具有支撐流批一體架構的能力，但在自動化能力和集成能力等方面仍有提升空間，特別是對實時數(shù)據(jù)的元數(shù)據(jù)管理能力有待進一步加強�；蛟S，其他元數(shù)據(jù)管理組件也會借此挑戰(zhàn)HMS的地位，比如Databricks今年開源的Unity Catalog。
最后總結一下，本文中我們將流批一體分為數(shù)據(jù)集成、存儲引擎、計算引擎和元數(shù)據(jù)管理四個方面，其中元數(shù)據(jù)管理和存儲引擎的統(tǒng)一規(guī)范是強約束，技術產品是排他的；數(shù)據(jù)集成層面以實時鏈路為主，批量鏈路為輔；計算引擎則是可分可合，不一定是單一計算引擎通吃的局面，而Flink從社區(qū)參與者的角度看，相對更有優(yōu)勢。
一家之言，且從行業(yè)視角出發(fā)，難免有偏頗之處，歡迎留言批評指正。
小編推薦閱讀
