一、概述
用hadoop1.x版本已经有一年多了，在使用的过程中发现hadoop1.X的资源管理机制存在诸多缺陷，甚至在这种资源管理机制下会造成服务器资源的严重浪费，负载过高或者过低。本文主要介绍hdaoop1.X的资源管理机制，这种机制的缺点，总结一下自己在这方面遇到的实际问题，最后是自己对改进hadoop资源管理机制的一些想法。
二、hadoop 1.x资源管理机制
hadoop 1.x的资源管理机制分为两部分：资源的表示方法和资源的分配。我们都知道计算机的资源是多维度的可以由CPU、内存、磁盘IO、网络IO等组成，hadoop 1.X将各个节点的这种多维度资源抽象成为了一种一维度的slot资源，此外考虑到Map Task和Reduce Task这两种任务使用的资源量不同，hadoop 1.x又将slot分成了Map slot和Reduce slot两种类型，并规定了Map Task只能用Map slot，Reduce Task只能用Reduce slot。这种设计方法的好处是简化了资源分配问题，但是也带来了一系列的问题，包括：导致节点上的资源利用率过低或者过高、对节点的负载不好控制等，下面我会根据自己在实际应用中的各种场景遇到这种问题进行分析和提出假设方案。
三、hadoop 1.x资源管理机制缺点实际场景分析以及假设解决方案
场景：
集群环境：10台16核16G内存的PC，集群配置的map并发数为110，reduce并发数为50。
作业1：需要110个Map slot，50个Reduce slot,计算密集型作业。
作业2：需要90个Map slot，40个Reduce slot，磁盘和网络IO密集型任务。
分析：
一般的PC服务器的瓶颈都在磁盘IO上，对于作业2这种IO密集型作业负载是非常大的，极端情况下如果作业2中的90-90*0.05（约等于85，因为当有5%的map运行完毕之后才会启动reduce任务）个map在运行，40个reduce在运行，那么集群的负载是远远超过125的，并且很可能超过整个集群总负载160，因为IO的等待时间太长。对于作业2这种计算密集型任务来说，负载相对会低，在极端情况下，作业2有110-110*0.05=104个map在运行，有40个reduce在运行，那么其整个集群负载会在144左右，不会超过集群总负载160。
对于这种情况，我们可以进行解决方案的假设:
假设一：如果可以动态的调整map和reduce任务的并发数（换句话说就是动态调整整个集群的slot数）那么就不会导致这种节点上的资源利用率过低或者过高情况。
假设二：如果资源表示粒度更细点，不用slot表示而是根据真实的作业资源需求，给作业分配需要CPU、内存、IO等资源，那么集群的资源就可以充分利用了。
基于上面2种假设，可以提出下面2种详细的解决方案：
（1）基于真实需求量的资源管理方案。
整个hadoop 1.X集群中存在2种slot，分别为map slot和reduce slot。但是从资源计算机资源的本质来看，这两种slot其实是同质的,都是代表相同的资源，比如CPU、IO、内存等。在实际环境中，作业队需求往往是多样化的，有点需要多些的Cpu、有的需要多写的内存等等，hadoop 1.X的这种无类别slot的资源划分粒度过于粗糙，会节点资源利用率的过高或者过低，上面的例子已经描述很清楚了。从真实资源的角度再举一个反例，例如管理员事先先规划好一个slot代表2G内存和1个CPU，如果一个应用的任务只需要1G内存，则会产生1G内存资源浪费，从而降低了集群资源的利用率；同样，如果一个应用任务需要需要3G的内存资源，则会隐式地抢占其他任务的资源，从而产生资源抢占现象，可能导致整个集群利用率过高。
现在回归到资源多维度(CPU、内存、IO等)分配的本质，根据实际的任务资源需求为其分配系统的各类资源。为了精确地控制系统资源的分配，不能够再用slot这种粗粒度的资源表示方式，而是用最直接最本质的方法让任务直接向调度器申请自己所需要的资源（比如，某个任务需要3G内存、2个CPU），而调度器则按照任务实际的需求为其精细分配对应的资源量，不再是简单地将一个slot分配给它。
这种基于真实资源需求的方案比基于slot的分配方案更加直观，可以很大程度上提高资源的利用效率。另外，hadoop 2.0已经采用了这种资源管理方案，比如yarn、corona。
（2）基于动态的slot管理方案。
根据hadoop 1.X的资源分配策略，一旦每个节点实现配置好可用的slot，即上面场景所说的map和reduce并发数，当集群启动后就无法在修改。在我们的实际应用场景中，不同的作业对资源的需求存在着巨大的差异，这种静态固定的slot分配方案往往会导致节点上的资源利用率过高或者过低。为了解决这种问题，我们不妨提出这样的假设在每个节点上安装一个slot池，它可以根据节点上负载的大小动态的调整节点上map和reduce的并发数，从而是节点上的资源得到充分合理的利用。看下面示意图：
（3）基于无类别的slot管理方案。
在MapReduce程序中，Map Task的输出结果会作为Reduce Task的输入，因此Map Task会得到优先调度，当Map Task完成数据达到一定比例（默认5%），Reduce Task才开始获得调度机会。对于一个作业来说，刚开始运行时说Map slot资源相对紧缺而Reduce slot却相当空闲，当Map Task全部运行完毕以后Reduce slot资源就变得相对紧缺而Map slot资源却很空闲。很明显，这种按照slot类别的资源管理方案有明显不足，从一定程度上降低了slot的使用效率。假设我们可以用一种直观的方案，不再区分Map slot和Reduce slot，而是只用一种slot，Map Task和Reduce Task共享这些slot，这些slot由任务调度器决定如何分配给Map Task和Reduce Task。这种方案从一定程度上提高了资源的利用效率。示意图如下：
四、总结
本文主要介绍了hadoop 1.X的资源表示和管理方案，另外根据在实际使用环境中发现这种资源管理方案的问题，提出了一些可以提高集群资源效率的解决方案。当然，这些方案的实现可行性还有待考证，但是基于真实需求量的资源管理方案已经在Hadoop 2.X中已经得到实现。
