Yarn实现了计算资源的调度能力，文章开始前可以先思考几个问题：
- Yarn是如何管理的集群资源
- 怎么提交作业到Yarn上
- Yarn如何给任务合理分配资源
1. Yarn的基础架构
| 成员 | 主要任务 |
|---|---|
| Resource Manager |
1. rm是一个全局的资源管理器。负责整个集群的资源管理和分配。主要由调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）组成
2. 调度器根据容量、队列等限制条件，将系统的资源分配给各个正在运行的app。资源分配的单位是Container
3. ASM管理整个集群中所有的app，包括app的提交、与调度器协商资源以启动AppMaster，监控AppMaster运行状态并在失败时重新启动它
|
| ApplicationMaster（AM） |
1. 用户提交的每个app都包含一个AM。
2. AM与RM的调度器协商获取资源，然后将资源分配给app，与NM通讯启动或停止任务。
3. AM监控所有任务运行状态，并在任务运行失败时重新资源以重启任务
|
| NodeManager |
NM是每个节点上的资源和任务管理器
1. 它会定时向RM会报本节点上的资源使用情况和各个Container的运行状态
2. 接收并处理来自AM的Container启动或停止的请求
|
| Container |
1. Yarn中的资源抽象，它封装了某个节点资源的如：内存、CPU、磁盘、网络等。当AM向RM申请资源时，RM返回的资源便是用Container表示的。
2. Yarn会为每个任务分配一个Container，且该任务只能使用该Container的资源
3. Container是一个动态资源划分的单位，它是根据app的需求动态生成的
|
2. 工作机制与作业提交运行过程
看一下一个MR程序提交到Yarn的全过程
| 过程 | 说明 |
|---|---|
|
1. 申请Application
|
MR程序提交任务到client，client YarnRunner向RM申请一个Application，RM将程序的资源路径+app_id返回给YarnRunner, YR将运行所需资源提交HDFS上。
|
|
2. 申请启动mrAppMaster
|
a. YarnRunner资源提交完之后，申请启动mrAppMaster。
b. RM收到client请求后，RM将用户请求初始化为一个Task，将该job添加到容量调度器
c. 其中一个空闲NM领到该Job，NM创建Container并启动mrAppMaster。
|
|
3. 申请资源与运行任务
|
a. mrAppMaster从HDFS上拷贝资源到本地，接着向RM申请运行MapTask的资源，RM将任务分配给另外两个NM，两个NM领取任务并创建container。
b. mrAppMaster向两个NM发送程序启动脚本，两个NM分别启动MapTask，MapTask开始计算：对数据分区排序。
c. mrAppMaster等待所有的MapTask运行完毕之后，向RM继续申请资源运行ReduceTask（ReduceTask向MapTask获取相应的分区数据）。
|
|
4. mrAppMaster注销
|
程序运行完毕之后，mrAppMaster向RM申请注销自己。
|
|
5. 进度和状态更新
|
Yarn中的任务将其任务和状态返回给Apps Manager，客户端每秒向其请求进度更新并展示给用户
|
|
6. 作业完成
|
a. 除了向应用管理器请求作业进度外, 客户端每 5 秒都会通过调用 waitForCompletion()来检查作业是否完成。
b. 作业完成之后, 应用管理器和 Container 会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。
|
3. Yarn调度器和调度算法
目前，Hadoop 作业调度器主要有三种：FIFO、容量（Capacity Scheduler）和公平（Fair Scheduler）。Apache Hadoop 3.3.1 默认的资源调度器是 Capacity Scheduler。
3.1. 容量调度器
a. 特点
1、多队列：每个队列可配置一定的资源量，每个队列采用FIFO调度策略。
2、容量保证：管理员可为每个队列设置资源最低保证和资源使用上限
3、灵活性：如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，而一旦该队列有新的应用
程序提交，则其他队列借调的资源会归还给该队列。
4、多租户：
支持多用户共享集群和多应用程序同时运行。
为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定。
b. 资源分配算法
队列资源分配：从root开始，使用深度优先算法，优先选择资源占用低的队列分配资源
作业资源分配：默认按照提交作业的优先级和提交时间顺序分配资源
容器资源分配： 按照容器的优先级分配资源，如果优先级相同，按照数据本地性原则：任务和数据在同一个节点、同一个机架、不在同一个机架也不在同一个节点。
c. 容器资源配置
相关介绍和配置见我的文章： Hadoop（3.3.1）: Capacity Scheduler：通过设置资源队列来满足不同业务之间的资源隔离、队列的弹性以及队列权限
3.2. 先进先出调度器（FIFO）
FIFO 调度器（First In First Out）：单队列，根据提交作业的先后顺序，先来先服务。
优点：简单易懂；
缺点：不支持多队列，生产环境很少使用；
3.3. 公平调度器（Fair Scheduler）
Fair Scheduler 是 Facebook 开发的多用户调度器。
公平调度器设计目标是：在时间尺度上，所有作业获得公平的资源。某一时刻一个作业应获资源和实际获取资源的差距叫“缺额”
a. 与容量调度器的异同
相同点
多队列，容量保证，灵活性，多租户
不同点
核心调度策略不同：容量调度器优先选择：资源利用率低的队列；公平调度器优先选择：对资源缺额比例比较大的
每个队列可以设置单独的资源分配方式：容量调度器：FIFO、DRF；公平调度器：FIFO、FAIR、DRF。
b. 资源分配方式
FIFO策略
公平调度器每个队列资源分配策略如果选择FIFO的话，此时公平调度器相当于上面讲过的容量调度器。
Fair策略
Fair 策略（默认）是一种基于最大最小公平算法实现的资源多路复用方式。
如果一个队列中有两个应用程序同时运行，则每个应用程序可得到1/2的资源；如果三个应用程序同时运行，则
每个应用程序可得到1/3的资源。
资源分配算法
1）队列资源分配
需求：集群总资源100，有三个队列，对资源的需求分别是：
queueA -> 20， queueB ->50， queueC -> 30
第一次计算：100 / 3 = 33.33
【queueA：分33.33 → 多13.33，queueB：分33.33 → 少16.67，queueC：分33.33 → 多3.33】
此时会进行第二次计算： （13.33 + 3.33）/ 1 = 16.66
【queueA：分20，queueB：分33.33 + 16.66 = 50，queueC：分30】
2）作业资源分配
不加权（关注点是Job的个数）：
需求：有一条队列总资源12个, 有4个job，对资源的需求分别是:
job1->1, job2->2 , job3->6, job4->5
第一次算: 12 / 4 = 3
job1: 分3 --> 多2个
job2: 分3 --> 多1个
job3: 分3 --> 差3个
job4: 分3 --> 差2个
第二次算: 3 / 2 = 1.5
job1: 分1
job2: 分2
job3: 分3 --> 差3个 --> 分1.5 --> 最终: 4.5
job4: 分3 --> 差2个 --> 分1.5 --> 最终: 4.5
第n次算: 一直算到没有空闲资源
加权（关注点是Job的权重）：
需求：有一条队列总资源16，有4个job
对资源的需求分别是:job1->4 job2->2 job3->10 job4->4
每个job的权重为:job1->5 job2->8 job3->1 job4->2
第一次算: 16 / (5+8+1+2) = 1
job1: 分5 --> 多1
job2: 分8 --> 多6
job3: 分1 --> 少9
job4: 分2 --> 少2
第二次算: 7 / (1+2) = 7/3
job1: 分4
job2: 分2
job3: 分1 --> 分7/3（2.33） -->少6.67
job4: 分2 --> 分14/3(4.66) -->多2.66
第三次算:2.66/1=2.66
job1: 分4
job2: 分2
job3: 分1 --> 分2.66/1 --> 分2.66
job4: 分4
第n次算: 一直算到没有空闲资源
算法基本的思路是：
第一次均分之后，将多出来的根据task需求再分，直到没有空闲资源。
有权重的根据权重比例去分。
DRF策略
DRF（Dominant Resource Fairness）考虑了如内存，CPU，网络带宽等资源，进行资源分配。
看一个需求
假设集群一共有100 CPU和10T 内存，而应用A需要（2 CPU, 300GB），应用B需要（6 CPU，100GB）。
上述需求意味着A是内存主导的, B是CPU主导的，针对这种情况，我们可以选择DRF策略对不同应用进行不同资源（CPU和内存）的一个不同比 例的限制。
