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和内存)的一个不同比 例的限制。