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资源。
2) 调度策略2: 动态共享CPU cores
若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模式。
2. 应用内调度
在应用内部（每一个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相关的配置文档，这里不赘述。
【參考资料】
2. Spark Programming Guide - Actions
3. Spark Programming Guide - Transformations
============================== EOF =========================