Hadoop1.0和Hadoop2.0资源管理的对比

在Hadoop中，资源管理是很重要的一个模块，它直接决定了资源的组织形式和分配方式，是其他功能的基础，而伴随着Hadoop的优化和升级，资源管理系统在发生的重大变化，本文将对比Hadoop 1.0和Hadoop 2.0中的资源管理方案。 1. Hadoop 1.0中的资源管理方案 Hadoo

1. Hadoop 1.0中的资源管理方案

Hadoop 1.0指的是版本为Apache Hadoop 0.20.x、1.x或者CDH3系列的Hadoop，内核主要由HDFS和MapReduce两个系统组成，其中，MapReduce是一个离线处理框架，由编程模型（新旧API）、运行时环境（JobTracker和TaskTracker）和数据处理引擎（MapTask和ReduceTask）三部分组成。

Hadoop 1.0资源管理由两部分组成：资源表示模型和资源分配模型，其中，资源表示模型用于描述资源的组织方式，Hadoop 1.0采用“槽位”（slot）组织各节点上的资源，而资源分配模型则决定如何将资源分配给各个作业/任务，在Hadoop中，这一部分由一个插拔式的调度器完成。

Hadoop引入了“slot”概念表示各个节点上的计算资源。为了简化资源管理，Hadoop将各个节点上的资源（CPU、内存和磁盘等）等量切分成若干份，每一份用一个slot表示，同时规定一个task可根据实际需要占用多个slot 。通过引入“slot“这一概念，Hadoop将多维度资源抽象简化成一种资源（即slot），从而大大简化了资源管理问题。

更进一步说，slot相当于任务运行“许可证”，一个任务只有得到该“许可证”后，才能够获得运行的机会，这也意味着，每个节点上的slot数目决定了该节点上的最大允许的任务并发度。为了区分Map Task和Reduce Task所用资源量的差异，slot又被分为Map slot和Reduce slot两种，它们分别只能被Map Task和Reduce Task使用。Hadoop集群管理员可根据各个节点硬件配置和应用特点为它们分配不同的map slot数（由参数mapred.tasktracker.map.tasks.maximum指定）和reduce slot数（由参数mapred.tasktrackerreduce.tasks.maximum指定）。

Hadoop 1.0中的资源管理存在以下几个缺点：

（1）静态资源配置。采用了静态资源设置策略，即每个节点实现配置好可用的slot总数，这些slot数目一旦启动后无法再动态修改。

（2）资源无法共享。Hadoop 1.0将slot分为Map slot和Reduce slot两种，且不允许共享。对于一个作业，刚开始运行时，Map slot资源紧缺而Reduce slot空闲，当Map Task全部运行完成后，Reduce slot紧缺而Map slot空闲。很明显，这种区分slot类别的资源管理方案在一定程度上降低了slot的利用率。

（3） 资源划分粒度过大。这种基于无类别slot的资源划分方法的划分粒度仍过于粗糙，往往会造成节点资源利用率过高或者过低 ，比如，管理员事先规划好一个slot代表2GB内存和1个CPU，如果一个应用程序的任务只需要1GB内存，则会产生“资源碎片”，从而降低集群资源的利用率，同样，如果一个应用程序的任务需要3GB内存，则会隐式地抢占其他任务的资源，从而产生资源抢占现象，可能导致集群利用率过高。

（4） 没引入有效的资源隔离机制。Hadoop 1.0仅采用了基于jvm的资源隔离机制，这种方式仍过于粗糙，很多资源，比如CPU，无法进行隔离，这会造成同一个节点上的任务之间干扰严重。

该部分具体展开讲解可阅读我的新书《Hadoop技术内幕：深入解析MapReduce架构设计与实现原理》 中“第6章 JobTracker内部实现剖析” 中的“6.7 Hadoop资源管理”。

2. Hadoop 2.0中的资源管理方案

Hadoop 2.0指的是版本为Apache Hadoop 0.23.x、2.x或者CDH4系列的Hadoop，内核主要由HDFS、MapReduce和YARN三个系统组成，其中，YARN是一个资源管理系统，负责集群资源管理和调度，MapReduce则是运行在YARN上离线处理框架，它与Hadoop 1.0中的MapReduce在编程模型（新旧API）和数据处理引擎（MapTask和ReduceTask）两个方面是相同的。

让我们回归到资源分配的本质，即根据任务资源需求为其分配系统中的各类资源。在实际系统中，资源本身是多维度的，包括CPU、内存、网络I/O和磁盘I/O等，因此，如果想精确控制资源分配，不能再有slot的概念，最直接的方法是让任务直接向调度器申请自己需要的资源（比如某个任务可申请1.5GB 内存和1个CPU），而调度器则按照任务实际需求为其精细地分配对应的资源量，不再简单的将一个Slot分配给它，Hadoop 2.0正式采用了这种基于真实资源量的资源分配方案。

Hadoop 2.0（YARN）允许每个节点（NodeManager）配置可用的CPU和内存资源总量，而中央调度器则会根据这些资源总量分配给应用程序。节点（NodeManager）配置参数如下：

（1）yarn.nodemanager.resource.memory-mb

可分配的物理内存总量，默认是8*1024，即8GB。

（2）yarn.nodemanager.vmem-pmem-ratio

任务使用单位物理内存量对应最多可使用的虚拟内存量，默认值是2.1，表示每使用1MB的物理内存，最多可以使用2.1MB的虚拟内存总量。

（3）yarn.nodemanager.resource.cpu-vcore

可分配的虚拟CPU个数，默认是8。为了更细粒度的划分CPU资源和考虑到CPU性能异构性，YARN允许管理员根据实际需要和CPU性能将每个物理CPU划分成若干个虚拟CPU，而每管理员可为每个节点单独配置可用的虚拟CPU个数，且用户提交应用程序时，也可指定每个任务需要的虚拟CPU个数。比如node1节点上有8个CPU，node2上有16个CPU，且node1 CPU性能是node2的2倍，那么可为这两个节点配置相同数目的虚拟CPU个数，比如均为32，由于用户设置虚拟CPU个数必须是整数，每个任务至少使用node2 的半个CPU（不能更少了）。

此外，Hadoop 2.0还引入了基于cgroups的轻量级资源隔离方案，这大大降低了同节点上任务间的相互干扰，而Hadoop 1.0仅采用了基于JVM的资源隔离，粒度非常粗糙。

尽管Hadoop 2.中的资源管理方案看似比较完美，但仍存在以下几个问题：

（1） 资源总量仍是静态配置的，不可以动态修改。这个已在完善中，具体可参考：

https://issues.apache.org/jira/browse/YARN-291

（2）CPU是通过引入的“虚拟CPU”设置的，而虚拟CPU的概念是模糊的，有歧义的，而社区正在尝试借鉴amazon EC2中的ECU概念对其进行规整化，具体参考：

https://issues.apache.org/jira/browse/YARN-1024

https://issues.apache.org/jira/browse/YARN-972

（3）无法支持以组为单位的资源申请，比如申请一组符合某种要求的资源，目前社区也在添加，具体参考：

https://issues.apache.org/jira/browse/YARN-624

（4）调度语义不完善，比如目前应用程序只能申请的同一个节点上相同优先级的资源种类必须唯一，比如来自节点node1上优先级为3的资源大小是<1 vcore 2048 mb>，则不能再有自他大小，否则将会被覆盖掉。目前社区正在完善，具体参考：

https://issues.apache.org/jira/browse/YARN-314

3. 总结

在资源管理方面，Hadoop 2.0比1.0先进的多，它摒弃了基于slot的资源管理方案，采用了基于真实资源的管理方案，这将在资源利用率、资源控制、资源隔离等方面有明显改善，随着Hadoop 2.0调度语义的丰富和完善，它必将发挥越来越大的作用。