Apache Paimon 文件管理

管理小文件

許多用戶關注小文件問題，可能導致以下情況：

理解 Checkpoint

假設你正在使用 Flink Writer，每個 Checkpoint 會生成 1 ～ 2 個 snapshot，並且 Checkpoint 時會強制將文件生成在分佈式文件系統（DFS）上，因此 Checkpoint 間隔越小，生成的小文件就越多。

1、所以先要增加 Checkpoint 間隔時間

默認情況下，不僅 Checkpoint 會生成文件，寫入器（Writer）的內存（write-buffer-size）耗盡時也會將數據刷新到 DFS 並生成相應的文件。你可以啓用 write-buffer-spillable 在寫入器中生成溢出文件，以生成更大的文件在 DFS 上。

2、其次增加 write-buffer-size 或啓用 write-buffer-spillable

理解 Snapshot


Paimon 維護文件的多個版本，文件的合併和刪除是邏輯上的操作，並不實際刪除文件。只有在 snapshot 過期時，文件纔會真正被刪除，所以減少文件的一種方法是縮短 snapshot 過期的時間。Flink Writer 會自動處理過期的 snapshot。

理解 分區 和 Buckets

Paimon 的文件以分層方式組織。下圖展示了文件佈局。從 snapshot 文件開始，Paimon 的讀取器可以遞歸地訪問表中的所有記錄。

舉個例子：

CREATE TABLE MyTable (
    user_id BIGINT,
    item_id BIGINT,
    behavior STRING,
    dt STRING,
    hh STRING,
    PRIMARY KEY (dt, hh, user_id) NOT ENFORCED
) PARTITIONED BY (dt, hh) WITH (
    'bucket' = '10'
);

表數據會被物理分片到不同的分區，裏面有不同的 Bucket ，所以如果整體數據量太小，單個 Bucket 中至少有一個文件，建議你配置較少的 Bucket 數量，否則會出現也有很多小文件。

理解 Primary Table 的 LSM

LSM 樹將文件組織成多個 sorted run。一個 sorted run 由一個或多個數據文件組成，每個數據文件都屬於且僅屬於一個 sorted run。

默認情況下，sorted run 的數量取決於 num-sorted-run.compaction-trigger 參數，這意味着一個 Bucket 中至少有 5 個文件。如果你想減少這個數量，可以保留較少的文件，但寫入性能可能會受到影響。如果該值變得過大，在查詢表時會需要更多的內存和 CPU，這是寫入性能和查詢性能之間的權衡。

理解 Append-Only 表的文件

默認情況下 Append Only 表也會進行自動合併以減少小文件的數量。

然而，對於 Bucket 的 Append Only 表來說，它會出於順序目的而只壓縮 Bucket 內的文件，這可能會保留更多的小文件。

理解 Full Compaction

也許你認爲 Primary Key 表中的 5 個文件還可以接受，但 Append Only 表（Bucket）可能在一個單獨的 Bucket 中就會有 50 個小文件，這是很難接受的。更糟糕的是，不再活躍的分區也會保留這麼多小文件。

建議你配置全量合併（Full-Compaction），通過設置 full-compaction.delta-commits參數，在 Flink 寫入過程中定期執行全量合併，這樣可以確保在寫入結束之前對分區進行完全合併。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/cJXLDom48cgQpLf5V5Ttcw

猜你喜歡