分布式系统Hadoop作业调度器及其问题的讨论

sunbird

　　Hadoop是Apache基金会下的一个分布式系统基础架构，它最核心的两个部分：分布式文件系统HDFS，存储Hadoop集群中所有存储节点上的文件；由NameNode和DataNode组成；分布式计算引擎MapReduce，由JobTracker和TaskTracker组成。
　　Hadoop使得用户可以在不了解分布式系统底层细节的情况下，轻松地根据自己的业务需求，开发出分布式应用程序。在Hadoop的实际应用中，往往存在多种应用共用Hadoop的情况，例如：

• 生产性应用：数据分析、统计计算等；
  
• 批处理应用：机器学习等；
  
• 交互式应用：SQL查询等。
  

　　因此，在Hadoop集群中，可能同时运行多道作业，不同类型的作业，作业之间可能还存在依赖关系，那么，这种情况下该如何保证整个集群计算资源得到充分的利用呢？这就要求有一个作业调度器，来保证在整个集群内有效地进行作业的调度与执行过程。
　　Hadoop作业调度器的设计采用的是插件机制，即作业调度器是动态加载的、可插拔的，同时第三方可以开发自己的作业调度器替代Hadoop默认的调度器。目前，Hadoop的作业调度器主要有以下三个：

• FIFO Scheduler：采用一个FIFO队列进行调度，在其基础上Hadoop还提供一个扩展的调度器，可以对每个job的tasks总数作限制；优点是实现非常简单、调度过程快；缺点是资源的利用率不高。
  
• Capacity Scheduler：采用多个队列，每个队列分配一定的系统容量，空闲资源可以动态分配给负荷重的队列，支持作业优先级；优点是支持多作业并行执行，提高资源利用率，动态调整资源分配，提高作业执行效率；缺点是用户需要了解大量系统信息，才能设置和选择队列。
  
• Fair Scheduler：将作业分组形成作业池，每个作业池分配最小共享资源，然后将多余的资源平均分配给每个作业；优点是支持作业分类调度，使不同类型的作业获得不同的资源分配，提高服务质量，动态调整并行作业数量，充分利用资源；缺点是不考虑节点的实际负载状态，导致节点负载实际不均衡。
  

　　虽然Hadoop自带的作业调度器原理简单且使用，但分析它的原理不难发现其存在以下问题（有些问题可能Capacity Scheduler和Fair Scheduler也并未予以考虑或者很好的解决），罗列出来以供大家讨论：

• 并未明确区分长作业和短作业：长作业一般要保证服务质量，而短作业则要求保证足够短的响应时间，但是FIFO调度器并未考虑进行区分（Facebook的Fair Scheduler进行了考虑）。
  
• 并未充分考虑到每个计算节点TaskNode的实际计算负载情况：在FIFO调度器中，JobTracker完全按照TaskNode的map/reduce slots数分配map/reduce作业运行，但是每个TaskNode节点的实际负载情况，JobTracker考虑的很少。一种方法是可以在JobTracker和TaskTracker的心跳之间，TaskTracker主动汇报其实时负载信息给JobTracker，以便JobTracker综合考虑是否为其分配新的map/reduce作业。
  
• 并未考虑在虚拟化平台下各个节点资源的分配与实际使用情况：如果在虚拟化平台下部署和应用Hadoop，那么每个VM就是一个Hadoop节点，那么同处于一个物理机上的不同VM，以及处于不同物理机上的不同VM，需要区分对待，一个物理机上的不同VM，它们之间可能被预先分配了CPU、Memory、Disk等资源，但是同时运行时还可能存在资源争用的情景，进而会影响到这些VM作为Hadoop的计算节点TaskNode时，单独使用map/reduce slots的分配方式，显得不够合理，可能出现某个VM上运行的Task滞后进而导致整个Job滞后的现象。另外，虚拟化的一些特性（如虚拟机的实时迁移技术来平衡物理机的负载，对上层应用Hadoop来说是透明的）也可以考虑在Hadoop集群中进行应用。
  
• 并未支持作业之间的依赖关系分析：如果能根据作业间的依赖关系，找到关键路径，那么就能提高作业的执行完成效率，提高响应速度。
  

　　这里只是根据自己的理解，列出的几个问题，欢迎读者提出讨论。