關於任務調度，主要通過上面的這張圖進行一個相應的講解，在這張圖裡面主要分為兩個部分，一是關於任務調度的流程，二是關於任務調度的重試機制，這也是我們spark優化的其中一個方面

首先是RDD Object，

這也就相當於我們的應用程序，當我們在開發一個application的時候我們會將一個個的RDD之間有了一個依賴關係，形成一個有向無環圖，然後我們將這個有向無環圖提交給DAGScheduler，它存在於Driver中，而我們都知道Driver的作用就是根絕RDD的寬窄以來的關係對job進行切割，劃分Stage，每一個stage中包含一組並行執行的task，並將Stage封裝到taskSet中然後分發到TaskScheduler中， taskScheduler會將taskSet中的任務抽取出來然後分發到各個不同的Executor中進行執行

相信大家又有疑問了，那這個數據的分發是怎麼進行的呢？

他會根據我們的數據位置進行分發，那為什麼會這樣呢？大家應該都知道，大數據的一個工作原理是計算向數據移動，節省了磁盤和網絡IO，提高了運行的效率，這是他的一個標準，所有的任務的執行都會遵循這個標準進行工作的處理，然後taskScheduler將數據分發到worker節點上的Executor進行處理。

但是我們也都知道，有的時候車一次性啟動不起來，那我相信正常人的做法就是在啟動一次，不會直接放棄這輛車然後重新買車吧，當然了，要是家裡有礦的話咱另說，你是土豪我也沒辦法，在spark的任務調度中也是存在這種機制的，他就是重試機制，當task在Executor中執行失敗之後TaskScheduler負責重試，默認重試3次，如果三次重試之後還是失敗那怎麼辦呢？我會打電話找4s店，讓他們委派專業的人員來進行操作，也就是DAGScheduler繼續進行重試，如果默認重試3次，如果還是失敗了，那麼這個job也就結束了，無法執行，這輛車也就要重新回廠了

但是有的時候車子啟動不了可能不是因為你的原因，而是車子的原因，比如車鑰匙或者繼電器不好用了，那麼我會直接聯繫4s店，在spark中也是這樣的，當task的失敗是由於Shuffle file not find造成的，那麼TaskScheduler是不會負責重試的，會直接聯繫4S店，DAGScheduler進行重試

就像本田的機油門事件，你能說它性能不好嗎？不是的，他只是那一部分車拖了後腿，在spark中叫做推測執行機制（拖後腿），那遇到拖後腿的怎麼辦，本田的做法是將這個型號的車進行了召回，那spark呢，他會啟動一個和拖後腿的task完全一樣的task進行比賽，這兩個task誰先執行完就以誰的執行時間為準

那麼拖後腿的任務是怎麼選擇的呢？

在默認的情況下，如果有75%的任務已經執行完畢了，剩下的task去一箇中位數然後乘1.5得到一個新的時間節點，然後進行比對，超過這個時間的就是拖後腿的任務，但是重試機制會有一個重複數據的問題，當數據出錯後會重新執行，先前產生的數據就會和後來的數據重複，或者進行ETL的時候，task進行的操作多而且時間會很長，當推測執行機制啟動之後我們會認為它是拖後腿任務然後會啟動一個完全一樣的任務進行執行，那這兩個task的執行結果就會產生衝突，造成數據的重複，解決方法就是採用冪等操作，對於冪等操作的簡單解釋就是別人打你10巴掌你就感覺到了一巴掌，反射神經有點長

這就是關於spark任務調度的相關過程，難嗎？不難！簡單嗎？不簡單吧，但是，隨著大數據以及人工智能的發展，spark，flink這樣的一些處理技術如日中天的發展起來，但是我們該如何去準備呢？明知道是高薪產業卻啃不到這塊蛋糕，難受嗎？

那就看我給你們準備的資料吧，私信“資料”獲取