Hadoop组件之Yarn

Yarn简介

Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是Hadoop资源管理器,它是一个通用资源管理系统和调度平台,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

Yarn负责为运算程序提供服务器运算资源,相当于一个分布式的操作系统平台,而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。

Yarn产生的原因

Yarn是在hadoop2.0之后的版本才加入进hadoop的,hadoop1.0的各版本中是没有Yarn的,在hadoop1.0的各版本中,资源分配与工作调度这些任务是由MapReduce来完成的,在实际使用过程中,MapReduce即负责逻辑运算又要负责资源调度,开发人员非常的不方便,程序运行效率也很低。所以在hadoop2.0中开发人员加入了Yarn这一组件专门负责资源管理和调度,Yarn的加入让hadoop更加的完善。现在Yarn已经变成了hadoop中必不可少的组件之一。
在这里插入图片描述

Yarn架构

Yarn主要由ResourceManager、NodeManager、ApplicationMaster和Container等组件构成,下图是Yarn的架构图:

在这里插入图片描述

ResourceManager

ResourceManager是一个全局的资源管理器,集群里只有一个,为整个集群管理和分配资源。ResourceManager主要负责处理客户端请求、启动和监控ApplicationMaster、监控NodeManager、资源的分配与调度。它主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager)。

ApplicationMaster

ApplicationMaster负责管理Yarn内运行的应用程序的每个实例。ApplicationMaster的主要任务是进行数据切分、为应用程序申请资源并进一步分配给内部任务,同时它还有任务监控与容错的功能,可以协调来自ResourceManager的资源,并通过NodeManager监视任务的执行和资源使用情况。

NodeManager

在hadoop集群中,每个节点上有一个Nodemanager,Nodemanager负责每个节点上的资源分配和使用,处理来自ResourceManager,ApplicationMaster的命令。NodeManager还管理着抽象容器Container,这些抽象容器代表着一些特定程序使用针对每个节点的资源。NodeManager定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态(cpu和内存等资源)

Container

Container是YARN中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当ApplicationMaster向ResourceManager申请资源时,ResourceManager为ApplicationMaster返回的资源就是用Container表示的。Yarn会为每个任务分配一个Container,且该任务只能使用该Container中分配的资源。Container是一个动态的资源划分单位,它里面的资源是根据应用程序的需求动态生成的。目前为止,YARN仅支持CPU和内存两种资源,且使用了轻量级资源隔离机制Cgroups进行资源隔离。

Yarn工作流程分析

下图是Yarn的工作原理图,Yarn作业执行的全过程可以分为六步:作业提交、作业初始化、任务分配、任务运行、进度和状态更新、作业完成。

在这里插入图片描述

作业提交

第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。
第2步:Client向RM申请一个作业id。
第3步:RM给Client返回该job资源的提交路径和作业id。
第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。
第5步:Client提交完资源后,向RM申请运行MrAppMaster。

作业初始化

第6步:当RM收到Client的请求后,将该job添加到容量调度器中。
第7步:某一个空闲的NM领取到该Job。
第8步:该NM创建Container,并产生MRAppmaster。
第9步:下载Client提交的资源到本地。

任务分配

第10步:MrAppMaster向RM申请运行多个MapTask任务资源。
第11步:RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。

任务运行

第12步:MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
第13步:MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask。
第14步:ReduceTask向MapTask获取相应分区的数据。
第15步:程序运行完毕后,MR会向RM申请注销自己。

进度和状态更新

YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。

作业完成

除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和Container会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

Yarn中的资源调度器

Hadoop作业调度器主要有三种:FIFO、Capacity Scheduler和Fair Scheduler。Hadoop默认的资源调度器是Capacity Scheduler。

先进先出调度器(FIFO)

原理非常简单也很好理解,将作业放到一个队列中,先进入队列的作业先执行。

在这里插入图片描述

容量调度器(Capacity Scheduler)

支持多个队列,每个队列可配置一定的资源量,每个队列采用FIFO调度策略。为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源量进行限定。首先,计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值,选择一个该比值最小的队列。其次,按照作业优先级和提交时间顺序,同时考虑用户资源量限制和内存限制对队列内任务排序。三个队列同时按照任务的先后顺序依次执行,比如,job11、job21和job31分别排在队列最前面,最先运行,也是同时运行。

在这里插入图片描述

公平调度器(Fair Scheduler)

支持多队列多用户,每个队列中的资源量可以配置,同一队列中的作业公平共享队列中所有资源。
比如有三个队列:queueA、queueB和queueC,每个队列中的作业按照优先级分配资源,优先级越高分配的资源越多,但是每个 job 都会分配到资源以确保公平。在资源有限的情况下,每个job理想情况下获得的计算资源与实际获得的计算资源存在一种差距, 这个差距就叫做缺额。在同一个队列中,job的资源缺额越大,越先获得资源优先执行。作业是按照缺额的高低来先后执行的,而且可以有多个作业同时运行。

在这里插入图片描述

Yarn任务的推测执行机制

一个作业由若干个Map任务和Reduce任务构成。因硬件老化、软件Bug等,某些任务可能运行非常慢。例如,比如某个Map任务运行速度远慢于Map任务的平均速度,系统中有99%的Map任务都完成了,只有这个Map任务非常慢,需要好久才能完成,那么这个个Map就拖了整个作业的后腿,拉长了作业运行时间。

针对这种情况,Yarn也做了一些工作,Yarn有任务的推测执行机制,会预测任务的执行时间。如果任务的实际执行时间和预测执行时间相差较多,Yarn便会为拖后腿任务启动一个备份任务,同时运行。避免发生因为硬件和软件Bug而产生一个任务拖慢整个作业的情况。

启用推测执行任务的条件

  1. 每个Task只能有一个备份任务
  2. 当前Job已完成的Task必须不小于0.05(5%)

不启用推测执行任务的情况

  1. 任务间存在严重的负载倾斜
  2. 特殊任务,比如任务向数据库中写数据

estimatedRunTime = (currentTimestamp - taskStartTime) / progress
推测运行时间(60s) =(当前时刻(6) - 任务启动时刻(0)) / 任务运行比例(10%)

推测执行算法原理

假设某一时刻,任务T的执行进度为progress,则可通过一定的算法推测出该任务的最终完成时刻estimateEndTime。另一方面,如果此刻为该任务启动一个备份任务,则可推断出它可能的完成时刻estimateEndTime` ,于是可得出以下几个公式:

estimateEndTime = estimatedRunTime + taskStartTime
推测执行完时刻 60 = 推测运行时间(60s) + 任务启动时刻(0)

estimatedRunTime = (currentTimestamp - taskStartTime) / progress
推测运行时间(60s) =(当前时刻(6) - 任务启动时刻(0)) / 任务运行比例(10%)

estimateEndTime` = currentTimestamp + averageRunTime
备份任务推测完成时刻(16) = 当前时刻(6) + 运行完成任务的平均时间(10s)

关于推测执行算法,MR总是选择(estimateEndTime- estimateEndTime ` )差值最大的任务,并为之启动备份任务。为了防止大量任务同时启动备份任务造成的资源浪费,MR为每个作业设置了同时启动的备份任务数目上限。推测执行机制实际上采用了经典的优化算法,以空间换时间,它同时启动多个相同任务处理相同的数据,并让这些任务竞争以缩短数据处理时间。显然,这种方法需要占用更多的计算资源。在集群资源紧缺的情况下,应合理使用该机制,争取在多用少量资源的情况下,减少作业的计算时间。

发布了170 篇原创文章 · 获赞 150 · 访问量 18万+

猜你喜欢

转载自blog.csdn.net/eagleuniversityeye/article/details/104081191
今日推荐