Yarn——基础概念
1、Yarn 资源调度器
Yarn
是一个资源调度平台,负责为运算程序提供服务器运算资源,相当于一个分布式的操作系统平台,而 MapReduce
等运算程序则相当于运行于操作系统之上的应用程序。
2、Yarn的基础框架
YARN
主要由 ResourceManager
、NodeManager
、ApplicationMaster
和 Container
等组件构成。
-
ResourceManager(RM)
主要作用如下- 处理客户端请求
- 监控
NodeManager
- 启动或监控
ApplicationMaster
- 资源的分配与调度
-
NodeManager(NM)
主要作用如下- 管理单个节点上的资源
- 处理来自
ResourceManager
的命令 - 处理来自
ApplicationMaster
的命令
-
ApplicationMaster(AM)
作用如下- 为应用程序申请资源并分配给内部的任务
- 任务的监控与容错
-
Container
Container
是YARN
中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU
、磁盘、网络等。
3、Yarn的工作机制
MR
程序提交到客户端所在的节点。YarnRunner
向ResourceManager
申请一个Application
。RM
将该应用程序的资源路径返回给YarnRunner
。- 该程序将运行所需资源提交到
HDFS
上。 - 程序资源提交完毕后,申请运行
mrAppMaster
。 RM
将用户的请求初始化成一个Task
。- 其中一个
NodeManager
领取到Task
任务。 - 该
NodeManager
创建容器Container
,并产生MRAppmaster
。 Container
从HDFS
上拷贝资源到本地。MRAppmaster
向RM
申请运行MapTask
资源。RM
将运行MapTask
任务分配给另外两个NodeManager
,另两个NodeManager
分别领取任务并创建容器。MR
向两个接收到任务的NodeManager
发送程序启动脚本,这两个NodeManager
分别启动MapTask
,MapTask
对数据分区排序。MrAppMaster
等待所有MapTask
运行完毕后,向RM
申请容器,运行ReduceTask
。ReduceTask
向MapTask
获取相应分区的数据。- 程序运行完毕后,
MR
会向RM
申请注销自己。
4、作业全提交过程
4.1、HDFS、YARN、MapReduce三者关系
4.2、作业提交过程之YARN
4.3、作业提交过程之HDFS & MapReduce
-
作业提交
- 第 1 步:
Client
调用job.waitForCompletion
方法,向整个集群提交MapReduce
作业。 - 第 2 步:
Client
向RM
申请一个作业id
。 - 第 3 步:
RM
给Client
返回该job
资源的提交路径和作业id
。 - 第 4 步:
Client
提交jar
包、切片信息和配置文件到指定的资源提交路径。 - 第 5 步:
Client
提交完资源后,向RM
申请运行MrAppMaster
。
- 第 1 步:
-
作业初始化
- 第 6 步:当
RM
收到Client
的请求后,将该job
添加到容量调度器中。 - 第 7 步:某一个空闲的
NM
领取到该Job
。 - 第 8 步:该
NM
创建Container
,并产生MRAppmaster
。 - 第 9 步:下载
Client
提交的资源到本地。
- 第 6 步:当
-
任务分配
- 第 10 步:
MrAppMaster
向RM
申请运行多个MapTask
任务资源。 - 第 11 步:
RM
将运行MapTask
任务分配给另外两个NodeManager
,另两个NodeManager
分别领取任务并创建容器。
- 第 10 步:
-
任务运行
- 第 12 步:
MR
向两个接收到任务的NodeManager
发送程序启动脚本,这两个NodeManager
分别启动MapTask
,MapTask
对数据分区排序。 - 第13步:
MrAppMaster
等待所有MapTask
运行完毕后,向RM
申请容器,运行ReduceTask
。 - 第 14 步:
ReduceTask
向MapTask
获取相应分区的数据。 - 第 15 步:程序运行完毕后,
MR
会向RM
申请注销自己。
- 第 12 步:
-
进度和状态更新
YARN
中的任务将其进度和状态(包括counter
)返回给应用管理器, 客户端每秒(通过
mapreduce.client.progressmonitor.pollinterval
设置)向应用管理器请求进度更新, 展示给用户。 -
作业完成
除了向应用管理器请求作业进度外, 客户端每 5 秒都会通过调用
waitForCompletion()
来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval
来设置。作业完成之后, 应用管理器和Container
会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。
5、Yarn 调度器和调度算法
Hadoop 作业调度器主要有三种:FIFO
、容量(Capacity Scheduler
)和公平(Fair Scheduler
)。Apache Hadoop3.1.3
默认的资源调度器是 Capacity Scheduler
。
CDH 框架默认调度器是 Fair Scheduler。
<!-- yarn-default.xml-->
<property>
<description>The class to use as the resource scheduler.</description>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.
scheduler.capacity.CapacityScheduler</value>
</property>
5.1、先进先出调度器(FIFO)
FIFO
调度器(First In First Out
):单队列,根据提交作业的先后顺序,先来先服务。
-
优点: 简单易懂;
-
缺点: 不支持多队列,生产环境很少使用。
5.2、容量调度器(Capacity Scheduler )
Capacity Scheduler
是Yahoo
开发的多用户调度器。
- 多队列: 每个队列可配置一定的资源量,每个队列采用
FIFO
调度策略; - 容量保证: 管理员可为每个队列设置资源最低保证和资源使用上限;
- 灵活性: 如果一个队列中的资源有剩余,可以暂时共享给那些需要资源的队列,而一旦该队列有新的应用程序提交,则其他队列借调的资源会归还给该队列;
- 多租户: 支持多用户共享集群和多应用程序同时运行。为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源量进行限定。
5.3、容量调度器资源分配算法
-
队列资源分配
- 从
root
开始,使用深度优先算法,优先 - 选择资源占用率最低的队列分配资源。
- 从
-
作业资源分配
- 默认按照提交作业的优先级和提交时间顺序分配资源。
-
容器资源分配
按照容器的优先级分配资源;
如果优先级相同,按照数据本地性原则:-
任务和数据在同一节点
-
任务和数据在同一机架
-
任务和数据不在同一节点也不在同一机架
-
5.4、公平调度器(Fair Scheduler)
- 与容量调度器相同点
- 多队列: 支持多队列多作业
- 容量保证: 管理员可为每个队列设置资源最低保证和资源使用上线
- 灵活性: 如果一个队列中的资源有剩余,可以暂时共享给那些需要资源的队列,而一旦该队列有新的应用程序提交,则其他队列借调的资源会归还给该队列。
- 多租户: 支持多用户共享集群和多应用程序同时运行;为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源量进行限定。
- 与容量调度器不同点
- 核心调度策略不同
容量调度器: 优先选择资源利用率低的队列
公平调度器: 优先选择对资源的缺额比例大的 - 每个队列可以单独设置资源分配方式
容量调度器:FIFO
、DRF
公平调度器:FIFO
、FAIR
、DRF
- 核心调度策略不同
5.4.1、公平调度器——缺额
- 公平调度器设计目标是:在时间尺度上,所有作业获得公平的资源。某一时刻一个作业应获资源和实际获取资源的差距叫“缺额”;
- 调度器会优先为缺额大的作业分配资源。
5.4.2、公平调度器队列资源分配方式
- FIFO 策略: 公平调度器每个队列资源分配策略如果选择
FIFO
的话,此时公平调度器相当于上面讲过的容量调度器。 - Fair 策略:
Fair
策略(默认)是一种基于最大最小公平算法实现的资源多路复用方式,默认情况下,每个队列内部采用该方式分配资源。这意味着,如果一个队列中有两个应用程序同时运行,则每个应用程序可得到1/2的资源;如果三个应用程序同时运行,则每个应用程序可得到1/3的资源。
5.4.3、公平调度器资源分配算法
队列资源分配
需求: 集群总资源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
5.4.4、公平调度器队列资源分配方式
作业资源分配
**(a)不加权 (是关注点是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次算: 一直算到没有空闲资源
**(b)加权(关注点是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次算: 一直算到没有空闲资源
5.4.5、DRF策略
DRF(Dominant Resource Fairness)
,我们之前说的资源,都是单一标准,例如只考虑内存(也是Yarn默认的情况)。但是很多时候我们资源有很多种,例如内存,CPU
,网络带宽等,这样我们很难衡量两个应用应该分配的资源比例。
问: 那么在YARN
中,我们用DRF
来决定如何调度:
答: 假设集群一共有100 CPU
和10T 内存,而应用A需要(2 CPU
, 300GB),应用B需要(6 CPU
,100GB)。则两个应用分别需要A(2%CPU
, 3%内存)和B(6%CPU
, 1%内存)的资源,这就意味着A是内存主导的, B是CPU
主导的,针对这种情况,我们可以选择DRF策略对不同应用进行不同资源(CPU
和内存)的一个不同比例的限制。