Sparrow——分布式、低延时调度器

        有半年没写东西了，今天给大家分享下加州大学伯克利分校的Sparrow调度器。

        大规模数据分析框架正朝着两个发展趋势在变化：更短的任务执行时间和更大的并行度。调度100ms内完成的高并发的作业对调度器来说是一个巨大的挑战，与此同时还要保证高吞吐率和高可用性。

         当前分布式处理框架中的调度主要是分层调度的方法。例如Mesos/Yarn，有一个Master中心节点同时维护作业和资源两类信息，调度效率较低，不能很好的胜任短作业的调度。

         而Sparrow的出现主要就是为了解决时间短、实时性高的作业（如语言翻译、个性化搜索等方面的应用）。Sparrow采用了分布式的调度方法，而且不保存集群的负载状态。通俗来讲就是：以前的Mesos/Yarn等调度器Master节点保存了整个集群的负载情况，当提交新的作业后，调度器会主动向有空闲资源的节点上安排任务。而Sparrow的调度器不止有一个，分布在多个节点上，多个调度器甚至都不需要共享信息。当提交新的作业后，不是主动向节点安排任务，而是基于规则去集群中探测节点的时间状态，找到“最合适”的节点来运行任务。这个探测规则的思想我感觉十分地巧妙，正是我下面要谈到的。

         现在把Sparrow的大体思想说一下：首先是取样方法：

        图（a）是对每个任务取样：作业中有两个任务，调度器为每个任务独立地随机探测两个工作节点，并且以节点的等待队列长度来衡量哪个节点更好（假设每个任务需要的执行时间是一样的），如果该节点没有其它任务在排队，则直接调度任务；否则把任务丢到队列短的那个节点的队列末尾以等待执行。

        图（b）是批量取样：与图（a）对比来说，每个任务需要探测2个节点，有两个任务，总共需要探测4个节点，然后从这4个节点中找出队列最短的那2个节点来执行这两个任务。从上图这种假设的情况可以看出，图（b）批量取样效果更好。

        说到这里问题就来了？（挖机技术哪家强？）

        Sparrow是不是就是完全用批量取样的思想呢？批量取样还有什么问题吗？

        肯定是有问题的。问题就在刚才的假设上：“假设每个任务需要的执行时间是一样的”。每个任务的执行时间肯定不可能是一样的啊，所以单单以队列长 短来判断等待时间明显不合理。因此，Sparrow又加以使用了后期绑定技术。何谓后期绑定？

        我先举一个生活中的例子。假如我们中午去吃饭，几家餐厅都没座位（空闲资源）了。还都有人（任务）在排队。我们可以看看哪家等着的人比较少（队列短），我们就在那家排队。另一种方法就是我们跟服务员说一下我们要先去下商场，帮我们排个队，如果轮到我们就给我们打电话让我们过来吃饭。然后我们出去玩了，哪家先给我们打电话，我们就去哪家吃，然后我们跟另外的几家说我们已经找到吃的地方了，不用再给我们留位子了。这是不是更好的选择呢。后面这种预留的方式就是后期绑定。

        在任务的调度中讲，也就是假设一个作业有m个任务，对每个任务探测d个（一般d取2）节点，然后调度器向dm个节点发送探测信号，每个节点在队列末尾加一个“预留位置”，当节点执行到“预留位置”时，就会向调度器发送一个可以接受任务的消息，然后执行该任务。当调度器已经成功调度了前m个（任务总数）任务后，向剩下的（d-1）m个节点发送一个不用操作的信号，表明所有的任务都已经调度完了，没必要再等了。

         如果对整个调度的流程不清楚的话，看一下上面这个RPC调用图就会豁然开朗了。

        使用Sparrow的框架被分解成前端和执行器。前端生成任务，执行器运行任务。框架通过与一系列分布式的Sparrow调度器之一交互来调度作业。每个节点上都运行一个Sparrow节点监视器来监视节点的资源使用情况。

        这是在100个节点的集群上，把集群利用率固定在80%，每个作业含10个任务，响应时间随任务时间的下降函数。可以看到当任务时间较长（>1500ms）的时候，Spark原生的调度器调度效果也不差。但是当任务时间小于1500ms后，Spark原生的调度器陷入崩溃。但Sparrow还依然可以正常调度，跟完美的调度（没有等待时延）所差无几。

        所以说Sparrow在短任务的调度上表现十分优秀。

        以上是自己对Sparrow的一点理解，有不对的地方，欢迎指正。

          参考资料：Sparrow: Distributed, Low Latency Scheduling