Yarn资源调度器

　　　　　　　　　　　　Yarn资源调度器

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

 

 

　　YARN是一个资源调度平台,负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce,Spark,Flink邓运算程序则相当于运行于操作系统之上的应用程序。

 

一.YARN基本架构

　　如下图所示,YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等组件构成。

　　ResourceManager(简称RM):
　　　　全局的资源管理器,负责整个各系统的资源管理和分配，它带了FIFO,Capacity Schedule,Fair Schedule三种常用调度器。
　　　　RM的主要作用如下:
　　　　　　(a)处理客户端请求;
　　　　　　(b)监控NodeManager;
　　　　　　(c)启动或监控ApplicationMaster;
　　　　　　(d)资源的分配与调度;

　　NodeManager(简称NM):
　　　　每个节点上的资源和任务管理器，定时向RM汇报本节点上的资源以及使用情况和各个Container的运行状态，接收并处理来自AM的Container启动/停止等各种请求。
　　　　NM的主要作用如下:
　　　　　　(a)管理单个节点上的资源;
　　　　　　(b)处理来自ResourceManager的命令;
　　　　　　(c)处理来自ApplicationMaster的命令

　　ApplicationMaster(简称AM):
　　　　用户提交的每个应用程序均包含一个AM,它与RM调度器协商以获取资源分配给内部的任务;与NM通信以启动/停止任务;监控所有的任务运行状态，并在任务运行失败时为任务申请资源以重启任务。
　　　　AM的主要作用如下:
　　　　　　(a)负责数据的切分;
　　　　　　(b)为应用程序申请资源并分配给内部的任务;
　　　　　　(c)任务的监控与容错;

　　Container:
　　　　YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存，CPU,磁盘,网络,运行环境(如job.xml)等，当AM向RM申请资源时,RM为AM返回的资源是用Continer表示的。YARN回味每个任务分配一个Container且该任务只能使用该Container中描述的资源。

 

二.YARN的运行原理

　　(1)MapReduce程序提交到客户端所在的节点。

　　(2)YarnRunner向ResourceManager申请一个Application。

　　(3)RM将该应用程序的资源路径返回给YarnRunner。

　　(4)该程序将运行所需资源提交到HDFS上。

　　(5)程序资源提交完毕后，申请运行mrAppMaster。

　　(6)RM将用户的请求初始化成一个Task。

　　(7)其中一个NodeManager领取到Task任务。

　　(8)该NodeManager创建容器Container，并产生MRAppmaster。

　　(9)Container从HDFS上拷贝资源到本地。

　　(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申请注销自己。

 

三.作业提交流程

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

　　2>.作业初始化
　　　　(6)当RM收到Client的请求后，将该job添加到容量调度器中。
　　　　(7)某一个空闲的NM领取到该Job。
　　　　(8)该NM创建Container，并产生MRAppmaster。
　　　　(9)下载Client提交的资源到本地。

　　3>.任务分配
　　　　(10)MrAppMaster向RM申请运行多个MapTask任务资源。
　　　　(11)RM将运行MapTask任务分配给另外两个NodeManager，另两个NodeManager分别领取任务并创建容器。

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

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

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

 

四.资源调度器概述

　　如下图所示,Hadoop作业调度器主要有三种：FIFO、Capacity Scheduler和Fair Scheduler。

　　我们可以通过修改yarn-site.xml文件的"yarn.resourcemanager.scheduler.class"来修改你使用那种调度器,在Hadoop 2.x版本中默认使用的是Capacity Scheduler

1>.先进先出调度器(FIFO)

　　FIFO生产环境中很少有人使用,不能实现更高级的调度策略，比如优先级，层级等策略均不支持。

　　FIFO队列优点: 　　　
　　　　简单,即按照job到达时间排序，先到达先服务。
　　FIFO队列缺点:
　　　　会存在一个巨大的任务阻塞整个队列。

　　举个例子:
　　　　以学校住宿舍打水的场景为例,有10个人排队大水，第一个人同时拿了8个电壶打水，其余9人没人拿1个电壶打水，但是第一个人严重阻塞大家打水的效率。

2>.容量调度(Capacity Scheduler)

　　容量调度器简单点就是多个FIFO调度器同时运行。它缓解了FIFO的缺点,但并不灵活。

　　Capacity Scheduler队列优点:
　　　　（1)支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO调度器并行运行;
　　　　(2)为了防止同一个用户的作业独占队列中的资源,该调度器会对同一个用户提交的作用所占资源量进行限定;
　　　　(3)每个队列中正在运行的任务数与应该分得的计算资源之间的比值，选择一个该比值最小的队列(即分配一个最闲的队列给最新提交的job),按照作业优先级和提交时间顺序，同时考虑用户资源啦限制和内存限制队列任务排序。

　　Capacity Scheduler队列缺点:
　　　　灵活性差,一个job被分配到一个队列后其它队列的资源无法给该队列使用。

　　举个例子:
　　　　还是假设10个人打水,此时有3个打水的地方,第一个人拿了8个壶打水，其余九人都拿了一个壶。但此时第一个人同时只能使用一个位置,其它2个位置要让给其余9人打水，当拿九个人打完水后其余2个位置空余了，但第一个人并不允许使用空余的位置资源，因为它同时只能占用一个位置，其余位置就算空着也不能用，空着的位置是为了等其它同学来打水。

3>.公平调度器(Fair Scheduler)

　　公平调度器实在容量调度器的基础之上又做了升级,它优化了容量调度器不灵活的缺陷。每个对类中的job按照优先级分配资源，优先级越高分配的资源越多,但是每个job都会分配到资源以确保公平。

　　在资源有限的情况下，每个job理想情况下获得的计算资源与实际获得的计算资源存在一种差距，这个差距叫做缺额。在同一个对类中，job的资源缺额越大，越有限获得资源有限执行。作业时按照缺额的高低来先后执行的。

　　Fair Scheduler优点:
　　　　支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源。
　　　　假设有根队列下有4个队列分别为A,B,C,D。我们假设这4个队列中分配的资源是相同的，即每个队列各占整个集群的25%资源，我们此时手动又为A划分了两个子队列E,F我们假设它们2个队列分配的资源相同，即分别栈整个集群的12.5%,当一个集群正在运行时,如果我们job提交到A,B.C.D任何一个队列该job理论上可以支配25%的集群资源，如果我们将该job手动分配到E或者F队列，那么此时他回去的资源仅有12.5$的集群资源。

　　Fair Scheduler缺点:
　　　　每个队列都有一个最小资源占比的参数,假设根队列有5个队列，此时有5个job分配在5个队列在执行，我们假设队列的最小资源占比是20%,此时往根下的第六个队列提交任务是不可行的，需要等待其它队列释放资源。

　　举个例子:
　　　　还是说上面打水的案例,当第一个人拿8个壶去打水时，如果发现3个位置都是空的，它可以一个人同时占用3个位置打水，当有第二个同学来打水时,他会主动让出一个位置，当有第三个同学来打水时,他会继续让出一个位置，当第四个同学来打水时，他不会让他了，因为他最少得有一个位置来打水。相对来说这种场景更符合我们生活规律。

　　温馨提示:
　　　　公平调度器适合用于集群资源比较紧张的大数据集群，需要你对集群的资源做相应的规划，如果你的集群资源比较充裕，基本上默认的容量调度器也够使用了。身为一个大数据运维工程师，我推荐大家生产环境中使用公平调度器，这样可以充分利用集群资源。尤其是老板跟你说没钱买机器的时候，你就得硬着头皮来搞集群调度器优化了。

 

五.任务推测执行

1>.作业完成时间取决于最慢的任务完成时间

　　一个作业由若干个Map任务和Reduce任务构成。因硬件老化、软件Bug等，某些任务可能运行非常慢。系统中有99%的Map任务都完成了，只有少数几个Map老是进度很慢，完不成，怎么办？建议查看YARN的WebUI相应的日志信息以便于定位问题。其次就是开启任务推测执行机制。

2>.推测执行机制

　　发现拖后腿的任务，比如某个任务运行速度远慢于任务平均速度。为拖后腿任务启动一个备份任务，同时运行。谁先运行完，则采用谁的结果。

3>.执行推测任务的前提条件 

　　(a)每个Task只能有一个备份任务
　　(b)当前Job已完成的Task必须不小于0.05（5%）
　　(c)开启推测执行参数设置。mapred-site.xml文件中默认是打开的。

　　mapred-site.xml开启推测执行参数如下:
　　　　mapreduce.map.speculative:
　　　　　　如果为true，则可以并行执行某些MapTask的多个实例。

　　　　mapreduce.reduce.speculative
　　　　　　如果为true，则可以并行执行某些MapTask的多个实例。

4>.不能启用推测值机制情况

　　(a)任务间存在严重的负载倾斜；
 
　　(b)特殊任务，比如任务向数据库中写数据。

　　温馨提示:
　　　　除了上述两种情况外，在集群的资源比较吃紧的时候，建议关闭推测执行机制，因为推测任务执行其实时需要付出资源代价的。

5>.推测执行算法原理

　　假设某一时刻，任务T的执行进度为progress，则可通过一定的算法推测该任务的最终完成时刻estimateEndTime。

　　另一方面，如果此可为该任务启动一个备份任务，则可推断出他可能的完成时可estimateEndTime，于是可读出以下几个公式:
　　　　推测运行时间(estimateTunTime) 　　= 　(当前时刻(currentTimestamp    - taskStartTime(任务启动时刻)))　　/　　任务运行比例(progress)
　　　　推测执行完成时刻(estimateEndTime) =　　推测运行时间(estimateTunTime) + taskStartTime(任务启动时刻)
　　　　备份任务推测完成时刻(estimateEndTime) =　　当前时刻(currentTimestamp) + 运行完成任务的平均时间(averageRunTime)

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