YARN总结

最新推荐文章于 2021-09-15 20:29:36 发布

TUJC

最新推荐文章于 2021-09-15 20:29:36 发布

阅读量292

点赞数

分类专栏：大数据知识总结

本文链接：https://blog.csdn.net/TU_JCN/article/details/104471704

版权

大数据知识总结专栏收录该内容

21 篇文章 7 订阅

订阅专栏

YARN资源调度系统

hadoop：hadoop-2.6.0-cdh5.14.2 CDH版本

1. YARN概述

Apache Hadoop YARN(Yet Another Resource Negotiator)是Hadoop的子项目，为分离Hadoop2.0资源管理和计算组件而引入
YRAN具有足够的通用性，可以支持其它的分布式计算模式

2. YARN架构

类似HDFS，YARN也是经典的主从（master/slave）架构

主节点 ResourceManager：调度器Scheduler / Application Master应用程序的管理器，

从节点NodeManager

Client 向 ResourceManager 提交的每一个应用程序都必须有一个 ApplicationMaster，它经过 ResourceManager 分配资源后，运行于某一个 Slave 节点的 Container 中，具体做事情的 Task，同样也运行与某一个 Slave 节点的 Container 中。

1）Resource Manager：全局资源管理器
- 一个集群只有一个RM。
- 负责和AM(Application Master)交互，资源调度、资源分配等工
2）Node Manager：一台机器上的管理者，
- 类似于部门经理。
- 管理着本机上若干小弟Containers的生命周期、监视资源和跟踪节点健康并定时上报给RM；接收并处理来自AM的Container启动/停止等各种请求。
3）Application Master：应用程序的管理器，
- 类似项目经理，一个应用程序只有一个AM。
- 负责任务开始时找RM要资源，任务完成时向RM注销自己，释放资源；
- 与NM通信以启动/停止任务；接收NM同步的任务进度信息。
- ApplicationMaster可以在容器内运行任何类型的任务，不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响。
4）Container：一台机器上具体提供运算资源，
- 将设备上的内存、CPU、磁盘、网络等资源封装在一起的抽象概念——“资源容器”，
- Container是一个动态资源分配单位，为了限定每个任务使用的资源量。

2.1 ResourceManager

RM是一个全局的资源管理器，集群只有一个
- 负责整个系统的资源管理和分配，处理客户端请求
- 启动/监控 ApplicationMaster
- 监控 NodeManager、资源的分配与调度
它主要由两个组件构成：
- 调度器（Scheduler）
- 应用程序管理器（Applications Manager，ASM）
调度器（Scheduler）
- 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
- 需要注意的是，该调度器是一个“纯调度器”
  - 它不从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
  - 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
应用程序管理器（Applications Manager，AM）
- 应用程序管理器主要负责管理整个系统中所有应用程序
- 接收job的提交请求
- 为应用分配第一个 Container 来运行 ApplicationMaster，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等

2.2 NodeManager

NodeManager 是一个 slave 服务，整个集群有多个
NodeManager ：
- 接收 ResourceManager 的资源分配请求，分配具体的 Container 给应用。
- 监控并报告 Container 使用信息给 ResourceManager。
- NodeManager 只负责管理自身的 Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是 ApplicationMaster

2.3 Container

Container 是 YARN 中的资源抽象
- 它封装了某个节点上的多维度资源，如内存、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等）；
- 任务运行环境

2.4 ApplicationMaster

功能：
- 数据切分；
- 为应用程序申请资源并进一步分配给内部任务（TASK）；
- 任务监控与容错；
- 负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用情况。
ApplicationMaster 与 ResourceManager 之间的通信
- 是整个 Yarn 应用从提交到运行的最核心部分，是 Yarn 对整个集群进行动态资源管理的根本步骤
- Yarn 的动态性，就是来源于多个Application 的 ApplicationMaster 动态地和 ResourceManager 进行沟通，不断地申请、释放、再申请、再释放资源的过程。

2.5 Resource Request

引用连接

Yarn的设计目标
- 允许我们的各种应用以共享、安全、多租户的形式使用整个集群。
- 并且，为了保证集群资源调度和数据访问的高效性，Yarn还必须能够感知整个集群拓扑结构。
为了实现这些目标，ResourceManager的调度器Scheduler为应用程序的资源请，求定义了一些灵活的协议，Resource Request和Container。
- 一个应用先向ApplicationMaster发送一个满足自己需求的资源请求
- 然后ApplicationMaster把这个资源请求以resource-request的形式发送给ResourceManager的Scheduler
- Scheduler再在这个原始的resource-request中返回分配到的资源描述Container。

2.6 JobHistoryServer

作业历史服务

记录在yarn中调度的作业历史运行情况情况 ,
通过命令启动

mr-jobhistory-daemon.sh start historyserver


- 在集群中的数据节点机器上单独使用命令启动直接启动即可,

- 启动成功后会出现JobHistoryServer进程(使用jps命令查看，下面会有介绍) ,

- 可以从19888端口进行查看日志详细信息

如果没有启动jobhistoryserver，无法查看应用的日志
jobhistoryserver启动后，在此运行MR程序，如wordcount
点击History连接，跳转一个赞新的页面
- TaskType中列举的map和reduce，Total表示此次运行的mapreduce程序执行所需要的map和reduce的任务数
点击TaskType列中Map连接
看到map任务的相关信息比如执行状态,启动时间，完成时间。
可以使用同样的方式我们查看reduce任务执行的详细信息，这里不再赘述.
jobhistoryserver就是进行作业运行过程中历史运行信息的记录，方便我们对作业进行分析.

2.7 Timeline Server

用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等)
它是对jobhistoryserver功能的有效补充，jobhistoryserver只能对mapreduce类型的作业信息进行记录
它记录除了jobhistoryserver能够进行对作业运行过程中信息进行记录之外
还记录更细粒度的信息，比如任务在哪个队列中运行，运行任务时设置的用户是哪个用户。
根据官网的解释jobhistoryserver只能记录mapreduce应用程序的记录，timelineserver功能更强大,但不是替代jobhistory两者是功能间的互补关系.
官网教程

3. YARN应用运行原理

3.1 YARN应用提交过程

Application在Yarn中的执行过程，整个执行过程可以总结为三步：
- 应用程序提交
- 启动应用的ApplicationMaster实例
- ApplicationMaster 实例管理应用程序的执行
精简版的：
- 步骤1：客户端程序向 ResourceManager 提交应用，请求一个 RM的ApplicationMaster 实例，并请求传递给RM的scheduler（调度器）；调度器分配container（容器）
步骤2：ResourceManager 找到一个可以运行一个 Container 的 NodeManager，并在这个 Container 中启动 ApplicationMaster 实例；
- 步骤3：ApplicationMaster 与 ResourceManager 注册进行通信，为内部要执行的任务申请资源，一旦得到资源后，将于 NodeManager 通信，以启动对应的 Task；
- 步骤4：所有任务运行完成后，ApplicationMaster 向 ResourceManager 注销，整个应用程序运行结束。
具体提交过程为：
- 客户端程序向 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 也归还给系统。

3.2 MapReduce on YARN

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iVc6blG2-1582505845716)(assets/820234-20160604233916133-2026396104.jpg)]

提交作业：

提交job到集群，调用resourcemanager的submitApplication()提交作业
- ①程序打成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()提交作业
初始化作业
- 当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.3 yarn应用生命周期

申请资源container->启动AppMaster->申请运行任务的container->分发Task->运行Task->Task结束->回收container

4. 如何使用YARN

4.1 配置文件

<!-- $HADOOP_HOME/etc/hadoop/mapred-site.xml -->
<configuration>
    <property>
        <name>mapreduce.framework.name</name>
        <value>yarn</value>
    </property>
</configuration>

<!-- $HADOOP_HOME/etc/hadoop/yarn-site.xml -->
<configuration>
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>
</configuration>

4.2 YARN启动停止

启动 ResourceManager 和 NodeManager （以下分别简称RM、NM）

#主节点运行命令
$HADOOP_HOME/sbin/start-yarn.sh

停止 RM 和 NM

#主节点运行命令
$HADOOP_HOME/sbin/stop-yarn.sh

若RM没有启动起来，可以单独启动

#若RM没有启动，在主节点运行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start resouremanager
#相反，可单独关闭
$HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager

若NM没有启动起来，可以单独启动

#若NM没有启动，在相应节点运行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager
#相反，可单独关闭
$HADOOP_HOME/sbin/yarn-daemon.sh stop nodemanager

4.3 YARN常用命令

4.3.2 yarn application命令

#1.查看正在运行的任务
yarn application -list

#2.杀掉正在运行任务
yarn application -kill 任务id

#3.查看节点列表
yarn node -list

#4.查看节点状况；所有端口号与上图中端口号要一致（随机分配）
yarn node -status node-03:45568

#5.查看yarn依赖jar的环境变量
yarn classpath

5. YARN调度器

在Yarn框架中，调度器是一块很重要的内容。
有了合适的调度规则，就可以保证多个应用可以在同一时间有条不紊的工作。
最原始的调度规则就是FIFO，即按照用户提交任务的时间来决定哪个任务先执行，先提交的先执行。但是这样很可能一个大任务独占资源，其他的资源需要不断的等待。也可能一堆小任务占用资源，大任务一直无法得到适当的资源，造成饥饿。所以FIFO虽然很简单，但是并不能满足我们的需求。
理想情况下，yarn应用发出的资源请求应该立刻给予满足。然而现实中的资源有限，在一个繁忙的集群上，一个应用经常需要等待才能得到所需的资源。
yarn调度器的工作：根据既定的策略为应用分配资源。
yarn分为一级调度管理和二级调度管理
一级调度管理(更近底层,更接近于操作资源, 更偏向于应用层和底层结合)
- 计算资源管理(cpu,内存等,计算复杂消耗的cpu多)
- App生命周期管理
二级调度管理(自己代码的算法等, 更偏向于应用层)
- App内部的计算模型管理
- 多样化的计算模型
5.1 调度器
在YARN中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，FairS cheduler

5.2 FIFO Scheduler

FIFO Scheduler 先进先出队列
- 把应用按提交的顺序排成一个队列
- 在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。
- 大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
- 在FIFO 调度器中，小任务会被大任务阻塞。

5.3 Capacity Scheduler

Capacity Scheduler 容量调度器
- 有一个专门的队列用来运行小任务，
- 但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间
CDH版本默认使用Fair Scheduler公平调度器
- 若要使用capacity scheduler，需要修改yarn-site.xml文件；node01上
```
<property>
	<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>
```
- 并分发到各节点，集群中所有yarn-site.xml文件要同步更新
- 重启yarn
如何配置容量调度器
- 队列层级结构如下
```
root 
├── prod 
└── dev 
	├── spark 
	└── hdp
```
- 主节点上，将$HADOOP_HOME/etc/hadoop/中的对应capacity-scheduler.xml配置文件，备份到其它目录
  - 目录$HADOOP_HOME/etc/hadoop/中建立一个新的capacity-scheduler.xml；内容如下
  - 将此xml文件，远程拷贝到相同目录下
- 将应用放置在哪个队列中，取决于应用本身。
动态更新配置：
- 容量调度器的配置在运行时，可以随时重新加载，调整资源分配参数；
- 需要编辑conf/capacity-scheduler.xml 并在yarn主节点运行命令让配置文件生效
- 另外，除非重启resourcemanager，否则队列只能添加不能删除；但允许关闭

5.4 Fair Scheduler

Apache Hadoop默认使用Capacity Scheduler容量调度器
CDH版本默认使用Fair Scheduler公平调度器

Fair 公平调度器

为所有运行的job动态调整系统资源，不需要预先占用一定的系统资源，
- 当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
- 需要注意的是，在Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。
- 小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成.
支持资源抢占
- 在yarn-site.xml中设置yarn.scheduler.fair.preemption为true
- 可通过一个名为fair-scheduler.xml文件对公平调度器进行配置，此文件可放置在${HADOOP_HOME}/etc/hadoop/目录下
- 当没有设置此配置文件时，每个应用放置在以当前用户名命名的队列中，队列是用户提交第一个应用时动态创建的
若要用Fair Scheduler的话，需要配置yarn-site.xml，

<property>
	<name>yarn.resourcemanager.scheduler.class</name>	<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

注意：同样，集群中所有yarn-site.xml文件要同步更新

6. YARN应用状态

我们在yarn 的web ui上能够看到yarn 应用程序分为如下几个状态:

NEW -----新建状态
NEW_SAVING-----新建保存状态
SUBMITTED-----提交状态
ACCEPTED-----接受状态
RUNNING-----运行状态
FINISHED-----完成状态
FAILED-----失败状态
KILLED-----杀掉状态

查看官网capacity scheduler内容
capacity scheduler参考资料
官网查看fair scheduler内容
《Hadoop权威指南第4版》
- 4.3 YARN中的调度
- 7.1 剖析MapReduce运行机制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FKQWiHkz-1582505845718)(assets/Image201907172014.png)]

介绍了yarn的应用场景
yarn的核心组件
yarn应用调度过程
yarn的典型应用

ED-----失败状态

KILLED-----杀掉状态

查看官网capacity scheduler内容
capacity scheduler参考资料
官网查看fair scheduler内容
《Hadoop权威指南第4版》
- 4.3 YARN中的调度
- 7.1 剖析MapReduce运行机制

[外链图片转存中…(img-FKQWiHkz-1582505845718)]

介绍了yarn的应用场景
yarn的核心组件
yarn应用调度过程
yarn的典型应用

TUJC

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
YARN总结

YARN资源调度系统hadoop：hadoop-2.6.0-cdh5.14.2 CDH版本文章目录YARN资源调度系统1. YARN概述2. YARN架构2.1 **ResourceManager**2.2 **NodeManager**2.3 Container2.4 **ApplicationMaster**2.5 Resource Request2.6 JobHistoryServe...
复制链接

扫一扫