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 =========================