Realtime Compute for Apache Flink：Paimon效能最佳化

使用限制

僅Realtime Compute引擎VVR 8.0.5及以上版本支援Paimon表。

主鍵表最佳化

寫入作業最佳化

Paimon寫入作業的瓶頸通常由小檔案合并引起。預設情況下，Flink每次做檢查點時，如果分桶中小檔案數量過多或使用了lookup變更資料產生機制，則需要等待當前的Paimon小檔案合并過程結束。如果等待時間過長，或部分並發的檢查點出現了長尾，會造成反壓，影響作業效率。

您可以從以下角度進行最佳化：

• 調整Paimon Sink並發

  通過SQL Hints設定sink.parallelism參數，以調整Paimon Sink的並發數。需要注意調整並發數可能會引起資源使用方面的變化。

• 調整Flink檢查點間隔

  檢查點間隔將影響Paimon的時效性。增大檢查點間隔時，需要注意業務能否接受更長的延遲。

  • 增大Flink檢查點間隔，即增加execution.checkpointing.interval作業參數的值，配置方法請參見如何配置作業運行參數？。

  • 設定作業參數execution.checkpointing.max-concurrent-checkpoints: 3，其將允許至多3個檢查點同時進行，主要用於減小部分並發檢查點長尾的影響。

  • 考慮執行批作業。

• 將小檔案合并改為完全非同步

  將小檔案合并完全非同步化之後，Flink做檢查點時無需等待小檔案合并完成。

  通過ALTER TBALE語句或SQL Hints設定以下表參數：

  'num-sorted-run.stop-trigger' = '2147483647',
  'sort-spill-threshold' = '10',
  'changelog-producer.lookup-wait' = 'false'

  參數的含義如下：

  參數	資料類型	預設值	說明
  num-sorted-run.stop-trigger	Integer	5	當一個分桶內的小檔案數量超過該參數時，將強制停止該分桶的寫入，直到小檔案合并完成。這一參數主要是防止小檔案合并流程太慢，導致的小檔案數量無限增長，影響Paimon表的批式消費和即席（OLAP）查詢的效率。小檔案數量對下遊流式消費的影響不大。 將該參數設為一個很大的值後，小檔案合并將不再強制停止分桶資料的寫入，而是完全非同步進行。如果您需要監控分桶中小檔案的數量，可以查詢Files系統資料表。
  sort-spill-threshold	Integer	無	預設情況下，小檔案合并會在記憶體中進行歸併排序，每個小檔案的reader都需要佔用一定的堆記憶體。如果小檔案數量過多，可能會造成堆記憶體不足。 設定該參數後，若小檔案數量超過該參數，小檔案合并流程將由歸併排序改為外部排序，減小堆記憶體的消耗。
  changelog-producer.lookup-wait	Boolean	true	Flink在執行檢查點操作時是否等待lookup變更資料產生機制觸發的小檔案合并。參數取值如下： true：等待。您可以通過Checkpoint建立的速度覺察到作業的延遲情況，從而決定是增加資源還是採用非同步化處理方式。 false：不等待，允許已完成小檔案合并的並發繼續處理後續資料。提高了CPU的利用率，並對變更資料的產出無太大影響。但開啟非同步後，Checkpoint建立速度較快，因此無法準確判斷當前資料處理的延遲情況。

• 變更檔格式

  如果您不需要對Paimon表進行即席（OLAP）查詢，只需進行批式或流式消費，可以選擇配置以下表參數，將資料檔案格式改為avro，並關閉採集統計資料，以進一步提高寫入作業的效率。

  'file.format' = 'avro',
  'metadata.stats-mode' = 'none'

  說明

  該配置只能在建立表時指定，無法更改已經建立表的資料檔案格式。

消費作業最佳化

• 調整Paimon Source並發

  通過SQL Hints設定scan.parallelism參數調整Paimon Source的並發數。

• 從Read Optimized系統資料表消費資料

  在批作業消費、流作業消費的全量階段，以及即席（OLAP）查詢中，Paimon源表的瓶頸主要由小檔案引起。Paimon源表需要將小檔案中的資料在記憶體中歸併才能產出結果，因此小檔案數量過多會增加歸併過程的代價。然而寫入作業過於頻繁的小檔案合并也會降低寫入作業的效率，因此您需要在寫入效率與消費效率之間做出平衡。

  您可以在對應的寫入作業中調整將小檔案合并改為完全非同步中提及的參數。如果您不需要消費最新的資料，也可以選擇消費Read-optimized系統資料表以提高消費效率。

Append Scalable表常用最佳化

寫入作業最佳化

通常情況下，Paimon Append Scalable表寫入作業的瓶頸由並發限制以及檔案系統或Object Storage Service的頻寬節流設定所決定。當遇見寫入作業瓶頸時，應首先查看對應檔案系統寫入頻寬是否到達了瓶頸，若頻寬資源充裕，可嘗試從以下幾個方面對Append Scalable表進行最佳化。

• 調整Paimon Sink並發

  通過SQL Hints設定sink.parallelism參數，以調整Paimon Sink的並發數。需要注意調整並發數可能會引起資源使用方面的變化。

• 檢查資料是否傾斜

  Paimon Append Scalable表在寫入節點與上遊節點之間沒有資料重分布（Shuffle）。因此，若資料有較大傾斜，可能會導致部分節點資源使用率不高，整體寫入效率低下。此時，可以將sink.parallelism參數設為與上遊節點並發不同的值。完成設定後，在Realtime Compute開發控制台看到上遊節點與寫入節點之間出現資料重分布（不在同一個Subtask中）即可。

消費作業最佳化

• 調整Paimon Source並發

  通過SQL Hints設定scan.parallelism參數調整Paimon Source的並發數。

• 使用zorder、hilbert或者order對資料排序

  資料的順序對批作業處理或即席（OLAP）查詢的效率有較大影響。您可以對Append Scalable表中的資料進行排序，以提高查詢效率。資料排序需要進行相關配置，詳情請參見Paimon資料管理配置。作業的部署模式需要使用批模式，並在Entry Point Main Arguments中配置相關參數。

  例如，當需要對分區中的資料按date和type欄位排序時，Entry Point Main Arguments配置項的填寫樣本如下。

  compact
  --warehouse 'oss://your-bucket/data-warehouse'
  --database 'your_database'
  --table 'your_table'
  --order_strategy 'zorder'
  --order_by 'date,type'
  --partition 'dt=20240311,hh=08;dt=20240312,hh=09'
  --catalog_conf 'fs.oss.endpoint=oss-cn-hangzhou-internal.aliyuncs.com'
  --catalog_conf 'fs.oss.endpoint=oss-cn-beijing-internal.aliyuncs.com'
  --table_conf 'write-buffer-size=256 MB'
  --table_conf 'your_table.logRetentionDuration=7 days'

  參數說明如下。

  配置項	說明
  warehouse	需要排序的Paimon表所在的catalog的warehouse目錄。
  database	需要排序的Paimon表所在的資料庫名稱。
  table	需要排序的Paimon表名。
  order_strategy	排序的方式，有以下三種排序方式： zorder：推薦在過濾欄位小於5個且包含範圍查詢時使用。 hilbert：推薦在過濾欄位至少5個且包含範圍查詢時使用。 order：推薦在過濾條件均為等值條件時使用。
  order_by	排序欄位，請用英文逗號（,）分隔。
  partition	需要排序的分區，不同分區之間請用英文分號（;）分隔。非分區表可以刪除該參數。
  catalog_conf	需要排序的Paimon表所在的Catalog的WITH參數，每一項WITH參數需要獨佔一行catalog_conf。
  table_conf	臨時修改需要排序的Paimon表參數，與SQL Hint功能相同，每一項參數需要獨佔一行table_conf。