好记性不如烂笔头---hadoop的作业调度

早期的hadoop 使用非常简单的方法调度用户作业：按照作业的提交顺序，使用FIFO调度算法来运行作业。典型情况下，每个作业都会使用整个集群，但是这样作业需要等待直到轮到自己运行。不久后，增加了设置作业优先级的功能，可以通过设置mapred.job.priority属性或者jobclient的setjobpriority()方法来设置作业的优先级，在这两种方法中可以选择VERY-HIGH,HIGH,NORMAL,LOW,VERY_LOW中的任何值。在作业调度器选择要运行的下一个作业时，选择的是优先级最高的作业。在FIFO调度算法中，优先级并不支持抢占，所以高优先级的作业仍然受阻于此前已经开始的、长时间运行的低优先级的作业。

    MapReduce1的默认调度器是最初基于队列的FIFO调度器，还有两个多用户调度器，分别为公平调度器FairScheduler和容量调度器CapacityScheduler。FIFO调度器后来增加了设置作业优先级的功能，但是优先级并不支持抢占。

公平调度器目标是让每个用户公平共享集群能力，作业放在作业池中，每个用户都有自己的作业池，即使提交作业数多也不会因此获得更多的集群资源，用map和reduce的任务槽数来定制作业池的最小容量，也可以设置每个池的权重，支持抢占机制，所以如果一个池在特定的一段时间内未能公平共享资源，就会终止运行池中得到过多资源的任务，把空出来的任务槽数让给运行资源不足的作业池。

容量调度器就是，集群有多个队列，多个队列可能是层次结构的，每个队列被分配有一定的容量，在每个队列内部，作业根据FIFO方式且考虑优先级进行调度。简言之，公平调度器强制每个作业池内公平共享，使运行的作业共享池的资源，而容量调度器主要为每个用户或队列使用FIFO独立调度。

       PS:今天做了一个实验，输入路径中含有2769个文件，文件大小最大几M，最小仅有几b，一个map对一个文件执行挖掘操作，先调度运行的map作业完成的非常慢，几乎一个小时左右完成，有的完不成还报错（Container killed by the ApplicationMaster. Container killed onrequest. Exit code is 143 Container exited with a non-zero exit code 143），后调度运行的作业完成的很快，只有几秒钟，感觉YARN作业调度的策略似乎是先调度执行大文件的map作业，在调度执行小文件的map作业。