Flink的部署模式session 、pre job、aplication
生活随笔
收集整理的這篇文章主要介紹了
Flink的部署模式session 、pre job、aplication
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
傳統(tǒng)部署模式
Session模式
Session模式是預(yù)分配資源的,也就是提前根據(jù)指定的資源參數(shù)初始化一個(gè)Flink集群,并常駐在YARN系統(tǒng)中,擁有固定數(shù)量的JobManager和TaskManager(注意JobManager只有一個(gè))。提交到這個(gè)集群的作業(yè)可以直接運(yùn)行,免去每次分配資源的overhead。但是Session的資源總量有限,多個(gè)作業(yè)之間又不是隔離的,故可能會(huì)造成資源的爭用;如果有一個(gè)TaskManager宕機(jī),它上面承載著的所有作業(yè)也都會(huì)失敗。另外,啟動(dòng)的作業(yè)越多,JobManager的負(fù)載也就越大。所以,Session模式一般用來部署那些對延遲非常敏感但運(yùn)行時(shí)長較短的作業(yè)。Per-Job模式
顧名思義,在Per-Job模式下,每個(gè)提交到Y(jié)ARN上的作業(yè)會(huì)各自形成單獨(dú)的Flink集群,擁有專屬的JobManager和TaskManager。可見,以Per-Job模式提交作業(yè)的啟動(dòng)延遲可能會(huì)較高,但是作業(yè)之間的資源完全隔離,一個(gè)作業(yè)的TaskManager失敗不會(huì)影響其他作業(yè)的運(yùn)行,JobManager的負(fù)載也是分散開來的,不存在單點(diǎn)問題。當(dāng)作業(yè)運(yùn)行完成,與它關(guān)聯(lián)的集群也就被銷毀,資源被釋放。所以,Per-Job模式一般用來部署那些長時(shí)間運(yùn)行的作業(yè)。
Deployer代表向YARN集群發(fā)起部署請求的節(jié)點(diǎn),一般來講在生產(chǎn)環(huán)境中,也總有這樣一個(gè)節(jié)點(diǎn)作為所有作業(yè)的提交入口(即客戶端)。在main()方法開始執(zhí)行直到env.execute()方法之前,客戶端也需要做一些工作,即:獲取作業(yè)所需的依賴項(xiàng);
通過執(zhí)行環(huán)境分析并取得邏輯計(jì)劃,即StreamGraph→JobGraph;
將依賴項(xiàng)和JobGraph上傳到集群中。
只有在這些都完成之后,才會(huì)通過env.execute()方法觸發(fā)Flink運(yùn)行時(shí)真正地開始執(zhí)行作業(yè)。試想,如果所有用戶都在Deployer上提交作業(yè),較大的依賴會(huì)消耗更多的帶寬,而較復(fù)雜的作業(yè)邏輯翻譯成JobGraph也需要吃掉更多的CPU和內(nèi)存,客戶端的資源反而會(huì)成為瓶頸——
不管Session還是Per-Job模式都存在此問題。為了解決它,社區(qū)在傳統(tǒng)部署模式的基礎(chǔ)上實(shí)現(xiàn)了Application模式。
Application模式
此模式下的作業(yè)提交框圖如下。
參考:
https://blog.csdn.net/xuye0606/article/details/119619065
總結(jié)
以上是生活随笔為你收集整理的Flink的部署模式session 、pre job、aplication的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 两电平直接转矩控制MATLAB,基于MA
- 下一篇: Robust Initializatio