简介
大规模数据分析框架正在朝短任务和高并行度低延时方向发展。高并行度短运行时间（百毫秒级）任务调度为作业调度器的设计带来了挑战，既要求每秒百万级调度，又要提供毫秒级延时，还要保持高可用性（high availability）。我们阐述一个分散，随机采样的调度来提供接近最优的性能，分散调度相比集中调度可以避免吞吐量和可用性限制。我们在110台机器的集群上部署了我们的调度器 Sparrow，发现Sparrow与贪心调度器的差距只有12%。
1 介绍
如今的数据分析集群运行着越来越短越来越多的任务。受到工业需求（对低延时、交互式的数据处理的需求，工业界和学术界为了以秒级时延分析数据而开发了多种内存计算框架，比如Dremel，Spark，Impala）的启发。我们欢迎这种趋势，下一代框架目标在于亚秒级响应时间。将响应时间控制到100ms的范围会催发一大批非常强劲的应用，比如，面向用户的服务可以运行复杂的并行计算，比如语言翻译以及高度定制的搜索方案。
由亚秒级任务组成的作业对调度是一个艰难的挑战。对亚秒级任务的需求不仅仅来自于低延时任务，也来自于分解长运行时间的批作业为大量的小任务。比如，一种提高公平以及缓解straggler（集群计算拖后腿的机器）的技术[17]。当任务以百毫秒级运行是，调度决定必须以超高吞吐梁的方式运行：一个包含1万台机器每个机器16核的集群，如果需要按百毫秒级运行任务，那么每秒需要做百万个调度决策。调度还需要在低延时下进行：对100ms的任务，超过几十毫秒的调度（包括了排队时延）时延将带来不可忍受的开销。由于系统以交互的方式直接面向用户，高可用性也是一个需求。这些设计需求与传统的批处理系统不同。
修改如今的集中调度器来支持亚秒级并行任务有着苦难的工程挑战，支持亚秒级任务需要处理超过目前最快的调度器两个数量级的吞吐量（Mesos[8]，YARN[16]，SLURM[10]），使用一个节点来发射所有的任务相当困难。而且高可用性需要以亚秒级的时间复制或者恢复大量的状态。
本论文探索另一个极端；我们使用一组各自的机器来进行调度，不存在集中调度也不存在逻辑上集中的状态。离散调度提供有吸引力的拓展性和可用性。通过添加调度器，系统就可以支持更多的请求，如果一个调度器出现问题了，用户可以马上请求其他的调度器。考虑到并发调度会造成调度决策冲突，提供集中调度器相似的响应时间会成为一个挑战。
我们设计了Sparrow，一个利用了二选平衡负载理论[14]无状态分布式的调度器， 二选平衡负载理论提出调度每个任务时，探测两个随机的服务器，然后将任务交给队列更少的哪个服务器。我们介绍以下三个技术来有效利用平衡负载理论：
Batch Sampling: 因为作业响应时间对尾任务等待时间很敏感（直到最后一个任务完成，这个作业才完成），二选平衡理论在并行作业中表现很差。批采样使用最近的多重选择方法[18]来解决这个问题。批采样对m个任务随机选取d*m个机器进行采样。我们发现，不像二选理论， 当作业的并行性增加的时候，批采样性能不会急速下滑。
Late Binding:二选理论有两个问题：一， 机器队列长度不是等待时间一个好的预测，二因为消息时延，同时运行的多个调度器经历竞态条件。晚绑定通过延迟分配任务，直到任务快要运行来避免这个问题。比起只使用批采样，降低了45%的平均等待时间。
Policies and Constraints: Sparrow使用多重队列来保证全局策略，还支持分析框架所需要的按作业和按任务布置。policies 和 constraints都没有在理论模型中被提到，但是在真是的集群中有很重要的影响。‘
我们在110台机器的集群上部署了Sparrow来评估Sparrow的表现。当我们调度TPC-H询问（这是一个BENCHMARK）时， Sparrow提供低于理想调度器12%时间的响应时间， 平均队列延迟低于9ms， 调度器错误恢复时间低于120ms。 Sparrow对短任务提供了低响应时延。除去离散化的调度方案，Sparrow保持了良好的公平性，隔绝了不同优先度的用户。模拟结果显示，打不过集群的规模提升到数万个核时，Sparrow依然表现良好。我们的结果显示当作业有短时延时，离散调度的Sparrow是集中调度的一个可行替代。
2 设计目标
本文着重对低时延应用的细粒度任务调度。
低时延的工作相比批处理对调度有更多的要求，因为批处理一次请求很长时间的资源，因此不需要频繁的调度。为了支持亚秒级任务，调度器必须提供毫秒级调度延时，且提供每秒百万级调度决策。额外的，因为低时延框架很可能用于直接面对用户的服务，调度器应该能容忍调度器错误。
Sparrow提供的细粒度任务调度，是集群资源管理器的补充。Sparrow不为每个任务发射进程；相反，Sparrow假设每台机器上已经有一个长时间运行的执行进程（executor process），Sparrow只需要发送一个短的任务描述（而不是很大的执行文件）。这些执行进程是由集群的（静态部分？）发射的，或通过集群的资源管理器（YARN， Mesos，Omega）发射的， 这些资源管理器也为Sparrow分配资源。
集中调度器能提供很多复杂的调度特征，Sparrow为了提供高吞吐量和低延时，对这些特征做了近似。Sparrow不支持一些限制（比如，"我的任务不能跟X用户的任务在同一个机器上运行"）， 不支持bin packing，也不支持gang scheduling。
Sparrow支持小部分能够轻易扩展，降低时延的特征，Sparrow尽量保持系统的简单。很多应用为多用户提供低时延请求服务， 当需求和超过系统负担时，Sparrow保证严格的优先度调度。Sparrow同时支持基本的任务放置限制，比如每个任务限制（比如说， 每个任务的运行应该和他的输入数据在一个机器）和每个作业限制（比如说，该作业所有的任务都应该放到携带GPU的机器上）。该特征跟Hadoop Mapreduce 和 Spark的调度器相似。
3 基于采样的并行作业调度
传统的任务调度器保持着每个机器上跑的每个任务的所有信息， 并使用这些信息来分配接下来到达的任务。Sparrow采取一个完全不同的策略：Sparrow有多个并行的调度器，调度器不维持有关集群负载的任何信息。需要调度的时候，调度器向工作机器发送信息来获得回馈，并以此来作为调度的信息。Sparrow拓展了目前的负载均衡技术[14]，[18]，并加入了晚绑定来提高性能。
3.1 术语和作业模型
集群有工作机器和调度器组成，工作机器执行任务，调度器分配任务。一个作业由m个任务组成，每个任务都被分配到一个工作机器上。作业可以被任何调度器处理。工作机器在固定数量的槽上运行任务。我们避免更加复杂的装箱问题， 这会给设计带来过多的复杂性。如果一个工作机器被分配超过他的槽的数目，他会将任务放入队列，直到做够的资源被释放。我们使用等待时间来描述一个任务被提交到这个任务被执行的间隔时间，服务时间来描述工作机器执行任务花费的时间，响应时间用来描述作业提交到作业中最后一个任务完成的间隔时间， 延时用来描述一个作业中的总的调度延时和排队延时。我们使用作业的响应时间减去作业的理想响应时间（即调度不需要时间，也不会被放入队列，等于作业中最长的任务的服务时间）。
在评估不同的调度策略时，我们假设所有的作业都是一趟任务组成的。在真是的集群中，由于作业的任务数超过用户被分配的计算资源，作业可能被分为多趟的任务执行。我们使用单趟任务模型来评估调度策略是因为单趟任务最容易收到调度策略的影响，即使一个任务被延迟也会影响到整个作业的响应时间。不过Sparrow也能出来多趟任务模型。
3.2 单任务采样
Sparrow的设计参考了二选平衡理论[14]， 二选平衡理论在无状态，随机的调度方案下降低任务的等待时间。二选平衡理论指出在调度时随机选取两个工作机器，将被调度任务分配到低负载的机器上 比 随机安排任务到一个工作机器上以指数的形式降低了等待时间[14]。
我们首先考虑直接使用二选平衡理论，调度器随机选择两个工作机器，并发送每个机器一个探测消息，探测消息是轻量级的RPC（remote procedure call）。工作机器用目前的等待队列长度回复探测，然后调度器将任务分配到那个有更短队列的工作机器。调度器对每个任务都采用这个调度方案。我们称这种方案为单任务采样。
单任务采样比起随机分配有了相当大的性能提升，但相比贪心调度器表现任然差了2倍以上。直觉上说，在单任务采样中，作业的响应时间受到作业中任务的最长等待时间制约，这使得作业的响应时间比任务的平均响应时间长了很多。我们模拟了单任务采样和随机分配的对比， 模拟的场景是10000台4核的机器，网络RTT是1ms， 每个作业包含100个任务，并按泊松分布到达， 任务的执行时间为指数分布，期望是100ms，同一个作业中的所有任务执行时间相等。测试结果如图3， 响应时间随着负载增加而增加，这是由于工作机器队列变长导致的等待时间变长。在80%负载时，单任务采样比随机分配表现好3倍，不过比起贪心调度，依然造成2.6倍的响应时间。
3.3 批采样
批采样通过共享一个作业中所有任务的探测信息来优化单任务采样[18]。单任务采样中一对探测可能运气不好得到2个重负载机器的采样如图（2a中的任务1），而另外一对探测器得到2个轻负载机器的采样（如图2a中的任务2），这样会增加作业的响应时间。批采样聚集所有任务的探测信息，然后将m个任务分配到负载最轻的机器上。如果2，单任务采样选择了队列长度为1和3的两个机器，批采样选择了队列长度为1和2的两个机器。
使用批采样调度时，调度器随机选择dm个工作机器，调度器发送探测到这dm个机器，每个机器回复一个队列长度的值，然后调度器分配任务到最低负载的m个机器上，如果我们选择d=2，那么我们就得到了2b图。
如图3，在80%负载的时候，批采样的平均响应时间只有单任务采样的73%。不过依然是贪心调度的192%。
3.4 基于采样调度的问题
基于采样的调度在高负载时表现不好有两个原因。第一，调度器根据队列长度来做决策，但是队列长度只是等待时间一个粗略的预测。即使工作机器回复任务执行时间，要准确预测任务执行时间也是相当有难度的。
采样同时存在条件竞争的问题，当多个调度器并行执行，并在一个工作机器上做决策时[13]，调度器获得的回复就不是那么准确了。考虑两个不同的调度器同时探测到一个空闲的工作机器w，两个调度器肯定分配任务到w上，然后只有一个调度器真正的将任务分配到了空队列上，因为对另一个调度器来说，信息过时了。如果这个调度器知道w不是空的话，他可能就不会分配任务到w了。
3.5 晚绑定
Sparrow使用晚绑定来解决后一个问题。使用晚绑定，工作机器不直接回复探测，而是在任务队列末端预留一个位置。当预留位置达到队列的前端，工作机器再发送一个RPC给调度器。调度器为先回复的m个工作机器分配任务，然后给剩余的（d-1）m个工作机器回复无操作信号。在这么情况下，调度器保证任务会被分配到m个最早开始任务的机器上。对于执行时间为指数分布的任务，在80%负载的情况下， 晚绑定的平均响应时间为只使用批采样的55%，跟贪心调度器的差距只有5%（如图3）。
晚绑定的缺点在于当工作节点发送RPC去请求任务时，他正处于空闲。所有我们知道的集群调度器都做了权衡：调度器等到工作节点发送消息表示它有足够的资源时才分配任务。根据我们的设定目标，这个权衡相比不采用晚绑定导致了2%的效率损失。工作节点空闲的比率是（d*RTT）/（t+d*RTT）（d指每个任务的探测数，t指平均任务执行时间）。根据我们在EC2上的未经优化的部署，平均RTT是1ms。我们期望最短的任务能在100ms内完成，我们使用的探测系数不会超过2， 以上数据得出会造成不超过2%的效率损失。对于我们的目标工作量，这个权衡是值得的。图3的数据是合并了网络延时的。在某些网络延时跟任务运行时间同等数量级的情况下，晚绑定就不值得了。
3.6 主动取消
当调度器发射了一个作业的所有任务后，它有两种方式来处理预留的探测：主动发射一个取消RPC到工作机器，或者等待工作机器请求任务，然后回复工作机器任务已发完。我们使用模拟来研究主动取消的效果，发现当负载为95%时，主动取消可以降低平均响应时间6个百分点。负载为ρ时，工作机器的空闲时间实际少于1-ρ：它使用ρ的时间执行任务，但是还需要额外的时间来从调度器请求任务。在1ms RTT， 探测系数为2，任务平均执行时间为100ms时，使用主动取消会使得工作机器的忙时间平均降低1%。当负载趋近100%时，响应时间接近无限，工作机器忙时间降低1%会导致明显的响应时间减少。当工作机器接受到主动取消前已经发送任务请求时，会导致额外的RPC：在95%的负载下，主动取消导致2%的额外RPC。我们认为这额外的RPC相比提升的性能是值得的权衡，我们实现的Sparrow也包含了主动取消功能。当网络延时对比任务执行时间比率越高时主动取消作用越明显。
4 调度政策和限制
Sparrow支持一小部分有用的政策。本节介绍两种重要的调度政策：限制任务的运行机器，资源紧张时，用户间优先级问题。
4.1 处理放置限制
Sparrow处理两种限制，按作业限制和按任务限制。这些限制在数据并行框架下非常常见，比如限制任务智能被分配到包含任务输入数据的机器上运行。如第二节提到的，Sparrow不支持一些通用的资源管理限制。
平凡的按作业限制（比如该作业所有的任务必须在包含GPU的机器上运行）是受Sparrow支持的。Sparrow从满足限制条件的机器中随机选取dm个备选，然后按照之前的方式调度。
Sparrow也支持作业内的按任务限制，比如限制任务到包含其输入数据的机器上运行。把任务分配到数据旁会减少响应时间，因为数据不需要传过网络。对于作业内的按任务限制，每个任务都有不同的运行机器集，所以Sparrow不能使用批采样来调度。相反Sparrow采用单任务采样，调度器选择两个满足限制条件的机器探测，并且可以使用晚绑定。
尽管Sparrow在处理按任务限制时不能使用批采样，Sparrow仍然能提供接近最优的响应时间，毕竟对於单任务限制，集中调度器也没有多少选择。按任务限制的作业仍然能够使用晚绑定，这就保证了任务能尽可能早的获得机器。如HDFS的存储方案会备份数据到3个地方，所以即使贪心调度也仅多一个额外选择。
4.2 资源分配政策
当需求的资源和超过资源的总量时，Sparrow调度器尽可能按照政策分配资源。Sparrow支持两种调度政策：严格优先级和加权公平分享。
Sparrow通过保持多个队列来支持一下的政策：FIFO， 早截至时间优先， 短任务优先。这些政策都可以规约成为每个作业分配优先级，然后高运行级优先。集群操作器有时也会希望直接分配优先级。为了支持这些政策，Sparrow为每个优先级保持一个队列，当资源足够时，Sparrow先回应高优先队列的预定。由于随机选择备用机器加上节点不使用复杂的协议来交互信息，低优先级的任务可能比高优先级的任务先执行。我们相信这是一个值得的权衡，因为这种机制对高优先级任务提供了良好的性能。Sparrow目前不支持抢占。
Sparrow也支持加权公平分享。每个机器对每个用户维持一个不同的队列，然后在这些队列上运行加权公平排队。这个机制按预期提供了集群范围的公平：使用同一个机器的两个用户会得到他们权重比的资源，同样，使用同一个机器集的用户会得到他们权重比的资源。我们使用这个简单的机制是因为更加精确的机制会导致问题变得复杂。Sparrow简单的机制提供了接近完美的表现。