資料湖是大資料近年來的網紅專案，大家熟知的開源資料湖三劍客 Apache hudi、Apache iceberg 、Databricks delta 近年來野蠻生長，目前各自背後也都有商業公司支援，投入了大量的人力物力去做研發和宣傳。然而今天我們要講的是資料湖界的後起之秀 —— flink-table-store。
熟悉 Flink 專案的同學對這個專案應該並不陌生，它在去年作為 Flink 的子專案加入了 Apache 社群，由 Flink 團隊主導研發，截止到目前 star 數 423，fork 數 171，總體來說並不算大火，也許是因為開源的時間並不長，也許是因為資料湖市場早已被三劍客佔據了大半，也許是宣傳的力度不夠，也許是 Flink 子專案限制了它作為資料湖產品的發展。然而可能也正是這些種種的原因促成了這次 flink-table-store 作為獨立專案重新加入 Apache，不再依附 Flink，這無論是對於 flink-table-store 的未來發展，還是對於資料湖領域來說都是一件好事。
從 Apache 的提案可以看出，flink-table-store 作為獨立專案後的專案名是 Paimon，玩過原神的同學應該對這個名字不陌生，它是遊戲中的 NPC，作為嚮導在整個冒險過程中陪伴著旅行者，至於 Paimon 具體的寓意可能得等官宣解釋了。
說回正題，Paimon 的定位是分散式檔案系統（HDFS、S3 等）上的資料檔案支援的湖儲存，用於使用大資料計算引擎（即 Flink、Spark、Hive、Trino 等）為流式處理和批處理構建動態表，支援高速資料攝取和實時資料查詢。與其他資料湖儲存專案不同，Paimon 旨在同時支援高吞吐量和低端到端延遲（更好的資料新鮮度），尤其適用於密集型 UPDATE 和 DELETE 工作負載。
Paimon 獨立加入Apache 後的一些規劃：
- 擴充套件Paimon的生態，提供獨立的Java API，支援 Spark、Hive、Trino、Presto、Doris等更多大資料引擎的讀寫。
- 補充關鍵能力，特別是流式讀取和密集更新/刪除，以建立統一且易於使用的流式資料倉儲（lakehouse）。
- 成長為一個更有活力和中立的開源社群。（關鍵詞“中立”，這也是促成Paimon獨立的主要原因）
Paimon 解決的痛點
隨著流處理在生產中的應用（Flink、Spark-Streaming等技術），對儲存同時支援更新、刪除和流式讀取的需求越來越大，為了支援這樣的要求我們有如下一些方案：
- 一種選擇是使用 OLAP 系統，如 ClickHouse 和 Aapache Doris，它們能夠提供高速資料攝取。但是不支援流式讀取，儲存成本比較高。
- 另一種選擇是使用現有的湖儲存，例如 Apache Hudi 和 Apache Iceberg。然而，從實時處理系統高速攝取最新（更新）資料提出了巨大的挑戰，並且會使兩個系統不堪重負。
建立 Paimon 就是為了解決現有解決方案的侷限 - 支援大資料集儲存，支援批流式讀寫。
- 支援流消費的增量快照。
- 支援最低延遲至毫秒的流式查詢。
- 支援批處理/OLAP 查詢，延遲最小到秒級。
Paimon 基本原理說明
Paimon原生採用LSM（Log-Structured Merge-tree）作為其底層資料結構，除了常見的湖儲存能力外，還為帶主鍵的資料提供了增強的效能。更重要的是，Paimon 支援批流操作（讀和寫），方便應用程式追求批流統一語義。具體來說：
- Paimon 利用 LSM 資料結構的附加寫入功能，在密集的更新/刪除工作負載上提供出色的效能。
- Paimon 利用 LSM 的有序特性支援有效的過濾器下推，可以將主鍵過濾查詢的延遲降低到毫秒級。
- Paimon 支援各種（基於行或行列）檔案格式，包括 Apache Avro、Apache ORC 和 Apache Parquet（行在寫出之前將按主鍵排序）。
- Paimon提供的表可以被各種引擎查詢，包括Apache Flink、Apache Spark、Apache Hive、Trino等。
- Paimon 的後設資料是自我管理的，儲存在分散式檔案系統上，可以同步到 Hive metastore (HMS)。
- 除了常見的批次讀寫支援外，Paimon 還支援流式讀取和更改資料饋送。
目前該提案正在郵件討論的階段，孵化器導師對該專案獨立加入 ASF 都持贊同態度，相信不久就會官宣這一訊息。
另外有導師提出，鑑於大多數參與人員都熟悉 ASF 以及專案應該如何運作，是否可以不進過孵化器而直接作為單獨的頂級專案（TLP）。比如 Apache Camel 是 Apache ActiveMQ 的一個子專案， 它沒有經過孵化器過程就成為了 TLP，因為大多數開發人員知道如何執行 ASF 專案。該方案目前還在討論當中。
隨著 Paimon 的獨立，資料湖市場的爭奪將進入白熱化階段，其實百花齊發對於使用者來說是利好的，良性競爭可以促進專案的快速迭代，但是在做選擇上還是得頭痛一會兒了，關於資料湖“四劍客”技術細節的文章後續會在這個公眾號上陸續更新，歡迎持續關注。不知道這次 Paimon 可以在資料湖領域掀起多大的浪，讓我們拭目以待！
