yarn

最新推荐文章于 2020-04-11 19:56:47 发布

mztt3010

最新推荐文章于 2020-04-11 19:56:47 发布

阅读量161

点赞数

分类专栏：大数据文章标签： yarn

本文链接：https://blog.csdn.net/qq_42898087/article/details/85244544

版权

大数据专栏收录该内容

7 篇文章 0 订阅

订阅专栏

YARN：

YARN的基本思想是将资源管理和作业调度/监视的功能分解为单独的守护进程。 ResourceManager
负责集群中所有资源的统一管理和分配，它将各个资源部分（计算、内存、带宽等）精心安排给基础 NodeManager（YARN
的每节点代理）。rourceManager 还与 ApplicationMaster 一起分配资源，与 NodeManager
一起启动和监视它们的基础应用程序。

ApplicationMaster 每一个job有一个ApplicationMaster 。
功能：

与RM调度器协商以获取资源（用Container表示）；
将得到的任务进一步分配给内部的任务；与NM通信以启动/停止任务；
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
当前YARN自带了两个AM实现，一个是用于演示AM编写方法的实例程序distributedshell，它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本；
另一个是运行MapReduce应用程序的AM—MRAppMaste。此外，一些其他的计算框架对应的AM正在开发中，比如Open MPI、Spark等。

NodeManager

NM是每个节点上的资源和任务管理器，一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的Container启动/停止等各种请求。

Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。

一个应用程序所需的Container分为两大类，如下：
(1) 运行ApplicationMaster的Container：这是由ResourceManager（向内部的资源调度器）申请和启动的，用户提交应用程序时，可指定唯一的ApplicationMaster所需的资源；
(2) 运行各类任务的Container：这是由ApplicationMaster向ResourceManager申请的，并由ApplicationMaster与NodeManager通信以启动之。
以上两类Container可能在任意节点上，它们的位置通常而言是随机的，即ApplicationMaster可能与它管理的任务运行在一个节点上。

工作过程

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 申请容器，运行 reduce task。 reduce task 向 maptask 获取相应分区的数据。
程序运行完毕后，MR 会向 RM 申请注销自己。

YARN平台的资源管理方案

在YARN中，用户以队列的形式组织，每个用户可属于一个或多个队列，且只能向这些队列中提交application。每个队列被划分了一定比例的资源。
YARN的资源分配过程是异步的，也就是说，资源调度器将资源分配给一个application后，不会立刻push给对应的ApplicaitonMaster，而是暂时放到一个缓冲区中，等待ApplicationMaster通过周期性的RPC函数主动来取，也就是说，采用了pull-based模型，而不是push-based模型，这个与MRv1是一致的。
相比于MRv1中的资源调度器，尽管YANR的调度器也是插拔式的，但由于YARN采用了事件驱动的模型，因此编写起来更加复杂，难度也远远大于MRv1。
同MRv1一样，YARN也自带了三种常用的调度器，分别是FIFO，Capacity Scheduler和Fair
Scheduler，其中，第一个是默认的调度器，它属于批处理调度器，而后两个属于多租户调度器，它采用树形多队列的形式组织资源，更适合公司应用场景。需要注意的是，这三种调度器采用的算法与MRv1中的完全一致，只不过是根据YARN中资源调度器的对外接口重新实现了一遍。