大数据高级开发工程师——Hadoop学习笔记（7）

Hadoop进阶篇

YARN：Hadoop资源调度系统

什么是YARN

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

YARN架构剖析

• 类似于 HDFS，YARN 也是经典的主从（Master/Slave）架构。
• YARN 服务有一个 ResourceManager（RM）和多个 NodeManager（NM）构成。
• ResourceManager 为主节点(master)、NodeManager 为从节点(slave)

1. ResourceManager

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

2. NodeManager

• NodeManager 是YARN中的 slave角色：
  • 当一个节点启动时，它会向 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

• 功能：
  • 获得分片数据；
  • 为应用程序申请资源并进一步分配给内部任务；
  • 任务监控与容错；
  • 负载协调来自 ResourceManager 的资源，并通过 NodeManager 监控容器的执行和资源使用情况。
• ApplicationMaster 与 ResourceManager 之间的通信：
  • 是整个 Yarn 应用从提交到运行的最核心部分，是 Yarn 对整个集群进行动态资源管理的根本步骤；
  • application master周期性的向resourcemanager发送心跳，让rm确认appmaster的健康；
  • Yarn 的动态性，就是来源于多个Application 的 ApplicationMaster 动态地和 ResourceManager 进行沟通，不断地申请、释放、再申请、再释放资源的过程。

5. JobHistoryServer

• 作业历史服务：记录在 yarn 中调度的作业历史运行情况，可以通过历史任务日志服务器来查看 hadoop 历史任务，出现错误都应该第一时间来查看日志。

配置开启历史服务 JobHistoryServer

• 第一步：修改mapred-site.xml 增加如下内容

<property>
    <name>mapreduce.jobhistory.address</name>
    <value>node01:10020</value>
</property>

<property>
    <name>mapreduce.jobhistory.webapp.address</name>
    <value>node01:19888</value>
</property>

• 第二步：修改yarn-site.xml 增加如下内容

<!-- 开启日志聚合功能，将application运行时，每个container的日志聚合到一起，保存到文件系统，一般是HDFS -->
<property>
    <name>yarn.log-aggregation-enable</name>
    <value>true</value>
</property>
<!-- 多长时间删除一次聚合产生的日志 -->
<property>
    <name>yarn.log-aggregation.retain-seconds</name>
    <value>2592000</value><!--30 day-->
</property>
<!-- 保留用户日志多少秒。只有日志聚合功能没有开启时yarn.log-aggregation-enable，才有效；现已开启 
<property>
    <name>yarn.nodemanager.log.retain-seconds</name>
    <value>604800</value>
</property>
-->
<!-- 指定聚合产生的日志的压缩算法 -->
<property>
    <name>yarn.nodemanager.log-aggregation.compression-type</name>
    <value>gz</value>
</property>
<!--  nodemanager本地文件存储目录  -->
<property>
    <name>yarn.nodemanager.local-dirs</name>
    <value>/bigdata/install/hadoop-3.1.4/hadoopDatas/yarn/local</value>
</property>
<!--  resourceManager  保存完成任务的最大个数  -->
<property>
    <name>yarn.resourcemanager.max-completed-applications</name>
    <value>1000</value>
</property>
<property>
    <name>yarn.log.server.url</name>
    <value>http://master:19888/jobhistory/logs</value>
</property>

• 第三步：将修改后的文件同步到其它机器上去：

cd /bigdata/install/hadoop-3.1.4/etc/hadoop

• 第四步：重启 yarn 及 jobhistory 服务

cd /bigdata/install/hadoop-3.1.4/
sbin/stop-yarn.sh
sbin/start-yarn.sh
mapred --daemon stop historyserver
mapred --daemon start historyserver

• 提交 MR 程序，并查看应用日志：

hadoop jar hadoop-demo-1.0.jar com.yw.hadoop.mr.p13_map_join.MapJoinMain /order.txt /map_join_out

• 点击 history 查看：

6. TimelineServer

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

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（容器）；
• ⑤ RM与指定的 NodeManager 通信，通知 NodeManager 启动容器；
  • NodeManager收到通知后，创建占据特定资源的container；
  • 然后在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任务运行;
  • 在运行任何task之前，appMaster调用setupJob()方法，创建OutputCommitter，创建作业的最终输出目录（一般为HDFS上的目录）及任务输出的临时目录（如map任务的中间结果输出目录）；
  • 小作业判断依据：小于10个map任务，只有一个reduce任务，MR输入大小小于一个HDFS块大小
  • 如何开启 uber？设置属性 mapreduce.job.ubertask.enable 值为true

configuration.set("mapreduce.job.ubertask.enable", "true");

• ⑧ 若作业不以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：ResourceManager；AM：ApplicationMaster；NM：NodeManager

• ① 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调度器

1. 资源调度器的职能

• 资源调度器是YARN最核心的组件之一，是一个插拔式的服务组件，负责整个集群资源的管理和分配。YARN提供了三种可用的资源调度器：FIFO、Capacity Scheduler、Fair Scheduler。

2. 三种调度器的介绍

先进先出调度器(FIFO)

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

容量调度器(Capacity Scheduler)

公平调度器(Fair Scheduler)

3. 自定义队列，实现任务提交不同队列

建议在集群上做一些没把握的事情前，先给集群虚拟机打个快照再说

• 前面我们看到了hadoop当中有各种资源调度形式，当前hadoop的任务提交，默认提交到default队列里面去了，将所有的任务都提交到default队列，我们在实际工作当中，可以通过划分队列的形式，对不同的用户，划分不同的资源，让不同的用户的任务，提交到不同的队列里面去，实现资源的隔离
• 资源隔离目前有2种，静态隔离和动态隔离：
  • 所谓静态隔离是以服务隔离，是通过cgroups（LINUX control groups) 功能来支持的。比如HADOOP服务包含 HDFS，HBASE，YARN等等，那么我们固定的设置比例，HDFS:20%；HBASE:40%；YARN:40%。系统会帮我们根据整个集群的CPU、内存、IO数量来分割资源，先提一下，IO是无法分割的，所以只能说当遇到IO问题时根据比例由谁先拿到资源，CPU和内存是预先分配好的。
  • 这种按照固定比例分割就是静态分割，仔细想想，这种做法弊端太多，假设我按照一定的比例预先分割好了，但是如果我晚上主要跑mapreduce, 白天主要是HBASE工作，这种情况怎么办？ 静态分割无法很好的支持，缺陷太大。
  • 动态隔离只要是针对 YARN 以及impala，所谓动态只是相对静态来说，其实也不是动态。 先说YARN， 在HADOOP整个环境，主要服务有哪些？ mapreduce（这里再提一下，mapreduce是应用，YARN 是框架，搞清楚这个概念），HBASE、HIVE、SPARK、HDFS、IMPALA， 实际上主要的大概这些，很多人估计会表示不赞同，oozie、ES、storm、kylin、flink 等等这些和 YARN 离的太远了，不依赖YARN 的资源服务，而且这些服务都是单独部署就OK，关联性不大。 所以主要和 YARN 有关也就是 HIVE、SPARK、Mapreduce。这几个服务也正是目前用的最多的（HBASE用的也很多，但是和YARN没啥关系）。
• 根据上面的描述，大家应该能理解为什么所谓的动态隔离主要是针对YARN。好了，既然YARN占的比重这么多，那么如果能很好的对YARN 进行资源隔离，那也是不错的。如果我有 3 个部分都需要使用 HADOOP，那么我希望能根据不同部门设置资源的优先级别，实际上也是根据比例来设置，建立 3 个 queue name, 开发部们 30%，数据分析部分 50%，运营部门 20%。
• 设置了比例之后，再提交 JOB 的时候设置 mapreduce.queue.name，那么JOB就会进入指定的队列里面。默认提交JOB到YARN的时候，规则是 root.users.username， 队列不存在，会自动以这种格式生成队列名称。 队列设置好之后，再通过ACL来控制谁能提交或者KIll job。
• 从上面2种资源隔离来看，没有哪一种做的很好，如果非要选一种，我会选取后者，隔离YARN资源， 第一种固定分割服务的方式实在支持不了现在的业务
• 需求：现在一个集群当中，可能有多个用户都需要使用，例如开发人员需要提交任务，测试人员需要提交任务，以及其他部门工作同事也需要提交任务到集群上面去，对于我们多个用户同时提交任务，我们可以通过配置 yarn 的多用户资源隔离来进行实现。

查看默认提交方案

第一步：node01编辑yarn-site.xml

$ pwd
/bigdata/install/hadoop-3.1.4/etc/hadoop
vim yarn-site.xml

• 添加如下内容：

<!--  指定我们的任务调度使用fairScheduler调度器; apache默认用容量调度器；cdh默认用公平调度器  -->
<property>
	<name>yarn.resourcemanager.scheduler.class</name>
	<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

<!--  指定我们的任务调度的配置文件路径  -->
<property>
	<name>yarn.scheduler.fair.allocation.file</name>
	<value>/bigdata/install/hadoop-3.1.4/etc/hadoop/fair-scheduler.xml</value>
</property>

<!-- 是否启用资源抢占，如果启用，那么当整体集群资源利用率已经超过了
yarn.scheduler.fair.preemption.cluster-utilization-threshold 这么多比例的时候，允许资源抢占发生；包括计算需要抢占的资源量，然后开始抢占
  -->
<property>
	<name>yarn.scheduler.fair.preemption</name>
	<value>true</value>
</property>
<!-- 整体集群资源利用率是否已经超过了此比例 -->
<property>
	<name>yarn.scheduler.fair.preemption.cluster-utilization-threshold</name>
	<value>0.8f</value>
</property>

<!-- 设置为true，且没有指定队列名，提交应用到用户名同名的队列；如果设置为false或没设置，默认提交到default队列；如果在allocation文件中指定了队列提交策略，忽略此属性  -->
<property>
	<name>yarn.scheduler.fair.user-as-default-queue</name>
	<value>true</value>
	<description>default is True</description>
</property>

<!-- 是否允许在提交应用时，创建队列；如果设置为true，则允许；如果设置为false，如果要将应用提交的队列，没有在allocation文件中指定，那么则将应用提交到default队列；默认为true，如果队列防止策略在allocation文件定义过，那么忽略此属性  -->
<property>
	<name>yarn.scheduler.fair.allow-undeclared-pools</name>
	<value>false</value>
	<description>default is True</description>
</property>

第二步：node01添加fair-scheduler.xml配置文件

• 公平调度器官网文档参考

vim fair-scheduler.xml

• 内容如下：

<?xml version="1.0"?>
<allocations>
	<!-- 每个队列中，app的默认调度策略，默认值是fair -->
	<defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>

	<user name="hadoop">
		<!-- 用户hadoop最多运行的app个数 -->
		<maxRunningApps>30</maxRunningApps>
	</user>
	<!-- 如果用户没有设置最多运行的app个数，那么userMaxAppsDefault限制用户默认运行app个数 -->
	<userMaxAppsDefault>10</userMaxAppsDefault>

	<!-- 定义我们的队列  -->
	<!-- 
	weight 队列的默认权重是1
	资源池权重

	aclSubmitApps
	允许提交任务到此队列的用户名、所属组；
	格式为：“user1,user2 group1,group2” 或 “ group1,group2” -》如果只有组，那么组名前要加个空格
	如果提交应用的用户或所属组在队列的ACLs中，或在当前队列的父队列的ACLs中，那么此用户有权限提交应用到此队列
	下例：
		xiaoli有权限提交应用到队列a；xiaofan在队列a的父队列dev的acls中，所以xiaofan也有权限提交应用到队列a
		比如有队列层级root.dev.a；
		有定义
		<queue name="dev">
			...
			<aclSubmitApps>xiaofan</aclSubmitApps>
			...
			<queue name="a">
				...
				<aclSubmitApps>xiaoli</aclSubmitApps>
			</queue>
		</queue>

	aclAdministerApps
	允许管理任务的用户名、所属组；目前管理动作只有kill application
	格式同上。 
	 -->
	<queue name="root">
		<minResources>512 mb,4 vcores</minResources>
		<maxResources>102400 mb,100 vcores</maxResources>
		<maxRunningApps>100</maxRunningApps>
		<weight>1.0</weight>
		<schedulingMode>fair</schedulingMode>
		<aclSubmitApps> </aclSubmitApps>
		<aclAdministerApps> </aclAdministerApps>

		<queue name="default">
			<minResources>512 mb,4 vcores</minResources>
			<maxResources>30720 mb,30 vcores</maxResources>
			<maxRunningApps>100</maxRunningApps>
			<schedulingMode>fair</schedulingMode>
			<weight>1.0</weight>
			<!--  所有的任务如果不指定任务队列，都提交到default队列里面来 -->
			<aclSubmitApps>*</aclSubmitApps>
		</queue>

		<queue name="hadoop">
			<minResources>512 mb,4 vcores</minResources>
			<maxResources>20480 mb,20 vcores</maxResources>
			<maxRunningApps>100</maxRunningApps>
			<schedulingMode>fair</schedulingMode>
			<weight>2.0</weight>
			<aclSubmitApps>hadoop hadoop</aclSubmitApps>
			<aclAdministerApps>hadoop hadoop</aclAdministerApps>
		</queue>

		<queue name="develop">
			<minResources>512 mb,4 vcores</minResources>
			<maxResources>20480 mb,20 vcores</maxResources>
			<maxRunningApps>100</maxRunningApps>
			<schedulingMode>fair</schedulingMode>
			<weight>1</weight>
			<aclSubmitApps>develop develop</aclSubmitApps>
			<aclAdministerApps>develop develop</aclAdministerApps>
		</queue>

		<queue name="test1">
			<minResources>512 mb,4 vcores</minResources>
			<maxResources>20480 mb,20 vcores</maxResources>
			<maxRunningApps>100</maxRunningApps>
			<schedulingMode>fair</schedulingMode>
			<weight>1.5</weight>
			<aclSubmitApps>test1,hadoop,develop test1</aclSubmitApps>
			<aclAdministerApps>test1 group_businessC,supergroup</aclAdministerApps>
		</queue>
	</queue>
	<!-- 
		包含一系列的rule元素；这些rule元素用来告诉scheduler调度器，进来的app按照规则提交到哪个队列中
		有多个rule的话，会从上到下进行匹配；
		rule可能会带有argument；所有的rule都带有create argument，表示当前rule是否能够创建一个新队列；默认值是true
		如果rule的create设置为false，且在allocation中没有配置此队列，那么尝试匹配下一个rule
	-->
	<queuePlacementPolicy>
		<!-- app被提交到指定的队列；且此xml文件没有定义此队列，create为true，则创建；若为false，如果队列不存在，则不创建，匹配下一条rule -->
		<rule name="specified" create="false"/>
		<!-- app被提交到提交此app的用户所属组的组名命名的队列；如果队列不存在，则不创建，继续匹配下一个rule -->
		<rule name="primaryGroup" create="false" />
		<!-- 如果上边的rule都没有匹配上，则app提交到queue指定的的队列；如果没有指定queue属性，默认值是root.default -->
		<rule name="default" queue="root.default"/>
	</queuePlacementPolicy>
</allocations>

第三步：将修改后的配置文件拷贝到其它机器

scp yarn-site.xml fair-scheduler.xml node02:$PWD
scp yarn-site.xml fair-scheduler.xml node03:$PWD

第四步：重启yarn集群

cd /bigdata/install/hadoop-3.1.4/
sbin/stop-yarn.sh
sbin/start-yarn.sh

第五步：修改任务提交的队列

• 修改代码，添加我们mapreduce任务需要提交到哪一个队列里面去

Configuration configuration = new Configuration();

//情况1
//注释掉 configuration.set("mapreduce.job.queuename", "hadoop");
//匹配规则：<rule name="primaryGroup" create="false" />

//情况2
configuration.set("mapreduce.job.queuename", "hadoop");
//匹配规则：<rule name="specified" create="false"/>

//情况3
configuration.set("mapreduce.job.queuename", "hadoopv1");
//allocation文件中，注释掉<rule name="primaryGroup" create="false" />；刷新配置yarn rmadmin -refreshQueues
//匹配规则：<rule name="default" queue="root.default"/>

• hive任务指定提交队列，hive-site.xml文件添加：

<property>
    <name>mapreduce.job.queuename</name>
    <value>test1</value>
</property>

• spark任务运行指定提交的队列

1- 脚本方式
--queue hadoop

2- 代码方式
sparkConf.set("spark.yarn.queue", "develop")

YARN基本使用

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>

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
yarn --daemon start resourcemanager

#相反，可单独关闭
#过时$HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager
yarn --daemon stop resourcemanager

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

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

3. YARN 常用命令

• 查看 YARN 命令列表：

• 查看 yarn application 命令：

# 1.查看正在运行的任务
yarn application -list
# 2.杀掉正在运行任务
yarn application -kill application_1617095172572_0003	
# 3.查看节点列表
yarn node -list
# 4.查看节点状况；所有端口号与上图中端口号要一致（随机分配）
yarn node -status node03:38122
# 5.查看yarn依赖jar的环境变量
yarn classpath

• 查看 yarn logs：

# 1.查看应用的日志
yarn logs -applicationId application_1638460497520_0001