前言

Flink 是一個多功能框架惨缆，能夠以組合形式適配許多不同的部署場景辟灰。
在接下來的文章中岔冀，我們大致介紹了 Flink 集群的組成部分凯旭，它們的作用以及不同的實現(xiàn)方法。

1使套、架構總覽

下圖展示了 Flink 集群的組成架構罐呼。

Flink 架構總覽

• client：處理 Flink 應用代碼，將代碼轉換成 JobGraph 形式然后提交給 JobManager
• JobManager：分發(fā)工作童漩，將各 Job 的任務分發(fā)給各個 TaskManager
• TaskManager：真正處理工作的組件弄贿，運行 sources、transformations 以及 sinks 等算子

在實際部署 Flink 的過程中矫膨，通常每個組件都有多種實現(xiàn)差凹，我們會在后文中進行介紹。

2侧馅、Flink 固有組件

2.1 Flink Client

2.1.1 作用

• 將批處理或者流處理應用編譯成 dataflow graph
• 將 JobGraph 提交給 JobManager

2.1.2 實現(xiàn)

• Command Line Interface
• REST Endpoint
• SQL Client
• Python REPL
• Scala REPL

2.2 JobManager

2.2.1 作用

JobManager 被稱為 Flink 的中心工作調度組件危尿。根據(jù)資源提供商的不同，在 HA馁痴、資源分配以及不同作業(yè)提交模式的支持性方面均有不同的實現(xiàn)方法谊娇。
相關進程從功能上可以分為以下3類：

• ResourceManager：負責 Flink 集群中的資源（即：task slots，集群資源調度的基本單元）調配工作罗晕。僅能調度已有的 slots济欢，無法自己啟動新的 TaskManagers。
• Dispatcher：提供一個 REST 風格的接口用以提交 Flink 應用的執(zhí)行請求小渊。為每個提交過來的 job 啟動一個 JobMaster 進程法褥。同時提供 Flink WebUI 用以提供集群中 job 的執(zhí)行情況。
• JobMaster：負責管理單個 JobGraph 的執(zhí)行過程酬屉。同一個集群中可以同時運行多個 job半等，每個 job 都有自己的 JobMaster。

Flink 集群中至少會有一個 JobManager呐萨，如果開啟了高可用模式杀饵，則會有多個，其中一個是 leader谬擦，其他的是 standby 狀態(tài)切距。

根據(jù)不同的作業(yè)提交模式，JobManager 可以分為以下三種模式：

• Application Mode：單集群只跑單應用惨远。job 的 main 方法在 JobManagers 上執(zhí)行谜悟，且支持多次調用應用的 execute/executeAsync 接口
• Per-Job Mode：單集群只跑單 job饵沧。job 的 main 方法在 client 端執(zhí)行
• Session Mode：一個集群運行多個應用，各應用的 jobs 共享集群資源

2.2.2 實現(xiàn)

• Standalone (this is the barebone mode that requires just JVMs to be launched. Deployment with Docker, Docker Swarm / Compose, non-native Kubernetes and other models is possible through manual setup in this mode)
• Kubernetes
• YARN
• Mesos

2.3 TaskManager

2.3.1 作用

TaskManager 又被稱為 workers赌躺，每個 TaskManager 其實就是一個 JVM 進程，通過不同線程處理不同的子任務羡儿，對數(shù)據(jù)流中的數(shù)據(jù)執(zhí)行各種算子礼患、緩存并交換數(shù)據(jù)流。
集群中最少要有一個 TaskManager掠归，TaskManager 中最小的調度單元被稱為 task slot缅叠，TaskManager 中的 task slot 數(shù)量體現(xiàn)了可以同時處理 task 的數(shù)量，默認情況下一個 TaskManager 進程有一個 job slot虏冻，通過配置 taskmanager.numberOfTaskSlots可以設置更多的 job slot肤粱。注意，同一個 task slot 中可能會執(zhí)行多個算子厨相。

關于 Tasks 與 算子鏈
為實現(xiàn)分布式執(zhí)行领曼，F(xiàn)link 會將算子的 subtasks 鏈接成 task，每個 task 都用一個線程來執(zhí)行蛮穿。這是一個很有用的策略：它減少了線程之間切換和緩沖的開銷庶骄，在降低延遲的同時提高了整體吞吐量。鏈接行為是可以配置的践磅，詳情點此单刁。

3、Flink 外部組件

3.1 HA 服務提供商

Flink 的 JobManager 組件可以以 HA 模式運行府适，該模式允許 Flink 能夠從 JobManager 故障中自動恢復羔飞。為了保證更快的故障恢復，會啟動多個備份 JobManager 實例檐春，隨時做好準備逻淌。
目前已有下面兩種實現(xiàn)：

• Zookeeper
• Kubernetes HA

3.2 文件存儲及持久性實現(xiàn)

Flink 依賴外部文件存儲系統(tǒng)來實現(xiàn)其 checkpoint 機制，即：流式作業(yè)的恢復機制喇聊，詳見 FileSystems恍风。

3.3 資源提供商

Flink 可以部署到多種資源提供商平臺，如：Kubernetes誓篱、YARN 以及 Mesos朋贬。
各平臺具體實現(xiàn)參考 JobManager。

3.4 指標存儲

Flink 各組件報告指標窜骄，且 Flink job 還會額外報告 job 本身特有的指標锦募。
詳見 Metrics Reporter。

3.5 應用數(shù)據(jù) Sources 以及 Sinks

Sources：數(shù)據(jù)來源邻遏，如文件糠亩、目錄虐骑、sockets 等
Sinks：Flink 生成數(shù)據(jù)去向，如寫入文件赎线、打印到標準輸出或者 sockets 等

嚴格意義上來說廷没，在部署 Flink 集群時，應用數(shù)據(jù)的 Sources 以及 Sinks 并不屬于任何組件垂寥，而是在設計新 Flink 生產集群之初就要考慮進去的颠黎。將常用數(shù)據(jù)與 Flink 合并可以獲得顯著的性能優(yōu)勢。

3.5.1 常用的 Sources 以及 Sinks：

• Apache Kafka (source/sink)
• Apache Cassandra (sink)
• Amazon Kinesis Streams (source/sink)
• Elasticsearch (sink)
• FileSystem (Hadoop included) - Streaming only (sink)
• FileSystem (Hadoop included) - Streaming and Batch (sink)
• RabbitMQ (source/sink)
• Apache NiFi (source/sink)
• Twitter Streaming API (source)
• Google PubSub (source/sink)
• JDBC (sink)

詳見 Connectors滞项。

4狭归、部署模式

Flink 可以通過以下三種方法來運行應用：

• Application Mode
• Per-Job Mode
• Session Mode

不同之處在于：

• 集群生命周期以及資源隔離保障
• 應用main方法的執(zhí)行位置：在 client 端還是在集群中

Flink 部署模式

4.1 Application Mode

在其他運行模式中，應用的main方法都是在 client 端執(zhí)行的文判，執(zhí)行過程包括本地下載應用的依賴过椎、執(zhí)行main方法并將應用轉換成 Flink 運行時可以理解的形式（如： JobGraph），然后將依賴以及 JobGraph 提交給集群戏仓。這個過程需要大量的寬帶來完成依賴下載以及二進制文件的提交工作疚宇，同時需要 CPU 來執(zhí)行main方法，使得 Client 成為了一個資源消耗大頭赏殃，當 Client 被多個用戶共享時灰嫉，這個問題將變得尤其明顯。

基于上述問題的考慮嗓奢，Application Mode 采取了不同的處理機制讼撒，在此模式下，F(xiàn)link 會為每個應用創(chuàng)建一個集群股耽，并且選擇在 JobManager 上運行該應用的main方法根盒。新創(chuàng)建的集群資源，只會被同一個應用的 job 共享使用物蝙，并且當應用執(zhí)行結束時炎滞，集群也會隨之被釋放。通過這種架構诬乞，用戶能夠像 Per-Job Mode 一樣實現(xiàn)資源隔離以及負載均衡册赛，當然是從應用的粒度來說。

把應用main方法的執(zhí)行過程放到 JobManager 上可以節(jié)省 CPU震嫉，也減少了本地下載依賴的寬帶開銷森瘪。同時，由于本應用所有 Job 都共享一個 JobManager票堵，集群在下載應用程序的依賴項時扼睬，可以更均勻地平衡網絡負載。

注意：由于 Application Mode 將main方法的執(zhí)行過程安排在集群里而不是 client 端悴势，這可能會對應用的代碼有影響窗宇。舉個例子措伐，代碼中使用registerCachedFile()方法注冊的所有路徑，都必須能夠被本應用所屬集群的 JobManager 訪問军俊。

相比于 Per-Job Mode侥加，Application Mode 允許 client 提交包含多個 jobs 的應用。應用中各 job 的執(zhí)行順序由該 job 的觸發(fā)方式決定粪躬。如果使用execute()方法觸發(fā) job官硝，執(zhí)行過程會阻塞，只有上一個 job 完成后短蜕，下一個 job 才會被執(zhí)行到。如果使用executeAsync()方法觸發(fā) job傻咖，執(zhí)行過程不會阻塞朋魔，不管上一個 job 是否已完成，這個 job 都會開始執(zhí)行卿操。

注意：當應用中包含多個 job 時警检，集群將不支持 HA

4.2 Per-Job Mode

Per-Job Mode 利用 YARN、Kubernetes 這樣的資源提供框架為每個 client 提交的 job 創(chuàng)建一個集群害淤，以實現(xiàn)更好的資源隔離機制扇雕。創(chuàng)建的集群，僅限該 job 使用窥摄，當 job 執(zhí)行完成后镶奉，集群就會被釋放，包括所有的資源（文件等）崭放。這種情況下哨苛，job 執(zhí)行異常時，破壞的也僅僅是它自己的 TaskManagers币砂，可以帶來更好的資源隔離體驗建峭。除此之外，由于每個 job 的集群是獨立的决摧，JobManagers 之間的 book-keeping 負載開銷也更均衡亿蒸。也正是由于這些原因，Per-Job 模式下的資源分配模型更加受許多生產環(huán)境實施的喜愛掌桩。

4.3 Session Mode

Session Mode 假設已經有一個運行的集群边锁，并且使用該集群的資源來執(zhí)行所有提交的應用。
集群中應用共享集群資源波岛，并因此產生競態(tài)砚蓬，這樣做的好處是，你不必費力為每個提交的 job 創(chuàng)建集群盆色，但是灰蛙，如果某個 job 執(zhí)行異乘钐蓿或者損壞了某個 TaskManager，該 TaskManager 上運行的其他所有 job 也會受影響摩梧，因此除了那個執(zhí)行異常的 job 受影響之外物延，通常還意味著出現(xiàn)大規(guī)模的恢復過程，所有重啟的 job 都會讀取文件系統(tǒng)仅父，造成其他服務無法訪問叛薯。除此之外，在單集群中運行多個 job 會給 JobManager 帶來更高的負載笙纤，因為它需要 book-keeping 集群中所有的 job耗溜。

4.4 總結

Session Mode 模式 Flink 集群的生命周期跟集群中運行的 job 無關，是獨立運行的省容，集群資源被所有 job 共享抖拴。
Per-Job 模式為了提供更好的資源隔離體驗，犧牲精力為每個提交的 job 創(chuàng)建集群腥椒，因此阿宅，集群的生命周期是與一個個的 job 綁定在一起的。
Application 模式為每個應用創(chuàng)建一個會話集群笼蛛，并且在集群里執(zhí)行該應用的main方法洒放。