大数据培训新三板挂牌机构 股票代码:837906 | EN CN

论文”Apache Hadoop YARN: Yet Another Resource Negotiator”解析

于2017-03-29由小牛君创建

分享到:



关于Hadoop YARN的论文《Apache Hadoop YARN: Yet Another Resource Negotiator》已经发表在了SoCC’13上,这篇论文全面解析了YARN的产生背景、基本架构以及实际生产环境使用情况,而本文将尝试解析这篇论文。

在第一代Hadoop中,MapReduce最初只有FIFO调度器,无法支持多用户多队列应用场景,为此引入了HOD(Hadoop On Demand),它通过资源管理系统Torque将一个物理Hadoop集群隔离出若干个虚拟Hadoop集群,以应对不同类型的应用程序相互干扰的问题。但HOD存在两方面的问题:(1)它只对计算资源进行了隔离而未对存储资源进行隔离,这使得数据本地性(Data Locality)变得非常差,而在数据密集型应用中,数据本地性是必须要考虑和优化的,很显然HOD在这方面存在极大的欠缺;(2)HOD隔离出的虚拟集群之间无法进行资源共享,即当一个集群空闲时,无法通过一定的机制将这些资源共享给其它忙碌的集群,这使得集群总体资源利用率较低。为了弥补HOD存在的问题,后来又引入了多用户多队列调度器,典型的代表是yahoo!的capacity scheduler和fair scheduler,这些调度器至今仍被大部分公司采用,但仅从调度器并不能从根本上解决MapReduce架构上存在的问题:(1)无法支持更多的计算模型:MapReduce将两阶段计算模型Map-Reduce固化到Hadoop中系统中,无法很容易的支持更多的计算框架,比如DAG或者迭代计算框架,尽管当前很多计算框架,比如Giraph,通过在Map-Only类型的作业中初步实现了BSP模型,但用于Map类型资源均是一样的,无法实现资源定制化;(2)应用程序相关和资源管理相关的逻辑全部放在一个服务(JobTracker)中,使得主服务压力过大,进而限制了系统的扩展性。为了解决这些问题,YARN便诞生了。

YARN是Yet Another Resource Negotiator的简称,它仍可认为采用了master/slave结构,总体上采用了双层调度架构,它主要以下几部分组成:

(1)ResourceManager:负责资源管理的主服务,整个系统只有一个,负责资源管理、调度和监控,它支持可插拔的资源调度器,自带了FIFO、Fair Scheduler和Capacity Scheduler三种调度器;

(2) NodeManager:负责单个节点的资源管理和监控,它定期将资源使用情况汇报给ResourceManager,并接收来自ApplicationMaster的命令以启动Container(YARN中对资源的抽象),回收Container等;

(3)ApplicationMaster:负责管理单个应用程序,它向ResourceManager申请资源,并使用这些资源启动内部的任务,同时负责任务的运行监控和容错等;

(4)Container:对资源的抽象,它封装了某个节点上的CPU、内存等资源,ApplicationMaster只有获得一个Container后才能启动任务,另外,ApplicationMaster本身也是运行在一个Container之中。

论文谈到了Yahoo!目前YARN的使用情况。Yahoo!已经将所有集群切换为YARN,目前大约有7000个节点,每天运行50w个作业。同时论文比较了在2500个节点规模下1.0与2.0在吞吐率和资源利用率方面的不同,相比于Hadoop 1.0,YARN使得系统吞吐率(77k –> 100k)和资源利用率(cpu 利用率约提升了2倍)均有明显提高。

论文最后谈到了目前基于YARN实现的一些计算框架,包括Tez、Spark、Storm、Giraph等,具体我已经在多篇博文中进行了介绍,有兴趣的读者可以阅读:运行在YARN上的计算框架汇总运行在YARN上的开源系统