开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第7天 juejin.cn/post/716729…
什么是Yarn?
从Hadoop2开始，官方把资源管理单独剥离出来，主要是为了考虑后期作为一个公共的资源管理平台，任何满足规则的计算引擎都可以在它上面执行。所以YARN可以实现HADOOP集群的资源共享，不仅仅可以跑MapRedcue，还可以跑Spark、Flink。
Yarn架构分析
ResourceManager：是主节点，主要负责集群资源的分配和管理NodeManager：是从节点，主要负责当前机器资源管理
Yarn资源管理模型
YARN主要管理内存和CPU这两种资源类型
当NodeManager节点启动的时候自动向ResourceManager注册，将当前节点上的可用CPU信息和内存 信息注册上去。
集群内存：24GB
集群CPU 16Cores
活跃从节点3个，其中主节点是主从一体节点
这里显示的节点参数是
- yarn.nodemanager.resource.memory-mb：单节点可分配的物理内存总量，默认是8MB*1024， 即8G
- yarn.nodemanager.resource.cpu-vcores：单节点可分配的虚拟CPU个数，默认是8
就算你机器没有，读取默认的也会读取到这个值，属于虚标。
Yarn资源调度
集群资源是有限的，所以需要用资源调度器来进行合理分配。
资源调度器分为三种
- FIFO Scheduler：先进先出
- Capacity Scheduler：先进先出的多队列版本，队列内部先进先出
- FairScheduler：多队列，多用户共享资源
- FIFO Scheduler：是先进先出的，大家都是排队的，如果你的任务申请不到足够的资源，那你就等 着，等前面的任务执行结束释放了资源之后你再执行。这种在有些时候是不合理的，因为我们有一些 任务的优先级比较高，我们希望任务提交上去立刻就开始执行，这个就实现不了了。
- CapacityScheduler：它是FifoScheduler的多队列版本，就是我们先把集群中的整块资源划分成多 份，我们可以人为的给这些资源定义使用场景，例如图里面的queue A里面运行普通的任务， queueB中运行优先级比较高的任务。这两个队列的资源是相互对立的 但是注意一点，队列内部还是按照先进先出的规则。
- FairScheduler：支持多个队列，每个队列可以配置一定的资源，每个队列中的任务共享其所在队列 的所有资源，不需要排队等待资源 具体是这样的，假设我们向一个队列中提交了一个任务，这个任务刚开始会占用整个队列的资源，当 你再提交第二个任务的时候，第一个任务会把他的资源释放出来一部分给第二个任务使用
实际工作中，我们一般使用第二种资源调度器
实战：Yarn配置多资源队列
我们增加2个队列，一个是online队列，一个是offline队列
online队列里面运行实时任务
offline队列里面运行离线任务
具体步骤如下： 修改集群中 etc/hadoop 目录下的 capacity-scheduler.xml 配置文件 修改和增加以下参数，针对已有的参数，修改value中的值，针对没有的参数，则直接增加 这里的 default 是需要保留的，增加 online,offline ，这三个队列的资源比例为 7:1:2 具体的比例需要根据实际的业务需求来，看你们那些类型的任务比较多，对应的队列中资源比例就调高一 些，我们现在暂时还没有online任务，所以我就把online队列的资源占比设置的小一些。 先修改bigdata01上的配置
1：指定多队列
yarn.scheduler.capacity.root.queues
default,online,offline
队列列表
2.指定默认队列资源70%
yarn.scheduler.capacity.root.default.capacity
70
default队列70%
3.另外两个队列的资源
yarn.scheduler.capacity.root.online.capacity
10
yarn.scheduler.capacity.root.offline.capacity
20
4.资源上限
yarn.scheduler.capacity.root.default.maximum-capacity
70
Default队列可使用的资源上限.
yarn.scheduler.capacity.root.online.maximum-capacity
10
yarn.scheduler.capacity.root.offline.maximum-capacity
20
分别拷贝到2号机和3号机
scp -rq capacity-scheduler.xml bigdata02:/data/soft/hadoop-3.2.0/etc/hadoop/
scp -rq capacity-scheduler.xml bigdata03:/data/soft/hadoop-3.2.0/etc/hadoop/
重启集群生效配置
针对资源调度的看法
- FIFO Scheduler：仅做了解弃用
- Capacity Scheduler：容量调度器尝试用在集群节点100台+以上
- Fair Scheduler：节点台数<100优选，资源灵活配置
针对Fair Scheduler：
假设有两个用户 A 和 B，分别拥有一个自己的队列 Queue A 和 Queue B。当 A 启动一个 job1 而 B 没有提交任务时，A 会获得集群的全部资源（Queue A + Queue B）；当 A 的 job1 仍在运行，且 B 启动第一个 job2 时，Queue A 会逐渐释放一半资源，两个任务会各自占用集群的一半资源。如果此时 B 再启动第二个 job3 并且其它 job 仍在运行时，则它将会和 B 的第一个 job2 共享队列 B 的资源，也就是 Queue B 的两个 job 将会分别占用集群的四分之一资源，而 A 的 job1 仍然占用集群的一半资源。
此时，这个过程中，job1 和 job2 分别占用集群的一半资源，后来由于 job3 的加入，job2 和 job3 平分 Queue B 的资源。最终结果就是集群的资源在两个用户之间实现了公平共享。
参考案例：
生产级实践：Oozie Launcher优化，配合Yarn资源调度模式能够更好地理解
