傳統部署模式 Session模式 Session模式是預分配資源的，也就是提前根據指定的資源參數初始化一個Flink集群，并常駐在YARN系統中，擁有固定數量的JobManager和TaskManager（注意JobManager只有一個）。提交到這個集群的作業可以直接運行，免去每次分配資源的overhead。但是Session的資源總量有限，多個作業之間又不是隔離的，故可能會造成資源的爭用；如果有一個TaskManager宕機，它上面承載著的所有作業也都會失敗。另外，啟動的作業越多，JobManager的負載也就越大。所以，Session模式一般用來部署那些對延遲非常敏感但運行時長較短的作業。Per-Job模式 顧名思義，在Per-Job模式下，每個提交到YARN上的作業會各自形成單獨的Flink集群，擁有專屬的JobManager和TaskManager。可見，以Per-Job模式提交作業的啟動延遲可能會較高，但是作業之間的資源完全隔離，一個作業的TaskManager失敗不會影響其他作業的運行，JobManager的負載也是分散開來的，不存在單點問題。當作業運行完成，與它關聯的集群也就被銷毀，資源被釋放。所以，Per-Job模式一般用來部署那些長時間運行的作業。

Deployer代表向YARN集群發起部署請求的節點，一般來講在生產環境中，也總有這樣一個節點作為所有作業的提交入口（即客戶端）。在main()方法開始執行直到env.execute()方法之前，客戶端也需要做一些工作，即：獲取作業所需的依賴項； 通過執行環境分析并取得邏輯計劃，即StreamGraph→JobGraph； 將依賴項和JobGraph上傳到集群中。 只有在這些都完成之后，才會通過env.execute()方法觸發Flink運行時真正地開始執行作業。試想，如果所有用戶都在Deployer上提交作業，較大的依賴會消耗更多的帶寬，而較復雜的作業邏輯翻譯成JobGraph也需要吃掉更多的CPU和內存，客戶端的資源反而會成為瓶頸—— 不管Session還是Per-Job模式都存在此問題。為了解決它，社區在傳統部署模式的基礎上實現了Application模式。

Application模式
此模式下的作業提交框圖如下。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。