欢迎大家讨论,我也是接触时间不长,有问题欢迎大家指正。欢迎转载,转载请注明出处
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系统上的例子。具体的每个包是干什么用的,以后的文章会慢慢的讲到。
今天的文章先到这里。