Spark集羣的調度分應用間調度和應用內調度兩種情況，下文分別進行說明。
1. 應用間調度
1) 調度策略1: 資源靜態分區
資源靜態分區是指整個集羣的資源被預先劃分爲多個partitions，資源分配時的最小粒度是一個靜態的partition。根據應用對資源的申請需求爲其分配靜態的partition(s)是Spark支持的最簡單的調度策略。
我們已經知道，不同的應用有各自的Spark Context且佔用各自的JVM和executor(s)。根據Spark Job Scheduling文檔的說明，若Spark集羣配置了static partitioning的調度策略，則它對提交的多個應用間默認採用FIFO順序進行調度，每個獲得執行機會的應用在運行期間可佔用整個集羣的資源，這樣做明顯不友好，所以應用提交者通常需要通過設置spark.cores.max來控制其佔用的core/memory資源。
若Spark集羣採用Mesos模式，則除上面介紹的static partitioning的調度策略外，它還支持dynamic sharing of CPU cores的策略。
在這種調度策略下，每個應用仍擁有各自獨立的cores/memory，但當應用申請資源後並未使用時（即分配給應用的資源當前閒置），其它應用的計算任務可能會被調度器分配到這些閒置資源上。當提交給集羣的應用有很多是非活躍應用時（即它們並非時刻佔用集羣資源），這種調度策略能很大程度上提升集羣資源利用效率。
但它帶來的風險是：若某個應用從非活躍狀態轉變爲活躍狀態時，且它提交時申請的資源當前恰好被調度給其它應用，則它無法立即獲得執行的機會。
3) 調度策略3: 動態資源申請
Spark 1.2引入了一種被稱爲Dynamic Resource Allocation的調度策略，它允許根據應用的workload動態調整其所需的集羣資源。也即，若應用暫時不需要它之前申請的資源，則它可以先歸還給集羣，當它需要時，可以重新向集羣申請。當Spark集羣被多個應用共享時，這種按需分配的策略顯然是非常有優勢的。
在當前Spark版本下，動態資源申請是以core爲粒度的。
需要特別注意的是，動態資源申請的調度策略默認是不啓用的，且目前只支持在YARN模式（通過設置spark.dynamicAllocation.enabled可以啓用該策略），根據Spark文檔的說明，將來的版本會支持standalone模式和Mesos模式。
在應用內部（每個Application在Spark集羣看來均是一個獨立的Spark Context），每個action（spark支持的rdd action列表見這裏）以及計算這個action結果所需要的一系列tasks被統稱爲一個"job"。
默認情況下，Spark調度器對同一個Application內的不同jobs採用FIFO的調度策略。每個job被分解爲不同的stages（spark支持的每個rdd transformation即爲一個stage，完整的transformations列表見這裏），當多個job各自的stage所在的線程同時申請資源時，第1個job的stage優先獲得資源。如果job queue頭部的job恰好是需要最長執行時間的job時，後面所有的job均得不到執行的機會，這樣會導致某些job(s)餓死的情況。
從Spark 0.8開始，Spark集羣對同一Application內的jobs的調度策略可以被配置爲"fair sharing"，具體而言，Spark對不同jobs的stages提交的tasks採用Round Robin的調度方式，如此，所有的jobs均得到公平執行的機會。因此，即使某些short-time jobs本身的提交時間在long jobs之後，它也能獲得被執行的機會，從而達到可預期的響應時間。
要啓用fair sharing調度策略，需要在spark配置文件中將spark.scheduler.mode設置爲FAIR。
此外，fair sharing調度也支持把不同的jobs聚合到一個pool，不同的pools賦予不同的執行優先級。這是FIFO和fair sharing兩種策略的折衷策略，既能保證jobs之間的優先級，也能保證同一優先級的jobs均能得到公平執行的機會。
具體的設置細節請參考Spark相關的配置文檔，這裏不贅述。
【參考資料】
1. Job Scheduling2. Spark Programming Guide - Actions
3. Spark Programming Guide - Transformations
============================== EOF =========================