依旧是关于集群作业调度的文章，发表在OSDI 2014，是微软的工作。与之前看的中心化调度工作不同，Apollo与Sparrow一样采用了分布式框架，并且和Omega一样采用了共享集群状态的方式让每个调度器都拥有全局视角。最重要的是Apollo已经部署在微软的生产环境上了，每天都要对数十亿个作业进行合理的调度，其性能肯定没得说了。
以微软当时的并行计算的生产环境为例，每个集群有超过2万台服务器，有成千上万个用户每天都向集群提交作业，对调度器来说每秒能达到数万个调度请求，并且提交的作业也是多种多样的。在这样的场景下，调度器必须能达到以下三点：
- 在上万台服务器规模的集群中，每秒要能达到数万次调度。
- 在不同的用户和群体之间，要保持公平的资源共享。
- 在进行调度决策是，要考虑到数据的局部性、作业的特点和服务器的负载等因素，并尽可能地减少作业延迟，提高集群资源的利用率。
Apollo的主要特性为以下几点：
- Apollo采用分布式和松散协调的调度框架。传统的中心式调度框架，其可扩展性有很大的限制，为了平衡可扩展性和调度质量，该工作采用了分布式的调度框架，每个调度器根据整个集群的信息独立地进行调度。
- Apollo将每个任务的完成时间最小化。Apollo通过估计模型来对每一个提交的作业的任务完成时间进行预估，模型中同时考虑数据的局部性、服务器负载和其他各种因素，并可以根据这些因素进行加权决策，估计模型还可以通过以往类似作业的运行信息来对时间估计进行进一步的细化。
- 每个调度器都拥有整个集群的信息，供其进行调度决策。Apollo引入了轻量级的硬件独立机制来为调度器提供集群中所有服务器上的资源使用情况，拱调度器使用。
- Apollo提供了一系列的校正机制。集群中可能会出现作业运行时间估计不准确、作业冲突、运行时一些不正常的行为等意外状况，Apollo提供的校正机制可以在集群运行时动态的对其进行调整。
- Apollo引入了机会调度（opportunistic scheduling）。Apollo将作业分成了两类，常规作业（ regular tasks）和机会作业（ opportunistic tasks），保证常规作业的低延迟的同时使用机会作业来提高集群的利用率，并引入了基于token的机制来管理容量并通过限制常规任务的总数来避免集群的负载过高。
- Apollo的设计是为了替代生产环境中的旧调度器，因此在设计时支持分阶段部署到生产环境中并进行验证。
上图是Apollo的整体结构图。Job Manager（JM）就是一个调度器，它负责对作业进行调度，每一个集群都会拥有一个Resource Monitor（RM），每一台服务器都拥有一个Process Node（PN），它们两个协调工作来为调度器提供一个全局的视角，供调度器进行调度决策时使用。每个PN负责对本地服务器的资源进行管理，RM会从集群 中每个服务器上的PN那里收集信息，汇总成全局信息后给每个JM。