作者：任春德
Apache Flink作爲下一代大數據計算引擎，在迅速發展強大中，其內部架構也在不斷優化重構，以適應更多運行時環境和更大計算規模，Flink Improvement Proposals-6重新設計了在各集羣管理系統(Standalone/YARN/Kubernetes等)上資源調度的統一架構，本文將介紹資源調度的架構發展及其清晰分層等設計特點，YARN上per-Job和session兩種模式的實現，以及正在討論開發的與K8S雲原生融合的詳細設計。
本文內容如下：
-
Apache Flink Standalone Cluster
-
Apache Flink 與 YARN 的原生融合
-
Apache Flink 與 K8S 的原生融合
- 小結
Apache Flink Standalone Cluster
如圖1，Flink的Standalone集羣部署是主從架構，其中主JobManager(簡稱JM)負責Job的計算單元Task調度，TaskManager(簡稱TM)向JobManager彙報並負責在其內部用線程執行Task。
之所以是Standalone，是因爲其不依賴其他底層資源調度系統，直接部署啓動在各自的裸機器節點上，雖然可以用一些自動化運維工具方便地部署和管理，但是存在以下幾個問題：
-
隔離：多Job運行在一個集羣，可能同一TM上執行不同Job的Task，其線程所用資源(cpu/mem)無法控制，相互影響，甚至一個Task造成整個TM的Out Of Memory，使其之上的Job都受影響；多個Job的調度也在同一個JM中，同樣存在被有問題Job影響的問題。
-
多租戶的資源用量(quota)管理：無法控制用戶的Job資源使用總量，缺乏租戶間的資源協調管理。
-
集羣的可用性：雖然JM可以部署有Standby，支持High Available，但JM、TM進程缺乏被看護，難免因以上隔離等問題造成過多進程宕掉，整個集羣不可用。
- 集羣的可運維：版本升級，擴縮容等都需要複雜的運維操作。
爲了解決以上問題，需要將Flink跑在流行成熟的資源調度系統上，如YARN、Kubernetes、Mesos，如何實現呢？
Flink 與 YARN 的原生融合
Apache Flink Standalone Cluster on YARN
簡單有效的一種部署方式是利用YARN自身支持的特性，將Flink Standalone部署到YARN集羣上，如圖2(Apache Flink Standalone Cluster ON YARN)，
-
多個Job可以相應地起多個YARN Application，每個app是一個standalone cluster，各自獨立運行，而且依靠YARN本身支持的cgroups等隔離手段，避免了多任務間的相互影響，隔離問題迎刃而解。
-
不同用戶的App也可以運行在不同的YARN調度隊列中，通過queue quota管理能力解決多租戶的問題。
-
同時可以利用YARN對App進程的重啓重試再調度的策略，使Flink Standalone Cluster高可用。
- 簡單的參數、配置文件修改，通過YARN的distributed cache分發Flink jar，就可以方便的升級和擴縮容。
雖然解決了以上問題，但是每個(少量)Job起一個Standalone Cluster，難以達到高效的資源利用，因爲：
-
Cluster的規模(多少個TM)是在啓動YARN App時參數靜態指定的，Flink自身的編譯優化使其較難在運行前預估資源的需求，那就難以合理化TM數量，多了資源浪費，少了影響Job執行速度甚至無法運行。
-
每個TM擁有的資源大小也是參數靜態指定，同樣難以預估實際需要，不能針對不同的Task資源需求來動態申請不同大小的TM，只能設置相同規格大小的TM，那就難以恰好放置整數個Task，剩餘的部分資源浪費。
- App的啓動(1.Submit YARN App)和Flink Job的提交(7.Submit Job)需要2階段完成，會使每個任務的提交效率低，造成集羣的資源流轉率也會降低。
大規模YARN集羣中Flink Job越多，資源浪費的會更可觀，成本損失越大，而且不只是on YARN存在以上問題，Standalone直接運行於其他資源調度系統之上，也是有相同問題，所以阿里巴巴實時計算率先在YARN實際生產經驗上改進了Flink的資源利用模型，後續與社區討論設計實現了一套通用的架構，適用於不同的資源調度系統。
FLIP-6 - Deployment and Process Model
FLIP-6全面記錄了此次部署架構的重構，新的模塊如圖3。類似MapReduce-1架構向YARN+MapReduce-2的升級，將資源調度與Job計算邏輯單元(Task)的調度分成2層，使兩個模塊（系統）——ResourceManager(RM)和JobManager(JM)各司其職，與底層資源調度系統的耦合降低（只需實現不同plugable的ResourceManager即可），減少邏輯複雜度降低開發維護難度，優化JM實現資源按Task所需申請，解決了Standalone on YARN/K8S的資源利用率低的問題，同時還有利於集羣和Job規模的擴展。
-
Dispatcher: 負責與Client通信接收Job的提交，生成JobManager，生命週期可跨Job。
-
ResourceManager: 對接不同資源調度系統，實現資源的調度（申請/釋放），管理Container/TaskManager，同樣生命週期可跨Job。
-
JobManager: 每個Job一個實例，負責Job的計算邏輯的調度執行。
- TaskManager: 向RM註冊彙報資源情況，從JM接收Task執行並彙報狀態。
Apache Flink與YARN的原生融合
根據以上架構，Flink on YARN實現了2種不同的部署運行模式Per-Job和Session（用戶使用文檔Flink on Yarn）。
Per-Job
Per-Job即一個Flink Job與其YARN Application(App)生命週期綁定，執行過程如圖4，在提交YARN App時同時將Flink Job的file/jars通過YARN Distributed Cache分發，一次性完成提交，而且JM是根據JobGraph產生的Task的資源實際需求來向RM申請slot執行，Flink RM再動態的申請/釋放YARN的Container。完美(?)解決了之前的所有問題，既利用了YARN的隔離又有高效的資源利用。
Session
Per-Job完美？No，還是存在侷限，YARN App的提交時資源申請和啓動TM的時間較長(秒級)，尤其在交互式分析短查詢等場景上，Job計算邏輯執行時間很短，那麼App的啓動時間佔比大就嚴重影響了端到端的用戶體驗，缺少了Standalone模式上Job提交快的優點。但FLIP-6架構的威力，還是能輕鬆化解這個問題，如圖5，通過預啓動的YARN App來跑一個Flink Session（Master和多個TM已啓動，類似Standalone可運行多個Job），再提交執行Job，這些Job就可以很快利用已有的資源來執行計算。Blink分支與Master具體實現有點不同（是否預起TM），後續會合並統一，並且繼續開發實現Session的資源彈性——按需自動擴縮TM數量，這點是standalone無法實現的。
Resource Profile
前面是架構上的變化，而要實現資源按需申請，需要有協議API，這就是Resource Profile，可以描述單個算子(Operator)的CPU & Memory等的資源用量，進而RM根據這些資源請求來向底層資源管理系統申請Container來執行TM，詳細的使用文檔見Task slots and resources。
Flink 與 Kubernetes 的原生融合
最近幾年，Kubernetes的發展迅猛，已然成爲了雲時代的原生操作系統，下一代的大數據計算引擎Apache Flink的部署與其融合，是否可以開闢大數據計算的新大陸？
Apache Flink Standalone Cluster on Kubernetes
依靠K8S自身支持Service部署的強大能力，Flink Standalone Cluster可以通過簡單的K8S: Deployment & Service或Flink Helm chart很容易的部署到K8S集羣上，但同樣有類似Standalone on YARN的資源利用率低等問題，所以還是需要“原生融合”。
Apache Flink 和 Kubernetes 的原生融合
Flink與K8S的“原生融合”，主要是在FLIP-6架構上實現K8SResourceManager來對接Kubernetes的資源調度協議，現Blink的分支實現架構下圖所示，用戶使用文檔見Flink on K8S，merge到主幹Master上的工作正在進行中
小結
部署管理、資源調度是大數據處理系統的底層基石，通過FLIP-6的抽象分層和重構，Apache Flink構建了牢固的基礎，可以“原生”地運行於各大資源調度系統（YARN/Kubernetes/Mesos）上，支撐起更大規模更高併發的計算，高效地利用集羣資源，爲後續的不斷髮展強大提供了可靠的保障。
相關功能的優化改進依然在繼續，如Resource Profile配置資源的難度使一些開發者望而生畏，並且嚴重降低了Flink的易用性，我們在嘗試實現資源和併發配置的Auto Config/Scaling等功能來解決此類問題；“Serverless”架構在迅速發展，期待Flink與Kubernetes的融合成爲雲原生的強大計算引擎(類FaaS)，爲用戶節省資源，帶來更大的價值。