傳統(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è)提交框圖如下。

可見，原本需要客戶端做的三件事被轉(zhuǎn)移到了JobManager里，也就是說main()方法在集群中執(zhí)行（入口點(diǎn)位于ApplicationClusterEntryPoint），Deployer只需要負(fù)責(zé)發(fā)起部署請求了。另外，如果一個(gè)main()方法中有多個(gè)env.execute()/executeAsync()調(diào)用，在Application模式下，這些作業(yè)會(huì)被視為屬于同一個(gè)應(yīng)用，在同一個(gè)集群中執(zhí)行（如果在Per-Job模式下，就會(huì)啟動(dòng)多個(gè)集群）。可見，Application模式本質(zhì)上是Session和Per-Job模式的折衷。

參考：
https://blog.csdn.net/xuye0606/article/details/119619065

總結(jié)

以上是生活随笔為你收集整理的Flink的部署模式session 、pre job、aplication的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。