1、KeyBy 操作後，只有當 Key 的數量大於運算元的併發實例數才能獲得較好的計算性能。 A.而若Key 的數量比實例數量少，就會導致部分實例收不到數據，這些實例就得不到執行，這些實例的計算能力得不到充分發揮。 ~~B.當Key個數多餘並行實例數時，由於同一個 Key 對應的所有數據都能發送到同一 ...
1、KeyBy 操作後，只有當 Key 的數量大於運算元的併發實例數才能獲得較好的計算性能。
A.而若Key 的數量比實例數量少，就會導致部分實例收不到數據，這些實例就得不到執行，這些實例的計算能力得不到充分發揮。
B.當Key個數多餘並行實例數時，由於同一個 Key 對應的所有數據都能發送到同一個計算實例上，同一個Key中所對應的數據都能分配到同一個實例中，這樣Key內計算就免去了數據傳遞的序列化和網路IO等開銷。
2、執行環境的excute()方法
前面我們調用的所有方法，都不是在實際處理數據，而是在構通表達計算邏輯的DAG圖。只有當我們將整個圖構建完成並顯式調用 Execute 方法後，框架才會把計算圖提交到集群中，接入數據並執行實際的邏輯。
3、Flink Runtime 層的整個架構主要是在 FLIP-6 中實現的，整體上採用了標準 master-slave 的結構。
其中master負責管理整個集群中的資源和作業；而TaskExecutor 則是 Slave，負責提供具體的資源並實際執行作業。
4、Master 部分又包含了三個組件，即 Dispatcher、ResourceManager 和 JobManager。
A.Dispatcher負責接收用戶提供的作業，並且負責為這個新提交的作業拉起一個新的 JobManager 組件。
B.ResourceManager 負責資源的管理，在整個 Flink 集群中只有一個 ResourceManager。
C.JobManager 負責管理作業的執行，在一個 Flink 集群中可能有多個作業同時執行，每個作業都有自己的 JobManager 組件。
以上三個組件都包含在 AppMaster 進程中。
5、當用戶提交作業時，提交腳本會先啟動一個Client進程負責作業的編譯與提交。
它先將用戶編寫的代碼編譯為一個 JobGraph，在這個過程，它還會進行一些檢查或優化等工作，如判斷哪些 Operator 可以 Chain 到同一個 Task 中。然後，Client 將產生的 JobGraph 提交到集群中執行。此時有兩種情況，一種是類似於 Standalone 這種 Session 模式，AM 會預先啟動，此時 Client 直接與 Dispatcher 建立連接並提交作業即可。另一種是 Per-Job 模式，AM 不會預先啟動，此時 Client 將首先向資源管理系統 （如Yarn、K8S）申請資源來啟動 AM，然後再向 AM 中的 Dispatcher 提交作業。
6、當作業到 Dispatcher 後
Dispatcher 會先啟動一個 JobManager 組件，然後 JobManager 會向 ResourceManager 申請資源來啟動作業中具體的任務。這時根據 Session 和 Per-Job 模式的區別， TaskExecutor 可能已經啟動或者尚未啟動。若是前者，此時 ResourceManager 中已有記錄了 TaskExecutor 註冊的資源，可以直接選取空閑資源進行分配。若是後者，ResourceManager 也需要先向外部資源管理系統申請資源來啟動 TaskExecutor，然後等待 TaskExecutor 註冊相應資源後再繼續選擇空閑資源進程分配。
目前 Flink 中 TaskExecutor 的資源是通過 Slot 來描述的，一個 Slot 一般可以執行一個具體的 Task，但在一些情況下也可以執行多個相關聯的 Task。ResourceManager 選擇到空閑的 Slot 之後，就會通知相應的 TM “將該 Slot 分配給 JobManager XX ”，然後 TaskExecutor 進行相應的記錄後，會向 JobManager 進行註冊。JobManager 收到 TaskExecutor 註冊上來的 Slot 後，就可以實際提交 Task 了。TaskExecutor 收到 JobManager 提交的 Task 之後，會啟動一個新的線程來執行該 Task。Task 啟動後就會開始進行預先指定的計算，並通過數據 Shuffle 模塊互相交換數據。
7、Flink 支持兩種作業執行模式，即 Per-job 模式與 Session 模式。
7.1Per-job 模式下整個 Flink 集群只執行單個作業，即每個作業會獨享 Dispatcher 和 ResourceManager 組件。此外，Per-job 模式下 AppMaster 和 TaskExecutor 都是按需申請的。因此，Per-job 模式更適合運行執行時間較長的大作業，這些作業對穩定性要求較高，並且對申請資源的時間不敏感。【一般配合yarn、mesose、k8s等外部資源管理器】
7.2與之對應，在 Session 模式下，Flink 預先啟動 AppMaster 以及一組 TaskExecutor，然後在整個集群的生命周期中會執行多個作業。可以看出，Session 模式更適合規模小，執行時間短的作業。【一般在standalone模式下使用】
