Categories
程式開發

深入解讀Flink資源管理機制


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

  1. 基本概念
  2. 當前機制與策略
  3. 未來發展方向

1. 基本概念

1.1 相關組件

我們今天介紹的主要是與Flink 資源管理相關的組件,我們知道一個Flink Cluster 是由一個Flink Master 和多個Task Manager 組成的,Flink Master 和Task Manager 是進程級組件,其他的組件都是進程內的組件。

深入解讀Flink資源管理機制 1

圖1. Flink 資源管理相關組件

如圖1所示,一個Flink Master 中有一個Resource Manager 和多個Job Manager ,Flink Master 中每一個Job Manager 單獨管理一個具體的Job ,Job Manager 中的Scheduler 組件負責調度執行該Job 的DAG 中所有Task ,發出資源請求,即整個資源調度的起點;JobManager 中的Slot Pool 組件持有分配到該Job 的所有資源。 另外,Flink Master 中唯一的Resource Manager 負責整個Flink Cluster 的資源調度以及與外部調度系統對接,這裡的外部調度系統指的是Kubernetes、Mesos、Yarn 等資源管理系統。

Task Manager 負責Task 的執行,其中的Slot 是Task Manager 資源的一個子集,也是Flink 資源管理的基本單位,Slot 的概念貫穿資源調度過程的始終。

1.2 邏輯層級

介紹完相關組件,我們需要了解一下這些組件之間的邏輯關係,共分如下為4層。

  • 操作員
  • 算子是最基本的數據處理單元
  • 任務
  • Flink Runtime 中真正去進行調度的最小單位
  • 由一系列算子鍊式組合而成(chained operators)

(Note:如果兩個Operator 屬於同一個Task,那麼不會出現一個Operator 已經開始運行另一個Operator 還沒被調度的情況。)

  • 工作
  • 對應一個Job Graph
  • Flink集群
  • 1個Flink Master + N個任務管理器

深入解讀Flink資源管理機制 2

圖2. 組件的邏輯層級

資源調度的範疇,實際上是圖2紅框內的內容。 剛剛介紹的與資源調度相關的組件中,JobManager、Secheduler 和Slot Pool 對應於Job 級別,Resource Manager、Slot Manager 和Task Manager 對應於Flink Cluster 級別。

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

1.3 兩層資源調度模型

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

深入解讀Flink資源管理機制 3

圖3. 兩層資源調度模型

Task 對Slot 進行複用有兩種方式:

  • 插槽緩存
    • 批作業
    • 流作業的Failover
    • 多個task 先後/輪流使用slot 資源
  • 插槽共享
    • 多個Task 在滿足一定條件下可同時共享同一個Slot 資源

2. 當前機制與策略

截至Flink 1.10 版本,Flink 當前的資源管理機制與策略是怎樣的? 以下將詳細說明。

2.1 Task Manager 有哪些資源?

深入解讀Flink資源管理機制 4

圖4. Task Manager 資源組成

  • 資源類型
    • 內存
    • 中央處理器
    • 其他擴展資源
    • GPU(FLIP-108,在Flink 1.11 版本完成)
  • TM 資源由配置決定
    • Standalone 部署模式下,TM 資源可能不同
    • 其他部署模式下,所有TM 資源均相同

2.2 Slot 有哪些資源?

深入解讀Flink資源管理機制 5

圖5. Slot資源組成

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

2.3 Flink Cluster 有多少Task Manager ?

  • Standalone 部署模式

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

/conf/slaves
  • Active Resource Manager 部署模式
    • Kubernetes,Yarn,Mesos
    • 由SlotManager / ResourceManager 按需動態決定
    • 當前Slot 數量不能滿足新的Slot Request 時,申請並啟動新的TaskManager
    • TaskManager 空閒一段時間後,超時則釋放

Note:On-Yarn 部署模式不再支持指定固定數量的TM ,即以下命令參數已經失效。

yarn-session.sh -n 
flink run -yn 

2.4 Cluster -> Job 資源調度的過程

深入解讀Flink資源管理機制 6

圖6. Cluster 到Job 的資源調度過程

如圖6,Cluster 到Job 的資源調度過程中主要包含兩個過程。

  • Slot Allocation(圖6中紅色箭頭)

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

  • Starting TaskManagers(圖6中藍色箭頭)

在Active Resource Manager 資源部署模式下,當Resource Manager 判定Flink Cluster 中沒有足夠的資源去滿足需求時,它會進一步去底層的資源調度系統請求資源,由調度系統把新的Task Manager 啟動起來,並且TaskManager向Resource Manager 註冊,則完成了新Slot 的補充。

2.5 Job -> Task 資源調度的過程

  • 排程器
    • 根據Execution Graph 和Task 的執行狀態,決定接下來要調度的Task
    • 發起SlotRequest
    • 決定Task / Slot 之間的分配
  • 插槽共享
    • Slot Sharing Group 中的任務可共用Slot
    • 默認所有節點在一個Slot Sharing Group 中
    • 一個Slot 中相同任務只能有一個
  • 優點
    • 運行一個作業所需的Slot 數量為最大並發數
    • 相對負載均衡

深入解讀Flink資源管理機制 7

圖7. Job 到Task 資源調度過程

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

2.6 資源調優

通過以上介紹的機制,我們容易發現,Flink 所採用的是自頂向下的資源管理,我們所配置的是Job 整體的資源,而Flink 通過Slot Sharing 機制控制Slot 的數量和負載均衡,通過調整Task Manager / Slot 的資源,以適應一個Slot Sharing Group 的資源需求。 Flink 的資源管理配置簡單,易用性強,適合拓撲結構簡單或規模較小的作業。

3. 未來發展方向

3.1 細粒度資源管理

■ Slot Sharing 的局限性

深入解讀Flink資源管理機制 8

圖8. Slot Sharing的局限性

  • 資源利用率非最優

通過Slot Sharing 機制我們可以看到,對資源的利用率不是最優的,因為我們是按照最大並發數來配置Slot 的資源,這樣就會造成如圖8所示的部分資源被浪費。

深入解讀Flink資源管理機制 9

  • 不確定性

如圖9所示,A 的並發度是2,BC 的並發度是1,圖9中的兩種分配方式均滿足Slot Sharing 機制的要求,這樣就可能會出現如下情況:我們在測試的時候出現的是上圖右邊這種Slot 資源配置情況,我們進行了調優配置好了Slot 的大小,但是我們真正提交作業到生產環境中確是上圖左邊的情況,這樣就會造成資源不夠用,進而導致作業無法執行。

■ 細粒度資源管理

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

  • 當算子的資源需求是已知的,可以通過經驗性的預估、半自動化或自動化的工具來衡量Slot 的資源大小。
  • 每一個Task 獨占一個Slot 來進行資源調度。

3.2 動態Slot 切分

深入解讀Flink資源管理機制 10

圖10. 靜態Slot 分配

如圖10所示,我們用圓圈的大小來表示該任務所需資源的多少,如果不採用Slot Sharing Group 機制,現有的Flink 資源管理機制要求Slot 的大小必須一致,所以我們可以得到右側這樣的Slot 資源配置,四個Task Manager。

深入解讀Flink資源管理機制 11

圖11. 動態Slot 切分

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

  • 動態Slot 切分(FLIP-56)

深入解讀Flink資源管理機制 12

圖12. 靜態Slot 劃分

如圖12所示,這是當前靜態的固定大小的Task Manager 的管理方式,隨著任務的執行,Slot 只能簡單的被佔用或者被釋放,而不能進行更多額外調整。

深入解讀Flink資源管理機制 13

圖13. 動態Slot 劃分

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

3.3 碎片化問題

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

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

在不同的應用場景下也可使用不同的方案:

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

3.4 易用性問題

與現有的資源調優相反,細粒度資源管理下的資源調優是自底向上的資源管理,我們不再是需要配置Job 的整體資源,而是需要用戶去配置每個Task 具體的資源需求,我們需要把Task 的資源配置盡可能的接近其實際的資源需求,來提高資源利用率。 但是同樣帶來的問題是,配置難度高。 所以更適用於拓撲複雜或規模較大的作業。

與當前的資源調優相比,兩種機制並不是孰優孰劣的關係,而是可以針對不同的場景需求適配不同的調優策略,在社區看來,兩種策略均有存在的價值。

3.5 資源調度策略插件化(FLINK-14106)

不管是當前靜態的資源管理機制,還是細粒度資源管理機制都要求調度策略針對不同的場景來進行不同的變化。 目前Flink 1.11 中調度策略插件化的開發工作已經完成。

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

通過這三個資源調度策略,我們可以得到如下優勢:

  • 解決流處理和批處理的不同資源調度策略需求
  • 滿足用戶對於細粒度、非細粒度資源管理的不同選擇
  • 未來更多資源調度策略帶來的可能性
  • 例如:Spark 根據負載彈性伸縮集群的策略

隨著Flink 支持越來越多的應用場景,靈活的資源調度策略對於保障高性能及資源效率至關重要,我們歡迎更多Flink 愛好者和開發者加入我們社區,攜手共進。

作者介紹:

宋辛童(五藏),阿里巴巴高級開發工程師。 2018 年博士畢業於北京大學網絡與信息系統研究所,後加入阿里巴巴實時計算團隊,主要負責Apache Flink 及阿里巴巴企業版本Blink 中資源調度與管理機制的研發工作。

推薦閱讀:

  • Apache Flink運維和實戰系列文章

  • Apache Flink 零基礎入門到進階系列文章