这篇论文发自SOSP 2013，又是AMPLAB的牛文（就是发Spark的那个组）。
一作是Kay Ousterhout，有幸在10月底在上海开的SOSP大会上目睹作者真容，她今年在SOSP斩获两篇文章，已经从 UC Berkeley 毕业了，现在自己创业公司名为Kelda。她在Ada Workshop上分享了自己做学术的这么一个经验，有机会写篇博客分享一下。
以下为正文。
当下的数据分析集群运行越来越多的短作业，这些短作业要求调度器能有很低的延迟、高并发和高吞吐，这一需求也在不断地推动工业界和学术界寻求新的方法。
调度毫秒级别的短作业作业对调度器来说是一个巨大的挑战，Sparrow就是在这样的背景下被提出来，其针对于短作业来实现高并发和低延迟。
Sparrow是一个分布式调度器，其不同于现在工业界用的单体式调度器，单体式调度器是整个集群只有一个调度器来处理所有提交的作业，为这些作业分配运行的机器，中心式可以看到整个集群每个节点的状态、资源使用量和空闲资源量等信息，调度器可以为新来的作业分配空闲资源比较多的机器；但是分布式调度器是集群中有多个调度器，这些调度器分散在不同的节点上，这些调度器各自为战，相互之间没有沟通，当有新的作业提交到调度器上后，调度器不会马上为其分配运行的机器（因为调度器并不知道哪些机器有空闲资源），调度器会基于一定的规则去随机探测集群中的节点状态，来寻找“最合适的”节点来运行作业（只能说是相对最合适）。
以上图（a）为例，当有两个作业到达一个调度器后，这个调度器会为每个作业在集群中随机选择2个机器来发送探测（RPC），比如调度器为task1探测了上面两个机器，为task2探测了下面两个机器，哪个机器排队的作业比较少则把作业放到哪个机器上运行（假设每个作业的运行时间是相同的）。由下图的实验结果可以看出，这种单作业采样（per-task sampling）比调度器随机放置的效果要好很多。但是，这里要思考一个问题，以上图为例，2个作业一共探测了4台机器，其中第二个作业探测的两台机器明显是比第一台探测的两个机器排队的作业要少一些，但是task1只能选择它探测的那两台机器，这种问题怎么解决呢？
为了避免这种问题，作业提出了批作业采样（batch samping），如上图（b）为例，对m个作业（m=2），每个作业探测d台机器（d=2），然后调度器根据这m*d个探测信息来选择其中最合适的m台机器，并把作业调度到这些机器上运行。由下图的实验结果可以看出，这种batch samping的方法，比per task的效果要更好一些。
但是，以上都是基于每个作业的运行时间都是相同的假设来进行的，但是现实中每个task的作业是不相同的，这样会出现以下两种问题。
- 因为多个调度器之间是独立工作，互不沟通的，如果出现多个调度器同时把作业调度到这一个机器上该怎么办？那么这台机器相对于这些作业来说可能就不是“最合适的”了。
- 现在的作业调度是根据探测时返回的机器作业队列为依据的，但也会出现这种情况：一台机器上有两个作业在排队，但是每个作业只需要10ms就可以运行结束；另外一台机器上只有一个作业在排队，但是这个作业需要100ms才能运行结束。按照现在的策略来说，调度器会将作业调度到只有1个作业排队的机器上，这样显然是不合理的。
为了解决这个问题，作者提出了后期绑定（Late binding）这样一种方式。以一个生活中的例子来解释，比如你现在在家非常非常饿，自己心目中已经选好了你最爱吃的几家餐厅，但是这些餐厅都太火爆了，每天都要排队，那怎么知道排哪个队伍能最快吃到饭呢？这时可以掏出手机，网上进行排号，当排号排到自己时参订会把位置预留下来并打电话给你，告诉你排队排到啦，位置也给你留着啦，赶快来吃饭啊~ 这样就可以在家坐等电话响就可以了，并且也能保证最快吃到饭。
后期绑定就是用这样的方法，调度器会对m*d个机器发送探测信息，当机器收到这些探测信息时，他们不急着返回信息给调度器，他们先预先留一个位置在作业的队尾（排队），当排队排到的时候再向调度器返回信息，调度器则根据最先返回信息的m台机器来调度作业。当m个作业都调度完毕后，调度器会告诉剩下的机器，不用再返回信息啦，我们这边已经调度完了，或者等这些机器返回信息后再告诉他们已经没有可以调度的作业了。
由上图的实验结果可以看到，使用了late binding的bach sampling的方法的小伙比前几种都要好。
整篇文章的结构特别的好，层层递进，容易理解，以后要多学一学这样的写作风格~