1、前述數據庫
Spark的資源調度是個很重要的模塊，只要搞懂原理，才能具體明白Spark是怎麼執行的，因此尤爲重要。app
自願申請的話，本文分粗粒度和細粒度模式分別介紹。spa
2、具體線程
Spark資源調度流程圖：對象
Spark資源調度和任務調度的流程：ip
一、啓動集羣后，Worker節點會向Master節點彙報資源狀況，Master掌握了集羣資源狀況。資源
二、當Spark提交一個Application後，根據RDD之間的依賴關係將Application造成一個DAG有向無環圖。任務提交後，Spark會在Driver端建立兩個對象：DAGScheduler和TaskScheduler。spark
三、DAGScheduler是任務調度的高層調度器，是一個對象。DAGScheduler的主要做用就是將DAG根據RDD之間的寬窄依賴關係劃分爲一個個的Stage，而後將這些Stage以TaskSet的形式提交給TaskScheduler（TaskScheduler是任務調度的低層調度器，這裏TaskSet其實就是一個集合，裏面封裝的就是一個個的task任務,也就是stage中的並行度task任務）pip
四、TaskSchedule會遍歷TaskSet集合，拿到每一個task後會將task發送到計算節點Executor中去執行（其實就是發送到Executor中的線程池ThreadPool去執行）。io
五、task在Executor線程池中的運行狀況會向TaskScheduler反饋，
六、當task執行失敗時，則由TaskScheduler負責重試，將task從新發送給Executor去執行，默認重試3次。若是重試3次依然失敗，那麼這個task所在的stage就失敗了。
七、stage失敗了則由DAGScheduler來負責重試，從新發送TaskSet到TaskSchdeuler，Stage默認重試4次。若是重試4次之後依然失敗，那麼這個job就失敗了。job失敗了，Application就失敗了。
八、TaskScheduler不只能重試失敗的task,還會重試straggling（落後，緩慢）task（也就是執行速度比其餘task慢太多的task）。若是有運行緩慢的task那麼TaskScheduler會啓動一個新的task來與這個運行緩慢的task執行相同的處理邏輯。兩個task哪一個先執行完，就以哪一個task的執行結果爲準。這就是Spark的推測執行機制。在Spark中推測執行默認是關閉的。推測執行能夠經過spark.speculation屬性來配置。
總結：
一、對於ETL類型要入數據庫的業務要關閉推測執行機制，這樣就不會有重複的數據入庫。
二、若是遇到數據傾斜的狀況，開啓推測執行則有可能致使一直會有task從新啓動處理相同的邏輯，任務可能一直處於處理不完的狀態。（因此通常關閉推測執行）
三、一個job中多個action， 就會有多個job，通常一個action對應一個job,若是一個application中有多個job時，按照順序一次執行，即便後面的失敗了，前面的執行完了就完了，不會回滾。
四、有SparkContext端就是Driver端。
五、通常到以下幾行時，資源就申請完了，後面的就是處理邏輯了
val conf = new SparkConf()
conf.setMaster("local").setAppName("pipeline");
val sc = new SparkContext(conf)
粗粒度資源申請和細粒度資源申請
粗粒度資源申請(Spark）
在Application執行以前，將全部的資源申請完畢，當資源申請成功後，纔會進行任務的調度，當全部的task執行完成後，纔會釋放這部分資源。
優勢：在Application執行以前，全部的資源都申請完畢，每個task運行時直接使用資源就能夠了，不須要task運行時在執行前本身去申請資源，task啓動就快了，task執行快了，stage執行就快了，job就快了，application執行就快了。
缺點：直到最後一個task執行完成纔會釋放資源，集羣的資源沒法充分利用。當數據傾斜時更嚴重。
細粒度資源申請（MapReduce）
Application執行以前不須要先去申請資源，而是直接執行，讓job中的每個task在執行前本身去申請資源，task執行完成就釋放資源。
優勢：集羣的資源能夠充分利用。
缺點：task本身去申請資源，task啓動變慢，Application的運行就相應的變慢了