Apache Paimon 統一大數據湖儲存底座

2024-06-19資訊

摘要：本文整理自 Apache Paimon PMC Chair 李勁松（之信）老師在 5月16日 Streaming Lakehouse Meetup · Online 上的分享，主要分享 Apache Paimon 相關的演進、目標及套用。內容主要分為以下四個部份：

從孵化到畢業，Paimon 的發展與場景
統一儲存底座，Paimon 與流、批、OLAP
完整生態整合，Paimon 的計算引擎推薦
阿裏巴巴實踐，Paimon 數據湖戰役

Tips： 點選 「閱讀原文」 跳轉阿裏雲即時計算 Flink～

從孵化到畢業，Paimon 的發展與場景

Paimon 最初在Flink社群中以 Flink Table Store 的名稱出現，開始在 Flink 社群內孵化。直到 2023 年，Paimon 發展成為一個公共的、與具體引擎無關的湖式（Lakehouse）架構，從 Flink 社群獨立出來，轉變成一個 Apache 計畫。到了 2024 年 4 月，Paimon 正式完成了在 Apache 的孵化過程，成為了一個頂級計畫。

1.1 數據架構的演進：流批一體的 Lakehouse

在為什麽要做 Paimon 之前,必然會談及數據架構的演進，即為什麽最後會做出即時資料庫 Apache Paimon。

業界最開始的架構基本上是 Warehouse 架構，比如傳統的 Hive 數倉，是一個天級的ETL分析，不管是 LOG 還是 CDC 數據都是透過 Batch 的方式流入數倉，ETL 再進行加工，最終匯入業務庫。以上方式的好處是流程非常簡單，壞處是其數據時效性永遠是 T+1 的。

此時，Flink 出現了，Flink 主打流式計算，能將傳統離線數倉的時效性從 T+1（天級/小時級）加速至秒級。所有的數據透過秒級流動的方式流入數倉，稱為即時數倉（Streaming Warehouse），數據最終落入最底層的 ADS、OLAP 等系統提供秒級的查詢。整條鏈路非常即時，這是近年總體的發展方向，但成本很大，開發復雜度較高。所以可以遷移部份價值較高的業務至即時流式數倉，但是往往遷移不了全部業務，故上述兩種方式在業界並存。

不僅是即時數倉，離線數倉也在往更好的方向發展，出現了 Lake house，它不只是一個純離線架構，還能帶來一定的Streaming 處理。它在原來離線數倉上做更好的操作，因為底下的 Data Lake Format 有更細粒度的保證。在此基礎上，天級的重新整理帶來了更好的時效性保障。但此時，Warehouse、Lakehouse、Streaming Warehouse 還是比較割裂的狀態，中間仍缺乏讓兩種技術融合在一起的部份。

Paimon 的出發點是想透過底層格式的提升來實作 Streaming Warehouse 的分鐘級數據更新，以此促進 Lakehouse 的數據全鏈路流動。Paimon 把整套架構連在一起，數據以離線的方式或更低成本的方式來 Work，當離線的方式不夠，需要更高的時效性時，就可以用 Streaming 的方式使之流動。這離不開兩個技術，一個是 Flink，目前主流的流計算引擎，另一個是更好能力的格式支撐。

1.2 Paimon前身FTS誕生的特點與優勢

為什麽做 Paimon 這樣全新的湖格式，有以下三點緣由（優勢）。

（1）即時數據湖，以低成本的方式支持湖上更新，且在此基礎上還有開放的格式、數據、計算。

（2）流式數據湖，深度整合 Flink 流式計算，完整的流讀流寫與融合狀態計算的方式。

（3）國人主導的社群，目前可看到來自阿裏、字節等國內各種公司，Paimon 社群/ Flink Table Store 的存在確保了針對國內企業問題解決時的溝通更為直接，響應更加迅速。

我們認為以上三點是別的技術無法取代或根本解決的，所以研發了 Flink Table Store。

1.3 Paimon社群的發展

從 Flink Table Store 到 Paimon 孵化再到成功畢業這兩年來，Paimon 社群的發展非常迅速。從 2022 年到 2024 年， Contributors、Commits、Stars 都有巨大提升，這離不開國內各大公司的支持。

1.4 Paimon 的核心場景

目前 Paimon 的核心場景主要有以下三點。

（1）CDC 入湖

Paimon 對此做了相當多的最佳化，來保證更簡化的架構、更好的效能與即時性。具體有：一鍵整庫入湖，大幅簡化架構；也可達到即時更新、極速查詢的場景，且在此基礎上成本不高；可以靈活更新，定義部份列更新、多種聚合更新。

（2）構建流式鏈路

即可以用 Paimon 來構建完整的 Streaming 鏈路，有以下幾個支撐的場景：第一，可生成變更日誌，在流讀時就能拿到已更新好的全行的 Record 數據，這非常有利於 Streaming 鏈路的構建；第二，Paimon 也朝著變成真正的佇列的方式向前發展，有消費者機制，在最新版本當中，有變更日誌單獨生命周期管理，可像 Kafka 一樣定義更長的變更日誌的生命周期，比如 Kafka 保存一天以上或者三天；在此基礎上，構成了輕狀態低成本的流式鏈路。

（3）極速 OLAP 查詢

前二者使整條鏈路流起來了，但流起來之後，數據需要沈澱，所以 Paimon 也做了很多東西，使在這條鏈路沈澱下來的數據中能達到極速的OLAP查詢。第三點就是實作 Z-Order + 索引結合計算極速分析；分析引擎在 Paimon 上蓬勃發展，形成平權發展的引擎生態，包括 Flink, Spark, StarRocks, Trino 都能很好的查詢。

統一儲存底座，Paimon 與流、批、OLAP

接下來簡單分析一下，Paimon如何做統一儲存底座，如何賦能流、批，OLAP更好的查詢。

2.1 流、批、OLAP 一體化架構

首先看 Streaming Lakehouse 架構，數據可以被 Streaming Ingestion 流入數據湖中。Paimon 可以架設在 OSS、HDFS 等系統上，然後在此之上把數據沈澱下來，透過 Flink 或 Spark 以Batch 的計算方式降低成本。也可以為了時效性，用 Streaming 的方式，如 Flink Streaming SQL 使整條鏈路流動起來。數據沈澱需要分析，為了進行深入分析和獲取洞察，我們常常需要借助 OLAP。Trino 和 StarRocks 等技術都是進行 OLAP 分析的優秀選擇。Paimon 社群希望能將這三者都做到極致，或業界領先的水準，所以這套架構能支撐完整的三種計算，也能支撐各種各樣能力豐富的計算引擎。

2.2 Paimon 的統一儲存發展

下圖羅列了 Paimon 做了一些支撐。

（1）流

第一，作為統一儲存發展，在流方向與 Flink 深度整合，共同往前發展；第二，Flink 與 Paimon 兩個社群攜手共進，整體繼續提升更新能力，更新是流的基礎；第三，Paimon 擴大流寫流讀的場景，分鐘級覆蓋所有 Streaming 場景。

（2）批

主要分為兩個方向，一個方向是繼續和 Flink 往前，打造流批一體架構，流批一體計算 + 流批一體儲存；第二，目前業界常用的批次處理引擎是 Spark，所以 Paimon 深度整合 Spark，打造了業界領先的批讀批寫效能，預計在不久的將來，阿裏雲也會使用 Spark 與 Paimon 來進行 TPC-DS 的標準測試。

（3）OLAP

第一，Paimon 深度整合 OLAP 引擎：StarRocks、Trino 等；第二，推出 Deletion Vectors 模式，能在湖儲存上達到近即時更新，極速查詢；第三，檔上加強 Z-Order 及豐富的索引，加速查詢。

綜上，在流、批、OLAP 中，Paimon 作為一個儲存格式，低成本、分鐘級覆蓋主流大數據需求。

完整生態整合，Paimon 的計算引擎推薦

接下來分享完整生態整合以及 Paimon 的優勢。

主要分為三個領域：流寫流讀、批寫、批讀/OLAP。在這三個方面，擁有全部能力的是 Flink，這並不意味著 Flink 所有的東西都非常好，它最好的地方在流寫流讀；批寫批讀的能力除了 Flink 就是 Spark，它是推薦的批引擎，也有部份流寫流讀能力，但弱於 Flink；查詢側則整合了較為豐富的生態，目前市面上主流的引擎都能查詢 Paimon，目前有較強 OLAP 能力的是 StarRocks，當然 Trino、Doris 也提升了很多。

阿裏巴巴實踐，Paimon 數據湖戰役

接下來簡單介紹一下阿裏巴巴實踐，Paimon 數據湖戰役，以及究竟哪些業務能用於數據湖。

4.1 阿裏巴巴業務套用場景

下圖是阿裏內部業務的大致套用場景：Flink 流作業有 3 萬+ Cu（不包括 Contributors、Stars 等計算）、300+ 作業、20+ 業務方，整體作業並不多，這和阿裏降本增效有關，一個作業其實可能是十張甚至幾十張表的計算，可以很好降低成本。

（1）業務

透過流式湖倉提升原有純離線數據的時效性，但整體不會帶來太大的成本增加；還有其他業務，如 CDC 入湖降低成本；經過 Z-Order 或索引構建，結合 StarRocks 這類 OLAP 引擎，能極大提升查詢效能。

（2）進展

目前還仍處於初步階段，後面最重要是繼續整合內部計算系統和許可權系統形成完整的數倉體驗。

（ 3）收益

大幅降低即時化成本，達到流批一體化開發體驗，也能解鎖開放式的計算能力，能對接所有主流的計算引擎。

4.2 統一湖儲存：打通阿裏雲所有計算引擎

在統一湖儲存上，怎麽打通阿裏雲內部主流的計算引擎：Serverless Flink、Serverless Spark、MaxCompute、Hologres、Serverless StarRocks，有以下三點。

所有計算引擎打通 Paimon 達成 State-Of-Art 的效能，使所有的計算引擎/OLAP查詢效能達到業界領先的計算效能。

結合 Flink 構建流批一體的 Streaming Lakehouse。可以在一套架構中，有 Paimon 統一湖格式的儲存，靈活按照自己的業務選擇不同的計算引擎來賦能，這也是這幾年來業界的趨勢。

目前還沒有一套計算引擎能滿足所有需求，在計算上的能力非常多。不管哪個計算引擎需要補全所有的其他的能力，都非常難。所以 Paimon 在此假設基礎上，目的是打造統一的、可貢獻的儲存：在計算引擎和儲存的互動當中，做到業界領先的水準。但是儲存又擁有開放、基於物件儲存的低成本優勢，這樣能解鎖很多業務，按照不同需求使用不同的計算引擎。

4.3 Paimon 與 Serverless Flink

最後，是 Paimon 與 Serverless Flink 在產品上的融合。

首先是後設資料管理，以前 Flink 主流是基於 connector 的方式。但 Paimon 是面向 Catalog 的方式，這需要給 Flink 產品帶來了使用上的最佳化。第二，查詢指令碼 Flink 產品+Paimon 著力提升了查詢效能，以前是幾十秒才返回，最新版本已最佳化到最小幾秒返回查詢。第三，CDC 入湖 Flink CDC 做了非常多的最佳化，在產品上有對應的方式。第四，包括作業運維，甚至除了流以外，Flink 產品都有一定的批次處理能力。所以在 Flink 產品上也支持了工作流排程，支撐簡單的數據回刷。長期來講，Serverless Flink 和 Paimon往前發展，達到流批一體的開發與不斷的構建。