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
因此，在资源管理方面，Hadoop 2.0比1.0先进的多，它摒弃了基于slot的资源管理方案，采用了基于真实资源的管理方案，这将在资源利用率、资源控制、资源隔离等方面有明显改善，随着Hadoop 2.0调度语义的丰富和完善，它必将发挥越来越大的作用。
2. Yarn 框架原理及运行机制
2.1 Yarn 框架
(1) ResourceManager：以下简称RM。YARN的中控模块，负责统一规划资源的使用。它接收来自NM的汇报，建立AM，并将资源派送给AM。
(2) NodeManager：以下简称MM。YARN中的资源结点模块，负责启动管理container。
(3) ApplicationMaster：以下简称AM。YARN中每个应用都会启动一个AM，负责向RM申请资源，请求NM启动container，并告诉container做什么事情。
(4) Container：对任务运行环境的抽象。它描述一系列信息：任务运行资源（包括节点、内存、CPU）、任务启动命令、任务运行环境
Hadoop 2.0 中重构根本的思想是将 MR JobTracker 两个主要的功能分离成单独的组件，这两个功能是 资源管理和任务调度 / 监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG( 有向无环图 ) 任务。ResourceManager 和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织。
事实上，每一个应用的 ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。
上图中 ResourceManager 支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。
ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源，因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。可以看出，这同现 Mapreduce 固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件可以基于现有的能力调度和公平调度模型。
上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向调度器汇报。
每一个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。
2.2 Yarn 框架相对于老的 MapReduce 框架的优势呢
1. 这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
2. 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
3. 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
4. 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
5. Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。
2.3 以 Yarn 为基础的 Hadoop 2.0 生态系统
新一代的 YARN 容器框架，是传统的MR Hadoop容器框架的升级版本，之前的MR部署架构依赖于JobTracker和TaskTracker的交互模式，而新一代的YARN容器框架，则采用了ResourceManager和NodeManager的交互模式，更高层次的抽象和架构设计，是的YARN容器框架能够支撑多种计算引擎运行，包括传统的Hadoop MR和现在的比较新的SPARK。 Hadoop 2.0 中的资源管理框架，它是一个框架管理器，为各种框架进行资源分配和提供运行时环境。而 MRv2 则是运行在YARN之上的第一个计算框架，其他计算框架，比如Spark、Storm等，都正在往YARN上移植。
(1)离线计算框架：MapReduce
(2)DAG计算框架：Tez
(3)流式计算框架：Storm
(4)内存计算框架：Spark
(5)图计算框架：Giraph，Graphlib
注：以上内容皆来自于互联网。
