Hadoop Yarn资源管理——Hadoop1.0与Hadoop2.0对比

相关链接： Hadoop Yarn资源管理——核心组件详解

Yarn（Yet Another Resource Negotiator）是一个分布式的资源管理系统，用以提高分布式的集群环境下的资源利用率（内存、IO、网络、磁盘等）。它仍可认为采用了master/slave结构，总体上采用了双层调度架构。

1、Hadoop1.0缺陷

1. JobTracker是Map-reduce的集中处理点，存在单点故障。

2. JobTracker完成了太多的任务，造成了过多的资源消耗，当map-reduce job非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险，这也是业界普遍总结出老Hadoop的Map-Reduce只能支持4000节点主机的上限。

3. 在TaskTracker端，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM。

4. 在TaskTracker端，把资源强制划分为map task slot和reduce task slot, 如果当系统中只有map task或者只有 reduce task的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。

5. 源代码层面分析的时候，会发现代码非常的难读，常常因为一个class做了太多的事情，代码量达3000多行，造成 class的任务不清晰，增加bug修复和版本维护的难度。

6. 从操作的角度来看，现在的Hadoop MapReduce框架在有任何重要的或者不重要的变化 (例如bug修复，性能提升和特性化) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的Hadoop版本而浪费大量时间。

正是由于Hadoop 1.0存在以上这些弊端，所以Hadoop 2.0推出了资源管理器YARN，有效解决了上述问题。

2、YARN资源管理引入

从使用分布式系统的变化趋势和 hadoop 框架的长远发展来看，MapReduce 的 JobTracker/TaskTracker 机制需要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。在过去的几年中，hadoop 开发团队做了一些 bug 的修复，但是最近这些修复的成本越来越高，这表明对原框架做出改变的难度越来越大

为从根本上解决旧 MapReduce 框架的性能瓶颈，使下一代MapReduce(MRv2/Yarn)框架具有更好的扩展性、可用性、可靠性、向后兼容性和更高的资源利用率以及能支持除了MapReduce计算框架外的更多的计算框架。从 0.23.0 版本开始，Hadoop 的 MapReduce 框架完全重构，发生了根本的变化。新的 Hadoop MapReduce 框架命名为 MapReduceV2 或者叫 Yarn。

YARN中主要是三个组件：Resource Manager、Node Manager和Application Master

Resource Manager负责全局资源分配
Application Master每个节点一个，负责当前节点的调度和协调
Node Manager是每台机器的代理，监控应用程序的资源使用情况，并汇报给Resource Manager。

3、Hadoop1.0与Hadoop2.0对比

对于节点数超过4000的大型集群，mapreduce1.x系统开始面临着扩展性的瓶颈。
1.x版本中JobTracker负责作业调度和任务监视，追踪任务、重启失败或过慢的任务和进行任务等级划分等工作。

而YARN把资源管理与任务调度的工作分离开来，减少了MapReduce中Job Tracker的压力，大大减少了Job Tracker的资源消耗，并且让监测每个Job子任务状态的程序分布式化。 YARN中Application Master是一个可变更部分，用户可以对不同编程模型编写自己的AppMst，让更多类型的编程模型能跑在Hadoop集群中。

1. YARN将JobTracker的职能划分多个独立的实体
   资源管理器ResourceManager:负责整个集群资源管理，协调与分配
   应用管理器ApplicationMaster：管理集群上运行任务的生命周期（每个作业都有一个专用的应用管理器）
   这样一来，单点瓶颈的问题就算得到了解决，而且也提高了集群的扩展性。

   基本思路是应用服务器与资源管理器协调集群的计算资源（容器containers）：
   容器：对应MapReduce1中的任务槽，每个容器都有特定的内存上限，是将资源隔离出来的一种框架，每一个任务对应着一个container，且只能在该Container上运行。
   进程：在容器上运行的特定应用程序

2. YARN比MapReduce更具有一般性
   YARN中的应用主体是一个用户可自定制的部分，因此用户可针对编程模型编写自己的应用主体程序，使得YARN不再像mapreduce 1.x那么死板，不同的YARN应用可以在同一个集群上共存。
   在hadoop2.x中，实际上MapReduce只是YARN应用的一种形式

4、YARN资源管理优点
与旧MapReduce相比，YARN采用了一种分层的集群框架，它解决了旧MapReduce一系列的缺陷，具有以下几种优势：

1. 提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展
   对于运行中NameNode的单点故障，通过 NameNode热备方案（NameNode HA）实现。

2. YARN通过将资源管理和应用程序管理两部分分剥离开，分别由ResouceManager和ApplicationMaster负责
   ResouceManager专管资源管理和调度
   ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等，每个应用程序对应一个ApplicationMaster

3. YARN具有向后兼容性，用户在MRv1上运行的作业，无需任何修改即可运行在YARN之上

4. 对于资源的表示以内存为单位 (在目前版本的Yarn中，没有考虑cpu的占用)，比之前以剩余slot数目更合理

5. 支持多个框架， YARN不再是一个单纯的计算框架，而是一个框架管理器
   用户可以将各种各样的计算框架移植到YARN之上，由YARN进行统一管理和资源分配。目前可以支持多种计算框架运行在YARN上面，比如MapReduce、Storm、Spark、Flink等

6. 框架升级更容易
   在YARN中，各种计算框架不再是作为一个服务部署到集群的各个节点上（比如MapReduce框架，不再需要部署JobTracler、 TaskTracker等服务），而是被封装成一个用户程序库（lib）存放在客户端，当需要对计算框架进行升级时，只需升级用户程序库即可，多么容易。

5、运行在YARN上的计算框架

Yarn的另一个目标就是拓展Hadoop，在新的Hadoop2.x中，使得它不仅支持MapReduce计算，还有可能是其它应用。
还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，共享整个集群资源

离线计算框架：MapReduce
DAG计算框架：Tez
流式计算框架：Storm
内存计算框架：Spark
图计算框架：Giraph/GraphLib

6、hadoop2.0在最顶层包含5个独立的实体

1. 客户端：提交MapReduce作业

2. 资源管理器ResourceManager：
   是YARN资源控制框架的中心模块，负责集群上所有资源的统一管理和分配
   处理来自客户端的请求
   监控NodeManager并接收来自的汇报
   启动/监控ApplicationMaster并派送资源

3. 节点管理器NodeManager：
   负责单个节点上的资源管理（CPU，内存，磁盘）并向ResourceManager发送资源使用情况（心跳返回）
   负责处理来自ResourceManager和ApplicationMaster的命令
   负责管理容器（container）

4. 应用管理器ApplicationMaster：
   负责数据切分
   为应用程序申请资源并分配给内部任务（每个作业都有一个专用的ApplicationMaster）
   负责协调运行MapReduce作业的任务，和MapReduce任务均在容器container中运行
   任务监控与容错

5. 分布式文件系统：HDFS用来在其他实体之间共享作业文件

资源容器container：
Container是YARN中资源的抽象，它封装了某个节点上一定量的资源（CPU和内存两类资源）。
由ResourceManager分配并由NodeManager进行监控和管理，确保应用程序使用的资源不会超过分配给他的资源
YARN中所有的应用都是在container上运行的。ApplicationMaster也在container上运行