YARN(Yet Another Resource Negotiator)是Hadoop 2中开发的一个资源管理框架,主要用于改善之前Hadoop版本中的一些问题。和Mesos类似,是一个比较通用的分布式集群资源管理框架,目前主要用在Hadoop生态圈中。不过YARN一般主要是配合一些其他计算框架使用(比如spark、MapReduce 2(Hadoop 2)、Tez等),用户一般无需关注YARN管理资源的细节,也无需使用YARN提供的API,这些细节都在计算框架中处理好了,我们只需要使用计算框架提供的功能即可。所以本文主要介绍一下YARN的基本架构和一些关键点。

架构解析

和HDFS类似,YARN也是典型的Master-Slave架构:一个集群由一个Master节点和若干个Slave节点组成。在YARN中,Master节点称为Resource Manager,Slave节点称为Node Manager,或者说Node ManagerResource Manager的代理(agent),运行在每一个Slave节点上。在YARN中一个应用称为一个Application,一个Application可能有一个job或者多个job组成的DAG构成。

Resource Manager主要由两部分组成:SchedulerApplicationManager

Scheduler负责集群中Application的调度,实质就是负责为应用分配资源。在YARN中,资源的存在形式是Container(容器),这个Container和云计算中的容器类似,一个容器是内存、CPU、磁盘、网络等资源的一个抽象,应用就运行在容器中。需要注意的是,分配资源(Container)的时候都是分配在集群中的某个Slave节点上的。

调度策略是插件式的,用户可以开发自己的调度策略,目前系统内置了三种调度策略:

  • FIFO Scheduler:最简单的策略,只有一个队列,先来的任务先执行。好处是简单,劣势是大任务可能执行时间很久,导致小任务要等很久。
  • Capacity Scheduler:有多个队列,不同队列分配不同的资源,用户可以选择将任务提交到哪一个队列中。最简单的就是分两个队列,一个队列分配少量资源,专门用来执行可以迅速返回的小任务;另外一个队列分配较多的资源,专门用于执行耗时耗资源的大任务。Hadoop默认使用该策略。
  • Fair Scheduler:动态平衡每个任务所使用的资源。比如当系统内只有一个任务时,就分给他所有资源,如果有第二个任务提交了,就从第一个任务的资源中回收一半,分给第二个任务,以此类推。CDH默认使用该策略。

Scheduler只负责分配资源,应用的管理是由ApplicationManager做的。当我们提交一个应用的时候,就是提交到了ApplicationManager这里,然后等Scheduler为该应用分配了资源(Container)后,ApplicationManager就会在该容器上拉起一个特殊的进程(process):ApplicationMaster,后续ApplicationManager只负责管理ApplicationMaster(比如当ApplicationMaster失败后,重启它)。对于一个简单的应用,可能所有的工作都由ApplicationMaster去做就行,这样改应用就只有一个ApplicationMaster,但是对于复杂的应用,ApplicationMaster还会再申请一些资源,再起一些进程,这些新起的进程也可能再起进程,那对于后续的这些进程的管理都是由这个应用的ApplicationMaster去管理,管理的具体内容就是跟踪记录进程状态,监控进程,失败的时候重启等。也就是说,ApplicationManager是ResourceManager的一部分,而ApplicationMaster则是每个应用都有一个,运行在NodeManager上面的一个容器中,作为ApplicationManager的代理,去管理每一个应用的进程。

正如前面所说,NodeManager作为ResourceManager的代理,运行在每一个Slave节点上,负责接受ResourceManager的命令分配容器,监控进程等工作。

最后附一张YARN官方的架构图:

yarn_architecture

我们以红色的客户端为例,描述一下完整的流程。客户端向ResourceManager(RM)提交了一个MapReduce应用(在MR里面称之为Job),RM(RM里面的Scheduler)选择在右边中间的NodeManager上面为该应用分配容器(分配过程由NodeManager执行),然后RM(RM里面的ApplicationManager)在该容器里面启动了ApplicationMaster,后面ApplicationMaster又多次向RM请求资源,启动了多个进程(右上的NodeManager上有一个,右下的NodeManager上有两个),这些进程都由该应用的ApplicationMaster管理。

MR1 vs MR2

这里的MR1指Hadoop 2之前的MapReduce,MR2指Hadoop 2及之后的MapReduce,也就是YARN。在MR1中,对应的Master是Jobtracker,Slave是Tasktracker

Jobtracker负责应用的调度,进程的管理,对应到YARN里面,就是ResourceManager和ApplicationMaster;同时Jobtracker还要记录已经完成的历史应用,在YARN里面也独立出来由Timeline Server去存储记录。Tasktracker对应的就是YARN里面的NodeManager。在MR1中,资源的抽象不是Container,是Slot,其灵活性和Container相比也很差。

所以可以看到,MR2中将原来Jobtracker需要做的事情分到了好几个进程上面,这样Jobtracker就不会成为集群的瓶颈,集群就可以有更大的规模,官方给的数据是MR1的上限是4000个节点和40000个任务(task),MR2是10000个节点和100000个任务。同时,集群的资源利用率也提高了。另外,MR2的设计更贴近Google发布的MapReduce论文。

对于一个资源管理框架,调度和资源分配策略是非常核心的功能,YARN也提供了非常多的功能,有很多细节本文都没有提到,比如在资源分配上,会尽量的利用Hadoop在存储上的locality特性;在调度上,使用一些延迟调度等小策略,尽可能多的提高集群的资源利用率。有兴趣的同学可以去官网查看相关文档或者参考一些权威的书籍。

References: