Flink 之部署篇
- 1.概述和參考架構
- 2.可重復的資源清理
- 3.部署模式
- 3.1 Application 模式
- 3.2 Per-Job 模式(已廢棄)
- 3.3 Session 模式
Flink 是一個多用途框架,支持多種不同的混合部署方案。下面,我們將簡要介紹 Flink 集群的構建模塊、它們的用途和可用實現。如果您只想在本地啟動 Flink,我們建議您建立一個獨立集群(Standalone Cluster
)。
1.概述和參考架構
下圖顯示了每個 Flink 群集的構件。總有一個客戶端在運行,它接收 Flink 應用程序的代碼,將其轉換為 JobGraph 并提交給 JobManager。
JobManager 會將工作分配給 TaskManager,實際的算子(如 sources
,transformations
和 sinks
等)就在 TaskManager 上運行。
部署 Flink 時,每個構件通常有多個可用選項。我們在下表列出了這些選項。
組件 | | |
---|---|---|
Flink Client | 將批處理或流應用程序編譯成數據流圖,然后提交給 JobManager。 | 1?? Command Line Interface 2?? REST Endpoint 3?? SQL Client 4?? Python REPL |
JobManager | JobManager 是 Flink 中央工作協調組件的名稱。它為不同的資源提供者提供不同的實現,這些實現在高可用性、資源分配行為和支持方面各不相同。 作業提交的 JobManager 模式: (1)Application 模式:專門為一個應用程序運行群集。作業的 main 方法(或客戶端)在 JobManager 上執行。支持在一個應用程序中多次調用 execute / executeAsync 。(2)Per-Job 模式:只為一個作業運行集群。作業的 main 方法(或客戶端)僅在群集創建之前運行。(3)Session 模式:一個 JobManager 實例管理多個作業,共享同一個任務管理器集群。 | 1?? Standalone(這是裸機模式,只需要啟動 JVM。在此模式下,可通過手動設置使用 Docker、Docker Swarm / Compose、 non-native Kubernetes 和其他模式進行部署) 2?? Kubernetes 3?? YARN |
TaskManager | 任務管理器是實際執行 Flink 作業的服務。 |
外部組件 | | |
---|---|---|
High Availability Service Provider | Flink 的 JobManager 可在高可用性模式下運行,這使得 Flink 能夠從 JobManager 故障中恢復。為了更快地進行故障切換,可以啟動多個備用 JobManager 作為備份。 | 1?? Zookeeper 2?? Kubernetes HA |
File Storage and Persistency | 對于檢查點(流作業的恢復機制),Flink 依賴于外部文件存儲系統 | 請參閱 “文件系統” 頁面 |
Resource Provider | Flink 可通過不同的資源提供者框架(如 Kubernetes 或 YARN)進行部署。 | 參見上文的 JobManager 實現。 |
Metrics Storage | Flink 組件可報告內部指標,Flink 作業也可報告額外的特定作業指標。 | 請參閱 “指標報告器” 頁面 |
Application-level data sources and sinks | 雖然從技術上講,應用級數據源和匯并不是 Flink 群集組件部署的一部分,但在規劃新的 Flink 生產部署時,應考慮到這一點。將常用數據與 Flink 同地放置可帶來顯著的性能優勢。 | 例如: 1?? Apache Kafka 2?? Amazon S3 3?? Elasticsearch 4?? Apache Cassandra 請參閱 “連接器” 頁面 |
2.可重復的資源清理
一旦作業達到 完成、失敗 或 取消 的全局終端狀態,與作業相關的外部組件資源就會被清理。如果資源清理失敗,Flink 會嘗試重試清理。您可以配置所使用的重試策略。重試次數達到最大值而不成功,會使作業處于臟狀態。其工件需要手動清理(更多詳情,請參閱 High Availability Services / JobResultStore 部分)。重新啟動相同的作業(即使用相同的作業 ID)將導致清理工作被重新啟動,而不會再次運行作業。
3.部署模式
Flink 的部署模式有 Application
、Per-Job
和 Session
模式。三者的主要區別:
- 1?? 集群與作業的生命周期是否一致。
- 2?? 資源的隔離程度。
- 3?? 作業的
mian()
運行在 Client 還是集群上。
3.1 Application 模式
- 將啟動一個專用的 JobManager 來提交作業。JobManager 將只執行此作業,然后退出。Flink 應用程序在 JobManager 上運行。
- 作業與 Flink 集群打包在一起,在 JobManager 啟動的時候會執行作業的
main
函數直接啟動作業,而不需要通過 Flink Client 提交作業。 - 作業的生命周期與 Flink 集群的一致,即作業關閉后 Flink 集群也會關閉。
在所有其他模式下,應用程序的 main()
方法都在客戶端執行。這一過程包括在本地下載應用程序的依賴項,執行 main()
以提取 Flink 運行時可以理解的應用程序表示(即 JobGraph),并將依賴項和 JobGraph 發送到集群。這就使客戶端成為資源消耗大戶,因為它可能需要大量網絡帶寬來下載依賴項并將二進制文件發送到集群,還需要 CPU 周期來執行 main()
。當客戶端被多個用戶共享時,這一問題會更加突出。
在此基礎上,Application
模式為每個提交的應用程序創建一個集群,但這次應用程序的 main()
方法由 JobManager 執行。為每個應用程序創建一個集群可視為創建一個會話集群,僅在特定應用程序的作業之間共享,并在應用程序結束時關閉。通過這種架構,應用程序模式可提供與 Per-Job
模式相同的資源隔離和負載平衡保證,但其粒度為整個應用程序。
應用程序模式基于這樣一個假設:所有需要訪問用戶 jars
的 Flink 組件(JobManager、TaskManager)的類路徑(usrlib
文件夾)上都有用戶 jars
。換句話說,您的應用程序與 Flink 發行版捆綁在一起。這樣,Application
模式就不必像其他部署模式那樣通過 RPC 向 Flink 組件分發用戶 jars
,從而加快了部署 / 恢復過程。
Application 模式假定用戶
jars
與 Flink 發行版捆綁在一起。在集群上執行main()
方法可能會對您的代碼產生其他影響,例如您使用registerCachedFile()
在環境中注冊的任何路徑都必須能被應用程序的 JobManager 訪問。
與 Per-Job
(已廢棄)模式相比,Application
模式允許提交由多個作業組成的應用程序。作業的執行順序不受部署模式的影響,但受用于啟動作業的調用的影響。execute()
是阻塞式的,它會建立一個順序,并導致 “下一個” 作業的執行被推遲,直到 “這個” 作業完成。使用 executeAsync()
(非阻塞)會導致 “下一個” 作業在 “這個” 作業完成前開始執行。
應用模式允許
multi-execute()
應用,但在這種情況下不支持高可用性。應用模式下的高可用性僅支持single-execute()
應用程序。此外,當應用程序模式下多個正在運行的作業(例如使用executeAsync()
提交的作業)中的任何一個被取消時,所有作業都將停止,而 JobManager 也將關閉。支持常規作業完成(通過源關閉)。
3.2 Per-Job 模式(已廢棄)
- 將啟動一個專用的 JobManager 來提交作業。JobManager 將只執行此作業,然后退出。Flink 應用程序在提交每個作業集群的客戶端上運行。
- 作業與 Flink 集群不是打包在一起,在 JobManager 啟動后需要通過 Flink Client 提交作業,即增加了網絡傳輸的壓力和客戶端的 CPU 資源。
Per-Job
模式僅受 YARN 支持,在 Flink1.15
中已被棄用。它將在 FLINK-26000 中被棄用。請考慮使用Application
模式在 YARN 上按任務啟動專用集群。
為了提供更好的資源隔離保證,Per-Job
模式使用可用的資源提供者框架(如 YARN)為每個提交的作業啟動一個集群。該集群只對該作業可用。當作業完成后,集群會被拆除,任何殘留的資源(文件等)都會被清除。這提供了更好的資源隔離,因為行為不端的作業只能導致其自身的 TaskManager 宕機。此外,由于每個作業都有一個 TaskManager,它還能將記賬的負擔分散到多個 TaskManager 中。
🚀
Application
模式對比Per-Job
模式最大的區別是,前者使用executeAsync()
提交作業(不阻塞),而后者使用execute()
提交作業(阻塞),因此Application
模式可以運行多個作業。
3.3 Session 模式
- 多個作業共享一個 JobManager。
- 常駐的 JobManager,多個作業共享同一個集群。如果其中一個作業異常導致 TaskManager 關閉,則該 TM 上的全部作業都會重新調度。
Session 模式假定有一個已在運行的集群,并使用該集群的資源來執行任何已提交的應用程序。在同一(Session)集群中執行的應用程序使用相同的資源,因此也會競爭相同的資源。這樣做的好處是,您無需為每個提交的作業支付啟動整個群集的資源開銷。但是,如果其中一個作業出現問題或導致 TaskManager 宕機,那么在該 TaskManager 上運行的所有作業都會受到故障影響。這除了會對導致故障的作業造成負面影響外,還意味著所有重新啟動的作業都會同時訪問文件系統,從而導致其他服務無法使用文件系統,這就意味著潛在的大規模恢復過程。此外,單個集群運行多個作業意味著 JobManager 要承擔更多的負荷,因為它要負責管理群集中的所有作業。