作者：宋辛童（五藏）
整理：王文杰（Flink 社區(qū)志愿者）

摘要：本文根據(jù) Apache Flink 系列直播整理而成，由阿里巴巴高級開發(fā)工程師宋辛童分享。文章主要從基本概念、當(dāng)前機(jī)制與策略、未來發(fā)展方向等三個方面幫助開發(fā)者深入理解 Flink 的資源管理機(jī)制。

基本概念

當(dāng)前機(jī)制與策略

未來發(fā)展方向

Tips：點擊「下方鏈接」可查看更多數(shù)倉系列視頻～
https://ververica.cn/developers/flink-training-course-data-warehouse/

1. 基本概念

1.1 相關(guān)組件

我們今天介紹的主要是與 Flink 資源管理相關(guān)的組件，我們知道一個 Flink Cluster 是由一個 Flink Master 和多個 Task Manager 組成的，Flink Master 和 Task Manager 是進(jìn)程級組件，其他的組件都是進(jìn)程內(nèi)的組件。

圖1. Flink 資源管理相關(guān)組件

如圖1所示，一個 Flink Master 中有一個 Resource Manager 和多個 Job Manager ，Flink Master 中每一個 Job Manager 單獨管理一個具體的 Job ，Job Manager 中的 Scheduler 組件負(fù)責(zé)調(diào)度執(zhí)行該 Job 的 DAG 中所有 Task ，發(fā)出資源請求，即整個資源調(diào)度的起點；JobManager 中的 Slot Pool 組件持有分配到該 Job 的所有資源。另外，Flink Master 中唯一的 Resource Manager 負(fù)責(zé)整個 Flink Cluster 的資源調(diào)度以及與外部調(diào)度系統(tǒng)對接，這里的外部調(diào)度系統(tǒng)指的是 Kubernetes、Mesos、Yarn 等資源管理系統(tǒng)。

Task Manager 負(fù)責(zé) Task 的執(zhí)行，其中的 Slot 是 Task Manager 資源的一個子集，也是 Flink 資源管理的基本單位，Slot 的概念貫穿資源調(diào)度過程的始終。

1.2 邏輯層級

介紹完相關(guān)組件，我們需要了解一下這些組件之間的邏輯關(guān)系，共分如下為4層。

• Operator
• 算子是最基本的數(shù)據(jù)處理單元
• Task
• Flink Runtime 中真正去進(jìn)行調(diào)度的最小單位
• 由一系列算子鏈?zhǔn)浇M合而成（chained operators）

（Note：如果兩個 Operator 屬于同一個 Task，那么不會出現(xiàn)一個 Operator 已經(jīng)開始運(yùn)行另一個 Operator 還沒被調(diào)度的情況。）

• Job
• 對應(yīng)一個 Job Graph
• Flink Cluster
• 1 Flink Master + N Task Managers

圖2. 組件的邏輯層級

資源調(diào)度的范疇，實際上是圖2紅框內(nèi)的內(nèi)容。剛剛介紹的與資源調(diào)度相關(guān)的組件中，JobManager、Secheduler 和 Slot Pool 對應(yīng)于 Job 級別，Resource Manager、Slot Manager 和 Task Manager 對應(yīng)于 Flink Cluster 級別。

在 Operator 和 Task 中間的 Chaining 是指如何用 Operator 組成 Task 。在 Task 和 Job 之間的 Slot Sharing 是指多個 Task 如何共享一個 Slot 資源，這種情況不會發(fā)生在跨作業(yè)的情況中。在 Flink Cluster 和 Job 之間的 Slot Allocation 是指 Flink Cluster 中的 Slot 是怎樣分配給不同的 Job 。

1.3 兩層資源調(diào)度模型

Flink 的資源調(diào)度是一個經(jīng)典的兩層模型，其中從 Cluster 到 Job 的分配過程是由 Slot Manager 來完成，Job 內(nèi)部分配給 Task 資源的過程則是由 Scheduler 來完成。如圖3，Scheduler 向 Slot Pool 發(fā)出 Slot Request（資源請求），Slot Pool 如果不能滿足該資源需求則會進(jìn)一步請求 Resource Manager，具體來滿足該請求的組件是 Slot Manager。

圖3. 兩層資源調(diào)度模型

Task 對 Slot 進(jìn)行復(fù)用有兩種方式：

• Slot Caching
• 批作業(yè)
• 流作業(yè)的 Failover
• 多個 task 先后/輪流使用 slot 資源
• Slot Sharing
• 多個 Task 在滿足一定條件下可同時共享同一個 Slot 資源

2. 當(dāng)前機(jī)制與策略

截至 Flink 1.10 版本，Flink 當(dāng)前的資源管理機(jī)制與策略是怎樣的？以下將詳細(xì)說明。

2.1 Task Manager 有哪些資源？

圖4. Task Manager 資源組成

• 資源類型
• 內(nèi)存
• CPU
• 其他擴(kuò)展資源
• GPU（FLIP-108，在 Flink 1.11 版本完成）
• TM 資源由配置決定
• Standalone 部署模式下，TM 資源可能不同
• 其他部署模式下，所有 TM 資源均相同

2.2 Slot 有哪些資源？

圖5. Slot資源組成

Task Manager 中有固定數(shù)量的 Slot ，Slot 的具體數(shù)量由配置決定。同一 Task Manager 上 Slot 之間沒有差別，每一個 Slot 都一樣大，即資源一樣多。

2.3 Flink Cluster 有多少 Task Manager ？

• Standalone 部署模式

在 Standalone 部署模式下，Task Manager 的數(shù)量是固定的，如果是 start-cluster.sh 腳本來啟動集群，可以通過修改以下文件中的配置來決定 TM 的數(shù)量；也可以通過手動執(zhí)行 taskmanager.sh 腳本來啟動一個 TM 。

<FLINK_DIR>/conf/slaves

• Active Resource Manager 部署模式
• Kubernetes，Yarn，Mesos
• 由 SlotManager / ResourceManager 按需動態(tài)決定
• 當(dāng)前 Slot 數(shù)量不能滿足新的 Slot Request 時，申請并啟動新的 TaskManager
• TaskManager 空閑一段時間后，超時則釋放

Note：On-Yarn 部署模式不再支持指定固定數(shù)量的 TM ，即以下命令參數(shù)已經(jīng)失效。

yarn-session.sh -n <num> flink run -yn <num>

2.4 Cluster -> Job 資源調(diào)度的過程

圖6. Cluster 到 Job 的資源調(diào)度過程

如圖6，Cluster 到 Job 的資源調(diào)度過程中主要包含兩個過程。

• Slot Allocation（圖6中紅色箭頭）

Scheduler 向 Slot Pool 發(fā)送請求，如果 Slot 資源足夠則直接分配，如果 Slot 資源不夠，則由 Slot Pool 再向 Slot Manager發(fā)送請求（此時即為 Job 向 Cluster 請求資源），如果 Slot Manager 判斷集群當(dāng)中有足夠的資源可以滿足需求，那么就會向 Task Manager 發(fā)送 Assign 指令，Task Manager 就會提供 Slot 給 Slot Pool，Slot Pool 再去滿足 Scheduler 的資源請求。

• Starting TaskManagers（圖6中藍(lán)色箭頭）

在 Active Resource Manager 資源部署模式下，當(dāng) Resource Manager 判定 Flink Cluster 中沒有足夠的資源去滿足需求時，它會進(jìn)一步去底層的資源調(diào)度系統(tǒng)請求資源，由調(diào)度系統(tǒng)把新的 Task Manager 啟動起來，并且 TaskManager 向 Resource Manager 注冊，則完成了新 Slot 的補(bǔ)充。

2.5 Job -> Task 資源調(diào)度的過程

• Scheduler
• 根據(jù) Execution Graph 和 Task 的執(zhí)行狀態(tài)，決定接下來要調(diào)度的 Task
• 發(fā)起 SlotRequest
• 決定 Task / Slot 之間的分配
• Slot Sharing
• Slot Sharing Group 中的任務(wù)可共用Slot
• 默認(rèn)所有節(jié)點在一個 Slot Sharing Group 中
• 一個 Slot 中相同任務(wù)只能有一個
• 優(yōu)點
• 運(yùn)行一個作業(yè)所需的 Slot 數(shù)量為最大并發(fā)數(shù)
• 相對負(fù)載均衡

圖7. Job 到 Task 資源調(diào)度過程

Slot Sharing 過程如圖7所示（每一行分別是一個 task 的多個并發(fā)，自下而上分別是 A、B、C），A、B、C 的并行度分別是4、4、3，這些 Task 屬于同一個 Slot Sharing Group 中，所以不同的 Task 可以放在相同的 Slot 中運(yùn)行，如圖7右側(cè)所示，有3個 Slot 放入了 ABC，而第四個 Slot 放入了 AB 。通過以上過程我們可以很容易推算出這個 Job 需要的 Slot 數(shù)是4，也是最大并發(fā)數(shù)。

2.6 資源調(diào)優(yōu)

通過以上介紹的機(jī)制，我們?nèi)菀装l(fā)現(xiàn)，Flink 所采用的是自頂向下的資源管理，我們所配置的是 Job 整體的資源，而 Flink 通過 Slot Sharing 機(jī)制控制 Slot 的數(shù)量和負(fù)載均衡，通過調(diào)整 Task Manager / Slot 的資源，以適應(yīng)一個 Slot Sharing Group 的資源需求。Flink 的資源管理配置簡單，易用性強(qiáng)，適合拓?fù)浣Y(jié)構(gòu)簡單或規(guī)模較小的作業(yè)。

3. 未來發(fā)展方向

3.1 細(xì)粒度資源管理

■ Slot Sharing 的局限性

圖8. Slot Sharing的局限性

• 資源利用率非最優(yōu)

通過 Slot Sharing 機(jī)制我們可以看到，對資源的利用率不是最優(yōu)的，因為我們是按照最大并發(fā)數(shù)來配置 Slot 的資源，這樣就會造成如圖8所示的部分資源被浪費。

• 不確定性

如圖9所示，A 的并發(fā)度是2，BC 的并發(fā)度是1，圖9中的兩種分配方式均滿足 Slot Sharing 機(jī)制的要求，這樣就可能會出現(xiàn)如下情況：我們在測試的時候出現(xiàn)的是上圖右邊這種 Slot 資源配置情況，我們進(jìn)行了調(diào)優(yōu)配置好了 Slot 的大小，但是我們真正提交作業(yè)到生產(chǎn)環(huán)境中確是上圖左邊的情況，這樣就會造成資源不夠用，進(jìn)而導(dǎo)致作業(yè)無法執(zhí)行。

■ 細(xì)粒度資源管理

基于以上 Slot Sharing 機(jī)制的局限性，我們提出了細(xì)粒度資源管理的概念。

• 當(dāng)算子的資源需求是已知的，可以通過經(jīng)驗性的預(yù)估、半自動化或自動化的工具來衡量 Slot 的資源大小。
• 每一個 Task 獨占一個 Slot 來進(jìn)行資源調(diào)度。

3.2 動態(tài) Slot 切分

圖10. 靜態(tài) Slot 分配

如圖10所示，我們用圓圈的大小來表示該任務(wù)所需資源的多少，如果不采用 Slot Sharing Group 機(jī)制，現(xiàn)有的 Flink 資源管理機(jī)制要求 Slot 的大小必須一致，所以我們可以得到右側(cè)這樣的 Slot 資源配置，四個 Task Manager。

圖11. 動態(tài) Slot 切分

如果我們可以根據(jù)不同任務(wù)動態(tài)的決定每個 Slot 的大小，我們就可以將 Task Manager 切分成如圖11所示的情況，僅需要三個 Task Manager。

• 動態(tài) Slot 切分（FLIP-56）

圖12. 靜態(tài) Slot 劃分

如圖12所示，這是當(dāng)前靜態(tài)的固定大小的 Task Manager 的管理方式，隨著任務(wù)的執(zhí)行，Slot 只能簡單的被占用或者被釋放，而不能進(jìn)行更多額外調(diào)整。

圖13. 動態(tài) Slot 劃分

如圖13所示，每一個 Task Manager 啟動之后是一整塊的資源，每接收一個資源請求時，都可以根據(jù)該請求動態(tài)的切分出一個 Slot 提供給它。但這也是有缺陷的，因為不管我們怎樣切分，都經(jīng)常會出現(xiàn)一小部分資源被浪費的情況，這也是我們常說的資源碎片問題。

3.3 碎片化問題

針對上述提到的資源碎片問題，我們提出了一個解決方案，可以根據(jù) Slot Request 資源需求定制 Task Manager 資源，當(dāng)前Flink 1.10 中每一個 Task Manager 都是一致的，但是在細(xì)粒度的資源管理中，已知資源需求時，完全可以定制 Task Manager，從理論上講是完全可以徹底杜絕資源碎片問題。

這樣做的代價是需要延長作業(yè)的調(diào)度時間，要想定制 Task Manager 就必須要等收到 Slot Request 后才可以，啟動 Task Manager 的過程是比較耗時的。另一方面，可能會導(dǎo)致 Task Manager 比較難復(fù)用，很有可能需要釋放掉舊的 Task Manager 而啟動新的，這也會耗費很多時間。

在不同的應(yīng)用場景下也可使用不同的方案：

• Streaming（流處理）
• 一次調(diào)度，長期運(yùn)行
• 提高資源利用率的收益較高
• 適合采用定制 Task Manager 資源的調(diào)度策略
• Batch（批處理，尤其是短查詢）
• 頻繁調(diào)度，Task 運(yùn)行時間短
• 對調(diào)度延遲敏感
• 適合采用非定制的 Task Manager 資源的調(diào)度策略

3.4 易用性問題

與現(xiàn)有的資源調(diào)優(yōu)相反，細(xì)粒度資源管理下的資源調(diào)優(yōu)是自底向上的資源管理，我們不再是需要配置 Job 的整體資源，而是需要用戶去配置每個 Task 具體的資源需求，我們需要把 Task 的資源配置盡可能的接近其實際的資源需求，來提高資源利用率。但是同樣帶來的問題是，配置難度高。所以更適用于拓?fù)鋸?fù)雜或規(guī)模較大的作業(yè)。

與當(dāng)前的資源調(diào)優(yōu)相比，兩種機(jī)制并不是孰優(yōu)孰劣的關(guān)系，而是可以針對不同的場景需求適配不同的調(diào)優(yōu)策略，在社區(qū)看來，兩種策略均有存在的價值。

3.5 資源調(diào)度策略插件化（FLINK-14106）

不管是當(dāng)前靜態(tài)的資源管理機(jī)制，還是細(xì)粒度資源管理機(jī)制都要求調(diào)度策略針對不同的場景來進(jìn)行不同的變化。目前 Flink 1.11 中調(diào)度策略插件化的開發(fā)工作已經(jīng)完成。

• 資源調(diào)度策略
• Task Manager 的數(shù)量
• 何時申請/釋放 Task Manager
• Task Manager 的資源大小
• Slot Request 與 Task Manager 資源之間的適配

通過這三個資源調(diào)度策略，我們可以得到如下優(yōu)勢：

• 解決流處理和批處理的不同資源調(diào)度策略需求
• 滿足用戶對于細(xì)粒度、非細(xì)粒度資源管理的不同選擇
• 未來更多資源調(diào)度策略帶來的可能性
• 例如：Spark 根據(jù)負(fù)載彈性伸縮集群的策略

隨著 Flink 支持越來越多的應(yīng)用場景，靈活的資源調(diào)度策略對于保障高性能及資源效率至關(guān)重要，我們歡迎更多 Flink 愛好者和開發(fā)者加入我們社區(qū)，攜手共進(jìn)。

作者介紹：

宋辛童（五藏），阿里巴巴高級開發(fā)工程師。2018 年博士畢業(yè)于北京大學(xué)網(wǎng)絡(luò)與信息系統(tǒng)研究所，后加入阿里巴巴實時計算團(tuán)隊，主要負(fù)責(zé) Apache Flink 及阿里巴巴企業(yè)版本 Blink 中資源調(diào)度與管理機(jī)制的研發(fā)工作。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的深入解读Flink资源管理机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。