系列文章目录
第一章 HDFS分布式文件系统(一)
大数据框架Hadoop:第一章 HDFS分布式文件系统(二)
大数据框架Hadoop:第二章 计算框架MapReduce(一)
大数据框架Hadoop:第二章 计算框架MapReduce(二)
大数据框架Hadoop:第三章 资源调度系统YARN(一)
文章目录
前言
本文的主要内容是理解yarn架构中各角色的作用,能描述出来mr or yarn的流程,理解三种调度器的区别并且能自定义容量调度器、公平调度器等
提示:以下是本篇文章正文内容,下面案例可供参考
一、YARN是什么?
- Apache Hadoop YARN(Yet Another Resource Negotiator)是Hadoop的子项目,为分离Hadoop2.0资源管理和计算组件而引入
- YRAN具有足够的通用性,可以支持其它的分布式计算模式。
二、YARN架构
类似HDFS,YARN也是经典的主从(master/slave)架构
- YARN服务由一个ResourceManager(RM)和多个NodeManager(NM)构成
- ResourceManager为主节点(master)
- NodeManager为从节点(slave)
1.ResourceManager
- ResourceManager是YARN中主的角色
- RM是一个全局的资源管理器,集群只有一个active的对外提供服务
- 负责整个系统的资源管理和分配
- 包括处理客户端请求
- 启动/监控 ApplicationMaster
- 监控 NodeManager、资源的分配与调度
- 它主要由两个组件构成:
- 调度器(Scheduler)
- 应用程序管理器(Applications Manager,ASM)
- 调度器Scheduler
- 调度器根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。
- 需要注意的是,该调度器是一个“纯调度器”
- 它不从事任何与具体应用程序相关的工作,比如不负责监控或者跟踪应用的执行状态等,也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务,这些均交由应用程序相关的ApplicationMaster完成。
- 调度器仅根据各个应用程序的资源需求进行资源分配,而资源分配单位用一个抽象概念“资源容器”(Resource Container,简称Container)表示,Container是一个动态资源分配单位,它将内存、CPU、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量。
- 应用程序管理器Applications Manager,ASM
- 应用程序管理器主要负责管理整个系统中所有应用程序
- 接收job的提交请求
- 为应用分配第一个 Container 来运行 ApplicationMaster
- 包括应用程序提交
- 与调度器协商资源以启动 ApplicationMaster
- 监控 ApplicationMaster 运行状态并在失败时重新启动它等
2.NodeManager
- NodeManager 是YARN中的 slave角色
- NodeManager :
- 当一个节点启动时,它会向 ResourceManager 进行注册并告知 ResourceManager 自己有多少资源可用。
- 每个计算节点,运行一个NodeManager进程,通过心跳(每秒 yarn.resourcemanager.nodemanagers.heartbeat-interval-ms )上报节点的资源状态(磁盘,内存,cpu等使用信息)
- 功能:
- 接收及处理来自 ResourceManager 的命令请求,分配 Container 给应用的某个任务;
- NodeManager 监控本节点上的资源使用情况和各个 Container 的运行状态(cpu和内存等资源)
- 负责监控并报告 Container 使用信息给 ResourceManager。
- 定时地向RM汇报以确保整个集群平稳运行,RM 通过收集每个 NodeManager 的报告信息来追踪整个集群健康状态的,而 NodeManager 负责监控自身的健康状态;
- 处理来自 ApplicationMaster 的请求;
- 管理着所在节点每个 Container 的生命周期;
- 管理每个节点上的日志;
- 在运行期,通过 NodeManager 和 ResourceManager 协同工作,这些信息会不断被更新并保障整个集群发挥出最佳状态。
- NodeManager 只负责管理自身的 Container,它并不知道运行在它上面应用的信息。负责管理应用信息的组件是 ApplicationMaster。
3.Container
- Container 是 YARN 中的资源抽象
- YARN以Container为单位分配资源
- 它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等
- 当 AM 向 RM 申请资源时,RM 为 AM 返回的资源便是用 Container 表示的
- YARN 会为每个任务分配一个 Container,且该任务只能使用该 Container 中指定数量的资源。
- Container 和集群NodeManager节点的关系是:
- 一个NodeManager节点可运行多个 Container
- 但一个 Container 不会跨节点。
- 任何一个 job 或 application 必须运行在一个或多个 Container 中
- 在 Yarn 框架中,ResourceManager 只负责告诉 ApplicationMaster 哪些 Containers 可以用
- ApplicationMaster 还需要去找 NodeManager 请求分配具体的 Container。
- 需要注意的是
- Container 是一个动态资源划分单位,是根据应用程序的需求动态生成的
- 目前为止,YARN 仅支持 CPU 和内存两种资源,且使用了轻量级资源隔离机制 Cgroups 进行资源隔离。
- 功能:
- 对task环境的抽象;
- 描述一系列信息;
- 任务运行资源的集合(cpu、内存、io等);
- 任务运行环境
4.ApplicationMaster
- 功能:
- 获得数据分片;
- 为应用程序申请资源并进一步分配给内部任务(TASK);
- 任务监控与容错;
- 负责协调来自ResourceManager的资源,并通过NodeManager监视容器的执行和资源使用情况。
- ApplicationMaster 与 ResourceManager 之间的通信
- 是整个 Yarn 应用从提交到运行的最核心部分,是 Yarn 对整个集群进行动态资源管理的根本步骤
- application master周期性的向resourcemanager发送心跳,让rm确认appmaster的健康
- Yarn 的动态性,就是来源于多个Application 的 ApplicationMaster 动态地和 ResourceManager 进行沟通,不断地申请、释放、再申请、再释放资源的过程。
5.JobHistoryServer
- 作业历史服务记录在yarn中调度的作业历史运行情况情况,可以通过历史任务日志服务器来查看hadoop的历史任务,出现错误都应该第一时间来查看日志日志
三、YARN应用运行原理(重点)
1.YARN应用提交过程
- Application在Yarn中的执行过程,整个执行过程可以总结为三步:
- 应用程序提交
- 启动应用的ApplicationMaster实例
- ApplicationMaster 实例管理应用程序的执行
具体提交过程为:
-
客户端程序向 ResourceManager 提交应用,并请求一个 ApplicationMaster 实例;
-
ResourceManager 找到一个可以运行一个 Container 的 NodeManager,并在这个 Container 中启动 ApplicationMaster 实例;
-
ApplicationMaster 向 ResourceManager 进行注册,注册之后客户端就可以查询 ResourceManager 获得自己 ApplicationMaster 的详细信息,以后就可以和自己的 ApplicationMaster 直接交互了(这个时候,客户端主动和 ApplicationMaster 交流,应用先向 ApplicationMaster 发送一个满足自己需求的资源请求);
-
ApplicationMaster 根据 resource-request协议 向 ResourceManager 发送 resource-request请求;
-
当 Container 被成功分配后,ApplicationMaster 通过向 NodeManager 发送 container-launch-specification信息来启动Container,container-launch-specification信息包含了能够让Container 和 ApplicationMaster 交流所需要的资料;
-
应用程序的代码以 task 形式在启动的 Container 中运行,并把运行的进度、状态等信息通过 application-specific协议 发送给ApplicationMaster;
-
在应用程序运行期间,提交应用的客户端主动和 ApplicationMaster 交流获得应用的运行状态、进度更新等信息,交流协议也是 application-specific协议;
-
应用程序执行完成并且所有相关工作也已经完成,ApplicationMaster 向 ResourceManager 取消注册然后关闭,用到所有的 Container 也归还给系统。
-
精简版的:
- 步骤1:用户将应用程序提交到 ResourceManager 上;
- 步骤2:ResourceManager为应用程序 ApplicationMaster 申请资源,并与某个 NodeManager 通信 启动第一个 Container,以启动ApplicationMaster;
- 步骤3:ApplicationMaster 与 ResourceManager 注册进行通信,为内部要执行的任务申请资源,一 旦得到资源后,将于 NodeManager 通信,以启动对应的 Task;
- 步骤4:所有任务运行完成后,ApplicationMaster 向 ResourceManager 注销,整个应用程序运行结束。
2.MapReduce on YARN
提交作业
- ①程序打成jar包,在客户端运行hadoop jar命令,提交job到集群运行
- job.waitForCompletion(true)中调用Job的submit(),此方法中调用JobSubmitter的submitJobInternal()方法;
- ②submitClient.getNewJobID()向resourcemanager请求一个MR作业id
- 检查输出目录:如果没有指定输出目录或者目录已经存在,则报错
- 计算作业分片;若无法计算分片,也会报错
- ③运行作业的相关资源,如作业的jar包、配置文件、输入分片,被上传到HDFS上一个以作业ID命名的目录(jar包副本默认为10,运行作业的任务,如map任务、reduce任务时,可从这10个副本读取jar包)
- ④调用resourcemanager的submitApplication()提交作业
- 客户端每秒查询一下作业的进度(map 50% reduce 0%),进度如有变化,则在控制台打印进度报告;
- 作业如果成功执行完成,则打印相关的计数器
- 但如果失败,在控制台打印导致作业失败的原因(要学会查看日志,定位问题,分析问题,解决问题)
初始化作业
-
当ResourceManager(一下简称RM)收到了submitApplication()方法的调用通知后,请求传递给RM的scheduler(调度器);调度器分配container(容器)
-
⑤a RM与指定的NodeManager通信,通知NodeManager启动容器;NodeManager收到通知后,创建占据特定资源的container;
-
⑤b 然后在container中运行MRAppMaster进程
-
⑥MRAppMaster需要接受任务(各map任务、reduce任务的)的进度、完成报告,所以appMaster需要创建多个簿记对象,记录这些信息
-
⑦从HDFS获得client计算出的输入分片split
- 每个分片split创建一个map任务
- 通过 mapreduce.job.reduces 属性值(编程时,jog.setNumReduceTasks()指定),知道当前MR要创建多少个reduce任务
- 每个任务(map、reduce)有task id
-
Task 任务分配
-
如果小作业,appMaster会以uberized的方式运行此MR作业;appMaster会决定在它的JVM中顺序执行此MR的任务;
-
原因是,若每个任务运行在一个单独的JVM时,都需要单独启动JVM,分配资源(内存、CPU),需要时间;多个JVM中的任务再在各自的JVM中并行运行
-
若将所有任务在appMaster的JVM中顺序执行的话,更高效,那么appMaster就会这么做 ,任务作为uber任务运行
-
小作业判断依据:①小于10个map任务;②只有一个reduce任务;③MR输入大小小于一个HDFS块大小
-
如何开启uber?设置属性 mapreduce.job.ubertask.enable 值为true
configuration.set("mapreduce.job.ubertask.enable", "true");
-
在运行任何task之前,appMaster调用setupJob()方法,创建OutputCommitter,创建作业的最终输出目录(一般为HDFS上的目录)及任务输出的临时目录(如map任务的中间结果输出目录)
-
-
⑧若作业不以uber任务方式运行,那么appMaster会为作业中的每一个任务(map任务、reduce任务)向RM请求container
- 由于reduce任务在进入排序阶段之前,所有的map任务必须执行完成;所以,为map任务申请容器要优先于为reduce任务申请容器
- 5%的map任务执行完成后,才开始为reduce任务申请容器
- 为map任务申请容器时,遵循数据本地化,调度器尽量将容器调度在map任务的输入分片所在的节点上(移动计算,不移动数据)
- reduce任务能在集群任意计算节点运行
- 默认情况下,为每个map任务、reduce任务分配1G内存、1个虚拟内核,由属性决定mapreduce.map.memory.mb、mapreduce.reduce.memory.mb、mapreduce.map.cpu.vcores、mapreduce.reduce.reduce.cpu.vcores
-
-
Task 任务执行
- 当调度器为当前任务分配了一个NodeManager(暂且称之为NM01)的容器,并将此信息传递给appMaster后;appMaster与NM01通信,告知NM01启动一个容器,并此容器占据特定的资源量(内存、CPU)
- NM01收到消息后,启动容器,此容器占据指定的资源量
- 容器中运行YarnChild,由YarnChild运行当前任务(map、reduce)
- ⑩在容器中运行任务之前,先将运行任务需要的资源拉取到本地,如作业的JAR文件、配置文件、分布式缓存中的文件
-
作业运行进度与状态更新
- 作业job以及它的每个task都有状态(running、successfully completed、failed),当前任务的运行进度、作业计数器
- 任务在运行期间,每隔3秒向appMaster汇报执行进度、状态(包括计数器)
- appMaster汇总目前运行的所有任务的上报的结果
- 客户端每个1秒,轮询访问appMaster获得作业执行的最新状态,若有改变,则在控制台打印出来
-
完成作业
- appMaster收到最后一个任务完成的报告后,将作业状态设置为成功
- 客户端轮询appMaster查询进度时,发现作业执行成功,程序从waitForCompletion()退出
- 作业的所有统计信息打印在控制台
- appMaster及运行任务的容器,清理中间的输出结果,释放资源
- 作业信息被历史服务器保存,留待以后用户查询
3.yarn应用生命周期
- RM: Resource Manager
- AM: Application Master
- NM: Node Manager
- Client向RM提交应用,包括AM程序及启动AM的命令。
- RM为AM分配第一个容器,并与对应的NM通信,令其在容器上启动应用的AM。
- AM启动时向RM注册,允许Client向RM获取AM信息然后直接和AM通信。
- AM通过资源请求协议,为应用协商容器资源。
- 如容器分配成功,AM要求NM在容器中启动应用,应用启动后可以和AM独立通信。
- 应用程序在容器中执行,并向AM汇报。
- 在应用执行期间,Client和AM通信获取应用状态。
- 应用执行完成,AM向RM注销并关闭,释放资源。
申请资源->启动appMaster->申请运行任务的container->分发Task->运行Task->Task结束->回收container
总结
本文的主要内容是理解yarn架构中各角色的作用,描述了mr or yarn的流程,YARN的三种调度器将在下篇文章中重点描述,下篇文章还会提及到Hadoop的企业级调优的相关知识,尽情期待。
获取更多干货,请关注我的个人公众号,关注领取福利