stone

MRv2框架分析
传统的MRv1是由编程模型,资源管理和作业控制,数据处理引擎(MapTask和ReduceTask)三部份组成,相...
扫描右侧二维码阅读全文
20
2017/04

MRv2框架分析

传统的MRv1是由编程模型,资源管理和作业控制,数据处理引擎(MapTask和ReduceTask)三部份组成,相对来说并不是特别灵活。
在Yarn出现之后,则将资源管理模块交给yarn实现,而整个MapReduce框架则运行在Yarn之上,仅需实现ApplicationMaster组件
来完成作业控制功能。MR on Yarn的框架使得集群可以和其他的计算模型共享集群,大大增加了计算的灵活性。

下面是MR Application的架构图。

20066-8qprr3mlmlw.png

  • Container Allocator

对每一个任务的资源需求可以描述为一个五元组(Priority,hostname,capability,containers,relax_locality),分别代表资源的优先级,
期望资源所在的host,资源数量(支持内存和CPU两种),Container数量和是否松弛本地。

Container Allocator 周期性和RM进行通信,RM通过心跳的方式应答已经成功分配Container列表

  • ClientService

获取是对MRClientProtocal的实现,通过这个模块,client通过这个协议可以获取作业的具体执行状态,并控制作业(杀死,改变优先级)

  • Job

代表一个MR作业,负责监控Job的运行状态

  • Task

代表一个任务,负责监控一个任务的运行状态,维护一个任务状态机,以实现异步执行各种任务相关操作

  • TaskAttempt

代表一个实际运行的任务实例,和MRv1中的MapTask和ReduceTask相似

  • TaskCleaner

用于删除失败任务和临时结果,维护了一个线程池和共享队列,异步删除任务产生的垃圾数据

  • Specular

完成推测式执行功能,当任务的执行速度明显慢于其他任务的速度的时候,会为该任务启动一个备份任务,让他们之间进行竞争,将先完成的任务结果作为
最终的结果,然后杀死没有完成的任务

  • Container Launcher

负责和Node Manager进行通信,启动Container。当接收到RM分配的作业资源后就会将任务执行的相关信息发送给NM,要求其启动Container

  • TaskAttemptListener
    负责个任务的心跳信息,如果一段时间没有收到任务的心跳信息,则任务它已经死掉,会将其从系统中移除。
  • Job History Event Handler

负责对作业的各种事件记录日志,比如作业创建,作业开始运行,一个任务开始运行等等,这些日志对作业的恢复非常的有用。当AM出现故障之后,Yarn
会重新启动AM,AM会从HDFS上读取上次的运行日志,恢复已经完成运行完成的任务。

MR客户端

MR客户端的通信设计两个RPC协议,ApplicationClientProtocal(完成作业的提交,杀死作业,改变作业的优先级)和MRClientProtocal(控制查看作业的运行状态)

MR的运行模式

MR有三种不同的运行模式,分别为local,uber和non-uber,对于测试的话,使用local模式,对于小数据作业,使用uber模式,此模式下会将map和reduce过程安排在
一个节点上,而对于大作业,采用non-uber模式,该模式下,AM会优先为MapTask申请资源,当MapTask完成数目达到一定比例之后,就会为ReduceTask申请资源。

Uber运行模式

YARN针对小作业专门进行了优化,对于小作业来说,AM无需为每一个任务分别申请资源,直接重用同一个Container,并且按照先MapTask,后ReduceTask的顺序执行每一个任务,

Non-Uber运行状态

在此模式下,AM将一个作业的Map Task和Reduce Task阶段分为下面的四种状态,

  • pending: 刚启动,未向RM发送资源请求
  • scheduced: 已经向RM发送资源请求,但是尚未分配资源
  • assigned: 已经分配到资源,并正在运行
  • completed: 已经完成运行

对于Map Task来说,它的生命周期为: scheduled -> assigned -> completed
对于Reduce Task来说,它的生命周期为: pending -> scheduled -> assigned -> completed

Reduce Task一般都需要依赖于Map Task的输出结果,因此不会过早启动Reduce Task,会将其置于pending状态

整个框架的运行模式可以使用下面这个图表示:

61159-7tspa7sxnvo.png

MR的作业

MR中和作业相关的组件有Job,Task,TaskAttempt。真正执行任务的是TaskAttempt,一个Task可以启动过个计算实例TaskAttempt让其进行竞争。
除了TaskAttempt用于运行计算,另外两个组件主要用于监控和管理。

29008-qr01gmkxlki.png

推测执行机制

由于不同节点的状态和任务执行的情况不一样,一般任务的执行速度也不太一样。如果有些任务的完成时间明显慢于其他的任务,则会拖慢整个作业的速度,此时如果再启动一个备份任务和原来的任务进行竞争,取较早完成的任务的结果作为最终的结果,则可以加速任务的完成时间。但是其中存在一个问题,如果新启动的备份任务比原来的任务慢,则只是对资源的浪费,所以合理地选择需要启动备份任务的慢任务则显得非常重要。

在MR框架中,会估计原来的任务的剩余时间和新任务的执行时间之差,选出差值最大的的任务为其启动备份任务。

启动备份任务需要符合的几个条件:

  1. 每个任务最多只能启动一个备份任务实例
  2. 已经完成的进度必须在5%以上,这样才能提供足够的历史数据来进行估计

备份任务的有效率越高(备份任务比原任务完成时间更早),则说明推测执行算法越优秀。

Last modification:September 7th, 2018 at 08:20 pm
If you think my article is useful to you, please feel free to appreciate

Leave a Comment