文章目錄
任務調度+資源調度大體流程
1，Worker啓動成功向master註冊
2，提交App spark-submit --master --class jarPath
3，當TaskSchedule對象創建完成後，會向Master爲Application申請資源
4，當waitingApps集合中的元素髮生改變，會調用schedule（）方法。
5，當Excutor啓動成功後，會向TaskSchedule反向註冊，此時的TaskSchedule就會有一批Excutor的列表信息。
6，根據RDD的寬窄依賴，切割job，劃分Stage，每一個task是pipline的計算模式。
7，TaskSchedule會根據數據的位置分發Task。
8，分發task，並且監控task的執行情況。
9，若task失敗或者掙扎，會重試鑑定掙扎的Task。
10，重試Stage，只會重試失敗的Task。
問題思考
Excutor的默認機制
- 默認情況下，每一個worker爲當前的Application只會啓動一個Excutor（它默認使用當前Worker所管理的所有的核，1G運行內存）
- 如果想要在一個worker上啓動多個Excutor進程，再提交Application的時候，要指定Excutor使用的核數；
spark-submit --excutor -cores
- 默認情況下，Excutor的啓動，是輪訓方式啓動的，輪訓的方式在一定程度上有利於數據的本地化。
輪訓啓動
啓動Excutor的時候根本沒有考慮數據的位置，但是啓動方式有利於數據本地化（輪訓啓動，在每一個worker節點上都會啓動一個Excutor）
爲什麼要用輪訓啓動這種設計模式？
- 多個job：
若是多個job都運行在一臺節點上，此時計算的數據可能不在這個節點上，或者只有一部分在這個節點上，那麼就要從別的節點上拉取數據，那麼就要走網絡傳輸，這就導致數據找計算，不是我們想要的。若是多個job都運行在一臺節點上，此時計算的數據可能不在這個節點上，或者只有一部分在這個節點上，那麼就要從別的節點上拉取數據，那麼就要走網絡傳輸，這就導致數據找計算，不是我們想要的。 - task的執行效率以及時間
若是多個task都運行在一臺節點上，那麼會採用阻塞執行的方式，這樣只有等這個任務執行完才能行執行別的task，不能並行處理，效率也就大大降低，時間也隨之加長。
輪訓方式啓動Executor的公式
–executor-cores：每個executor需要的核；ec
–executor-memory：每個executor需要內存；em
–total-executor-cores：這個Application一共需要多少個核；tec
worker num：Worker節點個數；wn
worker memory：Worker節點的內存；wm
worker core：Worker節點的核；wc
min(min(wm/em,wc/ec)*wn,tec/ec)
Works集合爲什麼要使用Hashset？
Driver進程是怎麼啓動起來的？
Driver進程的啓動是通過執行我們用戶寫的Application程序啓動的，通過源碼分析，我們知道，是在創建上下文對象SparkCntext的時候啓動的。源碼分析請參考上篇博客
資源調度（學習筆記）。
掙扎的（掉隊的）任務
比如1000個task中，有9999個任務執行完成，只有一個task正在執行，那麼這個任務就叫掙扎的任務。
TaskSchedule遇到掙扎的任務也會重試，此時TaskSchedule會重新提交一個和掙扎的Task一模一樣的Task到集羣中運行，但掙扎的Task不會被kill掉，會讓他們在集羣中比賽執行，誰先執行完畢，就以誰的結果爲準。
推測執行機制
用來判斷哪些task是掙扎的。
推測執行機制的判斷標準
當所有的task 75%以上都執行完畢，那麼TaskSchedule纔會每隔100ms計算一下哪些task需要推測執行。
例如：100個task中有76個task已經執行完畢，24個task沒有執行完畢，此時它會計算出這24個task已經執行時間的中位數，然後將中位數*1.5得到最終的時間，拿到這個最終計算出來的時間，去查看哪一些task超時，此時這些task就是掙扎的task。
配置信息的使用
- 在代碼中SparkConf中修改。
- 在提交Application的時候通過–conf來配置，如果要修改多個配置信息的值，那麼需要多加一個–conf （常用）。
比如說stage、spark的重試次數都要修改，此時需要加上兩個–conf，分別來配置。
（spark-submit --master --conf k=v）
- 在spark的配置文件中配置，修改spark-default.conf文件
重試機制
- Taskschedule會實時跟蹤每一個Task的執行情況，若是執行失敗，Taskschedule會重試提交task，但是不會無休止的重試，默認是重試3次，若果重試3次依舊失敗，那麼這個task所在的stage就失敗了，此時會向DAGSchedule彙報，任務執行失敗。
- DAGSchedule會重試提交stage，如果DAGSchedule重試了4次，依然失敗，那麼stage所在的job就失敗了，job失敗是不會重試的。
注意：每一次重試提交stage，已經成功執行的不會被再次分發到Excutor進程執行，只是提交重試失敗的stage。
粗細粒度調度
粗粒度的資源調度
典型代表：Spark
描述：在任務執行前，會先將資源申請完畢，當所有的task執行完畢，纔會釋放這部分資源。
優點：每一個task執行之前，不需要自己去申請資源了，直接使用已經申請好的資源就行了，task啓動的時間變快，task執行的時間縮短了，stage job application操作時間也短了。
缺點：需要所有的task都執行完畢纔會使用資源 假設10000個task ，9999task執行完畢了，不會釋放直到最後一個task執行完畢，纔會釋放資源，集羣的資源就無法充分的利用了。
細粒度的資源調度
典型代表：MapReduce
描述：在任務提交的時候，每一個task自己去申請資源，申請到了纔會執行，執行完立馬釋放資源。
優點：每一個task執行完畢後立馬釋放資源，下一個task執行前自己再去申請資源，這樣有利於資源的充分利用。
缺點：由於需要每一個task自己去申請資源，導致task啓動時間變長了，stage job application也相對變長了。
Spark在yarn集羣上的兩種提交方式
請參考下篇博客