Flink是新的stream計算引擎，用java實現(xiàn)。既可以處理stream data也可以處理batch data，可以同時兼顧Spark以及Spark streaming的功能，與Spark不同的是，Flink本質上只有stream的概念，batch被認為是special stream。Flink在運行中主要有三個組件組成，JobClient，JobManager 和 TaskManager。主要工作原理如下圖 ??

用戶首先提交Flink程序到JobClient，經過JobClient的處理、解析、優(yōu)化提交到JobManager，最后由TaskManager運行task。

JobClient
JobClient是Flink程序和JobManager交互的橋梁，主要負責接收程序、解析程序的執(zhí)行計劃、優(yōu)化程序的執(zhí)行計劃，然后提交執(zhí)行計劃到JobManager。為了了解Flink的解析過程，需要簡單介紹一下Flink的Operator，在Flink主要有三類Operator，

Source Operator ，顧名思義這類操作一般是數(shù)據(jù)來源操作，比如文件、socket、kafka等，一般存在于程序的最開始
Transformation Operator 這類操作主要負責數(shù)據(jù)轉換，map，flatMap，reduce等算子都屬于Transformation Operator，
Sink Operator，意思是下沉操作，這類操作一般是數(shù)據(jù)落地，數(shù)據(jù)存儲的過程，放在Job最后，比如數(shù)據(jù)落地到Hdfs、Mysql、Kafka等等。?
Flink會將程序中每一個算計解析成Operator，然后按照算子之間的關系，將operator組合起來，形成一個Operator組合成的Graph。如下面的代碼解析之后形成的執(zhí)行計劃，
DataStream<String> data = env.addSource(...);
data.map(x->new Tuple2(x,1)).keyBy(0).timeWindow(Time.seconds(60)).sum(1).addSink(...)

解析形成執(zhí)行計劃之后，JobClient的任務還沒有完，還負責執(zhí)行計劃的優(yōu)化，這里執(zhí)行的主要優(yōu)化是將相鄰的Operator融合，形成OperatorChain，因為Flink是分布式運行的，程序中每一個算子，在實際執(zhí)行中被分隔為多個SubTask，數(shù)據(jù)流在算子之間的流動，就對應到SubTask之間的數(shù)據(jù)傳遞，SubTask之間進行數(shù)據(jù)傳遞模式有兩種一種是one-to-one的，數(shù)據(jù)不需要重新分布，也就是數(shù)據(jù)不需要經過IO，節(jié)點本地就能完成，比如上圖中的source到map，一種是re-distributed，數(shù)據(jù)需要通過shuffle過程重新分區(qū)，需要經過IO，比如上圖中的map到keyBy。顯然re-distributed這種模式更加浪費時間，同時影響整個Job的性能。所以，Flink為了提高性能，將one-to-one關系的前后兩類subtask，融合形成一個task。而TaskManager中一個task運行一個獨立的線程中，同一個線程中的SubTask進行數(shù)據(jù)傳遞，不需要經過IO，不需要經過序列化，直接發(fā)送數(shù)據(jù)對象到下一個SubTask，性能得到提升，除此之外，subTask的融合可以減少task的數(shù)量，提高taskManager的資源利用率。圖1.0中的執(zhí)行計劃，優(yōu)化結果如下圖，Flink的subTask融合規(guī)則可以參考官方文檔。
值得注意的是，并不是每一個SubTask都可以被融合，對于不能融合的SubTask會獨立形成一個Task運行在TaskManager中。
改變operator的并行度，可能會導致不同的優(yōu)化結果，同時這也是性能調優(yōu)的一個重要方式，例如不顯式設置operator的并行度的時候，默認所有算子的并行度是一樣的，所以會有下圖中的優(yōu)化結果。

我們來分析一下默認情況下可能發(fā)生的問題，假如設置作業(yè)的并行度為10，source明確為kafka，對應topic只有一個topic，因為source默認會根據(jù)topic的分區(qū)數(shù)，決定自己的分區(qū)數(shù)，那么10個source subtask只有一個會工作，而且任務比較重。這樣會導致后面的map實際也是有一個subTask在工作，處理所有的數(shù)據(jù)，假如map中的任務比較重，那么會導致數(shù)據(jù)傾斜，性能低下。在source不能改造的情況下，我們顯式減少source的并行度（為了節(jié)省資源，設置1），提高map的并行度（增加處理速度，設為20）。第一眼看上去，感覺性能提升了不少，但是在實際情況中卻不一定這樣。因為調整source和map的并發(fā)度， 失去了原有one-to-one數(shù)據(jù)傳遞的優(yōu)勢，導致subTask不能融合，數(shù)據(jù)需要reblance，產生大量的IO，所以修改并行度也不一定可以提升性能。修改并行度之后，執(zhí)行計劃的優(yōu)化結果如下圖。所以在實際優(yōu)化的過程中，還是要注意結合數(shù)據(jù)分布和執(zhí)行計劃調優(yōu)，理解Flink執(zhí)行計劃的生成過程很有必要。

JobManager
JobManager是一個進程，主要負責申請資源，協(xié)調以及控制整個job的執(zhí)行過程，具體包括，調度任務、處理checkpoint、容錯等等，在接收到JobClient提交的執(zhí)行計劃之后，針對收到的執(zhí)行計劃，繼續(xù)解析，因為JobClient只是形成一個operaor層面的執(zhí)行計劃，所以JobManager繼續(xù)解析執(zhí)行計劃（根據(jù)算子的并發(fā)度，劃分task），形成一個可以被實際調度的由task組成的拓撲圖，如上圖被解析之后形成下圖的執(zhí)行計劃，最后向集群申請資源，一旦資源就緒，就調度task到TaskManager。

為了保證高可用，一般會有多個JobManager進程同時存在，它們之間也是采用主從模式，一個進程被選舉為Leader，其他進程為follower。Job運行期間，只有Leader在工作，follower在閑置，一旦Leader掛掉，隨即引發(fā)一次選舉，產生新的Leader繼續(xù)處理Job。JobManager除了調度任務，另外一個主要工作就是容錯，主要依靠checkpoint進行容錯，checkpoint其實是stream以及executor（TaskManager中的Slot）的快照，一般將checkpoint保存在可靠的存儲中（比如hdfs），為了容錯Flink會持續(xù)建立這類快照。當Flink作業(yè)重新啟動的時候，會尋找最新可用的checkpoint來恢復執(zhí)行狀態(tài)，已達到數(shù)據(jù)不丟失，不重復，準確被處理一次的語義。一般情況下，都不會用到checkpoint，只有在數(shù)據(jù)需要積累或處理歷史狀態(tài)的時候，才需要設定checkpoint，比如updateStateByKey這個算子，默認會啟用checkpoint，如果沒有配置checkpoint目錄的話，程序會拋異常。

TaskManager
TaskManager是一個進程，及一個JVM（Flink用java實現(xiàn)）。主要作用是接收并執(zhí)行JobManager發(fā)送的task，并且與JobManager通信，反饋任務狀態(tài)信息，比如任務分執(zhí)行中，執(zhí)行完等狀態(tài)，上文提到的checkpoint的部分信息也是TaskManager反饋給JobManager的。如果說JobManager是master的話，那么TaskManager就是worker主要用來執(zhí)行任務。在TaskManager內可以運行多個task。多個task運行在一個JVM內有幾個好處，首先task可以通過多路復用的方式TCP連接，其次task可以共享節(jié)點之間的心跳信息，減少了網絡傳輸。TaskManager并不是最細粒度的概念，每個TaskManager像一個容器一樣，包含一個多或多個Slot，如圖1.2。

Slot是TaskManager資源粒度的劃分，每個Slot都有自己獨立的內存。所有Slot平均分配TaskManger的內存，比如TaskManager分配給Solt的內存為8G，兩個Slot，每個Slot的內存為4G，四個Slot，每個Slot的內存為2G，值得注意的是，Slot僅劃分內存，不涉及cpu的劃分。同時Slot是Flink中的任務執(zhí)行器（類似Storm中Executor），每個Slot可以運行多個task，而且一個task會以單獨的線程來運行。Slot主要的好處有以下幾點：
可以起到隔離內存的作用，防止多個不同job的task競爭內存。
Slot的個數(shù)就代表了一個Flink程序的最高并行度，簡化了性能調優(yōu)的過程
允許多個Task共享Slot，提升了資源利用率，舉一個實際的例子，kafka有3個partition，對應flink的source有3個task，而keyBy我們設置的并行度為20，這個時候如果Slot不能共享的話，需要占用23個Slot，如果允許共享的話，那么只需要20個Slot即可（Slot的默認共享規(guī)則計算為20個）。
共享Slot，雖然在flink中允許task共享Slot提升資源利用率，但是如果一個Slot中容納過多task反而會造成資源低下（比如極端情況下所有task都分布在一個Slot內），在Flink中task需要按照一定規(guī)則共享Slot。共享Slot的方式有兩種，SlotShardingGroup和CoLocationGroup，CoLocationGroup這種方式目前還沒有接觸過，如果感興趣可以查閱官方文檔。下面主要介紹一下SlotShardingGroup的用法，這種共享的基本思路就是給operator分組，同一組的不同operator的task，可以共享一個Slot。默認所有的operator屬于同一個組“default”，及所有operator的task可以共享一個Slot，可以給operator設置不同的group，防止不合理的共享。Flink在調度task分配Slot的時候有兩個重要原則：
同一個job中，同一個group中不同operator的task可以共享一個Slot
Flink是按照拓撲順序從Source依次調度到Sink的
還拿上述的例子來說明Slot共享以及task調度的原理，如圖1.3假設有兩個TaskManager（TaskManager1和TaskManager2），每個TaskManager有2個Slot（Slot1和Slot2）。為了方便理解Slot共享的流程需要提前定義operator的并發(fā)度，來決定task的調度順序。假設source/map的并發(fā)度為2，keyBy/window/sink的并發(fā)度為4，那么調度的順序依次為source/map[1] ->source/map[2] ->keyBy/window/sink[1]->keyBy/window/sink[2]->keyBy/window/sink[3]->keyBy/window/sink[4]。如圖1.3為了便于說明流程，將source/map的并發(fā)度設為4，keyBy/window/sink的并發(fā)度設為4。那么首先分配task source/map[1]，這個時候Slot中還沒有task，分配到TaskManager1中，然后分配 source/map[2]，根據(jù)Slot共享規(guī)則，source/map[1]和source/map[2] 屬于同一operator的不同task，所以source/map[2]不能共享Slot1，被分配到TaskManager1的Slot2，source/map[3]和source/map[4]同樣會依次分配不同的Slot，接下來分配keyBy/window/sink[1],根據(jù)Slot共享規(guī)則，它可以和source/map[1]，共享同一個slot，所以也被分配到TaskManager1的Slot1中，keyBy/window/sink的其他任務依次被分配到不同Slot中。圖1.4為并行度分別設置為2和4的分配過程，這里不再展開說明。
? ??

總結
? ? ? ?上述內容，主要介紹了，Flink的基本架構以及Flink執(zhí)行的基本原理，重點說明了Flink實現(xiàn)高性能的一些基本原理，因為寫的比較匆忙，如有錯誤之處，歡迎大家評論指正。

參考資料
https://ci.apache.org/projects/flink/flink-docs-master/internals/job_scheduling.html?spm=a2c4e.11153940.blogcont64819.14.4cc928ce5F2w98
https://ci.apache.org/projects/flink/flink-docs-master/concepts/programming-model.html
https://yq.aliyun.com/articles/64819
https://blog.csdn.net/lisi1129/article/details/54844919
Learning Apache Flink
————————————————
版權聲明：本文為CSDN博主「sxiaobei」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/sxiaobei/article/details/80861070

總結

以上是生活随笔為你收集整理的Flink基本架构的全部內容，希望文章能夠幫你解決所遇到的問題。

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