大数据-yarn

最新推荐文章于 2024-04-21 15:06:37 发布

海恋北斗星

最新推荐文章于 2024-04-21 15:06:37 发布

阅读量661

点赞数

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

本文链接：https://blog.csdn.net/zy12306/article/details/104695899

版权

大数据专栏收录该内容

70 篇文章 7 订阅

订阅专栏

大数据-yarn

容量调度器（Capacity Scheduler）

公平调度器（Fair Scheduler）

本章节主要介绍hadoop的第三个组件yarn,主要从yarn的架构，工作机制，任务提交流程以及任务调度器等几个方面来介绍。

每天进步一小点，加油鸭~

yarn的介绍

Apache Hadoop YARN(Yet Another Resource Negotiator)是Hadoop的子项目，为分离Hadoop2.0资源管理和计算组件而引入
YRAN具有足够的通用性，可以支持其它的分布式计算模式

yarn的架构

YARN是经典的主从（master/slave）架构

YARN服务由一个ResourceManager（RM）和多个NodeManager（NM）构成
ResourceManager为主节点（master）
NodeManager为从节点（slave）

ApplicationMaster可以在容器内运行任何类型的任务。例如，MapReduce, ApplicationMaster请求容器启动map或reduce任务，而Giraph ApplicationMaster请求容器运行Giraph任务。

ResourceManager

ResourceManager是YARN中的 master 角色
RM是一个全局的资源管理器，集群中只有一个，负责对外提供服务
- 负责整个系统的资源（CPU，内存等）管理和分配
- 处理客户端请求
- 启动并监控 ApplicationMaster
- 监控 NodeManager，并完成资源的分配与调度
RM主要由两个组件构成：
- 调度器（Scheduler）
- 应用程序管理器（Applications Manager，ASM）
调度器Scheduler
- 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
- 需要注意的是，该调度器是一个“纯调度器”
  - 它不从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
  - 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
应用程序管理器Applications Manager，ASM
- 应用程序管理器主要负责管理整个系统中所有应用程序
- 接收job的提交请求
- 为应用分配第一个 Container(容器) 来运行 ApplicationMaster
  - 包括应用程序提交
  - 与调度器协商资源以启动 ApplicationMaster
  - 监控 ApplicationMaster 运行状态并在失败时重新启动它等

NodeManager

NodeManager 是YARN中的 slave 角色
NodeManager ：
- 每个计算节点，运行一个NodeManager进程；通过心跳（每秒 yarn.resourcemanager.nodemanagers.heartbeat-interval-ms ）上报节点的资源状态(磁盘，内存，cpu等使用信息)
- 它负责接收 ResourceManager 的资源分配请求，分配具体的 Container 给应用。
负责监控并报告 Container 使用信息给 ResourceManager。
功能：
- NodeManager 监控本节点上的资源使用情况和各个 Container 的运行状态（cpu和内存等资源）
- 接收及处理来自 ResourceManager 的命令请求，分配 Container 给应用的某个任务；
- 定时地向RM汇报以确保整个集群平稳运行，RM 通过收集每个 NodeManager 的报告信息来追踪整个集群健康状态的，而 NodeManager 负责监控自身的健康状态；
- 处理来自 ApplicationMaster 的请求；
- 管理着所在节点每个 Container 的生命周期；
- 管理每个节点上的日志；
- 当一个节点启动时，它会向 ResourceManager 进行注册并告知 ResourceManager 自己有多少资源可用。
- 在运行期，通过 NodeManager 和 ResourceManager 协同工作，这些信息会不断被更新并保障整个集群发挥出最佳状态。
- NodeManager 只负责管理自身的 Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是 ApplicationMaster

Container

Container 是 YARN 中的资源抽象
- YARN以Container为单位分配资源
- 它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等
- 当 AM 向 RM 申请资源时，RM 为 AM 返回的资源便是用 Container 表示的
YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。
Container 和集群NodeManager节点的关系是：
- 一个NodeManager节点可运行多个 Container
- 但一个 Container 不会跨节点。
- 任何一个 job 或 application 必须运行在一个或多个 Container 中
- 在 Yarn 框架中，ResourceManager 只负责告诉 ApplicationMaster 哪些 Containers 可以用
- ApplicationMaster 还需要去找 NodeManager 请求分配具体的 Container。
需要注意的是
- Container 是一个动态资源划分单位，是根据应用程序的需求动态生成的
- 目前为止，YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离。
功能：
- 对task环境的抽象；
- 描述一系列信息；
- 任务运行资源的集合（cpu、内存、io等）；
- 任务运行环境

ApplicationMaster

功能：
- 获得数据分片；
- 为应用程序申请资源并进一步分配给内部任务（TASK）；
- 任务监控与容错；
- 负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用情况。
ApplicationMaster 与 ResourceManager 之间的通信
- 是整个 Yarn 应用从提交到运行的最核心部分，是 Yarn 对整个集群进行动态资源管理的根本步骤
- Yarn 的动态性，就是来源于多个Application 的 ApplicationMaster 动态地和 ResourceManager 进行沟通，不断地申请、释放、再申请、再释放资源的过程。

JobHistoryServer

作业历史服务

记录在yarn中调度的作业历史运行情况。

在yarn-site.xml中如下属性指定的节点上。

运行命令启动

 mr-jobhistory-daemon.sh start historyserver

启动成功后会出现JobHistoryServer进程，可以从19888端口进行查看日志详细信息。

Timeline Server

用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等)

timeline Server是对jobhistoryserver功能的有效补充，jobhistoryserver只能对mapreduce类型的作业信息进行记录，而timeline Server除了记录jobhistoryserver作业运行过程中信息之外，还记录更细粒度的信息，比如任务在哪个队列中运行，运行任务时设置的用户是哪个用户。

根据官网的解释jobhistoryserver只能记录mapreduce应用程序的记录，timelineserver功能更强大,但不是替代jobhistory两者是功能间的互补关系。

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分别领取任务并创建容器。
RM向两个接收到任务的NodeManager发送程序启动脚本，这两个NodeManager分别启动MapTask，MapTask对数据分区排序。
MrAppMaster等待所有MapTask运行完毕后，向RM申请容器，运行ReduceTask。
ReduceTask向MapTask获取相应分区的数据。
程序运行完毕后，MR会向RM申请注销自己。

yarn的任务调度器

资源调度器的职能

资源调度器是YARN最核心的组件之一，是一个插拔式的服务组件，负责整个集群资源的管理和分配。YARN提供了三种可用的资源调度器：FIFO、Capacity Scheduler、Fair Scheduler。

先进先出调度器（FIFO）

YRAN默认情况下使用的是该调度器，即所有的应用程序都是按照提交的顺序来执行的，这些应用程序都放在一个队列中，只有在前面的一个任务执行完成之后，才可以执行后面的任务，依次执行。

缺点：如果有某个任务执行时间较长的话，后面的任务都要处于等待状态，这样的话会造成资源的使用率不高；如果是多人共享集群资源的话，缺点更是明显。

容量调度器（Capacity Scheduler）

针对多用户的调度，容量调度器采用的方法稍有不同。集群由很多的队列组成(类似于任务池)，这些队列可能是层次结构的(因此，一个队列可能是另一个队列的子队列)，每个队列被分配有一定的容量。这一点于公平调度器类似，只不过在每个队列的内部，作业根据FIFO的方式(考虑优先级)调度。本质上，容量调度器允许用户或组织(使用队列自行定义)为每个用户或组织模拟出一个使用FIFO调度策略的独立MapReduce集群。相比之下，公平调度器(实际上也支持作业池内的FIFO调度，使其类似于容量调度器)强制池内公平共享，使运行的作业共享池内的资源。

总结：容量调度器具有以下几个特点

集群按照队列为单位划分资源，这些队列可能是层次结构的。
可以控制每个队列的最低保障资源和最高使用限制，最高使用限制是为了防止该队列占用过多的空闲资源导致其他的队列资源紧张。
可以针对用户设置每个用户的资源最高使用限制，防止该用户滥用资源。
在每个队列内部的作业调度是按照FIFO的方式调度的。
如果某个队列的资源使用紧张，但是另一个队列的资源比较空闲，此时可以将空闲的资源暂时借用，但是一旦被借用资源的队列有新的任务提交之后，此时被借用出去的资源将会被释放还回给原队列。
每一个队列都有严格的访问控制，只有那些被授权了的用户才可以查看任务的运行状态。

公平调度器（Fair Scheduler）

所谓的公平调度器指的是，旨在让每个用户公平的共享集群的能力。如果是只有一个作业在运行的话，就会得到集群中所有的资源。随着提交的作业越来越多，限制的任务槽会以“让每个用户公平共享集群”这种方式进行分配。某个用户的好事短的作业将在合理的时间内完成，即便另一个用户的长时间作业正在运行而且还在运行过程中。

作业都是放在作业池中的，默认情况下，每个用户都有自己的作业池。提交作业数较多的用户，不会因此而获得更多的集群资源。可以用map和reduce的任务槽数来定制作业池的最小容量，也可以设置每个池的权重。

公平调度器支持抢占机制。所以，如果一个池在特定的一段时间内未能公平的共享资源，就会终止运行池中得到过多的资源的任务，把空出来的任务槽让给运行资源不足的作业池。

主要特点：

也是将集群的资源以队列为单位进行划分，称为队列池。
每个用户都有自己的队列池，如果该队列池中只有一个任务的话，则该任务会使用该池中的所有资源。
每个用户提交作业都是提交到自己的队列池中，所以，提交作业数较多的用户，并不会因此而获得更多的集群资源。
支持抢占机制。也就是说如果一个吃在特定的时间内未能公平的共享资源，就会终止池中占用过多资源的任务，将空出来的任务槽让给运行资源不足的作业池。
负载均衡：提供一个基于任务数目的负载均衡机制。该机制尽可能的将任务均匀的分配到集群的所有的节点上。

此博文仅供学习参考，如有错误欢迎指正。

上一篇《大数据-MapReduce（二）》

下一篇《大数据-yarn（二）》

希望对大数据相关技术感兴趣的友友们关注一下，大家可以一起交流学习哦~

海恋北斗星

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
大数据-yarn

大数据-yarn（一）yarn（资源调度管理平台）的介绍Apache Hadoop YARN(Yet Another Resource Negotiator)是Hadoop的子项目，为分离Hadoop2.0资源管理和计算组件而引入 YRAN具有足够的通用性，可以支持其它的分布式计算模式yarn的架构YAR...
复制链接

扫一扫