离线计算框架MapReduce

hadoop技术内幕-深入理解YARN架构设计与实现原理-第九章笔记

MapReduce基本构成组件

ContainerAllocator:与ResourceManager进行通讯,为MapReduce作业申请资源
ClientService:由MRClientService实现了MRClientProtocol协议,获取作业状态,控制作业
Job:表示一个MapReduce作业,维护了作业状态机
Task:表示一个作业中的某个任务,负责监控任务的状态,维护了任务状态机
TaskAttempt:表示一个任务运行的实例,直接使用了MRV1的逻辑,与MRv1处理引擎一样
TaskCleaner:处理进程失败之后产生的临时目录或垃圾结果,有线程池,异步删除
Speculator:完成推测执行功能.同一个任务,如果执行相对于其他任务较慢,则启动一个新的任务,执行同样的逻辑
ContainerLauncher:与NodeManager通信,以启动一个container
TaskAttemptListener:管理任务的心跳信息,如果某任务一段时间没有上报,任务已经挂掉
JobHistoryEventHandler:对作业的各个事件记录日志

事件与事件处理器

核心思想,当出现某一种事件时,MRAppMaster会查询<事件,事件处理器>,将该事件分配给对应的事件处理器

MapReduce客户端

MapReduce客户端是MapReduce与YARN通信的唯一途径,可以提交作业,获取作业运行状态,控制作业

两种RPC协议:

ApplicationClientProtocol ResourceManager实现了该协议,客户端都需要使用该协议完成作业提交,杀死作业,改变作业优先级
MRClientProtocol 启动applicationMaster之后,启动MRClientService服务,实现了该协议,通过该协议,直接与applicationMaster通信控制作业,查询作业运行状态,减轻ResourceManager负载

MRAppMaster工作流程

三种运行模式
本地模式:本地开发调试
Uber模式:小任务复用container
non-uber模式:MapTask和ReduceTask的四种状态:pending(启动未发送资源申请),scheduled(已经申请资源但未被分配),assigned(已经分配且运行),completed(运行完成)
优化参数,map 和reduce 的container分配方式,书中的三个参数
mapreduce.job.reduce.slowstart.completedmaps : map task完成比例达到该值后会为reduce task申请资源,默认0.05
yarn.app.mapreduce.am.job.reduce.rampup.limit : 在map task完成前,最多启动的reduce task的比例,默认0.5
yarn.app.mapreduce.am.job.reduce.preemption.limit : map task需要资源,但暂时不能获取时,保证至少一个map task可以得到资源,最多抢占reduce task的比例,默认0.5

MR作业生命周期及相关的状态机

job,task负责管理,taskAttempt负责实际的运行

MR作业生命周期

job状态机

task状态机

TaskAttempt状态机

资源申请与再分配

相关组件:MRAppMaster
YARN中作业资源可以用5元组描述:<priority,hostname,capability,containers,relax_locality>

priority :作业优先级
hostname :期望资源所在的host
capability :资源量(内存和cpu)
containers :container的数目
relax_locality :是否松弛本地性,设置为false只能申请同一节点上的资源,默认为true,本机资源不足时先同一机架,还没有资源再其他机架

资源申请过程

参考2.5节

资源再分配

MRAppMaster收到新分配的Container后,将这些Container进一步分配给各个任务,

1.判断收到的container资源是否满足要求,不满足则通过下次心跳通知RM释放该container
2.判断收到的container所在节点是否被加入黑名单,如果是,寻找一个与该container匹配的任务,并重新为该任务申请资源,同时心跳通知RM释放Container
3.根据container优先级分配给对应类型的任务

Container启动与释放

相关组件:ContainerLauncher,NodeManager
ContainerLauncher负责与各个NM通信,启动或释放Container

推测执行机制

关键组件:Speculator,MRAppMaster
产生的原因:分布式环境,软件bug,负载不均衡,资源不均匀造成任务执行时间不一致,为了避免单个任务缓慢造成整体执行进度比较慢,让备份的任务同时处理同一份数据,先运行完的将作为最终结果

算法介绍

算法的重点关注在新启动的备份任务实例是否有潜力比当前运行的任务实例完成的更早,

预测执行时间 = (当前时间 - 执行开始时间) / 当前执行进度
当前执行节点预测结束时间 = 预测执行时间 + 执行开始时间
预测新节点的结束时间 = 当前时间 + 平均执行时间

如果 (预测新节点的结束时间)小于(当前执行节点预测结束时间),则使用新节点启动执行,总是选择两个时间差值最大的任务启动一个备份任务实例

最大化备份任务的有效率

推测执行相关类

Speculator接口
SpeculatorEvent类型事件
yarn.app.mapreduce.am.job.speculator.class指定,默认使用DefaultSpeculator

作业恢复

一个作业的MRAppMaster运行失败时,RM会迁移到另一个节点上执行,根据MRAppMaster运行过程中在hdfs上记录的运行日志
三种不同级别的恢复机制

作业级别的
任务级别的
记录级别的
采用Redo日志方式,根据日志重做日志,重构作业或任务的内存信息
MRAppMaster使用开源数据序列化工具apache Avro记录任务相关的事件

*数据处理引擎

Map端–使用Netty替代Jetty
Reduce端–批拷贝,之前是每个map task都分配一个http连接,现在是同一个节点上的多个map task使用同一个http连接
Reduce端–Shuffle和排序插件化

历史作业管理器

MRv1和Mrv2对比

mapreduce1

组成

编程模型(MapReduce API)
资源管理
作业控制模块(jobtracker和tasktracker)

缺点

扩展性差:jobTracker资源管理和作业控制两个功能,成了系统的瓶颈
可靠性差:使用master/slave,master存在单点问题,出现问题导致整个集群不可用
资源利用率低:基于solt,资源闲置也不能被使用
无法支持多种计算框架

mapreduce2

源码阅读引导