使用限制

僅實時計算引擎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表寫入作業的瓶頸由并發限制以及文件系統或對象存儲的帶寬限制所決定。當遇見寫入作業瓶頸時，應首先查看對應文件系統寫入帶寬是否到達了瓶頸，若帶寬資源充裕，可嘗試從以下幾個方面對Append Scalable表進行優化。

• 調整Paimon Sink并發

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

• 檢查數據是否傾斜

  Paimon Append Scalable表在寫入節點與上游節點之間沒有數據重分布（Shuffle）。因此，若數據有較大傾斜，可能會導致部分節點資源利用率不高，整體寫入效率低下。此時，可以將sink.parallelism參數設為與上游節點并發不同的值。完成設置后，在實時計算開發控制臺看到上游節點與寫入節點之間出現數據重分布（不在同一個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。