1.摘要
大型数据分析框架正在朝着缩短任务执行时间和提高并行度的方向发展来提供低延迟，任务调度器面临的主要挑战是在几百毫秒内完成高度并行的作业调度，这需要在合适的机器上每秒调度数百万个任务，同时提供毫秒级的延迟和高可用性。本文证明了去中心化、随机抽样方法可提供最佳性能，同时避免了中心化设计存在吞吐量和高可用的问题。本文在110台计算机集群上部署Sparrow，并证明Sparrow的性能与理想的调度程序的误差在12%以内。
2.介绍
当今的数据分析集群运行的时间越来越短，作业的任务越来越多。在对低延迟交互式数据处理的需求的刺激下，研究机构和同行业共同努力产生了一些框架（例如Dremel，Spark，Impala）可以在数千台机器上工作，或将数据存储在内存以秒级分析大量数据，如图1所示。预计这种趋势会继续推动开发针对次秒级响应时间的新一代框架响应时间进入100ms左右，这让新的强大的应用程序成为可能；例如，面向用户的服务在每个查询的基础上将能够运行复杂的并行计算，比如语言翻译和高度个性化的搜索。
图1：数据分析框架分析大量数据的延迟非常低
调度由简短的次秒级任务组成的作业极具挑战，这些作业不仅是因为低延迟框架出现的，也有将长时间运行的批处理作业分解为大量短时间任务的原因。当任务以几百毫秒的速度运行时，调度决策必须有很高的吞吐量：一个由10000个16核机器组成的集群并运行100毫秒任务，每秒可能需要超过一百万个调度决策。调度延迟还必须非常低：对于100 ms的任务，超过几十毫秒的调度延迟（包括排队延迟）开销是无法接受的。最后，处理框架逼近交互式时间范围，并应用于面向用户的系统中，高可用性也是必要的，这些设计需求不同于传统的批处理框架。
修改当前中心化调度程序来支持亚秒级并行任务面临艰巨的工程挑战，支持亚秒级任务需要处理比现有最快的调度程序（比如Mesos, YARN, SLURM）高两个数量级的吞吐量；通过单个节点调度和启动所有任务很难满足此设计要求。另外，要实现高可用性需要在亚秒级的时间内恢复大量状态。
本文探讨了设计领域中的相反极端：建议从一组自动运行且没有中心化或逻辑中心化状态的机器进行调度。去中心化设计提供了非常优秀的扩展性和可用性，系统可以通过添加更多调度器来支持更多请求，如果调度器异常，则用户可以将请求定向到其他调度器。考虑到同时运行的调度程序可能会做出相互冲突的调度决策，因此去中心化设计的关键挑战是提供与中心化调度器可比的响应时间。
本文提出了Sparrow，一种无状态的分布式调度器，它将Power of Two Choices负载均衡技术应用并行任务调度的领域。Power of Two Choices是通过探测两个随机服务器并将任务放置在队列较少的服务器上来调度每个任务。本文介绍三个方法，可以让Power of Two Choices在运行并行作业的集群有效果：
批量抽样：对于并行作业，Power of Two Choices表现较差，因为作业的响应时间取决于最后完成任务的等待时间，而最后完成任务的等待时间在Power of Two Choices下仍然很高。批量抽样将多选方法（A Generalization of Multiple Choice Balls-into-Bins，）应用于并行作业调度领域来解决此问题。批量抽样不是将每个任务单独进行抽样，而是将m个任务放置在d*m个随机选择的worker中负载最少的worker上（d> 1）。本文通过分析证明，与Power of Two Choices不同，批量抽样的性能不会随着作业并行度的提高而降低。
后期绑定：Power of Two Choices存在两个性能问题：1.服务器队列长度不能很好地表示等待时间；2.由于消息传递延迟，多个并行调度器可能会遇到竞争状况。后期绑定通过将任务延迟分配给节点，直到节点准备好运行任务来避免这些问题，并且与只做批次抽样相比，平均响应时间减少了多达45％。
策略和约束：Sparrow在worker上使用多个队列来实现全局性策略，并支持分析框架需要的按作业和按任务放置的约束。无论是策略执行和约束处理用一个简单的理论模型都可以解决，但是两者在实际集群中都起着重要作用。
本文将Sparrow部署在110台机器上的群集中以评估其性能。调度TPC-H查询时，Sparrow的响应时间与理想调度程序的差距在12％以内，调度中值排队延迟小于9ms，并在小于120ms的时间内从故障中恢复。Sparrow可为任务较短的作业提供较短的响应时间，即使任务数量要大3个数量级。尽管采用了去中心化设计，Sparrow仍保持合计（累加）的份额公平，同时隔离不同优先级的用户，这样恶意的低优先级用户最多可将高优先级作业的响应时间增加40％。仿真结果表明，随着群集增加到数以万计的CPU核，Sparrow表现依然良好。本文的结果表明，实现低延迟、并行的workload，使用Sparrow分布式调度可以作为替代中心化调度的一种可行的方案。
3.设计目标
本文针对低延迟应用程序的细粒度任务调度，与批处理workload相比，低延迟workload对调度的要求更高，因为批处理workload会用更多的时间获取资源，任务调度相对很少。为了支持由亚秒级任务组成的workload，调度程序必须提供毫秒级的调度延迟，并每秒支持数百万个任务调度决策。此外，由于低延迟框架可用于增强面向用户的服务的能力，低延迟workload的调度程序应该能够容忍故障。
Sparrow提供细粒度的任务调度，这是对群集资源管理器功能的补充。Sparrow不会为每个任务启动新的进程，相反，Sparrow假定每台worker计算机上已经运行了一个运行时间很长的进程，因此Sparrow在启动任务时仅需要发送简短的任务描述（而不是大的二进制文件，比如执行任务的镜像）。这些执行程序进程可以在集群启动的时候启动，或者Sparrow与其他框架（比如传统的批处理处理框架）一起通过集群资源管理器（例如YARN, Mesos, Omega）分配资源。
为了提供更高的调度吞吐量和更低的延迟，Sparrow在调度和权衡很多由尖端的中心化调度程序支持的复杂特性上也会做出近似。特别是，Sparrow不允许某些类型的放置约束（例如x用户任务不能和y用户任务运行在同一个机器），不支持bin packing（任务指定机器运行）和gang scheduling（作业的任务要么全调度要么全不调度）。
Sparrow以易于扩展、最小化延迟并保持系统设计简单的方式支持少量特性，许多应用程序运行来自多个用户的低延迟查询，因此当总需求超过容量时，Sparrow会强制执行严格的优先级或加权份额公平。Sparrow还支持基本的作业放置约束，例如按任务的约束（例如输入数据在哪任务就在哪执行）和按作业的约束（所有任务必须放置在具有GPU的机器上）。这些特性类似于Hadoop MapReduce和Spark的调度器。
4.基于抽样的并行作业调度
传统的任务调度器维护着哪些worker上正在运行的任务的完整视图，并根据这个视图将任务放置到可用的worker上。Sparrow采取了截然不同的方法：多个调度器并行运行，并且调度器不维护有关集群负载的任何状态。为了调度作业的任务，调度器依赖从worker获取的瞬时负载信息。Sparrow的方法将现有的负载平衡技术扩展到并行作业调度的领域，并引入了后期绑定以提高性能。
4.1术语和作业模型
我们假设一个集群由执行任务的worker和将任务分配给worker的scheduler组成。作业（job）包含m个任务，每个任务(task)分配给一个worker。作业可以由任何scheduler处理。worker在固定数量的槽位中运行任务；避免使用更复杂bin packing，因为这会增加设计的复杂性。如果并发的任务数量多于worker的槽位，将对新任务进行排队，直到现有任务释放足够的资源来运行新任务。本文使用等待时间(wait time)来描述从任务提交scheduler到任务开始执行的时间，使用服务时间(service time)来描述任务在worker上运行的时间。作业响应时间(job response time)描述了从作业提交到scheduler到最后一个任务完成执行的时间。本文使用延迟（delay）来描述由于调度和排队而导致的作业中的总延迟。通过计算作业响应时间和所有任务以零等待时间被调度的作业响应时间（相当于作业中任务最长的服务时间）之间的差值来计算延迟。
在评估不同的调度方法时，假设每个作业都是能够一波任务运行。在实际集群中，当m大于分配给用户的槽位数时，作业可能会多波任务运行。对于多波作业，scheduler可以执行早期任务进而不影响作业响应时间。
在评估调度技术时，假设采用单波作业模型，因为单波作业最能考验调度分布式调度方法：即使是单个延迟的任务也会影响作业的响应时间。当然，Sparrow也是可以处理多波工作的。
4.2单任务抽样（per-task sampling）
Sparrow的设计灵感来自Power of Two Choices的负载均衡技术，该技术使用无状态的随机方法可以缩短预期的任务等待时间。Power of Two Choices提出了对将任务随机分配给worker的简单改进：将每个任务放置在两个随机选择的worker负载最少的一个上。与使用随机放置相比，以这种方式分配任务指数级减少了等待时间。
首先考虑将Power of Two Choices技术直接应用于并行作业调度，scheduler会为每个任务随机选择两台worker，并向每台worker发送一个探测消息（probe），探测消息是轻量级的RPC调用。每个worker都会用当前排队的任务数响应探测消息，然后scheduler将任务放在队列最短的worker上。scheduler对作业中的每个任务重复此过程，如图2所示。将Power of Two Choices技术的应用称为单任务抽样。
图2：并行放置作业的两个任务，单任务抽样选择长度为1和3的队列
与随机放置相比，单任务抽样可以提高性能，但与omniscient scheduler相比，其性能仍然差2倍甚至更多（omniscient scheduler基于worker完整的负载信息使用贪婪调度算法，将任务放在空闲的worker（如果有）上，否则使用FIFO排队）。直观地讲，单任务抽样的问题在于作业的响应时间取决于任何一个任务的最长等待时间，使平均作业响应时间大大高于（并且对最后完成任务特别敏感）平均任务响应时间。本文模拟了由10,000个4核计算机、网络往返时间为1ms组成的集群中单任务抽样和随机放置的情况。作业是Poisson process(最广泛的计数过程之一)，每个作业包含100个任务。现实中作业的任务运行时间是以100ms为均值指数分布的，但是某些特殊的作业的任务的执行时间是相同的（使用这种分布可以给调度带来了最大的压力，当作业中的任务的持续时间不同时，较短的任务可以具有更长的等待时间而不会影响作业响应时间）。如图3所示，响应时间随着负载的增加而增加，这是因为scheduler成功找到空闲计算机放置任务的成功率较低。与随机放置相比，在80％的负载下，单任务抽样将性能提高了3倍以上，但响应时间仍然是omniscient scheduler所提供的响应时间的2.6倍以上。
图3：10000个4核计算机的模拟集群中运行100任务/作业的调度技术比较
4.3批量抽样（batch sampling）
批量抽样改进了单任务抽样，通过在特定作业内共享所有探测信息。单任务抽样一对探测请求可能运气不好抽样了两台负载率较高的机器（如图2中Task1那样），而另一对可能很幸运抽样到两个负载率较低的机器（如图2中Task2那样），有一个负载率最低的机器并没有使用。批量抽样汇总了针对作业所有任务探测的负载信息，并将作业的m个任务放置在所探测的所有工作机中负载最少的worker。在图2的示例中，单任务抽样将任务放置在长度为1和3的队列中，批量抽样将Task1和Task2都放置到了Task2抽样的worker上，如图4所示：
图4：批量抽样选择长度为 1 和 2 的队列
要使用批量抽样进行调度，scheduler会随机选择d*m个worker（d≥1），scheduler将发送探测消息给每个d*m worker，与单任务抽样一样，每个worker都会答复排队任务的数量。scheduler将作业的m任务放在负载最少的m个worker。除非另有说明，否则本文默认d = 2。
如图3所示，与单任务抽样相比，批量抽样可提高性能。在80％的负载下，批量抽样的响应时间是单任务抽样的响应时间的73%。尽管如此，批量抽样的响应时间仍比omniscient scheduler的响应时间差1.92倍。
4.4基于抽样调度的问题
由于两个问题，基于抽样的技术在高负载下的性能较差：1.scheduler根据worker上的队列长度放置任务，但是队列长度仅提供对等待时间的粗略预测。试想一个scheduler放置一个任务探测两个worker的情况，其中一个排队两个50ms任务，另一个排队一个300ms任务。scheduler会将任务放入只有一个任务排队的worker中即使该队列将导致300ms较长等待时间。尽管worker可以估计任务执行时间而不是队列长度来进行答复，但是准确预测任务执行时间却非常困难。2.几乎所有的任务执行时间估算都需要准确才能使这种技术有效，因为每个作业都包含许多并行任务，所有任务都必须放在等待时间短的机器上以确保良好的性能。
抽样还受到竞争条件的困扰，在该竞争条件下，多个scheduler同时将任务放置在看起来负载较轻的worker上。试想两个不同的scheduler同时探测同一台空闲工作机w的情况，显而易见，两个scheduler都可能在w上放置任务。但是，放置在worker上的两个任务中只有一个会进入空队列。如果scheduler知道任务到达时w将不会处于空闲状态，则排队的任务可能会被放置到其他的队列中。
4.5后期绑定
Sparrow引入了后期绑定来解决上述问题，worker不会立即答复探测消息，而是在worker内部队列的末尾为任务保留位置。当此保留位置到达队列的头部时，worker将向scheduler发送RPC请求一个相应作业的任务。scheduler将作业的任务分配给前m个worker作为回复，回复其余(d − 1)m worker无任何操作，表明所有任务均已启动。通过这种方式，scheduler保证任务将被放置在被探测的worker上，并在最快的时间启动它们。对于任务执行时间呈指数分布、集群负载为80％时，后期绑定提供的响应时间是批量抽样的响应时间的55%，使响应时间与omniscient scheduler相比达到5％（4毫秒）之内（如图3所示）。
后期绑定的缺点是，worker在向scheduler发送RPC请求新任务时处于空闲状态，当前我们知道的所有群集调度器权衡利弊都会做出这样的选择：scheduler会等待分配任务，直到worker发出信号说它有足够的可用资源来启动任务。与在worker上排队的任务相比，这种折衷会导致2％的效率损失。worker在请求任务时空闲的时间占比是 (d · RTT)/(t + d · RTT) （其中 d 表示每个任务的探测数，RTT 表示平均网络往返时间，t 表示平均任务服务时间）。在云服务器上部署未优化的网络栈，平均网络往返时间是 1 毫秒。我们预计最短的任务将在 100ms 内完成，并且调度程序将使用不超过 2 的探测比，最多导致 2% 的效率损失。对于本文的目标workload，这种取舍是值得的，如图 3 所示的结果（其中包含网络延迟）就说明了这一点。在网络延迟时间与任务运行时间比较相当的环境，后期绑定不会带来价值。
4.6主动取消
scheduler启动某个作业的所有任务后，可以通过以下两种方式之一来处理剩余的挂起的探测消息（作业的任务探测消息发给了worker1,worker2......workern，worker1,worker2.....workeri取走了所有任务，那么剩余的worker的探测消息就是挂起的）：它可以主动向所有挂起的worker发送取消RPC，也可以等待worker请求任务并通过没有剩余未启动的任务来答复这些请求。我们使用模拟环境对使用主动取消的好处进行建模，发现主动取消在集群95％的负载下将中位响应时间降低了6％。在给定的负载ρ下，worker的忙碌时间超过了ρ的时间：他们花费ρ的时间来执行任务，但是他们花费额外的时间从scheduler中请求任务。通过使用1毫秒网络RTT进行取消，探测比率为2，平均任务时间为100毫秒，可以将worker的忙碌时间减少大约1％；因为当负载接近100％时响应时间接近无穷大，因此worker在忙碌时间上减少1％导致响应时间明显减少。如果worker在已经请求任务之后收到取消，则取消会导致其他RPC：在95％的负载下，取消会导致2％的额外RPC。我们认为，额外的RPC是提高性能的值得权衡的选择，并且Sparrow实现了主动取消。当网络延迟与任务执行时间的比率增加时，主动取消任务的帮助会更大，因此，随着任务执行时间的减少，主动取消将变得更加重要，而随着网络延迟的减少，主动取消的重要性将降低。
5.调度策略与约束
Sparrow的目标是在去中心化的框架内支持少量有用策略，本节介绍支持的两种流行的调度策略：在哪个worker启动各个任务的约束，以及在资源充足时用户间隔离策略控制用户的相对性能。
5.1放置约束处理
Sparrow处理两种类型的约束，按作业和按任务的约束。数据并行框架通常需要此类约束，例如，在保存任务输入数据的磁盘或内存所在计算机上运行任务。如第2节所述，Sparrow不支持某些通用资源管理器支持的许多类型的约束（例如，作业间亲和）。
按作业的约束（例如，所有任务都应在具有GPU的worker上运行）在Sparrow调度器很容易处理。Sparrow从满足约束的worker子集中随机选择d*m候选worker。一旦选择了要探测的d*m worker，调度便会按照前面描述的进行。
Sparrow还处理按任务约束的作业，例如将任务限制为在输入数据所在的计算机上运行。将任务与输入数据放置在一起通常会减少响应时间，因为不需要通过网络传输数据。对于具有按任务约束的作业，每个任务约束不同造成可抽样的worker不同，因此Sparrow无法使用批量抽样来汇总作业中所有探测信息。相反，Sparrow使用单任务抽样，其中scheduler从要限制其运行的worker集合中选择两台worker来探测每个任务，并进行后期绑定。
Sparrow对具有按任务约束的作业在每个任务抽样上实现了一个小的优化。与其对每个任务进行单独探测，Sparrow尽可能跨任务共享信息。例如假设一种情况，任务0被约束在机器A，B和C中运行，而任务1被约束在机器C，D和E中运行。假设scheduler检测了任务0的计算机A和B它们负载较重，对于任务1探测机器C和D都是空闲的。在这种情况下，即使C和D两台机器都作为任务1的探测对象，Sparrow也会将任务0放置在机器C上，将任务1放置在机器D上。
尽管Sparrow不能对具有按任务约束的作业使用批量抽样，但是我们的分布式方法仍然为这些作业提供接近最佳响应时间，因为即使是中心化scheduler，对于放置每个任务的位置也只有很少的选择。具有按任务约束的作业仍可以使用后期绑定，因此可以确保scheduler将每个任务放置在将更早运行任务的两台探测计算机中的任何一台上。像HDFS这样的存储通常会数据会有三副本分别存储在三台不同的计算机上，因此读取输入数据的任务将被限制为在输入数据所在的三台计算机之一上运行。结果，即使是理想的omniscient scheduler，对于放置每个任务的位置也没有什么其他选择。
5.2资源分配策略
当对资源的总需求超过容量时，集群调度程序将根据特定策略分配资源。Sparrow支持两种类型的策略：严格优先级和加权份额公平。这些也是其他调度程序（包括Hadoop Map Reduce调度程序）提供的策略。
许多群集共享策略简化为使用严格的优先级，Sparrow通过在worker上维护多个队列来支持此类策略。FIFO、最早deadline优先、为每个作业分配优先级以及优先运行最高优先级的作业。例如，以将任务deadline较早的作业分配给更高的优先级。集群操作者也可能希望直接分配优先级，例如将生产作业优先或者临时作业优先。为了支持这些策略，Sparrow在每个worker上为每个优先级维护一个队列。当资源变为空闲时，Sparrow会从优先级最高的非空队列中响应探测消息。此机制以简单性换取准确性作为代价：节点无需使用复杂的协议来交换有关正在等待调度的作业的信息，但是如果低优先级作业的探测消息到达没有高优先级作业的节点，则低优先级作业可以在高优先级作业之前运行。我们认为这是一个值得的取舍：此分布式机制为高优先级用户提供了良好的性能。当高优先级任务到达运行低优先级任务的worker时，Sparrow当前不支持抢占，未来会探索任务抢占。
Sparrow还可以执行加权份额公平，每个worker为每个用户维护一个单独的队列，并对这些队列执行加权公平排队。该机制可提供预期的群集范围内的份额公平：使用相同worker的两个用户将获得与他们的权重成比例的份额，以此扩展，因此使用同一组机器的两个用户也将被分配与他们的权重成比例的份额。我们选择这种简单的机制是因为更精确的机制（例如Pisces）会增加相当大的复杂性，后续的章节会说明Sparrow的简单机制提供了近乎完美的份额公平。
6.分析
在研究实验评估之前，通过分析发现，在进行一些简化的假设后（不管任务执行时间的分布）批量抽样可达到接近最佳的性能。第4节证明了Sparrow的表现不错，但仅在一种特定的workload下，本节将这些结果推广到所有workload。本文还证明了通过单任务抽样，性能会随着作业中的任务数量增加呈指数下降，使其不适合并行workload。
为了分析批量和单任务抽样的性能，本文检验了将所有任务放在空闲计算机上的可能性，或等效地提供零等待时间。与最佳调度程序相比，量化Sparrow的方法多久将作业交给空闲的worker就可以确定Sparrow的性能。
为了进行此分析，本文做出一些简化的假设。本文假设网络延迟为零，服务器数量无限大，并且每个服务器一次运行一个任务。本文的实验评估显示了在没有这些假设的情况下的结果。
| n |
集群中服务器数量 |
| ρ |
负载 |
| m |
每个作业的任务数量 |
| d | 每个任务探测数量 |
| t | 平均任务服务时间 |
| ρn/(mt) |
平均请求到达率 |
表1：符号说明
表2：三种不同的调度技术，作业等待时间为零的概率
数学分析证实了第4章节中的结果，表明单抽样对并行作业的表现效果较差。将指定任务放置在空闲计算机上的概率是1减去所有探测消息命中繁忙计算机的概率：1-ρd（其中ρ表示集群负载，d表示探测比率，详情见表1）。作业中所有任务分配给空闲计算机的概率为(1-ρd)m（如表2所示），因为所有m组探测消息必须命中至少一台空闲计算机。这种可能性随着任务中任务的数量增加呈指数下降，这使得单任务抽样不适用于调度并行任务。图5说明了10个任务和100个任务的作业等待时间为零的概率，并且证明在20％的负载下，100个任务的作业经历零等待时间的可能性降至<2％。
图5：单核环境中使用随机放置、单任务抽样(d=2)和批量抽样(d=2)作业零等待时间的概率
批量抽样比单任务采样可以在集群负载高得多的情况下将作业的所有任务放在空闲计算机上，可以推出，只要d≥1/(1-ρ)，批量抽样就可以将所有m个任务放在空队列中。最重要的是，该表达式不取决于作业中的任务数（m）。图5展示了这种效果：对于10个任务和100个任务的作业，在50％的负载下零等待时间的概率从1降低到0。
到目前为止的分析考虑了一次只能运行一个任务的机器，但是，当今的集群通常都是多核计算机。多核计算机明显提高了批量抽样的性能，假设一个模型，其中每个服务器可以同时运行c个任务。每次探测等于探测了c个处理单元上的负载，而不只是一个负载，这增加了找到运行每个任务的空闲处理单元的可能性。为了分析多核环境中的性能，本文做出两个简化的假设：首先，本文假设一个核处于空闲状态的概率与同一台机器上其他核是否处于空闲状态无关；其次，本文假设即使多个核处于空闲状态，scheduler也最多在每台计算机上放置1个任务（在空闲计算机上放置多个任务会加剧“淘金热效应”，在此情况下，许多scheduler会同时将任务放置在空闲计算机上）。基于这些假设，可以将表2中的ρ替换为ρc以获得图6所示的结果。与单核结果相比，这些结果得到了显著改善：对于每台机器4个内核，每个作业100个任务的批量抽样，批量抽样在负载高达79％的情况下可获得接近完美的性能（99.9％的作业零等待时间）。该结果表明，在一些简化的假设下，无论任务执行时间的分布如何，批量抽样都表现良好。
图6：在四核服务器系统中作业零等待时间的概率