首页  思维导图  详情

Hadoop调优

2024-03-11 01:23:17   3  举报





AI智能生成

Hadoop调优

hadoop 大数据

作者其他创作

大纲/内容

HDFS调优

HDFS核心参数配置

查看NN和DN占用堆内存命令

查看NN和DN的进程号：jps

查看占用堆内存大小：jmap -heap 进程号

NameNode内存配置

hadoop-env.sh配置

Hadoop2.x

默认NameNode堆内存大小为2000MB

配置方法：通过HADOOP_NAMENODE_OPTS=-Xmx3072m  （这里配置为3M）

Hadoop3.x

默认NameNode堆内存大小不确定，由JVM堆内存弹性伸缩

配置方法：export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m"

推荐配置：NameNode最小内存配置为1G，每超过1000000个Block，增加1G内存

DataNode内存配置

hadoop-env.sh配置

Hadoop3.x

默认DataNode堆内存大小不确定，由JVM堆内存弹性伸缩

配置方法：export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m"

推荐配置：DataNode最小内存配置为4G，能够处理40000000个Block，如果Block数或者副本数每升高1000000个，提高1G内存

NameNode核心线程数

hdfs-site.xml配置

指导公式：20 * loge(Cluster数量)

配置方法：dfs.namenode.handler.count

开启回收站

hdfs-site.xml配置

默认不开启回收站

回收站内文件过期时间：dfs.trash.interval = 0

检查回收站中文件是否过期的线程开启间隔时间：dfs.trash.checkpoint.interval = 0

开启回收站

dfs.trash.interval = 具体时间   （表示回收站中文件默认多久后自动清空，单位是分钟）

检查回收站中文件是否过期的线程开启间隔时间配置：dfs.trash.checkpoint.interval = 具体时间（分钟）

dfs.trash.checkpoint.interval <= dfs.trash.interval

回收站文件默认存储到/user/用户名/.Trash目录下

删除逻辑走回收站的情况

命令行上的删除逻辑会走回收站：hadoop fs rm ...

WebUI上的删除逻辑不走回收站

代码删除逻辑默认不走回收站，除非走以上逻辑

HDFS集群压测

影响因素

网络带宽：尽可能提升网络带宽

磁盘：尽可能使用固态硬盘

通过python开启简单的服务器客观感受HDFS文件拉取速度：python -m SimpleHttpServer

Hadoop默认提供了测试HDFS性能的工具包

测试HDFS写性能

命令 hadoop -jar /xxx/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 文件个数（cpu个数 - 1） -fileSize 文件大小（128MB）

测试参数说明

nrFiles：cpu核数 - 1，表示同时并行启动MapTask个数

-fileSize：单个MapTsak处理的文件的大小

测试结果解析

Throughput mb/sec

含义：平均单个MapTask的吞吐量 MB/sec

计算方式：处理的总文件大小 / 单个MapTask处理时间总和

集群整体吞吐量计算

nrFiles * Throughput mb/sec

Average IO rate mb/sec

含义：平均单个MapTask的吞吐量

计算方式：每个MapTask处理文件大小/每一个MapTask的处理时间总和 / MapTask的总数量

IO rate std deviation：方差、反映各个mapTask处理的差值，越小越均衡

可能出现bug

因为整个测试的mr过程中内存消耗较大，如果Yarn没有关闭虚拟内存检测，可能报内存异常

处理方案：在yarn-site.xml中关闭虚拟内存检测，分发配置

测试HDFS读性能

命令 hadoop -jar /xxx/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 文件个数（cpu个数 - 1） -fileSize 文件大小 （128MB）

测试参数说明：同理测试HDFS写性能

测试结果分析

测试出的集群总吞吐量远超网络带宽

因为提交测试读性能的客户端根据节点距离最近，选择直接读取本地DN上的数据，不走网络IO

测试出的集群总吞吐量正常与带宽几乎一致

测试HDFS读性能以前，要先测试HDFS写性能

删除因测试HDFS写性能产生的数据

命令 hadoop -jar /xxx/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean

HDFS多目录

NameNode多目录

hdfs-site.xml

配置方式，配置文件看情况分发

一般来说配置的两个目录分别由不同磁盘mount

NameNode多目录是数据备份，配置的多目录下的数据完全一致

NameNode多目录配置在生产环境中意义并不大

DataNode多目录

hdfs-site.xml

配置方式，配置文件看情况分发

一般来说配置的两个目录分别由不同磁盘mount

DataNode配置多目录不再是数据备份，而是多数据分节点存储，配置的多目录下数据不一致

DataNode的多目录配置在生产环境下还是会用到的，特别是当原磁盘已经快要存满数据， 我们就添加一块新的磁盘去mount新的目录，从而将该目录关联到datanode的数据存储路径

磁盘数据均衡

生成磁盘均衡计划 hdfs diskbalancer -plan 节点主机名

执行磁盘均衡计划 hdfs diskbalancer -execute 节点主机名.plan.json

查询磁盘均衡情况 hdfs diskbalancer -query 节点主机名

停止磁盘均衡计划 hdfs diskbalancer -stop 节点主机名.plan.json

对于单磁盘来说，即使调用该命令也不会生成磁盘数据均衡计划

集群的扩容和缩容

白名单：配置的主机ip所对应的DataNode节点可以存储数据

可以动态添加DataNode节点实现动态扩容机制

扩容节点启动DataNode：hdfs --daemon start datanode

扩容节点启动NodeManager：yarn --daemon start nodemanager

扩容的节点后，集群数据不均衡

开启数据均衡：/etc/hadoop-3.1.3/sbin/start-balancer.sh -threashold x （其中x代表集群中个节点的磁盘利用率相差不超过x%）

关闭数据均衡：/etc/hadoop-3.1.3/sbin/stop-balancer.sh

黑名单：配置的主机ip所对应的DataNode节点不可以存储数据

可以动态添加DataNode节点实现动态缩容机制

退役节点时几点状态变为Decommissioning状态，在此过程中退役节点上的数据块会自动复制给其他存活节点， 直到退役节点的状态变为Decommissioned，所有数据块复制完成为止

要考虑当前的副本策略，如果副本数为3，服役的节点小于等于3，是不能退役成功的，需要修改副本数以满足当前集群节点数

缩容后，集群数据不均衡，同样可以使用start-balancer.sh -threashold x

如果黑白名单配置了同一DataNode节点，该DataNode节点展现退役状态

集群黑白名单配置及生效方案

在hadoop配置目录下创建whitelist和blacklist文件

在hdfs-site.xml中配置白名单和黑名单的文件路径

白名单配置

黑名单配置

每次对whitelist或者blacklist进行了改动都要分发配置

黑白名单生效方式

首次配置：重启集群

非首次配置（之前已配好，仅修改文件）：刷新NameNode即可命令为 hdfs dfsadmin -refreshNodes

HDFS存储优化

纠删码

Hadoop3.x引入

引入纠删码的原因：原有副本策略太耗费磁盘空间，假设300M的数据，存储3个副本，就需要整个集群900M的磁盘空间， 但是生产环境中实际上副本几乎用不到，但是又必须容错，所以这里有很大的磁盘空间浪费，因此引入了纠删码

原理：一种编码容错技术，对数据块分块分组并编码得到冗余校验信息，一旦某些数据信息丢失， 我们仍然可以根据剩下的数据信息和校验信息重新计算提高数据容错

纠删码使用的好处：将数据分为数据单元和校验单元存储，使用更少的磁盘空间保证同样的容错性， 但是一旦发生故障，会耗费cpu性能计算恢复数据

命令

查询HDFS中现有的纠删码策略 hdfs -ec -listPolicies

向HDFS中添加新的纠删码策略 hdfs -ec -addPolicies -policyFile <File>

获取某一文件或目录的纠删码策略 hdfs -ec -getPolicy -path <path>

移除HDFS中的纠删码策略 hdfs -ec -removePolicy -policy <policy>

给某一目录或者文件设置纠删码策略 hdfs -ec -path <path> -setPolicy  <policy> [-replicate]

取消某一目录或者文件的纠删码策略 hdfs -ec -unsetPolicy -path <path>

列出所有纠删码的编码方式 hdfs -ec -listCodecs

RS-LEGACY

XOR

启动某一纠删码策略 hdfs -ec -enablePolicy -policy <policy>

关闭某一纠删码策略 hdfs -ec -disablePolicy -policy <policy>

-help <command-name>

默认策略

RS-10-4-1024k

编码方式：RS

10个数据单元

4个校验单元

会把数据块划分为1024k的一个个小单元块，从而构成一个一个的数据单元

若数据单元和校验单元的总个数不低于10个，那么总能够在数据出现异常时可通过计算恢复数据

默认不开启

RS-3-2-1024k

RS-6-3-1024k

默认开启

RS-LEGACY-6-3-1024k

XOR-2-1-1024k

异构存储

含义：解决不同的数据存储在不同类型的硬盘中，达到最佳性能的问题

现在正在访问的数据：内存镜像RAM_DISK

经常访问的数据：固态硬盘SSD

不经常看的数据：机械硬盘DISK

永久保存的数据：ARCHIVE

ARCHIVE没有特指某种存储介质，通常指计算能力较弱，存储密度较高的存储介质，用来解决数据量扩增的问题，一般用于归档

存储策略

Lazy_Persist

RAM：1  DISK：n - 1

ALL_SSD

SSD: n

ONE_SSD

SSD：1，DISK：n - 1

HOT

默认存储策略，DISK：n

WARM

DISK：1，ARCHIVE：n - 1

COLD

ARCHIVE：n

如果当前硬盘类型均不为ARCHIVE，那么此时写数据会失败

hdfs-site.xml中配置

HDFS并不能主动识别硬盘的类型，所以我们需要手动指定

<property>     <name>dfs.datanode.data.dir</name>     <value>[SSD]file://${hadoop.tmp.dir}/dfs/data</value> </property>

硬盘类型

[RAM_DISK]

[SSD]

[DISK]

[ARCHIVE]

命令

查看当前有哪些存储策略 hdfs storagePolicies -listPolicies

为指定路径（目录或文件）配置存储策略 hdfs storagePolicies -setStoragePolicy -path xxx -policy xxx

一旦某目录或文件的我们更换存储策略后，必须使用 hdfs mover 文件或目录路径命令移动文件块

获取指定路径（目录或文件）的存储策略 hdfs storagePolicies -getStoragePolicy -path xxx

取消某路径的存储策略 hdfs storagePolicies -unsetStroragePolicy -path xxx

查看某个文件块的分布 hdfs fsck 文件名 -files -blocks -locations

查看集群节点：hadoop dfsadmin -report

Lazy_Persist存储策略可能出现的问题

现象：虽然当前采用的是Lazy_Persist存储策略，但是数据块均存储在DSIK中

如果提交写数据请求的Client所在的DataNode节点没有RAM_DISK， 则会写入Client所在DataNode节点的DISK中， 其余副本写入其他DataNode节点的DISK

如果提交写数据请求的Client所在的DataNode节点有RAM_DISK， 但是没有配置dfs.datanode.max.locked.memory，或者其配置的很小， 小于dfs.block.size，则会写入Client所在DataNode节点的DISK中， 其余副本写入其他DataNode节点的DISK

如果dfs.datanode.max.locked.memory设置过大也可能出现错误， 因为虚拟机的max.locked.memory默认为64KB，所以如果前一个参数配置过大，那么就会报错DataNode的可用内存空间不能超过64KB

HDFS故障排查

NameNode数据丢失

情景：NameNode挂了，并且NameNode存储的数据信息丢失

修复方式：将SecondaryNameNode节点上的对应数据块信息拷贝回NameNode节点

启动NameNode：hdfs --daemon start NameNode

集群安全模式&磁盘修复

集群安全模式

在安全模式下，客户端只能读取NameNode数据，不能修改和删除NameNode数据

进入安全模式的场景

NameNode在加载镜像文件和编辑日志的期间处于安全模式

NameNode在接受DataNode注册的期间处于安全模式

退出安全模式的场景

dfs.namenode.safemode.min.datanodes：最小的datanode数，默认为0

dfs.namenode.safemode.threadhold-pct：最小要求的block数达到系统总block数的百分比，默认为0.999f，言外之意就是仅仅容忍丢失1个块

dfs.namenode.safemode.extension：安全模式的稳定时间，默认为30000毫秒，也就是30秒

命令

hdfs dfsadmin -safemode get：查看安全模式状态

hdfs dfsadmin -safemode enter：强制进入安全模式

hdfs dfsadmin -safemode leave：强制离开安全模式

hdfs dfsadmin -safemode wait：阻塞安全模式的离开，需要我们调用强制离开安全模式才能离开安全模式

磁盘修复

场景：删除某DataNode的至少2个数据块，可能立马看不到效果 因为默认DataNode每隔6小时向NameNode报告块信息 所以我们可以重启HDFS集群即可马上进入到安全模式观察到WebUI提示我们缺少哪个块等信息

方案

利用磁盘数据恢复工具恢复被删除的数据快信息

按照WebUI上的提示信息取删除NameNode的元数据信息

慢磁盘问题

场景：慢磁盘是指写入数据很慢的一类磁盘，慢磁盘问题是很常见的问题，当机器运行时间长了，上面的任务跑多了， 磁盘的读写性能自然就会退化，那么严重的时候就会导致数据写入磁盘延迟的问题

如何发现慢磁盘？

通过现象观察慢磁盘：向HDFS创建一个目录，只需要不到1s，如果我们发现创建目录大多数时候超过1s，说明磁盘极大可能出现了问题

通过WebUI上NN和DN的心跳时间发现慢磁盘

默认NN和DN的心跳是每3秒一次

如果NN和DN上关于心跳通信时间超过了3s，那么就出现了慢磁盘问题

通过fio命令，测试磁盘的读写性能

安装fio：yum install -y fio

准备1G大小的test.log文件

执行fio测试磁盘顺序读性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r

结果分析：顺序读的速度为360MiB/s

执行fio测试磁盘顺序写性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_w

结果分析：顺序写的速度为341MiB/s

执行fio测试磁盘随机写性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randw

结果分析：随机写的速度为309MiB/s

执行fio测试磁盘混合随机读写性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r_w -ioscheduler=noop

结果分析：混合随机读写测试中，随机读速度为220MiB/s，随机写速度为94.6 MiB/s

小文件归档

归档原因

1M的小文件和128M的文件占用的NameNode的内存空间是一样的， 小文件过多会占用NameNode大量的内存空间，很快导致NameNode的内存空间不足  说明：1M的小文件占用的磁盘空间仍为1M，而不是128M

HAR归档

启动YARN，要启动MR

执行命令 hadoop archive -archiveName input.har /input /ouput

归档结果分析：HAR归档能够将多个小文件当作是一个大文件，整体归档存入一个HDFS数据块，仅占用一份文件所占用的NameNode的内存空间， 对内还是一个个独立的文件，对NameNode而言却是一个整体，减少了占用NameNode的内存空间

查看归档文件

方式一：hadoop fs -ls /output/input.har

方式二：hadoop fs -ls har:///output/input.har

解归档文件：hadoop fs -cp /output/input.har/* /

HDFS数据迁移

Apache Hadoop内部数据迁移

方案一：scp实现两个远程主机之间的数据复制

推数据 scp -r 本地文件路径  远程用户名@远程主机名:/文件路径

拉数据 scp -r 远程用户名@远程主机名:/文件路径本地文件路径

本地转发 scp -r 远程用户名1@远程主机名1:/文件路径  远程主机名2@远程主机名2:/文件路径 说明：远程主机1和远程主机2之间如果没有配置ssh的方式时即可采用本方式

方案二：采用distcp命令实现两个Hadoop集群之间的递归数据复制

bin/hadoop distcp hdfs://hadoop102:8020/user/liangheee/hello.txt hdfs://hadoop105:8020/user/liangheee/hello.txt

Apache Hadoop迁移到CDH

MapReduce调优

性能瓶颈

计算机性能

CPU

内存

网络

磁盘

I/O操作优化

数据倾斜

Map运行时间太长，Reduce等待太久

小文件过多

Shuffle

MapTask

解决数据倾斜：自定义partitioner

MapTask使用内存上限

mapreduce.map.memory.mb

默认上限1024M

建议：根据128M数据对应1G来动态调整

该内存配置指的是MapTask向RM申请的内存资源大小（可理解为要求Container至少有这么多内存资源）， 不仅可以跑java程序还可以跑其他语言的程序

MapTask堆内存大小

mapreduce.map.java.opts

如果堆内存不够，报错java.lang.OutOfMemoryError

这个是用于JVM堆内存大小配置，必须小于mapreduce.map.memory.mb，一般为mapreduce.map.memory.mb的0.75倍， 要预留一部分给java代码使用

MapTask的Cpu核数

mapreduce.map.cpu.vcores

默认MapTask的cpu核数为1

计算密集型任务可以增加cpu核数

减少环形缓冲区溢写次数

增加环形缓冲区大小

mapreduce.task.io.sort.mb

默认为100M

可以调整到200M

提高环形缓冲区反向溢写比例

mapreduce.sort.spill.percent

默认为80%

可以调整到90%

提高每轮merge文件个数

mapreduce.task.io.sort.factor

默认10个文件

可以提高到20个文件

不影响业务前提下进行预聚合

job.setCombinerClass(xxxReducer.class);

减少磁盘IO，可进行数据压缩

conf.setBoolean("mapreduce.map.output.compress",true); conf.setClass("mapreduce.map.output.compress.codec",SnappyCodec.class,CompressionCodec.class);

每个MapTask最大重试次数，超过该值则认为失败

mapreduce.map.maxattempts

默认4次，可根据己其性能适当提高

ReduceTask

ReduceTask使用内存上限

mapreduce.reduce.memory.mb

默认上限1024M

建议：根据128M数据对应1G来动态调整，可以调整到4G-6G

ReduceTask堆内存大小

mapreduce.reduce.java.opts

如果堆内存不够，报错java.lang.OutOfMemoryError

ReduceTask的Cpu核数

mapreduce.reduce.cpu.vcores

默认ReduceTask的cpu核数为1

计算密集型任务可以增加cpu核数，2到4个cpu核

提高每个Reduce到Map中拉取数据的Fetcher线程数

mapreduce.reduce.shuffle.parallelcopies

默认为5

可以调整为10

提高reduce阶段shuffle占用reduce内存大小

mapreduce.reduce.shuffle.input.buffer.percent

默认为0.70

可以提高至0.75

reduce阶段单个shuffle任务占用shuffle总内存比例，超过就溢写到磁盘

mapreduce.reduce.shuffle.memory.limit.percent

默认为0.25

保持不变

reduce阶段shuffle内存中数据达到多少比例开始merge

mapreduce.reduce.shuffle.merge.percent

默认为0.66

可以提高至0.70

每个ReduceTask最大重试次数，超过该值则认为失败

mapreduce.reduce.maxattempts

默认4次，可根据己其性能适当提高

Map任务完成数量达到该比例后，ReduceTask开始申请资源启动

mapreduce.job.reduce.slowstart.completedmaps

默认为0.05

视情况适当调整

尽量避免走reduce

设置mapreduce任务的超时时间

mapreduce.task.timeout （单位毫秒）

如果mapreduce任务在该配置时间内，既没有读入也没有写出，也没有更新状态信息，便会超时终止

默认600000毫秒，也就是10分钟

视实际情况调整该参数，若mapreduce处理时间较长，则可以延长超时时间

数据倾斜问题

数据倾斜现象

数据频率倾斜：某一区域的数据量远大于另一区域的数据量

数据大小倾斜：部分记录的大小远大于平均值

减少数据倾斜的方案

首先检查是否因为空值过多导致数据倾斜

方案一：如果空值无意义，那么尽量在map端过滤

方案二：如果空值有意义，可以自定义分区，加上随机数打散，再进行二次聚合

尽量在Reduce之前进行聚合，可行的方案有提前Combiner和Map Join

提升Reduce的数量

Yarn调优

配置参数

ResourceManager相关

调度器

yarn.resourcemanager.scheduler.class

Apache Hadoop默认为Capacity Scheduler；CDH默认为Fair Scheduler；我们一定不会使用FIFO调度器

RM处理调度器请求的线程数

yarn.resourcemanager.scheduler.client.thread-count

默认为50

不能超过集群总线程资源，而且还要预留一部分给其他应用使用

NodeManager相关

是否让Yarn自己检测硬件配置

yarn.nodemanager.resource.detect-hardware-capabilities

默认为false

建议采用默认，不开启

是否将虚拟核数当作cpu核数

yarn.nodemanager.resource.count-logical-processors-as-cores

默认为false

如果当前集群的cpu均为i5或i7，也就是物理cpu一致，此时不推荐采用逻辑核数

虚拟核数和物理核数的乘积

yarn.nodemanager.resource.pcores-vcores-multiplier

默认为1.0

nodemanager使用内存

yarn.nodemanager.resource.memory-mb

默认为8G

根据硬件环境来配置

nodemanager为系统预留多少内存

yarn.nodemanager.resource.system-reserved-memory-mb

一般配置nodemanager使用内存即可，这个参数不配置

nodemanager使用cpu核数

yarn.nodemanager.resource.cpu-vcores

默认为8个

按硬件环境来配置

是否开启物理内存检查限制Container

yarn.nodemanager.pmem-check-enabled

默认打开

是否开启虚拟内存检查限制Container

yarn.nodemanager.vmem-check-enabled

默认打开

建议关闭虚拟内存检测

虚拟内存和物理内存比例

yarn.nodemanager.vmem-pmem-ratio

默认2.1

Container相关

容器最小内存

yarn.scheduler.minimum-allocation-mb

默认为1G

按硬件环境来配置

容器最大内存

yarn.scheduler.maximum-allocation-mb

默认为8G

按硬件环境来配置

容器最小CPU核数

yarn.scheduler.minimum-allocation-vcores

默认为1个

按硬件环境来配置

容器最大CPU核数

yarn.scheduler.maximum-allocation-vcores

默认为4个

按硬件环境来配置

如果每个节点的资源不一致，需要为每个节点单独配置

调度器配置

生产环境下怎么创建队列

默认情况下调度器只有default队列

创建队列的参考方式

针对不同框架创建不同队列，比如Flink、Spark、Hive等，企业很少这样划分队列

按照业务模块创建不同队列，登录注册、购物车、下单、业务部门1、业务部门2

创建多队列的好处

因为担心员工不小心，写递归死循环代码，把所有资源全部耗尽

实现任务的降级使用，特殊时期保证重要的任务队列资源充足。11.11  6.18 业务部门1（重要）=》业务部门2（比较重要）=》下单（一般）=》购物车（一般）=》登录注册（次要）

容量调度器

需求：default队列占总内存的40%，最大资源容量占总资源60%，hive队列占总内存的60%，最大资源容量占总资源80%

步骤

配置多队列的容量调度器

分发配置文件

刷新yarn队列 yarn rmadmin -refreshQueues

测试：向Hive队列提交作业

方式一：hadoop jar的方式 (注: -D表示运行时改变参数值)

方式二：打jar包的方式，默认的任务提交都是提交到default队列的。如果希望向其他队列提交任务，需要在Driver中声明

测试效果

任务优先级

容量调度器支持任务优先级，在资源紧张时，优先级较高的任务将优先获取资源

默认情况下，Yarn上所有任务的优先级为0，如果想开启任务优先级，须开放此限制

设置任务优先级步骤

修改yarn-site.xml文件，增加以上参数

分发配置，重启Yarn

模拟资源环境紧张，可连续提交以上任务，直到新提交的任务申请不到资源为止

资源紧张如图所示

再次重新提交优先级高的任务

优先级更高的任务优先获取资源

也可以通过以下命令修改正在执行的任务的优先级，yarn application -appID <ApplicationID> -updatePriority 优先级

公平调度器

需求：创建两个队列，分别是test和atguigu（以用户所属组命名）。期望实现以下效果：若用户提交任务时指定队列，则任务提交到指定队列运行；若未指定队列，test用户提交的任务到root.group.test队列运行，atguigu提交的任务到root.group.atguigu队列运行（注：group为用户所属组）

公平调度器的配置涉及到两个文件，一个是yarn-site.xml，另一个是公平调度器队列分配文件fair-scheduler.xml（文件名可自定义）

配置文件参考资料： https://hadoop.apache.org/docs/r3.1.3/hadoop-yarn/hadoop-yarn-site/FairScheduler.html

任务队列放置规则参考资料： https://blog.cloudera.com/untangling-apache-hadoop-yarn-part-4-fair-scheduler-queue-basics/

配置步骤

修改yarn-site.xml文件，加入以下参数

配置fair-scheduler.xml

分发配置并重启Yarn

测试提交任务

提交任务时指定队列，按照配置规则，任务会到指定的root.test队列

结果显示

提交任务时不指定队列，按照配置规则，任务会到root.atguigu.atguigu队列

结果显示