本文僅為筆者平日學(xué)習記錄之用，侵刪
原文：https://mp.weixin.qq.com/s/DJCzL582-bBvUuUxlYTW_A

1. 基本概念

1.1 相關(guān)組件

我們今天介紹的主要是與 Flink 資源管理相關(guān)的組件舅逸，我們知道一個 Flink Cluster 是由一個 Flink Master 和多個 Task Manager 組成的拆座，F(xiàn)link Master 和 Task Manager 是進程級組件霜运，其他的組件都是進程內(nèi)的組件捺典。

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

如圖1所示恐锣，一個 Flink Master 中有一個 Resource Manager 和多個 Job Manager 仁卷，F(xiàn)link Master 中每一個 Job Manager 單獨管理一個具體的 Job ，Job Manager 中的 Scheduler 組件負責調(diào)度執(zhí)行該 Job 的 DAG 中所有 Task 邀窃，發(fā)出資源請求荸哟，即整個資源調(diào)度的起點；JobManager 中的 Slot Pool 組件持有分配到該 Job 的所有資源瞬捕。另外鞍历，F(xiàn)link Master 中唯一的 Resource Manager 負責整個 Flink Cluster 的資源調(diào)度以及與外部調(diào)度系統(tǒng)對接，這里的外部調(diào)度系統(tǒng)指的是 Kubernetes肪虎、Mesos劣砍、Yarn 等資源管理系統(tǒng)。

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

1.2 邏輯層級

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

• Operator

• 算子是最基本的數(shù)據(jù)處理單元

• Task

• Flink Runtime 中真正去進行調(diào)度的最小單位

• 由一系列算子鏈式組合而成（chained operators）

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

• Job

• 對應(yīng)一個 Job Graph

• Flink Cluster

• 1 Flink Master + N Task Managers

組件的邏輯層級

資源調(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 如果不能滿足該資源需求則會進一步請求 Resource Manager解幼，具體來滿足該請求的組件是 Slot Manager抑党。

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

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

• Slot Caching

• 批作業(yè)

• 流作業(yè)的 Failover

• 多個 task 先后/輪流使用 slot 資源

• Slot Sharing

• 多個 Task 在滿足一定條件下可同時共享同一個 Slot 資源

2. 當前機制與策略

截至 Flink 1.10 版本，F(xiàn)link 當前的資源管理機制與策略是怎樣的撵摆？以下將詳細說明底靠。

2.1 Task Manager 有哪些資源？

Task Manager 資源組成

• 資源類型

• 內(nèi)存

• CPU

• 其他擴展資源

• GPU（FLIP-108台汇，在 Flink 1.11 版本完成）

• TM 資源由配置決定

• Standalone 部署模式下苛骨，TM 資源可能不同

• 其他部署模式下篱瞎，所有 TM 資源均相同

2.2 Slot 有哪些資源苟呐？

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)決定
  • 當前 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)度的過程

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 判斷集群當中有足夠的資源可以滿足需求谣旁，那么就會向 Task Manager 發(fā)送 Assign 指令，Task Manager 就會提供 Slot 給 Slot Pool翁锡，Slot Pool 再去滿足 Scheduler 的資源請求蔓挖。

• Starting TaskManagers（圖6中藍色箭頭）

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

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

    • 默認所有節(jié)點在一個 Slot Sharing Group 中

    • 一個 Slot 中相同任務(wù)只能有一個

  • 優(yōu)點

    • 運行一個作業(yè)所需的 Slot 數(shù)量為最大并發(fā)數(shù)

    • 相對負載均衡

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

Slot Sharing 過程如圖7所示（每一行分別是一個 task 的多個并發(fā)，自下而上分別是 A匆瓜、B赢笨、C），A驮吱、B茧妒、C 的并行度分別是4、4左冬、3桐筏，這些 Task 屬于同一個 Slot Sharing Group 中，所以不同的 Task 可以放在相同的 Slot 中運行拇砰，如圖7右側(cè)所示梅忌，有3個 Slot 放入了 ABC，而第四個 Slot 放入了 AB 除破。通過以上過程我們可以很容易推算出這個 Job 需要的 Slot 數(shù)是4牧氮，也是最大并發(fā)數(shù)。

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

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

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

3.1 細粒度資源管理

■ Slot Sharing 的局限性

Slot Sharing的局限性

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

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

• 不確定性

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

■ 細粒度資源管理

基于以上 Slot Sharing 機制的局限性悟耘，我們提出了細粒度資源管理的概念。

• 當算子的資源需求是已知的织狐，可以通過經(jīng)驗性的預(yù)估暂幼、半自動化或自動化的工具來衡量 Slot 的資源大小。

• 每一個 Task 獨占一個 Slot 來進行資源調(diào)度移迫。

3.2 動態(tài) Slot 切分

靜態(tài) Slot 分配

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

動態(tài) Slot 切分

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

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

靜態(tài) Slot 劃分

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

動態(tài) Slot 劃分

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

3.3 碎片化問題

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

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

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

• Streaming（流處理）

  • 一次調(diào)度，長期運行
  • 提高資源利用率的收益較高
  • 適合采用定制 Task Manager 資源的調(diào)度策略

• Batch（批處理乐纸，尤其是短查詢）

  • 頻繁調(diào)度衬廷，Task 運行時間短
  • 對調(diào)度延遲敏感
  • 適合采用非定制的 Task Manager 資源的調(diào)度策略

3.4 易用性問題

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

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

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

不管是當前靜態(tài)的資源管理機制漱挚，還是細粒度資源管理機制都要求調(diào)度策略針對不同的場景來進行不同的變化。目前 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)度策略需求
• 滿足用戶對于細粒度、非細粒度資源管理的不同選擇
• 未來更多資源調(diào)度策略帶來的可能性
  • 例如：Spark 根據(jù)負載彈性伸縮集群的策略

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