flink作為基於流的大資料計算引擎，可以說在大資料領域的紅人，下面對flink-1.7的架構進行邏輯上的分析並和spark做了一些關鍵點的對比。
如圖1，flink架構分為3個部分，client，jobmanager（簡稱jm）和taskmanager（簡稱tm）。client負責提交使用者的應用拓撲到jm，注意這和spark的driver用法不同，flink的client只是單純的將使用者提交的拓撲進行優化，然後提交到jm，不涉及任何的執行操作。jm負責task的排程，協調checkpoints，協調故障恢復等。tm負責管理和執行task。通過flink的架構我們可以了解到，flink把任務排程管理和真正執行的任務分離，這裡的分離說的是物理分離。而對比spark的排程和執行任務是在乙個jvm裡的，也就是driver。分離的好處很明顯，不同任務可以復用同乙個任務管理（jm，tm），避免多次提交，缺點可能就是多了乙個步驟，需要額外提交維護tm。
圖1 架構
flink架構中另乙個重要的概念是slot，在tm中有乙個slot的概念，這個概念類似storm裡的slot，用來控制併發度的，但不同於storm，flink的slot控制的是執行緒。首先1個tm對應1個jvm，然後併發度task對應乙個執行緒，而slot就代表1個tm中可以執行的最大的task數。此外，task被tm管理，但是目前只會對記憶體進行管理，cpu是不做限制的。建議slot的數量和該節點的cpu數量保持一致。
flink支援多種部署策略，獨立部署模式或者基於其他資源容器yarn，mesos。
不依賴第三方資源容器進行部署，部署相對麻煩，需要將jm，tm分別部署到多個節點中，然後啟動，一般不建議單獨部署。
基於yarn的部署是比較常見的，flink提供了兩種基於yarn的提交模式，attached和detached。無論是jb和tm的提交還是任務的提交都支援這兩種模式。和spark基於yarn的兩種模式不同，flink的這兩種模式僅僅只是在client端阻塞和非阻塞的區別，attached模式會hold yarn的session直到任務執行結束，detached模式在提交完任務後就退出client，這個區別是很簡單的。結合flink的架構來看，client不參與任何任務的執行，這點和spark是有很大區別的，不要搞混。
圖2
圖3從架構上來看，flink也採用了常見的主從模型，不過不用擔心flink已經支援了對jm的ha，很多地方可以看到其他大資料計算引擎的影子，在選擇計算引擎的時候可以嘗試一下。
// flink官網對分布式執行環境的介紹
// flink官網對排程的介紹
Flink篇 架構設計介紹
從架構的層面 分為無界流和有界流 無界流資料 有定義流的開始，但沒有定義流的結束。它們會無休止地產生資料。無界流的資料必須持續處理，即資料被攝取後需要立刻處理。我們不能等到所有資料都到達再處理，因為輸入是無限的，在任何時候輸入都不會完成。處理無界資料通常要求以特定順序攝取事件，例如事件發生的順序，以...
flink學習 flink架構
flink結構 graph 2個併發度 source為1個併發度 的sockettextstreamwordcount四層執行圖的演變過程 jobgraph streamgraph經過優化後生成了 jobgraph，提交給 jobmanager 的資料結構。executiongraph jobman...
Flink 架構和拓撲概覽
架構 要了解乙個系統，一般都是從架構開始。我們關心的問題是 系統部署成功後各個節點都啟動了哪些服務，各個服務之間又是怎麼互動和協調的。下方是 flink 集群啟動後架構圖。當 flink 集群啟動後，首先會啟動乙個 jobmanger 和乙個或多個的 taskmanager。由 client 提交任...