全部產品
Search
文件中心

Realtime Compute for Apache Flink:配置作業資源

更新時間:Jul 15, 2026

您可以在作業啟動前配置作業資源或者作業上線後修改作業資源,支援基礎模式(粗粒度)和專家模式(細粒度)兩種資源模式。本文為您介紹如何配置作業資源,以及兩種資源模式下的參數資訊。

注意事項

資源配置後,需重啟作業才會生效。

操作步驟

  1. 進入資源配置入口。

    1. 登入Realtime Compute控制台

    2. 單擊目標工作空間操作列下的控制台

    3. 營運中心 > 作業營運頁面,單擊目標作業名稱。

    4. 部署詳情頁簽,單擊資源配置地區右側的編輯

  2. 修改作業資源資訊。

    支援基礎模式(粗粒度)和專家模式(細粒度)兩種資源配置模式。

    資源模式

    說明

    配置參數說明

    基礎模式

    基礎模式是一種靜態資源分配方式,您只需要給定每個TM啟動所需要的總資源(CPU和JVM總記憶體),系統會根據每個TaskManager Slot數(即flink conf taskmanager.numberOfTaskSlots)均勻分配所有資源。對於大多數簡單作業,粗粒度即可滿足要求。

    基礎模式(粗粒度)

    專家模式

    專家模式是一種動態資源分派方式,您可以配置每個Slot共用組(Slot Sharing Group,SSG)所需要的資源,Flink會計算出每個Slot需要的資源規格大小,動態地從可用資源集區去申請完全符合的TM和Slot。對於複雜作業,粗粒度可能導致資源使用率低,因此需要細粒度資源對每個運算元進行精細資源控制,從而提高資源使用率,滿足作業吞吐的要求。

    說明

    僅SQL作業支援配置專家模式。

    專家模式(細粒度)

    關於TM、JM、Task或Slot等概念,詳情請參見Apache Flink Architecture

  3. 單擊儲存

  4. 重啟作業。

    作業資源配置後,需重啟作業才會生效。

基礎模式(粗粒度)

配置項

說明

並發度

作業全域並發數。

JobManager CPU

根據Flink最佳實務,單個JM記憶體資源需要至少配置為0.5 Core和2 GiB,才能保證作業穩定運行。建議您配置為1 Core和4 GiB。最大值為16 Core。

JobManager Memory

單位為GiB,最小值為2 GiB,最大值為64 GiB。若 JM 記憶體水位長期處於 80% 以上,存在 OOM 風險,建議增加記憶體。在同步大量資料至 Paimon 等情境下,若出現 JM Direct Buffer Memory OOM,建議將jobmanager.memory.off-heap.size從預設的 128 MB 調整至 512 MB 或更大,可在運行參數配置 > 其他配置中設定。

TaskManager CPU

根據Flink最佳實務,單個TM記憶體資源需要至少配置為0.5 Core和2 GiB,才能保證作業穩定運行。建議您配置為1 Core和4 GiB。最大值為16 Core。

TaskManager Memory

單位為GiB,最小值為2 GiB,最大值為64 GiB。

每個TaskManager Slot數

請填寫TM的Slot數。

說明

在基礎模式下,您配置的 TaskManager Memory 是 TM 進程總記憶體(Total Process Memory),其中 JVM Overhead 記憶體由系統按預設比例自動分配(參數taskmanager.memory.jvm-overhead.fraction,預設值為0.1,即占 TM 總記憶體的 10%)。需注意,作業系統統計的 RSS(Resident Set Size)不包含 Page Cache,建議在 TM 總記憶體基礎上,至少預留 400 MB 供作業系統 Page Cache 使用,以避免因記憶體爭搶觸發 OOM。如需調整 JVM Overhead 比例,可在運行參數配置 > 其他配置中設定taskmanager.memory.jvm-overhead.fraction參數。

您可以根據以下公式進行推算:

  • 作業所配置的CU數 = MAX(JM和TM的CPU總和, JM和TM的記憶體總和/4)

  • 實際TM數 = 並發度 / 每個TaskManager Slot數

  • 實際每個TM上可分配的slot數 = 並發數 / 實際TM數。

說明
  • 計算比值需分別向上取整。

  • 資源配置預設情況下無法設定超過最大值。如果您需要設定大於預設TM記憶體和CPU的最大限制配置,請您提交工單

  • 您也可以在作業部署詳情頁簽運行參數配置地區的其他配置中設定numberOfTaskSlots參數,和介面配置每個TaskManager Slot數作用相同,但優先順序更高。

例如,當並發度設定為12,每個TM Slot數設定為4。

此樣本中,Job Manager CPU為2 Core,Job Manager Memory為4 GiB,Task Manager CPU為2 Core,Task Manager Memory為4 GiB。

在Flink開發控制台,您會看到實際的TaskManager數為3,每個TaskManager Slot數為4。

實際的TM數和每個TM的Slot數的推算過程如下:

  1. 實際TM數 = [設定的並發度/設定的每個TaskManager Slot數] = [12/4] = 3。

  2. 實際TM的Slot數=[並發數/實際TM數] = [12/3]= 4。

專家模式(細粒度)

說明
  • 僅SQL作業支援配置專家模式。

  • 在部署作業後,若對SQL或者資源配置進行了修改,需要重建資源計劃圖,以確保作業能夠正常啟動。

配置基礎資源

配置項

說明

JobManager CPU

根據Flink最佳實務,單個JM記憶體資源需要至少配置為0.25 Core和1 GiB,才能保證作業穩定運行,最大值16 Core。

JobManager Memory

單位為GiB,例如,4 GiB。最小值為1 GiB,最大值64 GiB。

每個TaskManager Slot數

無。

配置Slot資源

  1. 專家模式下,單擊立刻擷取,擷取資源計劃圖。

  2. 單擊Slot框上的編輯表徵圖。產生的資源計劃圖中顯示多個SLOT框,每個框內包含VERTEX運算元資訊及PARALLELISM值。

  3. 修改Slot配置資訊。對話方塊中可配置CPUHeap MemoryOff-Heap Memory並發數參數。

    此處設定的並發數為該Slot共用組內所有運算元的統一併發數。設定完成後,系統將自動進行以下操作:

    • 系統將自動為該Slot共用組內的所有運算元設定相同的並發數。

    • 系統會根據作業的計算邏輯按需自動產生Statebackend、Python和Operator所需的記憶體,無需您手動進行配置。

    • 說明

      在專家模式下,對話方塊中支援配置的記憶體僅為 Heap MemoryOff-Heap Memory。除此之外,JVM Overhead 等其他記憶體組件由系統按預設比例自動分配,並非按需動態申請。若預設比例導致記憶體不足(例如作業出現 Metaspace OOM 或 GC 開銷過高),可在運行參數配置 > 其他配置中手動調整以下參數:

      • taskmanager.memory.jvm-overhead.fraction:JVM Overhead 占 TM 總記憶體的比例,預設值為0.1

      • taskmanager.memory.jvm-overhead.min:JVM Overhead 的最小值

      • taskmanager.memory.jvm-overhead.max:JVM Overhead 的最大值

      說明
      • 建議Source節點並發度和分區數成比例,即並發度數能整除分區數。例如Kafka有16個分區,則並發度建議設定為16、8或4,這樣可以避免資料扭曲。同時Source節點的並發度不宜設定太小,避免一個Source需要讀取太多資料,導致出現入口瓶頸,影響作業吞吐。

      • 建議按需配置除Source外的其他節點的並發度。流量大的節點,並發設定大一些;流量小的節點,並發設定小一些。

      • 建議在有明確異常或者需求時,再調整Heap Memory和Off-heap Memory的大小,例如作業出現OOM或嚴重GC等。因為在作業正常運行時,調整Heap Memory和Off-heap Memory的大小,不會明顯改變作業的輸送量。

  4. 單擊確定

配置運算元資源

預設情況下,所有運算元都放在一個Slot共用組內,因此您無法為每個運算元單獨修改資源配置。如果您需要對單獨的運算元設定資源,需要開啟多SSG模式後讓每個運算元有自己獨立的Slot,這樣就可以直接在對應的Slot上設定運算元的資源。具體的運算元資源設定步驟如下:

  1. 在作業部署詳情頁簽資源配置地區,單擊編輯後,資源模式選擇為專家模式

  2. (可選)如果暫無資源計劃,單擊立刻擷取

    產生的資源計劃圖中,預設所有運算元位於同一個SLOT框內。

  3. 開啟多SSG模式開關後,單擊重建

    此時一個共用組內的運算元被拆分為單個Slot。

  4. 單擊目標運算元對應Slot框上的編輯表徵圖後,修改運算元資源。

    修改SLOT對話方塊中可配置CPUHeap MemoryOff-Heap Memory並發數參數。

  5. 單擊確定

配置運算元並發、Chain策略和TTL

說明

僅Realtime Compute引擎VVR 8.0.7及以上版本支援配置運算元TTL。

支援配置單個運算元的並發數、Chaining策略和運算元State到期時間(TTL)。

  1. 單擊目標VERTEX框上的image展開VERTEX。

    展開後的VERTEX框內顯示各個運算元節點及其PARALLELISM值,每個運算元旁有編輯表徵圖。

    說明

    您可以單擊目標VERTEX上的編輯表徵圖,大量設定對應VERTEX下的運算元並發數。

  2. 單擊運算元的image表徵圖。

  3. 配置運算元資源。

    參數說明如下:

    參數

    說明

    並發數

    對應運算元的並發數。

    Chaining策略

    Chain是指多個運算元被串連在一起形成的邏輯計算鏈。它能夠提高作業的執行效率和效能,減少資料在運算元之間的傳輸和序列化開銷。不過有時可能需要將Chain斷開,以便更好地控製作業的執行流程和效能。支援配置策略如下:

    • ALWAYS(預設值):運算元始終可以和上下遊運算元Chain一起。

    • HEAD:當前運算元作為Chain的前端節點,只和上遊運算元斷開Chain,下遊節點仍和當前運算元Chain在一起。

    • NEVER:當前運算元不會與上下遊運算元進行Chain。

    運算元State到期時間設定(TTL)

    支援設定秒、分鐘、小時和天為單位的到期時間。預設為作業的到期時間(未設定到期時間的作業預設為1.5天,作業到期時間配置請參見運行參數配置)。

    說明
    • 僅Realtime Compute引擎VVR 8.0.7及以上版本支援。

    • 僅有狀態運算元支援配置到期時間。

    • State 到期時間為近似清理機制,系統不保證在 TTL 到期後立即清除到期資料。實際清理時間取決於背景狀態訪問和清理策略。

  4. 單擊確定

常見問題

Q:設定並發度(Parallelism)是否等於佔用相同數量的 CU?

A:不等於。並發度(Parallelism)代表並發任務數(Task),不直接等於 CU 消耗量。總 CU 消耗量由以下公式決定:

總 CU 消耗 = 並發度(Parallelism)× 每個 Task 分配的 CU 數

每個 Task 佔用的 CU 數取決於作業配置中每個 Slot 的資源規格(CPU 和記憶體)。增加並發度會增加 CU 佔用,但並非 1:1 的關係。例如,當每個 Slot 配置為 1 Core 和 4 GiB 時,根據 CU = MAX(CPU 總和, 記憶體總和/4) 公式,1 個 Slot 消耗 1 個 CU;並發度為 10 時,總消耗約 10 個 CU(實際以 TM 總資源計算為準)。

Q:為什麼 SQL 作業中SET 'parallelism.default' = 'N'配置不生效?

A:在Realtime Compute Flink 版中,通過SET 'parallelism.default' = 'N'設定並發度的方式無效,平台不支援通過 SET 命令動態設定全域並發度。請使用以下方式修改並發度:

  1. 部署詳情頁簽資源配置地區,單擊編輯後修改並發度配置。

  2. 或在 SQL 陳述式的 WITH 參數中,針對特定運算元設定並發度。

Q:增加 Print Sink 或 Join 運算元後,作業出現資源不足或效能差,怎麼辦?

A:請根據具體情境參考以下建議:

  • 增加 Print Sink 後 TM 資源不足:Print Sink 會增加額外的計算和 I/O 開銷,無法僅靠調整參數解決。建議根據實際資料量評估並增加 TM 資源(CPU 和記憶體)。同時檢查源表欄位類型是否正確(例如數值型欄位建議使用BIGINT類型),避免因類型不符產生額外轉換開銷。

  • Join 任務記憶體使用量率不高但效能差:除開啟 mini-batch 最佳化外,主要提升方式是增加計算資源(CU)。若作業存在資料扭曲,單純增加資源效果有限,需先排查並解決資料扭曲問題。

  • 作業頻繁重啟且延遲高:若處於無狀態重啟後的全量同步階段,可嘗試將每個TaskManager Slot數設為 1,僅通過並發度調整並行度,選用 1 Core 4 GiB 的規格配合適當並發數(如 10)進行測試最佳化。

相關文檔