YARN产生背景

为什么会产生YRAN?这个与MapReduce1.x的架构有关,正是因为MapReduce1.x存在许多的问题,才会产生 YARN。

MapReduce1.x的架构如下:

storm 主节点 HA机制 yarn的主节点和从节点_storm 主节点 HA机制

Hadoop1.x时,MapReduce的架构仍然是主从架构。一个JobTracker带多个TaskTracker,主节点为JobTracker,只有一个,从节点为TaskTracker,可以有多个,从节点通过向主节点发送心跳信息(heartbeat)来告诉它自己的运行情况,而主节点则是负责管理调度的工作。

JobTracker(JT):负责资源管理和作业调度。

TaskTracker(TT):定期向JT汇报本节点的健康状况、资源使用情况、作业执行情况。接收来自JT的命令,从而启动任务或杀死任务。

那么这个架构存在什么样的问题呢?

首先是单点故障的问题,所有的从节点(TT)都是跟主节点(JT)直接关联的,如果主节点不小心挂了,那么整个系统就崩溃了,就没有办法运行了。

其次,JT的压力大且不易扩展,他要接收所有从节点(TT)的心跳信息(heartbeat)和客户端的请求,JT承担的职责特别多,随着集群扩展后,那么JT的压力就会越来越大。

最后,最大的问题就是兼容性问题,它不兼容除了MapReduce外的其他框架,比如Spark是不能跑在这个系统上的。

而有了YARN之后,基于YARN之上可以运行很多其他的计算框架,不同计算框架可以共享同一个HDFS集群上数据,享受整体的资源调度。它相当于操作系统,起着调度管理的工作。

YARN概述

关于YARN的概述我们在之前的文章中已经说过了,这里就不多介绍了。

  • YARN的全称是Yet Another Resource Negotiatord。
  • 通用的资源管理系统,要申请资源统一经过YARN进行申请就行了。
  • 为上层应用提供统一的资源管理和调度。

YRAN架构

YARN的架构如下图所示:

storm 主节点 HA机制 yarn的主节点和从节点_架构_02

YARN的架构由这几个部分构成:

  1. ResourceManager(RM):资源管理器
  • 整个集群同一时间提供服务的RM只有一个,负责集群资源的统一管理和调度。一般来说RM只有一个,多了的话不好协调容易混乱,但是如果只有一个的话,如果RM出问题了整个系统就崩溃了,所以生产中尽量会再加一个作为备用,这样就算主RM挂了,备用的RM也可以继续工作,但是在同一时间提供服务的只有一个,要么是主RM,要么是备用RM。
  • 处理客户端的请求:提交作业、杀死作业。
  • 监控NM,一旦某个NM挂了,那么该NM上运行的任务需要告诉AM来如何进行处理。
  1. NodeManager(NM):节点管理器
  • 整个集群中有多个NM,负责自己本身节点资源管理使用。管理自身节点的资源,比如某一时刻还剩多少资源,NM是能知道的。
  • 定时向RM汇报本节点的资源使用情况,RM只有知道所有NM上的资源使用情况,才能合理的进行调度。对于一个特定的作业,他才知道该分配到哪个NM上去。
  • 接受并处理来自RM的各种命令,比如启动Container。NM既然作为主从结构的从节点,那么就应该听老大的话,老大给你分配了任务,让你去执行你就去执行,让你别干了你就别干了。
  • 处理来自AM的命令,AM告诉NM需要在节点上启动多少container跑task,NM才能运行。
  • 单个节点的资源管理,在跑作业的过程中,对自己节点上资源的使用和剩余多少资源必须要有数。
  1. ApplicationMaster(AM):应用程序主控程序
  • 每个应用程序对应一个,比如一个Spark或者一个MapReduce作业对应一个AM。负责应用程序的管理,为应用程序向RM申请资源,比如需要多少内存和计算量。拿到资源后再分配给内部的task进行处理。
  • 需要与NM进行通信,启动或者停止task,task是运行在container里面,AM也是运行在container里面。
  1. Container:容器
  • 封装了CPU、Memory等资源的一个容器,相当于一个任务运行环境的抽象。
  1. Client:客户端
  • 提交作业、查看作业的运行进度、杀死作业

关于这个架构我是这么理解的,可以将它与企业或者公司的管理进行对比:

Client,很简单自然就是跟公司合作的客户。提交一个作业就相当于客户跟公司一笔生意谈成了,客户提要求,公司负责帮客户去完成项目,只是这里没有金钱交易而已。

RM,相当于公司的管事的boss,权力很大,所有公司的事都要听他的。我们对照则RM的作用一条一条来理解,首先,一个公司同一时间只能有一个拍板的,不能你说你的他说他的,最后整个公司也不知道听谁的,那就彻底乱套了。如果某天老板生病了,那就只能委托一个代理暂时帮他行使管理的责任,这个代理就是备用的RM。其次,老板可以决定项目何时终止,何时开始,这个很好理解。NM相当于公司下面分设的许多部门,AM相当于某个具体项目的负责人,具体的我们待会再说,暂时先这么理解。最后,老板可以随时知道部门的情况,如果某个部门集体度假了,或者出了什么重大事故,那么自然这个部门所牵涉的项目就要被搁置,这时候对于这个项目该怎么处理,是等他们回来再继续,还是直接把项目给其他的部门,这就要问这个项目的负责人了,怎么决断就要听他的意见,毕竟这个项目是他负责的。

NM所在的整个节点,相当于公司的各个部门,唯一的区别就是,在公司中,往往不会设立两个财务部门或三个人力部门,公司的部门往往是唯一的。而YARN 的结构中,每个节点并不具有唯一性,所以我们为了类比方便,可以假设这个公司有3个开发部门,4个测试部门这样。这样RM就可以理解成这个部门的负责人,显然RM对于本部门的情况是十分了解的,包括哪个人今天有没有来上班,部门现在的工作能力如何,是不是有人还处于空闲没事做的状态等等。负责人需要定期向老板递交工作记录(心跳信息)从而让老板知道这个部门的工作能力如何啊等等这些信息,这样下次有新任务的时候,老板就知道能不能分配给这个部门。作为部门负责人,自然得听老板的话,老板给你个任务,让你立马在部门中给我组个小组(container)完成,你就要执行老板的命令。同时对于项目负责人的要求,他也要尽量可能满足,比如项目负责人说我这个项目需要你们部门哪些哪些人帮我去做,那部门负责人就按照他的要求把那些人组成一个小组去执行任务。

AM,项目负责人或团队,一个公司可能有多个项目,自然每个项目需要有一个项目负责人。项目负责人在做项目的时候必定会用到公司中的资源,比如开会需要会议室、打印机啊,那自然得跟老板去申请说,我这个项目需要利用公司的会议室、打印机等等,老板说可以啊没问题,那么他拿到这些资源后就会给每个小组说,我已经帮你们申请到这些东西了,以后你们要用的话就直接可以用了。最后,他可以跟某个部门的负责人说,我需要你们部门的几个人组成一个小组(container)来帮我做这个项目,或者你们部门的这个小组做的不行,我不要他们了。

container就是一个小组,小组内有大家可以共用的一些资源,每个项目分成一个个小的任务也是在各个小组中完成的,每个小组都属于某个部门,一个部门可以有若干个小组。

不知道这样说会不会对理解YARN的架构有所帮助,这只是我在看到这个架构时的一些理解。

YRAN执行流程

storm 主节点 HA机制 yarn的主节点和从节点_storm 主节点 HA机制_03

  1. 客户端提交一个作业请求给RM,可以是MapReduce作业,也可以Spark作业。
  2. RM会为作业分配第一个container,假设这个container运行在第二个节点上,这样RM就会与对应的NM进行通信,也就是跟第二个节点的NM说,我要在你上面启动一个container。
  3. NM在接到了RM的指令后,在NM上启动了一个container,而application master就运行在这个container之中。
  4. AM启动完了之后,会在RM中进行注册,注册了用户就可以通过RM看到作业执行的进度了。并且AM会将需要使用的资源,比如需要多少memory,向RM进行申请,如果申请到资源就美滋滋,接着进行下面的步骤。
  5. 申请到资源后,AM就在对应的NM上开始启动任务。假设需要在第一个NM启动2个task,在第三个NM上启动1个task,那么把这些通知发送给对应的NM。
  6. NM在接受到这些通知后,就知道自己需要创建几个task,于是在NM上启动相应的container,并把task放到container中去运行。

其实这个流程并不是很复杂,可以对照着之前举的公司的例子,把相应的角色带入进去理解一下流程。

我们再来思考一个问题,为什么说在1.x版本不能支持其他计算框架的运行,而使用了YARN后就可以了呢?关键在于这个流程是个通用的流程,AM作为应用程序的主控程序,如果我们对于相应的框架都做出对应的AM的实现,也就是说,如果是MapReduce,那么这里的AM就是MapReduce对应的AM,对于spark也是同样的道理。那么在YARN之上就可以运行很多计算框架了。其实可以把YARN的作用理解成可以跑各种计算框架的操作系统,就跟使用Windows操作系统,你就可以在这个操作系统上运行各种软件一样。

更多的信息可以参见hadoop官网上关于YARN架构的文档描述