弊端：數據重復 -> 優勢：Paimon 主鍵表原生去重
原方案弊端 (Kafka)
- 問題: 消息隊列（Kafka）是僅支持追加（Append-Only）的日志流。當 Flink 作業發生故障恢復（Failover）或業務邏輯迭代重跑數據時，同樣的數據會被再次寫入消息隊列，形成重復數據。
- 影響: 下游應用（如DWS層、ADS層或直接對接的BI報表）必須自己實現復雜的去重邏輯，這不僅消耗大量計算資源（“資源消耗至少增加一倍”），而且可能導致作業不穩定。
Paimon 的優勢
- 解決方案: Paimon 提供了主鍵表（Primary Key Table）。這種表類型基于 LSM 樹（Log-structured merge-tree）結構，原生支持?
UPSERT?(更新或插入) 和?DELETE?操作。 - 工作原理: 當 Flink 作業將數據寫入 Paimon 的主鍵表時：
- 如果數據的主鍵已存在，Paimon 會更新該行記錄。
- 如果主鍵不存在，Paimon 會插入新行。
- 因此，即使上游作業重發了數據，Paimon 也能通過主鍵自動去重，確保表里存儲的始終是每個主鍵對應的最新狀態。下游消費者不再需要關心去重問題。
正如文檔中所描述的，主鍵表是 Paimon 的核心功能之一，用于支持大規模的實時更新。
# OverviewIf you define a table with primary key, you can insert, update or delete records in the table.Primary keys consist of a set of columns that contain unique values for each record. Paimon enforces data ordering by
sorting the primary key within each bucket, allowing users to achieve high performance by applying filtering conditions
on the primary key. See [CREATE TABLE]({{< ref "flink/sql-ddl#create-table" >}}).
在 Flink SQL 中創建這樣的主鍵表非常簡單：
// ... existing code ...
CREATE TABLE my_table (user_id BIGINT,item_id BIGINT,behavior STRING,dt STRING,hh STRING,PRIMARY KEY (dt, hh, user_id) NOT ENFORCED
);
// ... existing code ...
弊端：DWS 層缺失 -> 優勢：Paimon 支持聚合與更新，構建 DWS 層
原方案弊端 (Kafka)
- 問題: 由于 Kafka 不支持?
UPSERT，無法對聚合結果進行原地更新。例如，一個按用戶ID統計5分鐘窗口消費額的 DWS 層，10:00-10:05?的聚合結果和?10:05-10:10?的聚合結果會作為兩條獨立的消息存在于 Kafka 中。 - 影響: 無法構建一個持續更新狀態的 DWS 層。下游要么消費這個中間結果流自己再做一次聚合，代價極高；要么跳過 DWS 層，直接將 DWD 數據寫入在線存儲（如 ClickHouse），把聚合壓力和復雜性推給了下游系統。
Paimon 的優勢
- 解決方案: Paimon 的主鍵表能力完美解決了這個問題。我們可以輕松地在 Paimon 中構建 DWS 層。
- 工作原理: Flink 聚合任務（例如，每5分鐘統計一次用戶消費總額）可以將聚合結果?
UPSERT?到 Paimon 的 DWS 表中。這張表以用戶ID為主鍵。每次新的聚合結果到來時，它會直接更新對應用戶的消費總額，而不是插入一條新紀錄。 - Changelog 支持: 更重要的是，Paimon 可以為下游生成?
changelog（變更日志）。下游系統（如 ClickHouse）可以直接消費這個?changelog?流，輕松地同步最新的聚合結果，而無需處理復雜的合并邏輯。
Paimon 的?merge-engine?機制甚至允許自定義更新邏輯，例如?partial-update（部分更新）或?aggregation（聚合），這為構建 DWS 層提供了極大的靈活性。
// ... existing code ...
- Realtime updates:- Primary key table supports writing of large-scale updates, has very high update performance, typically through Flink Streaming.- Support defining Merge Engines, update records however you like. Deduplicate to keep last row, or partial-update, or aggregate records, or first-row, you decide.
// ... existing code ...
弊端：No Schema -> 優勢：Paimon 提供統一的、可查詢的 Schema
原方案弊端 (Kafka)
- 問題: 存儲在Kafka 中的數據（通常是 JSON 字符串）是半結構化的。雖然 Flink 作業在流處理時會解析它，但數據本身在消息隊列中沒有一個強定義的、可供外部查詢的 Schema。
- 影響: 其他數據消費者（如算法、BI 團隊）無法直接查詢 DWD 層數據。他們需要自己寫程序消費 Kafka，然后重復解析和計算，造成了巨大的資源浪費和協作成本。
Paimon 的優勢
- 解決方案: Paimon 是一個湖倉格式，它將數據以結構化的、帶 Schema 的表形式存儲。
- 工作原理: 數據一旦寫入 Paimon 表，就擁有了明確的表結構（列名、數據類型等）。這個 Schema 信息會和數據一起被管理。
- 生態兼容: Paimon 提供了強大的生態兼容性，支持 Flink, Spark, Hive, Trino, Doris 等多種查詢引擎。這意味著 BI、算法等團隊可以直接使用他們熟悉的 SQL 工具，像查詢普通數據庫一樣查詢 Paimon 中的 DWD 和 DWS 表，極大地提升了數據利用效率。
Paimon 的兼容性矩陣展示了其強大的生態整合能力：
// ... existing code ...
| Engine | Version | Batch Read | Batch Write | Create Table | Alter Table | Streaming Write | Streaming Read | Batch Overwrite | DELETE & UPDATE | MERGE INTO | Time Travel |
| :-------------------------------------------------------------------------------: | :-------------: | :-----------: | :-----------: | :-------------: | :-------------: | :----------------: | :----------------: | :---------------: | :---------------: | :----------: | :-----------: |
| Flink | 1.15 - 1.20 | ? | ? | ? | ?(1.17+) | ? | ? | ? | ?(1.17+) | ? | ? |
| Spark | 3.2 - 3.5 | ? | ? | ? | ? | ?(3.3+) | ?(3.3+) | ? | ? | ? | ?(3.3+) |
| Hive | 2.1 - 3.1 | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Trino | 420 - 440 | ? | ?(427+) | ?(427+) | ?(427+) | ? | ? | ? | ? | ? | ? |
// ... existing code ...
弊端：資源與效率 -> 優勢：Paimon 統一流批，簡化架構
原方案弊端 (Lambda 架構)
- 問題: 為了保證數據的最終準確性（例如，通過離線反作弊修正數據），需要維護實時（Flink on Kafka）和離線（ETL on MaxCompute）兩套獨立的數據鏈路和代碼。
- 影響: 開發和運維成本翻倍，架構復雜，數據同步和一致性保障困難。
Paimon 的優勢
- 解決方案: Paimon 作為統一存儲層，天然支持流式讀寫和批式讀寫，是構建流批一體（Unified Batch and Streaming）架構的理想選擇。
- 工作原理:
- 流式寫入: Flink 實時作業持續將數據寫入 Paimon。
- 批式讀/寫: 離線作業（如 Spark 或 Flink Batch）可以讀取 Paimon 表的最新快照進行批量處理（如反作弊計算），并將修正后的數據寫回到同一張 Paimon 表中。
- 統一視圖: 無論是實時查詢還是離線查詢，都訪問的是同一份存儲，同一張表。這徹底消除了兩套系統、兩份數據的問題。
在ODS層完成數據解析后，可以將數據反向寫入到Paimon中，這正是 Paimon 流批一體能力的完美體現。
Paimon 的架構設計就是為了解決這個問題，提供一個統一的存儲底座。
// ... existing code ...
Paimon provides table abstraction. It is used in a way that
does not differ from the traditional database:
- In `batch` execution mode, it acts like a Hive table andsupports various operations of Batch SQL. Query it to see thelatest snapshot.
- In `streaming` execution mode, it acts like a message queue.Query it acts like querying a stream changelog from a message queuewhere historical data never expires.
// ... existing code ...
總結
| 痛點 | Kafka 方案 | Paimon 解決方案 |
|---|---|---|
| 數據重復 | Append-only，導致Failover后數據重復 | 主鍵表，通過 UPSERT 自動去重 |
| DWS層構建 | 無 UPSERT，無法原地更新聚合結果 | 主鍵表，支持聚合結果的持續更新，可構建DWS層 |
| 數據共享 | No Schema，下游需重復解析 | 統一Schema，多引擎可直接用SQL查詢，提升協作效率 |
| 架構冗余 | Lambda架構，流批兩套代碼和存儲 | 流批一體，統一存儲，簡化架構，降低開發運維成本 |
常見優化策略
優化策略主要圍繞性能、存儲和穩定性三個方面展開，這是構建和維護高性能湖倉系統的核心。
一、 性能優化
性能優化的核心目標是提升數據寫入和處理的吞杜量，同時降低延遲。
1. 啟用異步 Compaction
分析:
- Paimon 基于 LSM 樹結構，寫入時會產生多個有序的小文件（Sorted Runs）。查詢時需要合并這些文件，文件過多會嚴重影響查詢性能。
- Compaction?就是將這些小文件合并成大文件的過程。默認情況下，Compaction 可能和數據寫入操作在同一個 Flink Task 中同步或半同步執行，這會占用寫入鏈路的資源，尤其是在寫入高峰期，可能導致反壓和延遲增加。
- 異步 Compaction?(
Asynchronous Compaction) 將合并操作與寫入操作解耦。寫入操作可以快速完成，將合并任務交給獨立的機制或在系統負載較低時執行。這極大地提升了寫入的吞吐量和穩定性，正如您提到的“節點切換的平均耗時超過 50 秒，而開啟后則縮短至 20 秒”。
實現與擴展:
- 完全異步化: 通過調整特定參數，可以讓 Compaction 完全不阻塞寫入，最大化寫入吞吐量。這適用于對寫入性能要求極高，但對數據查詢的即時性要求稍低的場景。
// ... existing code ... num-sorted-run.stop-trigger = 2147483647 sort-spill-threshold = 10 lookup-wait = false // ... existing code ... - 專用 Compaction 作業: 這是更徹底的解耦方式。可以將主寫入作業的 Compaction 完全關閉 (
'write-only' = 'true')，然后啟動一個獨立的、專用的 Flink 作業來負責 Compaction。這樣可以為寫入和 Compaction 分配獨立的資源，互不干擾，實現更精細的資源管理和調優。
然后通過 Flink Action 啟動專用作業：// ... existing code ...public static final ConfigOption<Boolean> WRITE_ONLY =key("write-only").booleanType().defaultValue(false).withFallbackKeys("write.compaction-skip").withDescription("If set to true, compactions and snapshot expiration will be skipped. "+ "This option is used along with dedicated compact jobs."); // ... existing code ...// ... existing code ... <FLINK_HOME>/bin/flink run \/path/to/paimon-flink-action-{{< version >}}.jar \compact \ // ... existing code ...
- 完全異步化: 通過調整特定參數，可以讓 Compaction 完全不阻塞寫入，最大化寫入吞吐量。這適用于對寫入性能要求極高，但對數據查詢的即時性要求稍低的場景。
2. 調整 Checkpoint Interval
分析:
- 在 Flink 流式寫入 Paimon 的場景中，Checkpoint 是觸發數據從內存刷寫到文件系統并生成 Paimon Snapshot 的關鍵。
- 過于頻繁的 Checkpoint?(短間隔) 會導致生成大量的小文件，增加文件系統壓力和后續 Compaction 的負擔。同時，頻繁的 Barrier 對齊和狀態快照也會消耗大量網絡和 CPU 資源，在高吞吐場景下極易引起反壓。
- 增大 Checkpoint Interval?可以讓數據在內存的?
write-buffer?中累積更多，單次刷寫生成的文件更大，從而減少小文件數量和 Checkpoint 開銷。
實現與擴展:
- 除了增大?
execution.checkpointing.interval，還可以調整?execution.checkpointing.max-concurrent-checkpoints?來允許更多的 Checkpoint 并行，提高容錯效率。 - Buffer 優化: 配合增大 Checkpoint 間隔，應適當增大 Paimon 的寫緩沖?
write-buffer-size，并可以開啟?write-buffer-spillable，當內存 Buffer 寫滿時，會先溢寫到本地磁盤，而不是直接刷到遠程存儲，這樣可以平滑 Checkpoint 峰值壓力，生成更大的最終文件。
// ... existing code ... 1. Flink Configuration (`'flink-conf.yaml'/'config.yaml'` or `SET` in SQL): Increase the checkpoint interval(`'execution.checkpointing.interval'`), increase max concurrent checkpoints to 3(`'execution.checkpointing.max-concurrent-checkpoints'`), or just use batch mode. 2. Increase `write-buffer-size`. 3. Enable `write-buffer-spillable`. // ... existing code ...- 除了增大?
3. 調整 Writer 節點資源與并行度
分析:
- Writer 節點的并行度直接決定了數據寫入的能力。這個并行度通常應該與 Paimon 表的?
bucket?數量相匹配或成倍數關系，以確保數據均勻分布到各個 bucket，避免數據傾斜。 - 在數據回刷或追趕歷史數據時，上游數據源的讀取速度會很快，此時必須相應地調大 Writer 的并行度來匹配處理能力。
- Writer 節點的內存 (
write-buffer-size) 也至關重要，它直接影響單次刷盤的文件大小和 Compaction 的效率。
- Writer 節點的并行度直接決定了數據寫入的能力。這個并行度通常應該與 Paimon 表的?
實現與擴展:
- 動態調整: 雖然分區和 Bucket 數不建議頻繁調整，但 Flink 作業的并行度是可以在停機重啟時調整的。在數據回刷場景，可以臨時調高并行度，完成后再恢復正常值。
- 使用 Flink 托管內存: 為了避免手動管理內存導致 OOM，可以啟用?
'sink.use-managed-memory-allocator' = 'true'。這樣 Paimon Writer 會使用 Flink 的托管內存，由 Flink TaskManager 統一管理和分配，可以提高資源利用率和穩定性。
// ... existing code ... INSERT INTO paimon_table /*+ OPTIONS('sink.use-managed-memory-allocator'='true', 'sink.managed.writer-buffer-memory'='256M') */ SELECT * FROM ....;
4. 合理設置分區與 Bucket
分析:
- 分區 (Partition)?是數據物理隔離的第一層，通常基于低基數的列（如日期?
dt），用于數據管理和查詢過濾。好的分區設計可以極大地提升查詢性能，因為查詢引擎可以直接跳過不相關的分區目錄。 - 桶 (Bucket)?是在分區內對數據進行哈希分桶，是數據讀寫并行的基本單位。
bucket?的數量決定了寫入的最大并行度和數據在分區內的分布。 - Rescale 的代價: 修改分區鍵或?
bucket?數需要?ALTER TABLE?后通過?INSERT OVERWRITE?重寫數據，這是一個成本很高的操作。因此，在表設計之初就必須對未來的數據量和并發量有充分預估。
- 分區 (Partition)?是數據物理隔離的第一層，通常基于低基數的列（如日期?
實現與擴展:
- 分區策略: 選擇更新頻率低、且常作為查詢條件的列做分區鍵。例如，按天分區?
dt?是最常見的策略。 - Bucket 數估算: Bucket 數應根據分區內的數據量峰值來設定。一個經驗法則是，保證每個 Bucket 內單個文件的大小在合理范圍（例如 128MB ~ 1GB）。您的例子中“每個分區的bucket num為512”就是一個很好的實踐，它為每小時高達 700GB 的數據量提供了足夠的寫入并行度和數據分布。
- 分區策略: 選擇更新頻率低、且常作為查詢條件的列做分區鍵。例如，按天分區?
二、 存儲優化
存儲優化的核心是控制文件數量，回收無效數據，降低存儲成本。
1. 文件生命周期管理 (TTL)
分析:
- Paimon 的每一次提交都會生成一個新的快照 (Snapshot)。為了支持時間旅行 (Time Travel)，舊的快照和對應的數據文件會保留一段時間。
snapshot.time-retained?和?snapshot.num-retained.min?控制了快照的保留策略。過長的保留時間會導致大量元數據和數據文件堆積。changelog-producer?產生的 Changelog 文件也有獨立的生命周期管理。
實現與擴展:
- 需要根據業務對數據回溯的需求來設定合理的 TTL。例如，如果業務只需要回溯 3 天的數據，那么?
snapshot.time-retained?就不應設置得過長。 - 定期檢查和調整 TTL 策略，以平衡數據可恢復性和存儲成本。
- 需要根據業務對數據回溯的需求來設定合理的 TTL。例如，如果業務只需要回溯 3 天的數據，那么?
2. 小文件合并
分析:
- 流式寫入不可避免地會產生小文件。除了前面提到的異步 Compaction 和專用 Compaction 作業，Paimon 還提供了其他機制。
precommit-compact: 在文件提交到快照之前進行一次合并，可以有效減少最終生成的 changelog 文件數量。full-compaction: 全量合并，可以將一個分區/桶內的所有文件合并成一個或少數幾個文件，對查詢性能提升最大。可以通過?'full-compaction.delta-commits'?定期觸發。
實現與擴展:
- Sort Compact: 在執行 Compaction 時，可以指定按某些列 (
Z-Order?或普通排序) 對數據進行排序。這可以極大地優化基于這些列的范圍查詢或點查性能，因為數據在物理上是連續存儲的，可以最大化數據跳過的效果。// ... existing code ... CALL sys.compact(`table` => 'database_name.table_name', partitions => 'partition_name', order_strategy => 'z-order',order_by => 'col1,col2' ); // ... existing code ... - 外部治理服務: 對于大型湖倉平臺，可以引入如?Apache Amoro?這樣的外部治理服務，它能提供更智能、自動化的表維護（Self-Optimizing），包括小文件合并、數據過期等。
- Sort Compact: 在執行 Compaction 時，可以指定按某些列 (
3. 清理廢棄/孤立文件
- 分析:
- 作業異常終止或舊版本 Paimon 的 Bug 可能會導致產生一些不被任何快照引用的孤立文件。這些文件占用了存儲空間且不會被自動清理。
- 實現與擴展:
- Paimon 提供了?
expire_snapshots?和?drop_partition?等 Action，可以用來清理快照和分區。 - 社區也提供了相應的工具或討論來識別和清理孤立文件。編寫定時腳本，定期執行 Paimon 提供的清理命令，是一種有效的運維實踐。
- Paimon 提供了?
三、 穩定性優化
穩定性優化的核心是保障作業在各種異常情況下（尤其是高負載時）的健壯性和可恢復性。
1. 啟用 Consumer
分析:
- 當 Flink 作業從 Paimon 消費數據時，它會從某個快照開始讀取。如果這個快照因為 TTL 過期而被刪除了，作業就無法從該點恢復。
- Consumer 機制允許為某個消費作業（由?
consumer-id?標識）“鎖定”一個快照。這個被鎖定的快照及其之后的所有快照都不會被 TTL 機制自動刪除，直到 Consumer 前進到新的快照。 - 這極大地增強了下游消費作業的可恢復性，但代價是可能會保留更多的快照和數據文件，增加了存儲成本。
實現與擴展:
- 這是一個典型的恢復能力與存儲成本之間的權衡。對于關鍵的下游應用，啟用 Consumer 是必要的。對于非核心應用，可以不啟用，或定期手動重置消費位點。
2. 調整 TM (Task Manager) 和 Committer 資源
分析:
- TM 資源: Paimon Writer 的內存需求與數據記錄大小、更新頻率、Bucket 數量等密切相關。內存不足是導致 OOM 和作業不穩定的主要原因。
- Committer 節點: 這是 Flink 寫入 Paimon 的最后一步，負責將所有 Task 生成的?
manifest?文件合并，并生成最終的?snapshot?文件。當一次 Checkpoint 寫入的分區和文件非常多時，Committer 會成為瓶頸，需要大量的內存來持有這些元數據信息，也需要足夠的 CPU 來完成合并。
實現與擴展:
- 精細化資源管理: Flink 1.18 之后默認開啟了細粒度資源管理。可以利用這個特性為 Paimon 的 Committer 算子單獨配置更高的內存和 CPU，而無需增加整個 TaskManager 的資源，從而實現更高效的資源利用。
// ... existing code ... You can use fine-grained-resource-management of Flink to increase committer heap memory only: 1. Configure Flink Configuration `cluster.fine-grained-resource-management.enabled: true`. (This is default after Flink 1.18) 2. Configure Paimon Table Options: `sink.committer-memory`, for example 300 MB, depends on your `TaskManager`.(`sink.committer-cpu` is also supported) // ... existing code ... - 經驗公式與監控: 結合 Paimon 社區提供的經驗公式和實際的監控數據（如內存使用率、GC 時間、反壓情況），持續迭代和優化資源配置。
- 精細化資源管理: Flink 1.18 之后默認開啟了細粒度資源管理。可以利用這個特性為 Paimon 的 Committer 算子單獨配置更高的內存和 CPU，而無需增加整個 TaskManager 的資源，從而實現更高效的資源利用。
總結
結合 Paimon 的文檔和特性，我們可以看到這些策略背后都有其深刻的技術原理支撐。核心思想可以歸納為：
- 解耦與異步: 將耗時的 Compaction 操作與主寫入鏈路解耦，是提升寫入性能和穩定性的關鍵。
- 批處理思想: 在流處理中引入批處理的思想，通過增大 Checkpoint 間隔和 Buffer，將多次小操作合并為一次大操作，以攤銷固定開銷。
- 預估與規劃: 在表設計階段充分預估未來數據量，合理規劃分區和 Bucket，避免后期高昂的調整成本。
- 權衡與取舍: 在性能、成本、穩定性、數據時效性之間做出權衡。例如，Consumer 提升了恢復能力但增加了存儲成本；高壓縮率降低了存儲但增加了 CPU 開銷。
- 精細化運維: 利用專用作業、細粒度資源管理等高級特性，對不同組件進行針對性優化，實現對整個系統的精細化控制。
這些策略共同構成了一套行之有效的 Paimon 湖倉優化方法論。
補充Paimon快照存儲占用
快照（Snapshot）的本質 是一個元數據文件。
Paimon 的數據組織是一個清晰的層級結構，正如文檔中圖示的那樣：?Snapshot?->?Manifest List?->?Manifest?->?Data File
- Snapshot 文件: 是表的某個時間點版本的入口。它本身很小，是一個 JSON 文件，記錄了這個版本包含哪些?
Manifest List?文件，以及其他元數據。您正在查看的?Snapshot.java?文件就定義了它的結構。 - Manifest List / Manifest 文件: 也是元數據文件，它們像目錄一樣，逐層記錄了哪些數據文件（Data File）屬于這個快照版本，以及這些數據文件的狀態（是新增的還是被刪除的）。
- Data File: 這才是真正存儲著表數據的物理文件（例如 Parquet 文件）。
所以，一個快照通過層層指向，最終“引用”了一批數據文件。
邏輯刪除 vs 物理刪除
當對表進行更新、刪除或執行 Compaction（合并）操作時，Paimon 并不會立即去物理刪除舊的數據文件。它會執行一個邏輯刪除：
- 生成新的數據文件。
- 創建一個新的 Snapshot。
- 在這個新 Snapshot 的 Manifest 文件中，將舊的數據文件標記為?
DELETE，將新的數據文件標記為?ADD。
此時，舊的 Snapshot 依然存在，并且它仍然指向那些被“邏輯刪除”的舊數據文件。這就是 Paimon 實現時間旅行（Time Travel）?的基礎——只要舊快照還在，就可以隨時回到過去的數據版本。
文檔?docs/content/learn-paimon/understand-files.md?中對此有清晰的描述：
Paimon maintains multiple versions of files, compaction and deletion of files are logical and do not actually delete files. Files are only really deleted when Snapshot is expired.
簡單來說：Compaction 等操作只做標記，不做真刪除。真正的刪除由快照過期來觸發。
禁止刪除有快照指向的文件
只要有一個活躍的、未過期的快照還在引用某個數據文件，這個數據文件就是安全的，絕對不會被刪除。物理刪除操作只會發生在那些“無主”的文件上——即所有引用它的快照都已經過期并被清除了。
這個機制確保了數據安全性和時間旅行能力，同時通過 TTL 自動回收不再需要的歷史數據，從而控制存儲成本。
這個過程的實現主要在?SnapshotDeletion.java?這個類中，它負責具體的清理邏輯。
// ... existing code ...
public class SnapshotDeletion extends FileDeletionBase<Snapshot> {// ... existing code ...@Overridepublic void cleanUnusedDataFiles(Snapshot snapshot, Predicate<ExpireFileEntry> skipper) {if (changelogDecoupled && !produceChangelog) {// Skip clean the 'APPEND' data files.If we do not have the file source information// eg: the old version table file, we just skip clean this here, let it done by// ExpireChangelogImplPredicate<ExpireFileEntry> enriched =manifestEntry ->skipper.test(manifestEntry)|| (manifestEntry.fileSource().orElse(FileSource.APPEND)== FileSource.APPEND);cleanUnusedDataFiles(snapshot.deltaManifestList(), enriched);} else {cleanUnusedDataFiles(snapshot.deltaManifestList(), skipper);}cleanUnusedDataFiles(snapshot.baseManifestList(), skipper);}
// ... existing code ...
這個類中的方法會遍歷過期快照的?deltaManifestList?和?baseManifestList，收集文件列表，然后執行清理。
快照 TTL 如何觸發物理刪除
快照 TTL（Time-To-Live，生命周期）是如何處理多版本數據刪除的？
- 定義過期策略: 可以配置快照的保留策略，比如?
snapshot.time-retained?(保留時長) 和?snapshot.num-retained.min?(最小保留數量)。 - 識別過期快照: 當一個快照的存活時間超過了您設定的 TTL，它就會被 Paimon 的過期機制（Expire）識別為“已過期”。
- 清理過程:
- 過期程序（
ExpireSnapshots）會啟動，它首先會刪除這些過期的?snapshot?JSON 文件本身。 - 接著，它會讀取這些過期快照所引用的 Manifest 文件，列出所有被這些過期快照“邏輯刪除”的數據文件。
- 最關鍵的一步：程序會檢查這個列表中的每一個數據文件，確認它是否還被任何一個“未過期”的（即活躍的）快照所引用。
- 只有當一個數據文件不再被任何活躍快照引用時，它才會被物理刪除。
- 過期程序（
