[Spark基礎]--Spark的任務排程

本文嘗試從源碼層面梳理Spark在任務排程與資源配置設定上的做法。

先從Executor和SchedulerBackend說起。Executor是真正執行任務的程序，本身擁有若幹cpu和記憶體，可以執行以線程為機關的計算任務，它是資源管理系統能夠給予的最小機關。SchedulerBackend是spark提供的接口，定義了許多與Executor事件相關的處理，包括：新的executor注冊進來的時候記錄executor的資訊，增加全局的資源量(核數)，進行一次makeOffer；executor更新狀态，若任務完成的話，回收core，進行一次makeOffer；其他停止executor、remove executor等事件。下面由makeOffer展開。

資源更新的情況下，通過調用scheduler的resourceOffers方法來觸發它對現有的任務進行一次配置設定，最終launch新的tasks。這裡的全局scheduler就是TaskScheduler，實作是TaskSchedulerImpl，它可以對接各種SchedulerBackend的實作，包括standalone的，yarn的，mesos的。SchedulerBackend在做makeOffer的時候，會把現有的executor資源以WorkerOfffer清單的方式傳給scheduler，即以worker為機關，将worker資訊及其内的資源交給scheduler。scheduler拿到這一些叢集的資源後，去周遊已送出的tasks并根據locality決定如何launch tasks。

優先級排序，這個排序算法目前是兩種：FIFO或FAIR。得到這一份待運作的tasks後，接下裡就是要把schedulerBackend交過來的worker資源資訊合理配置設定給這些tasks。配置設定前，為了避免每次都是前幾個worker被分到tasks，是以先對WorkerOffer清單進行一次随機洗牌。接下來就是周遊tasks，看workers的資源

“夠不夠”，

“符不符合”task，ok的話task就被正式launch起來。注意，這裡資源"夠不夠"是很好判斷的，在TaskScheduler裡設定了每個task啟動需要的cpu個數，預設是1，是以隻需要做核數的大小判斷和減1操作就可以周遊配置設定下去。而"符不符合"這件事情，取決于每個tasks的

locality設定。

delay scheduling。

到這裡，對于任務的配置設定，資源的使用大緻有個了解。實際上，TaskScheduler的resourceOffer裡還觸發了TaskSetManager的resourceOffer方法，TaskSetManager的resourceOffer是會檢查task的locality并最終調用DAGScheduler去launch這個task。這些類的名字以及他們彼此的調用關系，看起來是比較亂的。我簡單梳理下。

剝離的。我們上面提到的TaskSetManager的resourceOffer方法，是task與底下資源的互動，這個資源互動的協調人是TaskScheduler，也是全局的，TaskScheduler對接的是不同的SchedulerBackend的實作(比如mesos，yarn，standalone)，如此來對接不同的資源管理系統。同時，對資源管理系統來說，他們要負責的是程序，是worker上起幾個程序，每個程序配置設定多少資源。是以這兩層很清楚，

spark本身計算架構内管理線程級别的task，每個stage都有一個TaskSet，本身是個小DAG，可以丢到全局可用的資源池裡跑；spark下半身的

雙層資源管理部分掌控的是程序級别的executor，不關心task怎麼擺放，也不關心task運作狀态，這是TaskSetManager管理的事情，兩者的協調者就是TaskScheduler及其内的SchedulerBackend實作。

SchedulerBackend的實作，除去local模式的不說，分為細粒度和粗粒度兩種。細粒度隻有Mesos(mesos有粗細兩種粒度的使用方式)實作了，粗粒度的實作者有yarn，mesos，standalone。拿standalone模式來說粗粒度，每台實體機器是一個worker，worker一共可以使用多少cpu和記憶體，啟動時候可以指定每個worker起幾個executor，即程序，每個executor的cpu和記憶體是多少。在我看來，粗粒度與細粒度的主要差別，就是粗粒度是程序long-running的，計算線程可以調到executor上跑，但executor的cpu和記憶體更容易浪費。細粒度的話，可以存在複用，可以實作搶占等等更加苛刻但促進資源使用率的事情。這倆概念還是AMPLab論文裡最先提出來并在Mesos裡實作的。AMPLab在資源使用粒度甚至任務配置設定最優的這塊領域有不少論文，包括Mesos的DRF算法、Sparrow排程器等。是以standalone模式下，根據RDD的partition數，以及每個task需要的cpu數，可以很容易計算每台實體機器的負載量、資源的消耗情況、甚至知道TaskSet要分幾批才能跑完一個stage。