yarn 简单介绍

 Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一
种新的 Hadoop 资源管理器,它是一个通用资源管理系统和调度平台,可为上层应用提供统
一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨
大好处。

    可以把 yarn 理解为相当于一个分布式的操作系统平台,而 mapreduce 等运算程序则相

  yarn 并不清楚用户提交的程序的运行机制
  yarn 只提供运算资源的调度(用户程序向 yarn 申请资源,yarn 就负责分配资源)
  yarn 中的主管角色叫 ResourceManager
  yarn 中具体提供运算资源的角色叫 NodeManager
  yarn与运行的用户程序完全解耦,意味着yarn上可以运行各种类型的分布式运算程序,
比如 mapreduce、storm,spark,tez ……
  spark、storm 等运算框架都可以整合在 yarn 上运行,只要他们各自的框架中有符合
yarn 规范的资源请求机制即可
  yarn 成为一个通用的资源调度平台.企业中以前存在的各种运算集群都可以整合在一

yarn 的基础架构 

YARN 是一个资源管理、任务调度的框架,主要包含三大模块:ResourceManager(RM)、
NodeManager(NM)、ApplicationMaster(AM)。
ResourceManager 负责所有资源的监控、分配和管理;
ApplicationMaster 负责每一个具体应用程序的调度和协调;
NodeManager 负责每一个节点的维护。
对于所有的 applications,RM 拥有绝对的控制权和对资源的分配权。而每个 AM 则会和
RM 协商资源,同时和 NodeManager 通信来执行和监控 task。
net/qq_33624952/article/details/79341034

三、 yarn的三大组件介绍 

1.ResourceManager

1   ResourceManager 负责整个集群的资源管理和分配,是一个全局的资源管理系统。
2   NodeManager 以心跳的方式向 ResourceManager 汇报资源使用情况(目前主要是 CPU 和
3 内存的使用情况)。RM 只接受 NM 的资源回报信息,对于具体的资源处理则交给 NM 自己
4 处理。
5   YARN Scheduler 根据 application 的请求为其分配资源,不负责 application job 的
6 监控、追踪、运行状态反馈、启动等工作。

2. NodeManager

  NodeManager 是每个节点上的资源和任务管理器,它是管理这台机器的代理,负责该节
点程序的运行,以及该节点资源的管理和监控。YARN 集群每个节点都运行一个
NodeManager。
  NodeManager 定时向 ResourceManager 汇报本节点资源(CPU、内存)的使用情况和
Container 的运行状态。当 ResourceManager 宕机时 NodeManager 自动连接 RM 备用节
点。
  NodeManager 接收并处理来自 ApplicationMaster 的 Container 启动、停止等各种请
求。

3.ApplicationMaster

 1   用 户 提 交 的 每 个 应 用 程 序 均 包 含 一 个 ApplicationMaster , 它 可 以 运 行 在
 2 ResourceManager 以外的机器上。
 3   负责与 RM 调度器协商以获取资源(用 Container 表示)。
 4   将得到的任务进一步分配给内部的任务(资源的二次分配)。
 5   与 NM 通信以启动/停止任务。
 6   监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。
 7   当前 YARN 自带了两个 ApplicationMaster 实现,一个是用于演示 AM 编写方法的实例
 8 
 9     程序 DistributedShell,它可以申请一定数目的 Container 以并行运行一个 Shell 命
10 令或者 Shell 脚本;另一个是运行 MapReduce 应用程序的 AM—MRAppMaster。
11 注:RM 只负责监控 AM,并在 AM 运行失败时候启动它。RM 不负责 AM 内部任务的容错,
12 任务的容错由 AM 完成。

四、Yarn运行流程

 

 

 

步骤1 用户向YARN中提交应用程序,其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

步骤2 ResourceManager为该应用程序分配第一个Container,并与对应的Node-Manager通信,要求它在这个Container中启动应用程序的ApplicationMaster。

步骤3 ApplicationMaster首先向ResourceManager注册,这样用户可以直接通过ResourceManager查看应用程序的运行状态,然后它将为各个任务申请资源,并监控它的运行状态,直到运行结束,即重复步骤4~7。

步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

步骤5 一旦ApplicationMaster申请到资源后,便与对应的NodeManager通信,要求它启动任务。

步骤6 NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。

步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度,以让ApplicationMaster随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。

  在应用程序运行过程中,用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

步骤8 应用程序运行完成后,ApplicationMaster向ResourceManager注销并关闭自己。

五、Yarn调度器Scheduler

   理想情况下,我们应用对 Yarn 资源的请求应该立刻得到满足,但现实情况资源往往是
有限的,特别是在一个很繁忙的集群,一个应用资源的请求经常需要等待一段时间才能的到
相应的资源。在 n Yarn  中,负责给应用分配资源的就是  Scheduler。其实调度本身就是一个
难题,很难找到一个完美的策略可以解决所有的应用场景。为此,Yarn 提供了多种调度器
和可配置的策略供我们选择。

    在 Yarn 中有三种调度器可以选择:FIFO Scheduler ,Capacity Scheduler,Fair
Scheduler。

三种调度器:

1.FIFO Scheduler

FIFO Scheduler 把应用按提交的顺序排成一个队列,这是一个 先进先出队列,在进行
资源分配的时候,先给队列中最头上的应用进行分配资源,待最头上的应用需求满足后再给
下一个分配,以此类推。

 

 

 

 FIFO Scheduler 是最简单也是最容易理解的调度器,也不需要任何配置,但它并不适
用于共享集群。大的应用可能会占用所有集群资源,这就导致其它应用被阻塞。在共享集群
中,更适合采用 Capacity Scheduler 或 Fair Scheduler,这两个调度器都允许大任务和小
任务在提交的同时获得一定的系统资源。
.net/qq_33624952/article/details/79341034

2.Capacity Scheduler

  Capacity 调度器允许多个组织共享整个集群,每个组织可以获得集群的一部分计算能
力。通过为每个组织分配专门的队列,然后再为每个队列分配一定的集群资源,这样整个集
群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外,队列内部又可以垂直
划分,这样一个组织内部的多个成员就可以共享这个队列资源了,在一个队列内部,资源的
调度是采用的是先进先出(FIFO)策略。

 

 

 3.Fair Scheduler

    在 Fair 调度器中,我们不需要预先占用一定的系统资源,Fair 调度器会为所有运行的
job 动态的调整系统资源。如下图所示,当第一个大 job 提交时,只有这一个 job 在运行,
此时它获得了所有集群资源;当第二个小任务提交后,Fair 调度器会分配一半资源给这个
小任务,让这两个任务公平的共享集群资源。

    需要注意的是,在下图 Fair 调度器中,从第二个任务提交到获得资源会有一定的延
迟,因为它需要等待第一个任务释放占用的 Container。小任务执行完成之后也会释放自
己占用的资源,大任务又获得了全部的系统资源。最终效果就是 Fair 调度器即得到了高的
资源利用率又能保证小任务及时完成。

 

 

调度器的使用是通过 yarn-site.xml 配置文件中的
yarn.resourcemanager.scheduler.class 参数进行配置的, 默认采用 Capacity
Scheduler 调度器。

 假设我们有如下层次的队列:

 

 

下面是一个简单的 Capacity 调度器的配置文件,文件名为 capacity-scheduler.xml。
在这个配置中,在 root 队列下面定义了两个子队列 prod 和 dev,分别占 40%和 60%的容量。
需要注意,一个队列的配置是通过属性 yarn.sheduler.capacity.<queue-path>.<sub-
property>指定的,<queue-path>代表的是队列的继承树,如 root.prod 队列,<sub-property>
一般指 capacity 和 maximum-capacity。
t/qq_33624952/article/details/79341034
<configuration>
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>prod,dev</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.queues</name>
<value>mapreduce,spark</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.prod.capacity</name>
<value>40</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.capacity</name>
<value>60</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
<value>75</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.mapreduce.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.spark.capacity</name>
<value>50</value>
</property>
</configuration>
   dev 队列又被分成了 mapreduce 和 spark 两个相同容量的子队列。dev
的 maximum-capacity 属性被设置成了 75%,所以即使 prod 队列完全空闲 dev 也不会占用全
部集群资源,也就是说,prod 队列仍有 25%的可用资源用来应急。我们注意到,mapreduce
和 spark 两个队列没有设置 maximum-capacity 属性,也就是说 mapreduce 或 spark 队列中
的 job 可能会用到整个 dev 队列的所有资源(最多为集群的 75%)。而类似的,prod 由于没
有设置 maximum-capacity 属性,它有可能会占用集群全部资源。

    关于队列的设置,这取决于我们具体的应用。比如,在 MapReduce 中,我们可以通过
mapreduce.job.queuename 属性指定要用的队列。如果队列不存在,我们在提交任务时就
会收到错误。如果我们没有定义任何队列,所有的应用将会放在一个 default 队列中。

    注意:对于 Capacity 调度器,我们的队列名必须是队列树中的最后一部分,如果我们
使用队列树则不会被识别。比如,在上面配置中,我们使用 prod 和 mapreduce 作为队列名
是可以的,但是如果我们用 root.dev.mapreduce 或者 dev. mapreduce 是无效的。

 

posted @ 2021-07-13 07:42  青紫天涯  阅读(663)  评论(1编辑  收藏  举报