您可以在作業啟動前配置作業資源或者作業上線後修改作業資源,支援基礎模式(粗粒度)和專家模式(細粒度)兩種資源模式。本文為您介紹如何配置作業資源,以及兩種資源模式下的參數資訊。
注意事項
資源配置後,需重啟作業才會生效。
操作步驟
-
進入資源配置入口。
-
單擊目標工作空間操作列下的控制台。
-
在頁面,單擊目標作業名稱。
-
在部署詳情頁簽,單擊資源配置地區右側的編輯。
-
修改作業資源資訊。
支援基礎模式(粗粒度)和專家模式(細粒度)兩種資源配置模式。
資源模式
說明
配置參數說明
基礎模式
基礎模式是一種靜態資源分配方式,您只需要給定每個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。
-
單擊儲存。
-
重啟作業。
作業資源配置後,需重啟作業才會生效。
基礎模式(粗粒度)
|
配置項 |
說明 |
|
並發度 |
作業全域並發數。 |
|
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,建議將 |
|
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數的推算過程如下:
-
實際TM數 = [設定的並發度/設定的每個TaskManager Slot數] = [12/4] = 3。
-
實際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資源
-
在專家模式下,單擊立刻擷取,擷取資源計劃圖。
-
單擊Slot框上的
表徵圖。產生的資源計劃圖中顯示多個SLOT框,每個框內包含VERTEX運算元資訊及PARALLELISM值。 -
修改Slot配置資訊。對話方塊中可配置CPU、Heap Memory、Off-Heap Memory和並發數參數。
此處設定的並發數為該Slot共用組內所有運算元的統一併發數。設定完成後,系統將自動進行以下操作:
-
系統將自動為該Slot共用組內的所有運算元設定相同的並發數。
-
系統會根據作業的計算邏輯按需自動產生Statebackend、Python和Operator所需的記憶體,無需您手動進行配置。
-
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的大小,不會明顯改變作業的輸送量。
說明在專家模式下,對話方塊中支援配置的記憶體僅為 Heap Memory 和 Off-Heap Memory。除此之外,JVM Overhead 等其他記憶體組件由系統按預設比例自動分配,並非按需動態申請。若預設比例導致記憶體不足(例如作業出現 Metaspace OOM 或 GC 開銷過高),可在中手動調整以下參數:
說明 -
-
單擊確定。
配置運算元資源
預設情況下,所有運算元都放在一個Slot共用組內,因此您無法為每個運算元單獨修改資源配置。如果您需要對單獨的運算元設定資源,需要開啟多SSG模式後讓每個運算元有自己獨立的Slot,這樣就可以直接在對應的Slot上設定運算元的資源。具體的運算元資源設定步驟如下:
-
在作業部署詳情頁簽資源配置地區,單擊編輯後,資源模式選擇為專家模式。
-
(可選)如果暫無資源計劃,單擊立刻擷取。
產生的資源計劃圖中,預設所有運算元位於同一個SLOT框內。
-
開啟多SSG模式開關後,單擊重建。
此時一個共用組內的運算元被拆分為單個Slot。
-
單擊目標運算元對應Slot框上的
表徵圖後,修改運算元資源。修改SLOT對話方塊中可配置CPU、Heap Memory、Off-Heap Memory和並發數參數。
-
單擊確定。
配置運算元並發、Chain策略和TTL
僅Realtime Compute引擎VVR 8.0.7及以上版本支援配置運算元TTL。
支援配置單個運算元的並發數、Chaining策略和運算元State到期時間(TTL)。
-
單擊目標VERTEX框上的
展開VERTEX。展開後的VERTEX框內顯示各個運算元節點及其PARALLELISM值,每個運算元旁有編輯表徵圖。
說明您可以單擊目標VERTEX上的
表徵圖,大量設定對應VERTEX下的運算元並發數。 -
單擊運算元的
表徵圖。 -
配置運算元資源。
參數說明如下:
參數
說明
並發數
對應運算元的並發數。
Chaining策略
Chain是指多個運算元被串連在一起形成的邏輯計算鏈。它能夠提高作業的執行效率和效能,減少資料在運算元之間的傳輸和序列化開銷。不過有時可能需要將Chain斷開,以便更好地控製作業的執行流程和效能。支援配置策略如下:
-
ALWAYS(預設值):運算元始終可以和上下遊運算元Chain一起。
-
HEAD:當前運算元作為Chain的前端節點,只和上遊運算元斷開Chain,下遊節點仍和當前運算元Chain在一起。
-
NEVER:當前運算元不會與上下遊運算元進行Chain。
運算元State到期時間設定(TTL)
支援設定秒、分鐘、小時和天為單位的到期時間。預設為作業的到期時間(未設定到期時間的作業預設為1.5天,作業到期時間配置請參見運行參數配置)。
說明-
僅Realtime Compute引擎VVR 8.0.7及以上版本支援。
-
僅有狀態運算元支援配置到期時間。
-
State 到期時間為近似清理機制,系統不保證在 TTL 到期後立即清除到期資料。實際清理時間取決於背景狀態訪問和清理策略。
-
-
單擊確定。
常見問題
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 命令動態設定全域並發度。請使用以下方式修改並發度:
-
在部署詳情頁簽資源配置地區,單擊編輯後修改並發度配置。
-
或在 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)進行測試最佳化。
相關文檔
-
資源最佳化技巧,詳情請參見高效能Flink SQL最佳化技巧。
-
如果不想手動調節資源,可以使用自動調優,系統會自動完成資源調節,詳情請參見配置自動調優。
-
作業的基礎配置、運行參數配置和日誌配置,詳情請參見配置作業部署資訊。
-
您可以通過Flink Advisor作業智能診斷服務幫您監控作業健康情況,詳情請參見作業智能診斷。