http://www.cs.berkeley.edu/~matei/papers/2013/sosp_sparrow.pdf
http://www.eecs.berkeley.edu/~keo/talks/sparrow-sosp-talk.pdf
解决的问题
现有的scheduler方案, 都是基于master的, 因为schedule必须要知道所有slave的情况, 然后才能决定到底如果schedule
这个对于传统的batch系统是没有问题的, 因为Hadoop一个job可能需要几个小时, 在划分task的时候可以比较粗粒度, task的个数也比较少, 所以花费几秒去schedule task没有任何问题
但是随着对latency的要求越来越高, 比如spark, task的响应时间在100ms左右, 这样会存在非常细粒度的task, 同样的task数量也很多(1 million scheduling decisions per second)
那么在这种场景下, 使用基于master的schedule就会比较低效, 你无法忍受100ms级别的task, 需要同样甚至更多的时间去schedule
所以就需要一种更加low latency和high throughput的schedule方法.
下面就是Sparrow的优势, 当然在quality placement上, Sparrow会稍微差些, 这是balance
How
首先如果要快, high throughput, 要易于扩展, 用中心化的设计就会有单点问题, 所以必须去中心化
Sparrow, 就是一种去中心化的scheduler算法
但是去中心化, 如何知道全局的slave的情况?
答案就是, 你不需要知道, Sparrow是一种基于随机算法的scheduler
最简单的是每次随机选一个worker, 很快很简单, 但是太naive
Per-task sampling
所以使用two choices load balancing technique, 其实也很简单
对每个task随机选两个workers, 然后从两个里面挑一个load轻的(shortest task queue), 这种方法对每个task单独的进行sampling, 所以叫做Per-task sampling
这种方法问题, 过于随机, 运气成分比较大, 比如上图的task1, 同时选到两个都很忙的workers, 就会做出一个很差的schedule
由于Job的响应时间, 是由最差那个task决定的, 因为只要有一个没完成, job也不能算完成.
Job’s response time is dictated by the longestwait time of any of the job’s tasks
而Job的响应时间取决于表现最差的那个task, 所以当load变得比较heavy的时候, 这种差的schedule发生的几率会大增, 导致整个效率随着load变重快速下降
Batch sampling
Batch sampling就是将一个job中的所有task一起来进行sampling
比如有2个task, 先随机选取4个workers, 然后从里面选出2个load轻的, 采取这种策略明显出现差的schedule的概率会大大减小
如下图, 对于上面同样的例子, 使用Batch sampling会做出更好的schedule
这种方法从下面的performance图上看, 是要比Per-task sampling要好些, 但是仍然不太理想
原因是,
1. 以task queue里面的task的数量来进行schedule不合理, 因为task运行的时间是不一定的, 一个long task的运行时间也许远远大于几个short task的和
2. Race condition where multiple schedulers concurrently place tasks, 比如m个scheduler同时发现worker1比较闲, 这样所有scheduler都把task放到worker1上, 导致差的schedule出现
Late binding
首先因为task运行时间是比较难准确预估的, 所以采用late binding的方法
如下图, 还是上面的例子, 随机选中4个worker后, 现不做decision, 而只是在每个worker上都插入一个reservation
这样不用预估, 而是让实际的运行情况来决定, 先排到的reservation就会发通知给scheduler, request task, 而scheduler会选取最先返回的2个workers
如图, worker1虽然task数目比较多, 但是却最先执行到reservation, 这个时候worker1就可以先向scheduler request task
这个方法的问题, 当worker在request task这段时间内是idle的, 有点浪费, 是否值得就看network round trip time和task执行时间之间的比例
在作者的测试系统中, task执行时间远大于network round trip time, 所以是值得的
In our target setting, this tradeoff leads to a 2% efficiency loss compared to queueing tasks at worker machines.
Proactive Cancellation
在late binding中, 当一个job的task已经schedule结束后, 应该主动的发送Proactive Cancellation给剩下的workers, 从queue里面删除相应的reservation
如果等worker发送request task时, 再告诉它已经没有task, 会造成时间浪费
Performance
