Yarn源代码分析之旅---总体架构---概述与总体架构

欢迎大家讨论，我也是接触时间不长，有问题欢迎大家指正。欢迎转载，转载请注明出处

Haddoop 1.0的不足与Hadoop2.0的产生

        学习和研究过Hadoop1.0的人都应该知道，在Hadoop1.0中，使用了Master\Slave的架构模式，jobTracker运行在单点的NameNode上，同时兼备了资源管理和作业控制两个功能，使得它成为了系统的最大一个瓶颈，严重制约了Hadoop集群的扩大；并且单点的NameNode一旦出现故障将导致整个集群不可用；而且MRV1使用槽位slot作为资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源，资源之间无法共享，利用率低；最关键的是，它无法支持多重计算框架。基于以上原因，Hadoop2.0产生了。

       Hadoop2.0的核心是yarn，它是一个独立的资源管理与分配的通用系统，yarn只负责资源管理与分配，在上面可以运行各种不同的框架。

Yarn的基本组成结构

      Yarn总体上仍然是master \ slave 结构，在整个集群中，ResourceManager充当Master，NodeManager充当Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。下图为Yarn的基本结构，YARN主要有ResourceManager、NodeManager和ApplicationMaster和Container等几个组件构成。

      ResourceManager是Master上一个独立运行的进程，负责集群统一的资源管理、调度、分配等等；NodeManager是Slave上一个独立运行的进程，负责上报节点的状态；App Master和Container是运行在Slave上的组件，Container是yarn中分配资源的一个单位，包涵内存、CPU等等资源，yarn以Container为单位分配资源。

      Client向ResourceManager提交的每一个应用程序都必须有一个Application Master，它经过ResourceManager分配资源后，运行于某一个Slave节点的Container中，具体做事情的Task，同样也运行与某一个Slave节点的Container中。RM，NM，AM乃至普通的Container之间的通信，都是用RPC机制。

Yarn详细架构设计

     下面这个图是我参考了一些资料之后，自己画出的，请看：

分别进行介绍，所有的线条都是RPC协议，Client和Admin都是yarn系统外的，Client是用户，他可以向yarn系统提交新的应用，Admin是yarn的管理员，它可以通过命令行来操作和管理yarn系统；RM(ResourceManager，以后的文章都简称RM)负责管理调度资源，NM(NodeManager，以后的文章都简称NM)负责管理Slave节点，并且定时向RM报告自己的状态，集群中有很多Slave节点。AMS(ApplicationMaste，以后的文章都简称AM)负责单个应用的资源再分配（从RM申请到资源以后，具体在分配给应用程序的任务）以及定时向RM汇报应用程序的状态。AMS也是yarn系统外的，每个提交的应用程序都需要自己去实现一个AM。大家可能会迷惑为什么ApplicationMasterProtocol和ContainerManagerProtocol在yarn系统中都已经实现了，为什么是虚线？的确这两个RPC协议都已经实现了，不过在AMS中需要自己去调用，比如ApplicationMasterProtocol协议，仅仅定义了register，stop和allocate接口，没有实现任何心跳的代码，那就需要AM自己在代码里重新开线程自己定期调用allocate去汇报自己的情况。RMClientProtocol和TaskUmbilicalProtocol是两个在MRV2的应用程序中自己实现的RPC，所以严格的来说也是在yarn系统之外的，因为MRV2已经是一个运行在yarn平台上的应用，从这点来看，yarn越来越像一个云操作系统了。

代码目录

        本系列文章，我们仅关注hadoop-yarn-project

hadoop-yarn-applications是两个系统自带的运行在yarn系统上的例子。具体的每个包是干什么用的，以后的文章会慢慢的讲到。

今天的文章先到这里。