之前寫過一篇文章，介紹flink的並行度問題：
並行度的設定有幾種，按優先順序先後依次是：
公司用的flink是基於開源改造的，跟開源還是有些區別，使用過程中也碰到一些問題，這裡簡單總結下。
有兩個跟並行度相關的配置
任務啟動的時候，slot數量=numberoftaskmanagers*numberoftaskslots。
有兩個跟任務相關的資源
前提條件：申請了cpu核心數為4，記憶體8g，numberoftaskmanagers為4，numberoftaskslots為2，理論上slot數量為：4*2=8.
一般認為：4個cpu核心數和8g記憶體，4個taskmanager，8個slot。任務起來的時候，有多少slot就申請多少，這裡應該申請8個slot，沒用的閒置著，如果任務需要的slot數量超過了8，資源申請不下來任務啟動失敗。
實際情況
為啥已經分配了15個slot，不是最多8個？
看來並行度、numberoftaskmanagers、numberoftaskslots、cpu、記憶體、實際slot數量之間的關係，有一定迷惑性。
前面說了，設定並行度的方法，按優先順序先後：運算元級別、執行環境級別、命令列級別、配置檔案級別，既然運算元級別設定並行度，不好控制實際啟動的taskmanager和slot的數量，那就試試其他的。
env.setparallelism(8);
為什麼會這樣？需要重新研究下parallism、subtask、task、slot、operator chain等概念，另外還需要研究下sharing group slot概念，內容比較多，這裡不詳細介紹。
flink 並行度 任務鏈 task分配
不同的運算元操作複雜度不同 我們可以稱像source map sink 這種 計算不複雜的運算元稱為非資源密集型的運算元 aggregate reduce sum window 這種計算複雜的運算元稱為為資源密集型的運算元 如果把這兩種運算元的優先順序看作相同，平等的分配到slo中，當資料流sour...
flink之slot 並行度 任務鏈
2.並行度，乙個特定運算元的子任務的個數被稱之為其並行度，可以認為乙個流程式的並行度是 所有運算元中最大的並行度 乙個程式中，不同的運算元並行度可能不同 3.因為是資源密集型的運算元的子任務在不同的slot中，所以可以做到負載均衡。4.非資源密集型的子任務和資源密集型的子任務不被放到同乙個slot中...
streaming 並行度設定
sparkstreaming並行度屬性設定 spark.streaming.blockinterval 該屬性是對batchinterval的進一步細化切分。將乙個batchinterval的資料喜歡切分成更小的block，乙個block對應乙個spark partition。batchinterv...