一、YARN是如何产生的
1.在Hadoop1.x中,mapreduce在集群中的架构是:1个Job Tracker(负责资源管理和作业调度)带多个Task Tracker(定期向Job Tracker汇报本节点的健康状况、资源使用情况、任务执行情况以及接收来自Job Tracker的命令并执行)。
Hadoop1.x存在的问题:
- 单点故障:由于Job Tracker只有一个,如果它挂了,集群就没法使用了。
- Job Tracker会接收来自各个Task Tracker节点的RPC请求,随着节点规模增大,Job Tracker压力会很大。
- 而这系列版本的Hadoop仅支持mapreduce计算框架,不支持其他类型的计算框架。
2.从资源利用率的角度来看,在没有yarn之前,集群之间是独立的,例如Hadoop是一个集群,spark(计算框架)是一个集群,而Hbase又是一个集群,这样的情况就造成集群管理起来很复杂,而各个集群独立使得资源不能共享导致集群间资源浪费。
解决的思路:将所有的计算框架运行在一个集群中,共享一个集群的资源,按需分配。哪个集群需要资源就将资源分配给哪个集群,这样的集群资源利用率就高于多个独立集群的资源利用率。
3.从数据共享角度来看,海量数据在集群间移动不但耗时,硬件成本也会增加。共享集群模式可以让多种框架共享数据(HDFS上的数据)、共享硬件资源,大大减少了移动数据带来的成本(即移动计算要比移动数据好,将作业任务分配到数据所在节点上去运行,减少数据网络传输的开销)。
二、YARN(Yet Another Reource Negotiator,另一资源协调者)
一个通用的资源管理系统,为上层应用提供统一的资源管理和调度。解决了集群资源利用率、数据共享、资源统一管理等方面的问题,yarn取代了Job Tracker的角色。
YARN架构(采用Master/Slave结构——主从设备模式)
组成:
- Client:向Resource Manager提交任务、终止任务
- Resource Manager(RM):
-
集群只有一个RM,一个RM对应多个NM;
-
处理客户端的请求(启动/终止应用程序);
-
启动/监控AM,若AM挂掉,RM会在另一NM节点上启动AM;
-
监控NM,接收NM汇报的心跳信息并分配任务给NM执行;一旦某个NM故障,标记下该NM上的任务,告诉对应的AM如何处理。
- Node Manager(NM):
-
集群中有多个NM,负责单个节点资源管理和使用;
-
周期性地通过心跳信息向RM汇报本节点上资源使用情况和各个Container的运行状态;
-
接收并处理来自RM的Container启动/停止的各种命令 。
- Application Master(AM):
-
对应每一个应用程序,负责应用程序的管理;
-
AM向RM申请资源用在NM上启动相应的任务;
-
为应用程序/作业向RM申请资源(Container),并分配给内部任务;
-
与NM通信,以启动/停止任务;
-
任务监控和容错,在任务执行失败时重新为该任务申请资源以重启任务;
-
处理RM 发过来的命令(终止Container、让NM重启)。
- Container(任务运行环境的抽象):任务是在Container中运行的,一个Container既可以运行AM,也可以运行具体的Map、Reduce、MPI、SparkTask。
Mapreduce作业启动时产生Map任务——Map Task
MPI框架对应的执行任务——MPI Task
三、YARN的架构设计
yarn的工作原理
-
用户向yarn提交应用程序/作业,包括AM程序,及启动AM程序的命令和用户程序;
-
RM为作业分配第一个Container,并与对应的NM通信,要求它在这个Container中启动该作业的AM;
-
AM首先向RM注册,这样用户就可以直接通过RM查询作业的运行状态;然后再为各个任务申请资源并监控任务的运行状态,直到运行结束(AM采用轮询的方式通过RPC请求向RM申请资源);
-
AM一旦申请到资源,便与对应的NM通信,要求它启动任务;
-
NM启动任务;
-
各个任务通过RPC协议向AM汇报自己的状态和进度,以便AM随时掌握各个任务的运行状态,从而在任务失败时重新启动任务;
-
作业在运行过程中,用户可随时通过RPC向AM查询作业当前的运行状态;
-
作业完成后,AM向RM注销并关闭自己。
yarn的容错性
- RM可基于Zookeeper实现HA(高可用),避免单点故障;
- NM执行失败后,RM将失败任务告诉对应的AM,由AM决定如何处理失败任务;
- AM执行失败后,由RM负责重启(AM需处理内部任务的容错问题,保存已经运行完成的Task,重启后不用再运行).