隨著結構化數(shù)據(jù)、半結構化數(shù)據(jù)和非結構化數(shù)據(jù)的不斷增加，越來越多的企業(yè)選擇將數(shù)據(jù)存儲在數(shù)據(jù)湖中，便于更好地管理和利用數(shù)據(jù)資產。但是企業(yè)對數(shù)據(jù)更新處理時效性的要求越來越高，數(shù)據(jù)湖無法實現(xiàn)高吞吐、低延遲的數(shù)據(jù)攝入、流式訂閱以及實時查詢。因此流式數(shù)據(jù)湖存儲技術誕生了。

在近日舉辦的WOT全球技術創(chuàng)新大會2023·北京站的《大數(shù)據(jù)技術創(chuàng)新》專場中，來自阿里云的高級技術專家李勁松帶來了主題為《Apache Paimon 流式數(shù)據(jù)湖 V0.4與后續(xù)展望》的精彩分享，從理論、實踐和未來發(fā)展方面詳細介紹了Apache Paimon 流式數(shù)據(jù)湖。

Apache Paimon 流式數(shù)據(jù)湖是什么？

Apache Paimon是一個從準實時出發(fā)的流式數(shù)據(jù)湖，也是專門為CDC處理流計算而生的數(shù)據(jù)湖。Apache Paimon的創(chuàng)新之處在于采用了湖存儲+ LSM的文件組織架構，基于分布式文件系統(tǒng)管理元數(shù)據(jù)。

在管理元數(shù)據(jù)之前，首先需要處理元數(shù)據(jù)。當元數(shù)據(jù)流入Apache Paimon后，其處理流程分為寫入、壓縮、清理和讀取。寫入和壓縮都在Flink Job中完成，用戶無需創(chuàng)建Spark的離線作業(yè)再做異步聚簇（Clustering）?；谶@樣的設計，Apache Paimon的優(yōu)勢之一就是Append 寫入，所以吞吐大；局部壓縮減少了寫入放大，所以消耗低。最后在Flink Sink中自動清理、有序合并。

而對于任何一個創(chuàng)新的技術來說，沒有良好的生態(tài)體系就無法走得長遠。雖然Apache Paimon目前的生態(tài)體系還不及傳統(tǒng)數(shù)據(jù)湖，但也已經支持或部分支持Flink、Hive、Trino、Spark和Presto。

其中，Apache Paimon對Flink的支持最佳，可以支持Flink的所有特征。其次是Spark，目前能夠支持讀寫，也基本支持Create Table。StarRocks、DORIS、網易Arctic，阿里云大數(shù)據(jù)計算（MaxCompute）和實時數(shù)倉（Hologres）等產品也正在積極對接中。

流式數(shù)據(jù)湖新場景

“實時”是流式數(shù)據(jù)湖的核心。所以Apache Paimon最大的特點就是能讓數(shù)據(jù)實時流入，做到實時數(shù)據(jù)流讀和實時字段打寬，不再是每天或每小時更新離線數(shù)倉的數(shù)據(jù)。但是目前在實時入湖、打寬和流讀中也面臨許多痛點，比如吞吐量低和資源消耗高、存在亂序等等。在本次分享中，李勁松詳細介紹了數(shù)據(jù)湖新場景中的痛點，以及Apache Paimon是如何解決這些難題的。

實時數(shù)據(jù)入湖

想要處理數(shù)據(jù)，首先需要讓數(shù)據(jù)入湖。而實時數(shù)據(jù)入湖是實時更新來自數(shù)據(jù)庫的 CDC 數(shù)據(jù)。但是在實時數(shù)據(jù)入湖時存在著三類問題。首先，是吞吐量低和資源消耗高的問題。第二，在管理方面，數(shù)據(jù)湖需要管理好壓縮、清理歷史文件和清理過期分區(qū)，并且不需要額外的管理成本。最后在模型演進方面，數(shù)據(jù)湖不會跟隨模型的變化而變化，僅僅只是存儲數(shù)據(jù)。

針對這些問題，Apache Paimon從架構和功能兩方面雙管齊下。從架構方面來說，當數(shù)據(jù)湖結合LSM 的Append后，形成了高效寫入吞吐的優(yōu)勢；結合LSM的Minor Compaction后，可以有效減少寫入放大，從而解決吞吐量小和資源消耗高的問題。而LSM是按照組件排序的，所以Apache Paimon的寫入性能較原有的Hudi表提升了3倍以上；部分查詢性能則提升了7倍。

在功能方面，李勁松重點介紹了Apache Paimon的CDC入湖功能：表同步和整庫同步。

表同步可以同步表的結構，包括增列、刪列、類型變更和重命名列，還可以新增計算力、定義分區(qū)力和定義組件，甚至做到分庫分表的同步。整庫同步可以指定表、增加前后綴，也可以動態(tài)新增表。在這兩個功能基礎上，Apache Paimon還提供了CDC Data Schema API，基于Data Schema API便能同步更多的數(shù)據(jù)，甚至在分級的流計算中做到模型同步。

實時字段打寬

數(shù)據(jù)入湖存儲后，如果不用則會變成數(shù)據(jù)沼澤。實時打寬維表的字段能夠給下游提供查詢及流讀，讓數(shù)據(jù)流動起來。但是實時字段打寬同樣存在三類問題。第一個問題也是吞吐量低和資源消耗高。第二，在讀取方面，如果無法支持列裁剪，則無法達到高效的讀時合并（Merge On Read）。最后是亂序的處理問題，Apache Paimon是基于分布式文件系統(tǒng)管理元數(shù)據(jù)的，但是分布式處理的亂序場景非常多，亂序如何處理？

Apache Paimon通過支持部分更新來解決這些問題。Apache Paimon基于LSM的部分更新（Partial-Update）功能，從而在讀時合并和合并（Merge）時做到部分更新。這就意味著在查詢時可以做到列裁剪，并且在寫入達到高吞吐時，也能保證查詢有非常好的性能。

而針對亂序問題，Apache Paimon支持定義Sequence Field處理亂序。Apache Paimon V0.5版本引入了一個新的概念——Sequence Group。Sequence Group是讓每個流定義自己的序列組應對多流亂序，從而真正做到部分更新，而不是non-null Update。

實時數(shù)據(jù)流讀

實時數(shù)據(jù)流讀是提供消息隊列體驗的流讀，并能根據(jù)主鍵生成變更日志。數(shù)據(jù)湖流讀的痛點之一在于沒有全量數(shù)據(jù)。如果沒有以前的數(shù)據(jù)，數(shù)據(jù)只能完全從零開始生成，那么結果可能就會很不理想。除此之外，數(shù)據(jù)湖還有生成變更日志成本較高、文件清理與流讀的矛盾（FileNotFound）以及不支持Flink的Lookup Join的問題。

Apache Paimon著重增強了流讀。Apache Paimon首先支持流讀原始數(shù)據(jù)，實現(xiàn)全增量數(shù)據(jù)一體流讀。而在生成變更日志方面，Apache Paimon是以Full-compaction的方式生成變更日志，同時也支持多種生成方案，其中就包括Flink的Lookup Join。通過Apache Paimon生成的變更日志，時延也有所降低：Lookup 模式時延在1-3分鐘；Full-compaction 模式時延在3-10分鐘。

此外，Apache Paimon還有一個新的功能——Consumer-ID。Consumer-ID類似Kafka的GroupID，確保數(shù)據(jù)不會被淘汰，保證流讀的安全性。Consumer-ID也支持流讀無狀態(tài)重啟，解決流讀恢復時的FileNotFound的問題。

Apache Paimon在社區(qū)中的應用實踐

以上都是從理論方面介紹Apache Paimon的獨特之處。而在實踐應用中，Apache Paimon的表現(xiàn)又如何？接下來，李勁松主要介紹了Apache Paimon在阿里云計算平臺、字節(jié)跳動、同程旅行及其它社區(qū)中的應用實踐，展現(xiàn)出Apache Paimon出色的實踐能力。

阿里云計算平臺目前已達到了計算全集成，Apache Paimon替代Hudi成為實時入湖的首選。計算平臺可以通過實時計算Flink入湖，或通過CTAS、CDAS命令達到模型同步入湖，并進行實時計算流讀。

而字節(jié)跳動集成了Apache Paimon + Flink，解決了血緣管理和一致性管理問題，實現(xiàn)了真正意義上的Streaming Warehouse生產體系，讓每個數(shù)據(jù)流動并沉淀。

同程旅行引入Apache Paimon，優(yōu)化了原有的Hudi近實時數(shù)倉，整體規(guī)模達到了上百個作業(yè)，最大的表有90億+的數(shù)據(jù)。

除此以外，中原銀行、米哈游、Bilibili、塵鋒信息、汽車之家、巴別時代、海蘭寰宇等企業(yè)都在用Apache Paimon + Flink探索流式數(shù)倉，甚至是向流批一體近實時數(shù)倉的方向前進。

Apache Paimon未來規(guī)劃

通過從理論和應用實踐方面的介紹，不難看出Apache Paimon已經解決了很多目前數(shù)據(jù)湖存在的問題。但是Apache Paimon的創(chuàng)新不止于此。在演講的最后，李勁松提到了Apache Paimon短期和長期的發(fā)展規(guī)劃，表明了未來的發(fā)展方向。

首先在短期內，Apache Paimon需要加強CDC場景、實現(xiàn)動態(tài) Bucket 全自動、創(chuàng)建Immutable Tag從而提供Immutable的離線版本、增強Append-Only處理以及Spark集成。

從長期發(fā)展來看， CDC實時數(shù)據(jù)湖需要在Apache Paimon中達到完全成熟的狀態(tài)；其次，Append離線表達到生產可用的狀態(tài)；最后，生態(tài)能夠達到全面對接，Spark集成完全成熟。

以上內容整理自阿里云高級技術專家李勁松在WOT全球技術創(chuàng)新大會2023·北京站《大數(shù)據(jù)技術創(chuàng)新》專場中的精彩分享。獲取完整PPT請關注51CTO技術棧公眾號，后臺發(fā)送【WOT2023PPT】即可直接領取。