作者：任春德

10年積累的成都網(wǎng)站建設(shè)、做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有銅官免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

Apache Flink作為下一代大數(shù)據(jù)計算引擎，在迅速發(fā)展強大中，其內(nèi)部架構(gòu)也在不斷優(yōu)化重構(gòu)，以適應(yīng)更多運行時環(huán)境和更大計算規(guī)模，F(xiàn)link Improvement Proposals-6重新設(shè)計了在各集群管理系統(tǒng)(Standalone/YARN/Kubernetes等)上資源調(diào)度的統(tǒng)一架構(gòu)，本文將介紹資源調(diào)度的架構(gòu)發(fā)展及其清晰分層等設(shè)計特點，YARN上per-Job和session兩種模式的實現(xiàn)，以及正在討論開發(fā)的與K8S云原生融合的詳細設(shè)計。

本文內(nèi)容如下：

• Apache Flink Standalone Cluster

• Apache Flink 與 YARN 的原生融合

• Apache Flink 與 K8S 的原生融合

• 小結(jié)

Apache Flink Standalone Cluster

如圖1，F(xiàn)link的Standalone集群部署是主從架構(gòu)，其中主JobManager(簡稱JM)負責(zé)Job的計算單元Task調(diào)度，TaskManager(簡稱TM)向JobManager匯報并負責(zé)在其內(nèi)部用線程執(zhí)行Task。

cdn.xitu.io/2019/5/6/16a8b08199dfa29c?w=2145&h=916&f=png&s=115499">
之所以是Standalone，是因為其不依賴其他底層資源調(diào)度系統(tǒng)，直接部署啟動在各自的裸機器節(jié)點上，雖然可以用一些自動化運維工具方便地部署和管理，但是存在以下幾個問題：

• 隔離：多Job運行在一個集群，可能同一TM上執(zhí)行不同Job的Task，其線程所用資源(cpu/mem)無法控制，相互影響，甚至一個Task造成整個TM的Out Of Memory，使其之上的Job都受影響；多個Job的調(diào)度也在同一個JM中，同樣存在被有問題Job影響的問題。

• 多租戶的資源用量(quota)管理：無法控制用戶的Job資源使用總量，缺乏租戶間的資源協(xié)調(diào)管理。

• 集群的可用性：雖然JM可以部署有Standby，支持High Available，但JM、TM進程缺乏被看護，難免因以上隔離等問題造成過多進程宕掉，整個集群不可用。

• 集群的可運維：版本升級，擴縮容等都需要復(fù)雜的運維操作。

為了解決以上問題，需要將Flink跑在流行成熟的資源調(diào)度系統(tǒng)上，如YARN、Kubernetes、Mesos，如何實現(xiàn)呢？

Flink 與 YARN 的原生融合

Apache Flink Standalone Cluster on YARN

簡單有效的一種部署方式是利用YARN自身支持的特性，將Flink Standalone部署到Y(jié)ARN集群上，如圖2(Apache Flink Standalone Cluster ON YARN)，

• 多個Job可以相應(yīng)地起多個YARN Application，每個app是一個standalone cluster，各自獨立運行，而且依靠YARN本身支持的cgroups等隔離手段，避免了多任務(wù)間的相互影響，隔離問題迎刃而解。

• 不同用戶的App也可以運行在不同的YARN調(diào)度隊列中，通過queue quota管理能力解決多租戶的問題。

• 同時可以利用YARN對App進程的重啟重試再調(diào)度的策略，使Flink Standalone Cluster高可用。

• 簡單的參數(shù)、配置文件修改，通過YARN的distributed cache分發(fā)Flink jar，就可以方便的升級和擴縮容。

雖然解決了以上問題，但是每個(少量)Job起一個Standalone Cluster，難以達到高效的資源利用，因為：

• Cluster的規(guī)模(多少個TM)是在啟動YARN App時參數(shù)靜態(tài)指定的，F(xiàn)link自身的編譯優(yōu)化使其較難在運行前預(yù)估資源的需求，那就難以合理化TM數(shù)量，多了資源浪費，少了影響Job執(zhí)行速度甚至無法運行。

• 每個TM擁有的資源大小也是參數(shù)靜態(tài)指定，同樣難以預(yù)估實際需要，不能針對不同的Task資源需求來動態(tài)申請不同大小的TM，只能設(shè)置相同規(guī)格大小的TM，那就難以恰好放置整數(shù)個Task，剩余的部分資源浪費。

• App的啟動(1.Submit YARN App)和Flink Job的提交(7.Submit Job)需要2階段完成，會使每個任務(wù)的提交效率低，造成集群的資源流轉(zhuǎn)率也會降低。

大規(guī)模YARN集群中Flink Job越多，資源浪費的會更可觀，成本損失越大，而且不只是on YARN存在以上問題，Standalone直接運行于其他資源調(diào)度系統(tǒng)之上，也是有相同問題，所以阿里巴巴實時計算率先在YARN實際生產(chǎn)經(jīng)驗上改進了Flink的資源利用模型，后續(xù)與社區(qū)討論設(shè)計實現(xiàn)了一套通用的架構(gòu)，適用于不同的資源調(diào)度系統(tǒng)。

FLIP-6 - Deployment and Process Model

FLIP-6全面記錄了此次部署架構(gòu)的重構(gòu)，新的模塊如圖3。類似MapReduce-1架構(gòu)向YARN+MapReduce-2的升級，將資源調(diào)度與Job計算邏輯單元(Task)的調(diào)度分成2層，使兩個模塊（系統(tǒng)）——ResourceManager(RM)和JobManager(JM)各司其職，與底層資源調(diào)度系統(tǒng)的耦合降低（只需實現(xiàn)不同plugable的ResourceManager即可），減少邏輯復(fù)雜度降低開發(fā)維護難度，優(yōu)化JM實現(xiàn)資源按Task所需申請，解決了Standalone on YARN/K8S的資源利用率低的問題，同時還有利于集群和Job規(guī)模的擴展。

• Dispatcher: 負責(zé)與Client通信接收Job的提交，生成JobManager，生命周期可跨Job。

• ResourceManager: 對接不同資源調(diào)度系統(tǒng)，實現(xiàn)資源的調(diào)度（申請/釋放），管理Container/TaskManager，同樣生命周期可跨Job。

• JobManager: 每個Job一個實例，負責(zé)Job的計算邏輯的調(diào)度執(zhí)行。

• TaskManager: 向RM注冊匯報資源情況，從JM接收Task執(zhí)行并匯報狀態(tài)。

Apache Flink與YARN的原生融合

根據(jù)以上架構(gòu)，F(xiàn)link on YARN實現(xiàn)了2種不同的部署運行模式Per-Job和Session（用戶使用文檔Flink on Yarn）。

Per-Job

Per-Job即一個Flink Job與其YARN Application(App)生命周期綁定，執(zhí)行過程如圖4，在提交YARN App時同時將Flink Job的file/jars通過YARN Distributed Cache分發(fā)，一次性完成提交，而且JM是根據(jù)JobGraph產(chǎn)生的Task的資源實際需求來向RM申請slot執(zhí)行，F(xiàn)link RM再動態(tài)的申請/釋放YARN的Container。完美(?)解決了之前的所有問題，既利用了YARN的隔離又有高效的資源利用。

Session

Per-Job完美？No，還是存在局限，YARN App的提交時資源申請和啟動TM的時間較長(秒級)，尤其在交互式分析短查詢等場景上，Job計算邏輯執(zhí)行時間很短，那么App的啟動時間占比大就嚴重影響了端到端的用戶體驗，缺少了Standalone模式上Job提交快的優(yōu)點。但FLIP-6架構(gòu)的威力，還是能輕松化解這個問題，如圖5，通過預(yù)啟動的YARN App來跑一個Flink Session（Master和多個TM已啟動，類似Standalone可運行多個Job），再提交執(zhí)行Job，這些Job就可以很快利用已有的資源來執(zhí)行計算。Blink分支與Master具體實現(xiàn)有點不同（是否預(yù)起TM），后續(xù)會合并統(tǒng)一，并且繼續(xù)開發(fā)實現(xiàn)Session的資源彈性——按需自動擴縮TM數(shù)量，這點是standalone無法實現(xiàn)的。

Resource Profile

前面是架構(gòu)上的變化，而要實現(xiàn)資源按需申請，需要有協(xié)議API，這就是Resource Profile，可以描述單個算子(Operator)的CPU & Memory等的資源用量，進而RM根據(jù)這些資源請求來向底層資源管理系統(tǒng)申請Container來執(zhí)行TM，詳細的使用文檔見Task slots and resources。

Flink 與 Kubernetes 的原生融合

最近幾年，Kubernetes的發(fā)展迅猛，已然成為了云時代的原生操作系統(tǒng)，下一代的大數(shù)據(jù)計算引擎Apache Flink的部署與其融合，是否可以開辟大數(shù)據(jù)計算的新大陸？

Apache Flink Standalone Cluster on Kubernetes

依靠K8S自身支持Service部署的強大能力，F(xiàn)link Standalone Cluster可以通過簡單的K8S: Deployment & Service或Flink Helm chart很容易的部署到K8S集群上，但同樣有類似Standalone on YARN的資源利用率低等問題，所以還是需要“原生融合”。

Apache Flink 和 Kubernetes 的原生融合

Flink與K8S的“原生融合”，主要是在FLIP-6架構(gòu)上實現(xiàn)K8SResourceManager來對接Kubernetes的資源調(diào)度協(xié)議，現(xiàn)Blink的分支實現(xiàn)架構(gòu)下圖所示，用戶使用文檔見Flink on K8S，merge到主干Master上的工作正在進行中

小結(jié)

部署管理、資源調(diào)度是大數(shù)據(jù)處理系統(tǒng)的底層基石，通過FLIP-6的抽象分層和重構(gòu)，Apache Flink構(gòu)建了牢固的基礎(chǔ)，可以“原生”地運行于各大資源調(diào)度系統(tǒng)（YARN/Kubernetes/Mesos）上，支撐起更大規(guī)模更高并發(fā)的計算，高效地利用集群資源，為后續(xù)的不斷發(fā)展強大提供了可靠的保障。
相關(guān)功能的優(yōu)化改進依然在繼續(xù)，如Resource Profile配置資源的難度使一些開發(fā)者望而生畏，并且嚴重降低了Flink的易用性，我們在嘗試實現(xiàn)資源和并發(fā)配置的Auto Config/Scaling等功能來解決此類問題；“Serverless”架構(gòu)在迅速發(fā)展，期待Flink與Kubernetes的融合成為云原生的強大計算引擎(類FaaS)，為用戶節(jié)省資源，帶來更大的價值。

更多資訊請訪問 Apache Flink 中文社區(qū)網(wǎng)站

本文題目：DeployApacheFlinkNativelyonYARN/Kubernetes
URL鏈接：http://www.rwnh.cn/article28/jepjjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、外貿(mào)建站、域名注冊、建站公司、關(guān)鍵詞優(yōu)化、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)