重磅!flink-table-store 將作為獨立資料湖專案重新加入 Apache

老懞大資料發表於2023-03-01

資料湖是大資料近年來的網紅專案,大家熟知的開源資料湖三劍客 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 可以在資料湖領域掀起多大的浪,讓我們拭目以待!


相關文章