通過文章“Spark核心概念RDD”我們知道，Spark的核心是根據RDD來實現的，Spark Scheduler則為Spark核心實現的重要一環，其作用就是任務調度。Spark的任務調度就是如何組織任務去處理RDD中每個分區的數據，根據RDD的依賴關系構建DAG，基于DAG劃分Stage，將每個Stage中的任務發到指定節點運行。基于Spark的任務調度原理，我們可以合理規劃資源利用，做到盡可能用最少的資源高效地完成任務計算。

分布式運行框架

Spark可以部署在多種資源管理平臺，例如Yarn、Mesos等，Spark本身也實現了一個簡易的資源管理機制，稱之為Standalone模式。由于工作中接觸較多的是Saprk on Yarn，不做特別說明，以下所述均表示Spark-on-Yarn。Spark部署在Yarn上有兩種運行模式，分別為yarn-client和yarn-cluster模式，它們的區別僅僅在于Spark Driver是運行在Client端還是ApplicationMater端。如下圖所示為Spark部署在Yarn上，以yarn-cluster模式運行的分布式計算框架。

其中藍色部分是Spark里的概念，包括Client、ApplicationMaster、Driver和Executor，其中Client和ApplicationMaster主要是負責與Yarn進行交互；Driver作為Spark應用程序的總控，負責分發任務以及監控任務運行狀態；Executor負責執行任務，并上報狀態信息給Driver，從邏輯上來看Executor是進程，運行在其中的任務是線程，所以說Spark的任務是線程級別的。通過下面的時序圖可以更清晰地理解一個Spark應用程序從提交到運行的完整流程。

提交一個Spark應用程序，首先通過Client向ResourceManager請求啟動一個Application，同時檢查是否有足夠的資源滿足Application的需求，如果資源條件滿足，則準備ApplicationMaster的啟動上下文，交給ResourceManager，并循環監控Application狀態。

當提交的資源隊列中有資源時，ResourceManager會在某個NodeManager上啟動ApplicationMaster進程，ApplicationMaster會單獨啟動Driver后臺線程，當Driver啟動后，ApplicationMaster會通過本地的RPC連接Driver，并開始向ResourceManager申請Container資源運行Executor進程（一個Executor對應與一個Container），當ResourceManager返回Container資源，則在對應的Container上啟動Executor。

Driver線程主要是初始化SparkContext對象，準備運行所需的上下文，然后一方面保持與ApplicationMaster的RPC連接，通過ApplicationMaster申請資源，另一方面根據用戶業務邏輯開始調度任務，將任務下發到已有的空閑Executor上。

當ResourceManager向ApplicationMaster返回Container資源時，ApplicationMaster就嘗試在對應的Container上啟動Executor進程，Executor進程起來后，會向Driver注冊，注冊成功后保持與Driver的心跳，同時等待Driver分發任務，當分發的任務執行完畢后，將任務狀態上報給Driver。

Driver把資源申請的邏輯給抽象出來，以適配不同的資源管理系統，所以才間接地通過ApplicationMaster去和Yarn打交道。

從上述時序圖可知，Client只管提交Application并監控Application的狀態。對于Spark的任務調度主要是集中在兩個方面: 資源申請和任務分發，其主要是通過ApplicationMaster、Driver以及Executor之間來完成，下面詳細剖析Spark任務調度每個細節。

Spark任務調度總覽

當Driver起來后，Driver則會根據用戶程序邏輯準備任務，并根據Executor資源情況逐步分發任務。在詳細闡述任務調度前，首先說明下Spark里的幾個概念。一個Spark應用程序包括Job、Stage以及Task三個概念：

• Job是以Action方法為界，遇到一個Action方法則觸發一個Job；
• Stage是Job的子集，以RDD寬依賴(即Shuffle)為界，遇到Shuffle做一次劃分；
• Task是Stage的子集，以并行度(分區數)來衡量，分區數是多少，則有多少個task。

Spark的任務調度總體來說分兩路進行，一路是Stage級的調度，一路是Task級的調度，總體調度流程如下圖所示。

Spark RDD通過其Transactions操作，形成了RDD血緣關系圖，即DAG，最后通過Action的調用，觸發Job并調度執行。DAGScheduler負責Stage級的調度，主要是將DAG切分成若干Stages，并將每個Stage打包成TaskSet交給TaskScheduler調度。TaskScheduler負責Task級的調度，將DAGScheduler給過來的TaskSet按照指定的調度策略分發到Executor上執行，調度過程中SchedulerBackend負責提供可用資源，其中SchedulerBackend有多種實現，分別對接不同的資源管理系統。有了上述感性的認識后，下面這張圖描述了Spark-On-Yarn模式下在任務調度期間，ApplicationMaster、Driver以及Executor內部模塊的交互過程。

Driver初始化SparkContext過程中，會分別初始化DAGScheduler、TaskScheduler、SchedulerBackend以及HeartbeatReceiver，并啟動SchedulerBackend以及HeartbeatReceiver。SchedulerBackend通過ApplicationMaster申請資源，并不斷從TaskScheduler中拿到合適的Task分發到Executor執行。HeartbeatReceiver負責接收Executor的心跳信息，監控Executor的存活狀況，并通知到TaskScheduler。下面著重剖析DAGScheduler負責的Stage調度以及TaskScheduler負責的Task調度。

Stage級的調度

Spark的任務調度是從DAG切割開始，主要是由DAGScheduler來完成。當遇到一個Action操作后就會觸發一個Job的計算，并交給DAGScheduler來提交，下圖是涉及到Job提交的相關方法調用流程圖。

Job由最終的RDD和Action方法封裝而成，SparkContext將Job交給DAGScheduler提交，它會根據RDD的血緣關系構成的DAG進行切分，將一個Job劃分為若干Stages，具體劃分策略是，由最終的RDD不斷通過依賴回溯判斷父依賴是否是款依賴，即以Shuffle為界，劃分Stage，窄依賴的RDD之間被劃分到同一個Stage中，可以進行pipeline式的計算，如上圖紫色流程部分。劃分的Stages分兩類，一類叫做ResultStage，為DAG最下游的Stage，由Action方法決定，另一類叫做ShuffleMapStage，為下游Stage準備數據，下面看一個簡單的例子WordCount。

Job由saveAsTextFile觸發，該Job由RDD-3和saveAsTextFile方法組成，根據RDD之間的依賴關系從RDD-3開始回溯搜索，直到沒有依賴的RDD-0，在回溯搜索過程中，RDD-3依賴RDD-2，并且是寬依賴，所以在RDD-2和RDD-3之間劃分Stage，RDD-3被劃到最后一個Stage，即ResultStage中，RDD-2依賴RDD-1，RDD-1依賴RDD-0，這些依賴都是窄依賴，所以將RDD-0、RDD-1和RDD-2劃分到同一個Stage，即ShuffleMapStage中，實際執行的時候，數據記錄會一氣呵成地執行RDD-0到RDD-2的轉化。不難看出，其本質上是一個深度優先搜索算法。

一個Stage是否被提交，需要判斷它的父Stage是否執行，只有在父Stage執行完畢才能提交當前Stage，如果一個Stage沒有父Stage，那么從該Stage開始提交。Stage提交時會將Task信息（分區信息以及方法等）序列化并被打包成TaskSet交給TaskScheduler，一個Partition對應一個Task，另一方面監控Stage的運行狀態，只有Executor丟失或者Task由于Fetch失敗才需要重新提交失敗的Stage以調度運行失敗的任務，其他類型的Task失敗會在TaskScheduler的調度過程中重試。

相對來說DAGScheduler做的事情較為簡單，僅僅是在Stage層面上劃分DAG，提交Stage并監控相關狀態信息。TaskScheduler則相對較為復雜，下面詳細闡述其細節。

Task級的調度

Spark Task的調度是由TaskScheduler來完成，由前文可知，DAGScheduler將Stage打包到TaskSet交給TaskScheduler，TaskScheduler會將其封裝為TaskSetManager加入到調度隊列中，TaskSetManager負責監控管理同一個Stage中的Tasks，TaskScheduler就是以TaskSetManager為單元來調度任務。前面也提到，TaskScheduler初始化后會啟動SchedulerBackend，它負責跟外界打交道，接收Executor的注冊信息，并維護Executor的狀態，所以說SchedulerBackend是管“糧食”的，同時它在啟動后會定期地去“詢問”TaskScheduler有沒有任務要運行，也就是說，它會定期地“問”TaskScheduler“我有這么余量，你要不要啊”，TaskScheduler在SchedulerBackend“問”它的時候，會從調度隊列中按照指定的調度策略選擇TaskSetManager去調度運行，大致方法調用流程如下圖所示。

調度策略

前面講到，TaskScheduler會先把DAGScheduler給過來的TaskSet封裝成TaskSetManager扔到任務隊列里，然后再從任務隊列里按照一定的規則把它們取出來在SchedulerBackend給過來的Executor上運行。這個調度過程實際上還是比較粗粒度的，是面向TaskSetManager的。

TaskScheduler是以樹的方式來管理任務隊列，樹中的節點類型為Schdulable，葉子節點為TaskSetManager，非葉子節點為Pool，下圖是它們之間的繼承關系。

TaskScheduler支持兩種調度策略，一種是FIFO，也是默認的調度策略，另一種是FAIR。在TaskScheduler初始化過程中會實例化rootPool，表示樹的根節點，是Pool類型。如果是采用FIFO調度策略，則直接簡單地將TaskSetManager按照先來先到的方式入隊，出隊時直接拿出最先進隊的TaskSetManager，其樹結構大致如下圖所示，TaskSetManager保存在一個FIFO隊列中。

在闡述FAIR調度策略前，先貼一段使用FAIR調度策略的應用程序代碼，后面針對該代碼邏輯來詳細闡述FAIR調度的實現細節。

object MultiJobTest {
  // spark.scheduler.mode=FAIR
  def main(args: Array[String]): Unit = {
    val spark = SparkSession.builder().getOrCreate()

    val rdd = spark.sparkContext.textFile(...)
      .map(_.split("\\s+"))
      .map(x => (x(0), x(1)))

    val jobExecutor = Executors.newFixedThreadPool(2)

    jobExecutor.execute(new Runnable {
      override def run(): Unit = {
        spark.sparkContext.setLocalProperty("spark.scheduler.pool", "count-pool")
        val cnt = rdd.groupByKey().count()
        println(s"Count: $cnt")
      }
    })

    jobExecutor.execute(new Runnable {
      override def run(): Unit = {
        spark.sparkContext.setLocalProperty("spark.scheduler.pool", "take-pool")
        val data = rdd.sortByKey().take(10)
        println(s"Data Samples: ")
        data.foreach { x => println(x.mkString(", ")) }
      }
    })

    jobExecutor.shutdown()
    while (!jobExecutor.isTerminated) {}
    println("Done!")
  }
}

上述應用程序中使用兩個線程分別調用了Action方法，即有兩個Job會并發提交，但是不管怎樣，這兩個Job被切分成若干TaskSet后終究會被交到TaskScheduler這里統一管理，其調度樹大致如下圖所示。

    var sortedTaskSetQueue = new ArrayBuffer[TaskSetManager]
    val sortedSchedulableQueue = schedulableQueue.asScala.toSeq.sortWith(taskSetSchedulingAlgorithm.comparator)
    for (schedulable <- sortedSchedulableQueue) {
      sortedTaskSetQueue ++= schedulable.getSortedTaskSetQueue
    }
    sortedTaskSetQueue
  }

使用FAIR調度策略時，上面代碼中的taskSetSchedulingAlgorithm的類型為FairSchedulingAlgorithm，排序過程的比較是基于Fair-share來比較的，每個要排序的對象包含三個屬性: runningTasks值（正在運行的Task數）、minShare值、weight值，比較時會綜合考量runningTasks值，minShare以及weight值。如果A對象的runningTasks大于它的minShare，B對象的runningTasks小于它的minShare，那么B排在A前面；如果A、B對象的runningTasks都小于它們的minShare，那么就比較runningTasks與minShare的比值，誰小誰排前面；如果A、B對象的runningTasks都大于它們的minShare，那么就比較runningTasks與weight的比值，誰小誰排前面。整體上來說就是通過minShare和weight這兩個參數控制比較過程，可以做到不讓資源被某些長時間Task給一直占了。

從調度隊列中拿到TaskSetManager后，那么接下來的工作就是TaskSetManager按照一定的規則一個個取出Task給TaskScheduler，TaskScheduler再交給SchedulerBackend去發到Executor上執行。前面也提到，TaskSetManager封裝了一個Stage的所有Task，并負責管理調度這些Task。

本地化調度

從調度隊列中拿到TaskSetManager后，那么接下來的工作就是TaskSetManager按照一定的規則一個個取出Task給TaskScheduler，TaskScheduler再交給SchedulerBackend去發到Executor上執行。前面也提到，TaskSetManager封裝了一個Stage的所有Task，并負責管理調度這些Task。

在TaskSetManager初始化過程中，會對Tasks按照Locality級別進行分類，Task的Locality有五種，優先級由高到低順序：PROCESS_LOCAL(指定的Executor)，NODE_LOCAL(指定的主機節點)，NO_PREF(無所謂)，RACK_LOCAL(指定的機架)，ANY(滿足不了Task的Locality就隨便調度)。這五種Locality級別存在包含關系，RACK_LOCAL包含NODE_LOCAL，NODE_LOCAL包含PROCESS_LOCAL，然而ANY包含其他所有四種。初始化階段在對Task分類時，根據Task的preferredLocations判斷它屬于哪個Locality級別，屬于PROCESS_LOCAL的Task同時也會被加入到NODE_LOCAL、RACK_LOCAL類別中，比如，一個Task的preferredLocations指定了在Executor-2上執行，那么它屬于Executor-2對應的PROCESS_LOCAL類別，同時也把他加入到Executor-2所在的主機對應的NODE_LOCAL類別，Executor-2所在的主機的機架對應的RACK_LOCAL類別中，以及ANY類別，這樣在調度執行時，滿足不了PROCESS_LOCAL，就逐步退化到NODE_LOCAL，RACK_LOCAL，ANY。

TaskSetManager在決定調度哪些Task時，是通過上面流程圖中的resourceOffer方法來實現，為了盡可能地將Task調度到它的preferredLocations上，它采用一種延遲調度算法。resourceOffer方法原型如下，參數包括要調度任務的Executor Id、主機地址以及最大可容忍的Locality級別。

def resourceOffer(
      execId: String,
      host: String,
      maxLocality: TaskLocality.TaskLocality)
    : Option[TaskDescription]

延遲調度算法的大致流程如下圖所示。

首先看是否存在execId對應的PROCESS_LOCAL類別的任務，如果存在，取出來調度，否則根據當前時間，判斷是否超過了PROCESS_LOCAL類別最大容忍的延遲，如果超過，則退化到下一個級別NODE_LOCAL，否則等待不調度。退化到下一個級別NODE_LOCAL后調度流程也類似，看是否存在host對應的NODE_LOCAL類別的任務，如果存在，取出來調度，否則根據當前時間，判斷是否超過了NODE_LOCAL類別最大容忍的延遲，如果超過，則退化到下一個級別RACK_LOCAL，否則等待不調度，以此類推…..。當不滿足Locatity類別會選擇等待，直到下一輪調度重復上述流程，如果你比較激進，可以調大每個類別的最大容忍延遲時間，如果不滿足Locatity時就會等待多個調度周期，直到滿足或者超過延遲時間退化到下一個級別為止。

失敗重試與黑名單機制

除了選擇合適的Task調度運行外，還需要監控Task的執行狀態，前面也提到，與外部打交道的是SchedulerBackend，Task被提交到Executor啟動執行后，Executor會將執行狀態上報給SchedulerBackend，SchedulerBackend則告訴TaskScheduler，TaskScheduler找到該Task對應的TaskSetManager，并通知到該TaskSetManager，這樣TaskSetManager就知道Task的失敗與成功狀態，對于失敗的Task，會記錄它失敗的次數，如果失敗次數還沒有超過最大重試次數，那么就把它放回待調度的Task池子中，否則整個Application失敗。

在記錄Task失敗次數過程中，會記錄它上一次失敗所在的Executor Id和Host，這樣下次再調度這個Task時，會使用黑名單機制，避免它被調度到上一次失敗的節點上，起到一定的容錯作用。黑名單記錄Task上一次失敗所在的Executor Id和Host，以及其對應的“黑暗”時間，“黑暗”時間是指這段時間內不要再往這個節點上調度這個Task了。

推測式執行

TaskScheduler在啟動SchedulerBackend后，還會啟動一個后臺線程專門負責推測任務的調度，推測任務是指對一個Task在不同的Executor上啟動多個實例，如果有Task實例運行成功，則會干掉其他Executor上運行的實例。推測調度線程會每隔固定時間檢查是否有Task需要推測執行，如果有，則會調用SchedulerBackend的reviveOffers去嘗試拿資源運行推測任務。

檢查是否有Task需要推測執行的邏輯最后會交到TaskSetManager，TaskSetManager采用基于統計的算法，檢查Task是否需要推測執行，算法流程大致如下圖所示。

TaskSetManager首先會統計成功的Task數，當成功的Task數超過75%(可通過參數spark.speculation.quantile控制)時，再統計所有成功的Tasks的運行時間，得到一個中位數，用這個中位數乘以1.5(可通過參數spark.speculation.multiplier控制)得到運行時間門限，如果在運行的Tasks的運行時間超過這個門限，則對它啟用推測。算法邏輯較為簡單，其實就是對那些拖慢整體進度的Tasks啟用推測，以加速整個TaskSet即Stage的運行。

資源申請機制

在前文已經提過，ApplicationMaster和SchedulerBackend起來后，SchedulerBackend通過ApplicationMaster申請資源，ApplicationMaster就是用來專門適配YARN申請Container資源的，當申請到Container，會在相應Container上啟動Executor進程，其他事情就交給SchedulerBackend。Spark早期版本只支持靜態資源申請，即一開始就指定用多少資源，在整個Spark應用程序運行過程中資源都不能改變，后來支持動態Executor申請，用戶不需要指定確切的Executor數量，Spark會動態調整Executor的數量以達到資源利用的最大化。

靜態資源申請

靜態資源申請是用戶在提交Spark應用程序時，就要提前估計應用程序需要使用的資源，包括Executor數(num_executor)、每個Executor上的core數(executor_cores)、每個Executor的內存(executor_memory)以及Driver的內存(driver_memory)。

在估計資源使用時，應當首先了解這些資源是怎么用的。任務的并行度由分區數(Partitions)決定，一個Stage有多少分區，就會有多少Task。每個Task默認占用一個Core，一個Executor上的所有core共享Executor上的內存，一次并行運行的Task數等于num_executor*executor_cores，如果分區數超過該值，則需要運行多個輪次，一般來說建議運行3～5輪較為合適，否則考慮增加num_executor或executor_cores。由于一個Executor的所有tasks會共享內存executor_memory，所以建議executor_cores不宜過大。executor_memory的設置則需要綜合每個分區的數據量以及是否有緩存等邏輯。下圖描繪了一個應用程序內部資源利用情況。

動態資源申請

動態資源申請目前只支持到Executor，即可以不用指定num_executor，通過參數spark.dynamicAllocation.enabled來控制。由于許多Spark應用程序一開始可能不需要那么多Executor或者其本身就不需要太多Executor，所以不必一次性申請那么多Executor，根據具體的任務數動態調整Executor的數量，盡可能做到資源的不浪費。由于動態Executor的調整會導致Executor動態的添加與刪除，如果刪除Executor，其上面的中間Shuffle結果可能會丟失，這就需要借助第三方的ShuffleService了，如果Spark是部署在Yarn上，則可以在Yarn上配置Spark的ShuffleService，具體操作僅需做兩點:

1.首先在yarn-site.xml中加上如下配置：

<property>
  <name>yarn.nodemanager.aux-services</name>
  <value>mapreduce_shuffle,spark_shuffle</value>
</property>
<property>
  <name>yarn.nodemanager.aux-services.spark_shuffle.class</name>
  <value>org.apache.spark.network.yarn.YarnShuffleService</value>
</property>
<property>
  <name>spark.shuffle.service.port</name>
  <value>7337</value>
</property>

2. 將Spark ShuffleService jar包$SPARK_HOME/lib/spark-*-yarn-shuffle.jar拷貝到每臺NodeManager的$HADOOP_HOME/share/hadoop/yarn/lib/下，并重啟所有的NodeManager。

當啟用動態Executor申請時，在SparkContext初始化過程中會實例化ExecutorAllocationManager，它是被用來專門控制動態Executor申請邏輯的，動態Executor申請是一種基于當前Task負載壓力實現動態增刪Executor的機制。一開始會按照參數spark.dynamicAllocation.initialExecutors設置的初始Executor數申請，然后根據當前積壓的Task數量，逐步增長申請的Executor數，如果當前有積壓的Task，那么取積壓的Task數和spark.dynamicAllocation.maxExecutors中的最小值作為Executor數上限，每次新增加申請的Executor為2的次方，即第一次增加1，第二次增加2，第三次增加4，…。另一方面，如果一個Executor在一段時間內都沒有Task運行，則將其回收，但是在Remove Executor時，要保證最少的Executor數，該值通過參數spark.dynamicAllocation.minExecutors來控制，如果Executor上有Cache的數據，則永遠不會被Remove，以保證中間數據不丟失。

結語

本文詳細闡述了Spark的任務調度，著重討論Spark on Yarn的部署調度，剖析了從應用程序提交到運行的全過程。Spark Schedule算是Spark中的一個大模塊，它負責任務下發與監控等，基本上扮演了Spark大腦的角色。了解Spark Schedule有助于幫助我們清楚地認識Spark應用程序的運行軌跡，同時在我們實現其他系統時，也可以借鑒Spark的實現。

轉載：http://sharkdtu.com/posts/spark-scheduler.html