溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
作者：任春德
Apache Flink作為下一代大數據計算引擎，在迅速發展強大中，其內部架構也在不斷優化重構，以適應更多運行時環境和更大計算規模，Flink Improvement Proposals-6重新設計了在各集群管理系統(Standalone/YARN/Kubernetes等)上資源調度的統一架構，本文將介紹資源調度的架構發展及其清晰分層等設計特點，YARN上per-Job和session兩種模式的實現，以及正在討論開發的與K8S云原生融合的詳細設計。
本文內容如下：
Apache Flink Standalone Cluster
Apache Flink 與 YARN 的原生融合
Apache Flink 與 K8S 的原生融合
如圖1，Flink的Standalone集群部署是主從架構，其中主JobManager(簡稱JM)負責Job的計算單元Task調度，TaskManager(簡稱TM)向JobManager匯報并負責在其內部用線程執行Task。
cdn.xitu.io/2019/5/6/16a8b08199dfa29c?w=2145&h=916&f=png&s=115499">
之所以是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，如何實現呢？
簡單有效的一種部署方式是利用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高可用。
雖然解決了以上問題，但是每個(少量)Job起一個Standalone Cluster，難以達到高效的資源利用，因為：
Cluster的規模(多少個TM)是在啟動YARN App時參數靜態指定的，Flink自身的編譯優化使其較難在運行前預估資源的需求，那就難以合理化TM數量，多了資源浪費，少了影響Job執行速度甚至無法運行。
每個TM擁有的資源大小也是參數靜態指定，同樣難以預估實際需要，不能針對不同的Task資源需求來動態申請不同大小的TM，只能設置相同規格大小的TM，那就難以恰好放置整數個Task，剩余的部分資源浪費。
大規模YARN集群中Flink Job越多，資源浪費的會更可觀，成本損失越大，而且不只是on YARN存在以上問題，Standalone直接運行于其他資源調度系統之上，也是有相同問題，所以阿里巴巴實時計算率先在YARN實際生產經驗上改進了Flink的資源利用模型，后續與社區討論設計實現了一套通用的架構，適用于不同的資源調度系統。
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的計算邏輯的調度執行。
根據以上架構，Flink on YARN實現了2種不同的部署運行模式Per-Job和Session（用戶使用文檔Flink on Yarn）。
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的隔離又有高效的資源利用。
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無法實現的。
前面是架構上的變化，而要實現資源按需申請，需要有協議API，這就是Resource Profile，可以描述單個算子(Operator)的CPU & Memory等的資源用量，進而RM根據這些資源請求來向底層資源管理系統申請Container來執行TM，詳細的使用文檔見Task slots and resources。
最近幾年，Kubernetes的發展迅猛，已然成為了云時代的原生操作系統，下一代的大數據計算引擎Apache Flink的部署與其融合，是否可以開辟大數據計算的新大陸？
依靠K8S自身支持Service部署的強大能力，Flink Standalone Cluster可以通過簡單的K8S: Deployment & Service或Flink Helm chart很容易的部署到K8S集群上，但同樣有類似Standalone on YARN的資源利用率低等問題，所以還是需要“原生融合”。
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)，為用戶節省資源，帶來更大的價值。
更多資訊請訪問 Apache Flink 中文社區網站
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
