DeployApacheFlinkNativelyonYARN/Kubernetes

作者：任春德

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

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

本文內(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(簡(jiǎn)稱JM)負(fù)責(zé)Job的計(jì)算單元Task調(diào)度，TaskManager(簡(jiǎn)稱TM)向JobManager匯報(bào)并負(fù)責(zé)在其內(nèi)部用線程執(zhí)行Task。

cdn.xitu.io/2019/5/6/16a8b08199dfa29c?w=2145&h=916&f=png&s=115499">
之所以是Standalone，是因?yàn)槠洳灰蕾嚻渌讓淤Y源調(diào)度系統(tǒng)，直接部署啟動(dòng)在各自的裸機(jī)器節(jié)點(diǎn)上，雖然可以用一些自動(dòng)化運(yùn)維工具方便地部署和管理，但是存在以下幾個(gè)問題：

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

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

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

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

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

Flink 與 YARN 的原生融合

Apache Flink Standalone Cluster on YARN

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

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

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

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

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

雖然解決了以上問題，但是每個(gè)(少量)Job起一個(gè)Standalone Cluster，難以達(dá)到高效的資源利用，因?yàn)椋?/p>

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

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

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

大規(guī)模YARN集群中Flink Job越多，資源浪費(fèi)的會(huì)更可觀，成本損失越大，而且不只是on YARN存在以上問題，Standalone直接運(yùn)行于其他資源調(diào)度系統(tǒng)之上，也是有相同問題，所以阿里巴巴實(shí)時(shí)計(jì)算率先在YARN實(shí)際生產(chǎn)經(jīng)驗(yàn)上改進(jìn)了Flink的資源利用模型，后續(xù)與社區(qū)討論設(shè)計(jì)實(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的升級(jí)，將資源調(diào)度與Job計(jì)算邏輯單元(Task)的調(diào)度分成2層，使兩個(gè)模塊（系統(tǒng)）——ResourceManager(RM)和JobManager(JM)各司其職，與底層資源調(diào)度系統(tǒng)的耦合降低（只需實(shí)現(xiàn)不同plugable的ResourceManager即可），減少邏輯復(fù)雜度降低開發(fā)維護(hù)難度，優(yōu)化JM實(shí)現(xiàn)資源按Task所需申請(qǐng)，解決了Standalone on YARN/K8S的資源利用率低的問題，同時(shí)還有利于集群和Job規(guī)模的擴(kuò)展。

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

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

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

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

Apache Flink與YARN的原生融合

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

Per-Job

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

Session

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

Resource Profile

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

Flink 與 Kubernetes 的原生融合

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

Apache Flink Standalone Cluster on Kubernetes

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

Apache Flink 和 Kubernetes 的原生融合

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

小結(jié)

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

更多資訊請(qǐng)?jiān)L問 Apache Flink 中文社區(qū)網(wǎng)站

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

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

廣告

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