真正開始運行代碼的是execute函數，這個函數會根據環境上下文采取不同的行爲，這個我們後面會詳細講解，我們先來看看flink的架構，下圖是結構圖
當 Flink 集羣啓動後，首先會啓動一個 JobManger 和一個或多個的 TaskManager。由 Client 提交任務給 JobManager，JobManager 再調度任務到各個 TaskManager 去執行，然後 TaskManager 將心跳和統計信息彙報給 JobManager。TaskManager 之間以流的形式進行數據的傳輸。上述三者均爲獨立的 JVM 進程。
- Client 爲提交 Job 的客戶端，可以是運行在任何機器上（與 JobManager 環境連通即可）。提交 Job 後，Client 可以結束進程（Streaming的任務），也可以不結束並等待結果返回。
- JobManager 主要負責調度 Job 並協調 Task 做 checkpoint，職責上很像 Storm 的 Nimbus。從 Client 處接收到 Job 和 JAR 包等資源後，會生成優化後的執行計劃，並以 Task 的單元調度到各個 TaskManager 去執行。
- TaskManager 在啓動的時候就設置好了槽位數（Slot），每個 slot 能啓動一個 Task，Task 爲線程。從 JobManager 處接收需要部署的 Task，部署啓動後，與自己的上游建立 Netty 連接，接收數據並處理。
Flink 的任務調度是多線程模型，並且不同Job/Task混合在一個 TaskManager 進程中。這種方式可以有效提高 CPU 利用率，但是缺點是資源沒有隔離，也不方便調試(strom更合理，一個jvm只跑一個job的tasks)
Flink的執行圖(Graph)
Flink的執行圖分爲四層StreamGraph -> JobGraph -> ExecutionGraph -> 物理執行圖，每層的解釋如下：
StreamGraph：是根據用戶通過 Stream API 編寫的代碼生成的最初的圖。用來表示程序的拓撲結構。
JobGraph：StreamGraph經過優化後生成了 JobGraph，提交給 JobManager 的數據結構。主要的優化爲，將多個符合條件的節點 chain 在一起作爲一個節點，這樣可以減少數據在節點之間流動所需要的序列化/反序列化/傳輸消耗。
ExecutionGraph：JobManager 根據 JobGraph 生成ExecutionGraph。ExecutionGraph是JobGraph的並行化版本，是調度層最核心的數據結構。
物理執行圖：JobManager 根據 ExecutionGraph 對 Job 進行調度後，在各個TaskManager 上部署 Task 後形成的“圖”，並不是一個具體的數據結構。
下圖是一個示例對應的四層執行圖
這裏對一些名詞進行簡單的解釋。
- StreamGraph：根據用戶通過 Stream API 編寫的代碼生成的最初的圖。
- StreamNode：用來代表 operator 的類，並具有所有相關的屬性，如併發度、入邊和出邊等。
- StreamEdge：表示連接兩個StreamNode的邊。
- JobGraph：StreamGraph經過優化後生成了 JobGraph，提交給 JobManager 的數據結構。
- JobVertex：經過優化後符合條件的多個StreamNode可能會chain在一起生成一個JobVertex，即一個JobVertex包含一個或多個operator，JobVertex的輸入是JobEdge，輸出是IntermediateDataSet。
- IntermediateDataSet：表示JobVertex的輸出，即經過operator處理產生的數據集。producer是JobVertex，consumer是JobEdge。
- JobEdge：代表了job graph中的一條數據傳輸通道。source 是 IntermediateDataSet，target 是 JobVertex。即數據通過JobEdge由IntermediateDataSet傳遞給目標JobVertex。
- ExecutionGraph：JobManager 根據 JobGraph 生成ExecutionGraph。ExecutionGraph是JobGraph的並行化版本，是調度層最核心的數據結構。
- ExecutionJobVertex：和JobGraph中的JobVertex一一對應。每一個ExecutionJobVertex都有和併發度一樣多的 ExecutionVertex。
- ExecutionVertex：表示ExecutionJobVertex的其中一個併發子任務，輸入是ExecutionEdge，輸出是IntermediateResultPartition。
- IntermediateResult：和JobGraph中的IntermediateDataSet一一對應。一個IntermediateResult包含多個IntermediateResultPartition，其個數等於該operator的併發度。
- IntermediateResultPartition：表示ExecutionVertex的一個輸出分區，producer是ExecutionVertex，consumer是若干個ExecutionEdge。
- ExecutionEdge：表示ExecutionVertex的輸入，source是IntermediateResultPartition，target是ExecutionVertex。source和target都只能是一個。
- Execution：是執行一個 ExecutionVertex 的一次嘗試。當發生故障或者數據需要重算的情況下 ExecutionVertex 可能會有多個 ExecutionAttemptID。一個 Execution 通過 ExecutionAttemptID 來唯一標識。JM和TM之間關於 task 的部署和 task status 的更新都是通過 ExecutionAttemptID 來確定消息接受者。
- 物理執行圖：JobManager 根據 ExecutionGraph 對 Job 進行調度後，在各個TaskManager 上部署 Task 後形成的“圖”，並不是一個具體的數據結構。
- Task：Execution被調度後在分配的 TaskManager 中啓動對應的 Task。Task 包裹了具有用戶執行邏輯的 operator。
- ResultPartition：代表由一個Task的生成的數據，和ExecutionGraph中的IntermediateResultPartition一一對應。
- ResultSubpartition：是ResultPartition的一個子分區。每個ResultPartition包含多個ResultSubpartition，其數目要由下游消費 Task 數和 DistributionPattern 來決定。
- InputGate：代表Task的輸入封裝，和JobGraph中JobEdge一一對應。每個InputGate消費了一個或多個的ResultPartition。
- InputChannel：每個InputGate會包含一個以上的InputChannel，和ExecutionGraph中的ExecutionEdge一一對應，也和ResultSubpartition一對一地相連，即一個InputChannel接收一個ResultSubpartition的輸出。
那麼 Flink 爲什麼要設計這4張圖呢，其目的是什麼呢？Spark 中也有多張圖，數據依賴圖以及物理執行的DAG。其目的都是一樣的，就是解耦，每張圖各司其職，每張圖對應了 Job 不同的階段，更方便做該階段的事情。我們給出更完整的 Flink Graph 的層次圖。
首先我們看到，JobGraph 之上除了 StreamGraph 還有 OptimizedPlan。OptimizedPlan 是由 Batch API 轉換而來的。StreamGraph 是由 Stream API 轉換而來的。爲什麼 API 不直接轉換成 JobGraph？因爲，Batch 和 Stream 的圖結構和優化方法有很大的區別，比如 Batch 有很多執行前的預分析用來優化圖的執行，而這種優化並不普適於 Stream，所以通過 OptimizedPlan 來做 Batch 的優化會更方便和清晰，也不會影響 Stream。JobGraph 的責任就是統一 Batch 和 Stream 的圖，用來描述清楚一個拓撲圖的結構，並且做了 chaining 的優化，chaining 是普適於 Batch 和 Stream 的，所以在這一層做掉。ExecutionGraph 的責任是方便調度和各個 tasks 狀態的監控和跟蹤，所以 ExecutionGraph 是並行化的 JobGraph。而“物理執行圖”就是最終分佈式在各個機器上運行着的tasks了。所以可以看到，這種解耦方式極大地方便了我們在各個層所做的工作，各個層之間是相互隔離的。
後面我們開始分析這四層圖生成的過程。