2024，游子未歸鄉(xiāng)。工作需要，flink?coding。覺(jué)知此事要躬行，未休，特記

Flink 社區(qū)希望能夠?qū)?Flink 的 Streaming 實(shí)時(shí)計(jì)算能力和 Lakehouse 新架構(gòu)優(yōu)勢(shì)進(jìn)一步結(jié)合，推出新一代的 Streaming Lakehouse 技術(shù)，促進(jìn)數(shù)據(jù)在數(shù)據(jù)湖上真正實(shí)時(shí)流動(dòng)起來(lái)，并為用戶(hù)提供實(shí)時(shí)離線一體化的開(kāi)發(fā)體驗(yàn)。原名 Flink Table Store （簡(jiǎn)稱(chēng) FTS ），2023年3月12日，FTS進(jìn)入 Apache 軟件基金會(huì) (ASF) 的孵化器，改名為 Apache Paimon (incubating)。

Apache Paimon是一個(gè)流數(shù)據(jù)湖平臺(tái)，具有高速數(shù)據(jù)攝取、變更日志跟蹤和高效的實(shí)時(shí)分析的能力。

Streaming 實(shí)時(shí)計(jì)算能力和 Lakehouse 新架構(gòu)優(yōu)勢(shì)結(jié)合
高速數(shù)據(jù)攝取、變更日志跟蹤和高效的實(shí)時(shí)分析的能力
統(tǒng)一存儲(chǔ)

1.1?Paimon是什么

1）讀/寫(xiě)：Paimon 支持多種讀/寫(xiě)數(shù)據(jù)和執(zhí)行 OLAP 查詢(xún)的方式。

（1）對(duì)于讀取，它支持以下方式消費(fèi)數(shù)據(jù)：

• 從歷史快照（批處理模式），
• 從最新的偏移量（在流模式下）
• 以混合方式讀取增量快照。

（2）對(duì)于寫(xiě)入，它支持來(lái)自數(shù)據(jù)庫(kù)變更日志（CDC）的流式同步或來(lái)自離線數(shù)據(jù)的批量插入/覆蓋。

2）生態(tài)系統(tǒng)

除了Apache Flink之外，Paimon還支持Apache Hive、Apache Spark、Trino等其他計(jì)算引擎的讀取。

3）內(nèi)部

在底層，Paimon 將列式文件存儲(chǔ)在文件系統(tǒng)/對(duì)象存儲(chǔ)上，并使用 LSM 樹(shù)結(jié)構(gòu)來(lái)支持大量數(shù)據(jù)更新和高性能查詢(xún)。

4）統(tǒng)一存儲(chǔ)

對(duì)于 Apache Flink 這樣的流引擎，通常有三種類(lèi)型的連接器：

• 消息隊(duì)列：例如 Apache Kafka，在源階段和中間階段都使用它，以保證延遲保持在秒級(jí)。
• OLAP系統(tǒng)：例如Clickhouse，它以流方式接收處理后的數(shù)據(jù)并為用戶(hù)的即席查詢(xún)提供服務(wù)。
• 批量存儲(chǔ)：例如Apache Hive，它支持傳統(tǒng)批處理的各種操作，包括INSERT OVERWRITE。

Paimon 提供表抽象。它的使用方式與傳統(tǒng)數(shù)據(jù)庫(kù)沒(méi)有什么區(qū)別：

• 在批處理執(zhí)行模式下，它就像一個(gè)Hive表，支持Batch SQL的各種操作。查詢(xún)它以查看最新的快照。
• 在流執(zhí)行模式下，它的作用就像一個(gè)消息隊(duì)列。查詢(xún)它的行為就像從歷史數(shù)據(jù)永不過(guò)期的消息隊(duì)列中查詢(xún)流更改日志。

1.2 核心特性

1）統(tǒng)一批處理和流處理

批量寫(xiě)入和讀取、流式更新、變更日志生成，全部支持。

2）數(shù)據(jù)湖能力

低成本、高可靠性、可擴(kuò)展的元數(shù)據(jù)。 Apache Paimon 具有作為數(shù)據(jù)湖存儲(chǔ)的所有優(yōu)勢(shì)。

3）各種合并引擎

按照您喜歡的方式更新記錄。保留最后一條記錄、進(jìn)行部分更新或?qū)⒂涗浘酆显谝黄?#xff0c;由您決定。

4）變更日志生成

Apache Paimon 可以從任何數(shù)據(jù)源生成正確且完整的變更日志，從而簡(jiǎn)化您的流分析。

5）豐富的表類(lèi)型

除了主鍵表之外，Apache Paimon還支持append-only表，提供有序的流式讀取來(lái)替代消息隊(duì)列。

6）模式演化

Apache Paimon 支持完整的模式演化。您可以重命名列并重新排序。

1.3 基本概念

1.3.1 Snapshot

快照捕獲表在某個(gè)時(shí)間點(diǎn)的狀態(tài)。用戶(hù)可以通過(guò)最新的快照來(lái)訪問(wèn)表的最新數(shù)據(jù)。通過(guò)時(shí)間旅行[訪問(wèn)不同的快照]，用戶(hù)還可以通過(guò)較早的快照訪問(wèn)表的先前狀態(tài)。

1.3.2 Partition

Paimon 采用與 Apache Hive 相同的分區(qū)概念來(lái)分離數(shù)據(jù)。

分區(qū)是一種可選方法，可根據(jù)日期、城市和部門(mén)等特定列的值將表劃分為相關(guān)部分。每個(gè)表可以有一個(gè)或多個(gè)分區(qū)鍵來(lái)標(biāo)識(shí)特定分區(qū)。

通過(guò)分區(qū)，用戶(hù)可以高效地操作表中的一片記錄。

如果定義了主鍵，則分區(qū)鍵必須是主鍵的子集。

1.3.3 Bucket

未分區(qū)表或分區(qū)表中的分區(qū)被細(xì)分為存儲(chǔ)桶，以便為可用于更有效查詢(xún)的數(shù)據(jù)提供額外的結(jié)構(gòu)。

桶的范圍由記錄中的一列或多列的哈希值確定。用戶(hù)可以通過(guò)提供bucket-key選項(xiàng)來(lái)指定分桶列。如果未指定bucket-key選項(xiàng)，則主鍵（如果已定義）或完整記錄將用作存儲(chǔ)桶鍵。

桶是讀寫(xiě)的最小存儲(chǔ)單元，因此桶的數(shù)量限制了最大處理并行度。不過(guò)這個(gè)數(shù)字不應(yīng)該太大，因?yàn)樗鼤?huì)導(dǎo)致大量小文件和低讀取性能。一般來(lái)說(shuō)，建議每個(gè)桶的數(shù)據(jù)大小為1GB左右。

1.3.4 Consistency Guarantees一致性保證

Paimon writer使用兩階段提交協(xié)議以原子方式將一批記錄提交到表中。每次提交在提交時(shí)最多生成兩個(gè)快照。

對(duì)于任意兩個(gè)同時(shí)修改表的writer，只要他們不修改同一個(gè)存儲(chǔ)桶，他們的提交都是可序列化的。如果他們修改同一個(gè)存儲(chǔ)桶，則僅保證快照隔離。也就是說(shuō)，最終表狀態(tài)可能是兩次提交的混合，但不會(huì)丟失任何更改。

1.4 文件布局

一張表的所有文件都存儲(chǔ)在一個(gè)基本目錄下。 Paimon 文件以分層方式組織。下圖說(shuō)明了文件布局。從快照文件開(kāi)始，Paimon 讀者可以遞歸地訪問(wèn)表中的所有記錄。

下面簡(jiǎn)單介紹文件布局

1.4.1 Snapshot Files

所有快照文件都存儲(chǔ)在快照目錄中。

快照文件是一個(gè) JSON 文件，包含有關(guān)此快照的信息，包括：

正在使用的Schema文件

包含此快照的所有更改的清單列表（manifest list）

1.4.2 Manifest Files

清單（manifest）-->??清單列表（manifest list） -->清單文件（manifest file）

所有清單列表（manifest list）和清單文件（manifest file）都存儲(chǔ)在清單（manifest）目錄中。

清單列表（manifest list）是清單文件名（manifest file）的列表。

清單文件（manifest file）是包含有關(guān) LSM 數(shù)據(jù)文件和更改日志文件的文件信息。例如對(duì)應(yīng)快照中創(chuàng)建了哪個(gè)LSM數(shù)據(jù)文件、刪除了哪個(gè)文件。

1.4.3 Data Files

數(shù)據(jù)文件按分區(qū)和存儲(chǔ)桶分組。每個(gè)存儲(chǔ)桶目錄都包含一個(gè) LSM 樹(shù)及其變更日志文件。目前，Paimon 支持使用 orc（默認(rèn)）、parquet 和 avro 作為數(shù)據(jù)文件格式。

1.4.4 LSM Trees

Paimon 采用 LSM 樹(shù)（日志結(jié)構(gòu)合并樹(shù)）作為文件存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)。

1.4.4.1 Sorted Runs

LSM 樹(shù)將文件組織成多個(gè)Sorted Run。Sorted Run由一個(gè)或多個(gè)數(shù)據(jù)文件組成，并且每個(gè)數(shù)據(jù)文件恰好屬于一個(gè)Sorted Run。

數(shù)據(jù)文件中的記錄按其主鍵排序。在Sorted Run中，數(shù)據(jù)文件的主鍵范圍永遠(yuǎn)不會(huì)重疊。

正如您所看到的，不同的Sorted Run可能具有重疊的主鍵范圍，甚至可能包含相同的主鍵。查詢(xún)LSM樹(shù)時(shí)，必須合并所有Sorted Run，并且必須根據(jù)用戶(hù)指定的合并引擎和每條記錄的時(shí)間戳來(lái)合并具有相同主鍵的所有記錄。

寫(xiě)入LSM樹(shù)的新記錄將首先緩存在內(nèi)存中。當(dāng)內(nèi)存緩沖區(qū)滿時(shí)，內(nèi)存中的所有記錄將被排序并刷新到磁盤(pán)。

1.4.4.2 Compaction

當(dāng)越來(lái)越多的記錄寫(xiě)入LSM樹(shù)時(shí)，Sorted Run的數(shù)量將會(huì)增加。由于查詢(xún)LSM樹(shù)需要將所有Sorted Run合并起來(lái)，太多Sorted Run將導(dǎo)致查詢(xún)性能較差，甚至內(nèi)存不足。

為了限制Sorted Run的數(shù)量，我們必須偶爾將多個(gè)Sorted Run合并為一個(gè)大的Sorted Run。這個(gè)過(guò)程稱(chēng)為Compaction。

然而，Compaction是一個(gè)資源密集型過(guò)程，會(huì)消耗一定的CPU時(shí)間和磁盤(pán)IO，因此過(guò)于頻繁的Compaction可能會(huì)導(dǎo)致寫(xiě)入速度變慢。這是查詢(xún)和寫(xiě)入性能之間的權(quán)衡。 Paimon 目前采用了類(lèi)似于 Rocksdb 通用壓縮的Compaction策略。

默認(rèn)情況下，當(dāng)Paimon將記錄追加到LSM樹(shù)時(shí)，它也會(huì)根據(jù)需要執(zhí)行Compaction。用戶(hù)還可以選擇在“專(zhuān)用Compaction作業(yè)”中獨(dú)立執(zhí)行所有Compaction。