MapReduce: JT默认task scheduling策略

herosrx

如果没有自己定制的调度策略，MapReduce就采用自带的JobQueue策略分发task。这种基于FIFO的策略挺简单，能满足基本的业务需求，但缺点也很明显，如不能实现job的实时性、所有TT的执行能力对用户共享等问题。当然这些只是按以往理解来概括，只有了解具体实现后，才能总结它的影响。本篇blog会从task 分发的流程入手，详细描述默认调度策略的细节，然后试着总结它的优点及不足。预期在对默认scheduling策略的能力有所掌握后，熟悉Facebook提供的Fair Scheduling策略。我相信合理的scheduling策略会对job执行有好地优化。那下面就开始正题吧。

        Job在JT初始化成map和reduce task后，这些task就需要分派到TT上执行。JT喜欢被动，得到TT的heartbeat后才响应，它考虑给这个TT应该分配哪些具体的task。怎样分派的工作是由JT的task scheduling策略来决定。现在要了解的就是MapReduce的默认FIFO scheduler：JobQueueTaskScheduler。

        FIFO很容易理解，重点在于依据什么条件来做FIFO。在JobQueue scheduler中，它是由job的优先级与提交时间来确定执行顺序。对于提交到JT的job， 默认是先根据优先级再根据提交时间排序，这样的一个job队列，就是scheduling策略的job处理顺序。job排序是第一步，最重要的一步是对于特定的TT，应该给它分配哪些task。在说明这些scheduling细节之前，先了解下与细节有关的概念，比如TT的slot数目，Cluster的slot数目等。

        Slot是task执行的逻辑概念，可以理解为TT同时并发可执行多少个task的能力。Slot分为map slot和reduce slot，可由用户通过mapreduce.tasktracker.map.tasks.maximum和mapreduce.tasktracker.reduce.tasks.maximum分别设置，默认分别为2。但一个TT到底能配置多少个slot，还是与它的物理环境有关。每个task是由新启动的JVM独立执行，有多个task的时候就会有多个JVM，每个JVM消耗一部分内存，再加上DN和TT的内存消耗，机器内存可能就会不够用。这样除了考虑调配每个新启动JVM的内存限制外，还得关注下到底需要多少个新启动JVM，也就是map slot 和 reduce slot的数目。它们的设置还与机器的处理器数目有关，如果期望每个处理器执行一个task，那么总slot数就是总处理器的数目减去DN和TT用去的处理器的数目(map slot + reduce slot = processors - 2)。具体的配置还得从Cluster的实际运行效果来观察和分析。

        知道每个TT的slot数目后，Cluster的map slot 和reduce slot数目就是把Cluster中所有TT的map 和 reduce slot加起来的效果。了解这些概念后，了解下图task 分发的流程。

        流程挺简单，后面只会大致说明下，但会对scheduler做具体分析。

        第一步：Cluster运行期，每个TT都要向JT汇报状态信息，这包括TT自身的状态属性、运行在TT上每个task的状态、slot的设置情况等。这些状态信息只是源数据(raw data)，提供给JT做分析决策使用，task scheduler也需要它的。

        第二步和第三步：在JT组装对某个TT的response时，会调用task scheduler选取出适合那个TT的task。

        先计算出scheduler依赖的FIFO job queue中有多少task还没有执行，这些将要执行的task越多，当前Cluster的负载就越大。TT的负载与Cluster的负载是差不多相互影响的，如果Cluster的负载很大，那么所有TT就得满负载工作；如果Cluster将要执行的task不多的话，那么相应地TT也可以减少些task 分配。这种方式我不知道是否妥当，如果很少有job在运行，且task数量不多的时候，有些TT就可以没有task来做闲呆着，不太合适吧。

        因为MapReduce也需要做些推测式task执行或是当失败时task重做的事，所有需要为这样的task做些考虑，只有当集群中TT数大于3台的时候才去做相应地计算，减少分配给当前TT的task数，以备其它需要。

        执行task最高效的方式当然是数据在本地，减少对网络流量的压力，再次些，如果数据不在本地，在同一个rack中，不经过外围交换机，流量还是很高的。所以选择map task时就要考虑数据局部性的影响，如果有这样的task满足它的依赖数据在当前TT的本地磁盘，那么就选择这个task。如果TT中空闲map slot多着，那么尽可能多地执行这种数据局部性强的task。

        但有可能数据放在本DC的其它rack或是再狠些，就在远程其它DC上，那么搬迁数据会给task执行带来很大影响。所有默认scheduling策略规定对于这种远程拉数据的task，每次给TT最大只分派一个，太影响网速了。

        但对于reduce来说，每个TT每次最多指派一个reduce task。reduce task都需要从map task端拉数据，基本都是有网络流量的消耗，所以也没有关于网络拓扑结果的验证。

        每次在检查job中task是否可以分配给TT时，都要判断TT是否满足task所需的内存资源。如map的输出结果，或是reduce的输入数据等。不要等分配到TT后内存有异常才把问题显现出来

        第四步：将选取出的task组装到返回到TT的response中，交付由TT来执行这些task。整个scheduling流程完成。

        在清楚了scheduling细节后，我们试着总结下它的优点与不足
        优点：公平，每个用户的每个job都公平地共享着整个Cluster。
        不足：对实时性job支持不好；不能很好地针对不同用户权限提供不同的计算能力；对于推测式执行等预留task的计算还感觉有问题，等等。但毕竟这只是一个简单的scheduling雏形，不能完全适应企业需求很正常。企业应该针对业务特性，适当调整scheduling策略。