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模式下使用】
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/29389.html
標籤：大數據
下一篇：大資料引擎分代