成都网页设计与网站建设,成都企业品牌网站建设,做网站一般图片的比例,超链接友情外链查询目录
一、YARN简介
二、YARN的由来
三、YARN的基本设计思想
四、YARN 的基本架构
4.1 基本架构图 4.2 基本组件介绍
4.2.1 ResourceManager 4.2.1.1 任务调度器(Resource Scheduler)
4.2.1.2 应用程序管理器#xff08;Applications Manager#xff09;
4.2.1.3 其他… 目录
一、YARN简介
二、YARN的由来
三、YARN的基本设计思想
四、YARN 的基本架构
4.1 基本架构图 4.2 基本组件介绍
4.2.1 ResourceManager 4.2.1.1 任务调度器(Resource Scheduler)
4.2.1.2 应用程序管理器Applications Manager
4.2.1.3 其他
4.2.2 NodeManagerNM
4.2.2.1 ApplicationMasterAM
4.2.2.2 Container
五、YARN的工作原理 5.1 工作流程图 5.2 工作流程步骤描述 5.2.1 步骤1 5.2.2 步骤2 5.2.3 步骤3
5.2.4 步骤4
5.2.5 步骤5
5.2.6 步骤6 5.2.7 步骤7
5.2.8 步骤8 六、YARN通讯协议
6.1 RPC通信图 6.2 组件通讯协议描述 6.2.1 ApplicationClientProtocol 6.2.2 ResourceManagerAdministrationProtocol 6.2.3 ApplicationMasterProtocol 6.2.4 ContainerManagementProtocol 6.2.5 ResourceTracker 七、资源调度器分类 7.1 FIFO Scheduler
7.2 Capacity Scheduler
7.3 Fair Scheduler 一、YARN简介
Apache Hadoop YARN Yet Another Resource Negotiator另一种资源协调者是一种新的 Hadoop 资源管理器它是一个通用资源管理系统可为上层应用提供统一的资源管理和调度它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
二、YARN的由来
在YARN出来之前其实在Hadoop体系里面负责资源管理和作业控制的是MRv1Hadoop 1.0体系中的JobTracker在承担但是MRv1体系其实有其缺点如下
1扩展性差
在MRv1中JobTracker是个重量级组件集中了资源管理分配、作业控制两大核心功能随着集群规模的增大JobTracker处理各种RPC请求负载过重这也是系统的最大瓶颈严重制约了Hadoop集群的扩展性。
2可靠性差。
MRv1 采用了 master/slave 结构其中master 存在单点故障问题一旦它出现故障将导致整个集群不可用。
3资源利用率低。
MRv1 采用了基于槽位的资源分配模型槽位是一种粗粒度的资源 划分单位通常一个任务不会用完槽位对应的资源且其他任务也无法使用这些空 闲资源。此外Hadoop 将槽位分为 Map Slot 和 Reduce Slot 两种且不允许它们之 间共享常常会导致一种槽位资源紧张而另外一种闲置(比如一个作业刚刚提交时 只会运行 Map Task此时 Reduce Slot 闲置)。
4无法支持多种计算框架。
随着互联网高速发展MapReduce 这种基于磁盘的离线计 算框架已经不能满足应用要求从而出现了一些新的计算框架包括内存计算框架、 流式计算框架和迭代式计算框架等而 MRv1 不能支持多种计算框架并存。
为了克服以上几个缺点Apache 开始尝试对 Hadoop 进行升级改造进而诞生了更加 先进的下一代 MapReduce 计算框架 MRv2。正是由于 MRv2 将资源管理功能抽象成了一个 独立的通用系统 YARN直接导致下一代 MapReduce 的核心从单一的计算框架 MapReduce转移为通用的资源管理系统 YARN。
YARN将 JobTracker 中的资源管理和作业控制功能分 开 分 别 由 组件ResourceManager 和 ApplicationMaster 实 现 其 中ResourceManager 负责所有应用程序的资源分配而 ApplicationMaster 仅负责管理一个应用程序基于 YARN用户可以运行各种类型的应用程序(不再像 1.0 那样仅局限于 MapReduce 一类应用)从离线计算的 MapReduce 到在线计算 (流式处理)的 Storm 等。
三、YARN的基本设计思想
在 Hadoop 1.0 中JobTracker 由资源管理(由 TaskScheduler 模块实现)和作业控制(由 JobTracker 中多个模块共同实现)两部分组成。当前 Hadoop MapReduce 之所以在可扩展性、资源利用率和多框架支持等方面存在不足正是由于 Hadoop 对 JobTracker 赋予的功能过多而造成负载过重。此外从设计角度上看Hadoop 未能够将资源管理相关的功能与应用程序相关的功能分开造成 Hadoop 难以支持多种计算框架。
下一代 MapReduce 框架的基本设计思想是将 JobTracker 的两个主要功能即资源管理和作业控制(包括作业监控、容错等)分拆成两独立的进程。资源管理进程与具体应用程序无关它负责整个集群的资源(内存、CPU、磁盘等)管理而作业控制进程则是直接与应用程序相关的模块且每个作业控制进程只负责管理一个作业。这样 通过将原有 JobTracker 中与应用程序相关和无关的模块分开不仅减轻了 JobTracker 负载 也使得 Hadoop 支持更多的计算框架。
四、YARN 的基本架构
4.1 基本架构图 Yarn在整体上看还是采用了和Hadoop1.x一样的Master/Slave结构横向扩展混杂Slave/Slave结构在整个Yarn资源管理系统当中ResourceManager作为Master各个节点的NodeManager作为Slave。各个节点上NodeManager的资源由ResourceManager统计进行管理和调度。当应用程序提交后会有一个单独的ApplicationMaster来对该应用程序进行跟踪和管理同时该ApplicationMaster还会为该应用程序向ResourceManager申请资源并要求NodeManager启动该应用程序占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上因此它们之间不会相互影响。 4.2 基本组件介绍
4.2.1 ResourceManager
ResourceManager是Yarn的核心组件主要由任务调度器Resource Scheduler和应用程序管理器Applications Manager组成。其主要功能是负责系统资源的管理和分配。 4.2.1.1 任务调度器(Resource Scheduler)
调度器根据容量、队列等限制条件(如每个队列分配一定的资源最多执行一定数量的作业等)将系统中的资源分配给各个正在运行的应用程序。需要注意的是该调度器是 一个“纯调度器”它不再从事任何与具体应用程序相关的工作比如不负责监控或者跟踪 应用的执行状态等也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务 这些均交由应用程序相关的 ApplicationMaster 完成。调度器仅根据各个应用程序的资源需 求进行资源分配而资源分配单位用一个抽象概念“资源容器”(Resource Container简 称 Container)表示Container 是一个动态资源分配单位它将内存、CPU、磁盘、网络等 资源封装在一起从而限定每个任务使用的资源量。此外该调度器是一个可插拔的组件 用户可根据自己的需要设计新的调度器YARN 提供了多种直接可用的调度器比如 Fair Scheduler 和 Capacity Scheduler 等。
4.2.1.2 应用程序管理器Applications Manager
应用程序管理器负责管理整个系统中所有应用程序包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。
4.2.1.3 其他
ResourceManager中还包含了其他组件如ResourceTrackerService用来直接处理心跳NMLivelinessMonitor用来监控NodeManagerNodesListManager 提供NodeManager的黑白名单等等
4.2.2 NodeManagerNM
NM是每个子节点上的资源和任务管理器一方面它会定向通过心跳信息向RM汇报本节点上的资源使用情况和各个Container的运行情况另一方面它会接收并且处理来自AM的Container启动和停止的各种请求。它的能有点像Hadoop1.x中的TaskTracker。
4.2.2.1 ApplicationMasterAM
每当用户提交了一个应用程序就会为这个应用程序产生一个对应的ApplicationMaster并且这个这个单独进程是在其中一个子节点上运行的。它的主要功能为应用向ResourceManager申请资源、在job对Task实行调度、与NodeManager通信以启动或者停止任务、监控所有任务的运行情况并且在任务失败的情下重新为任务申请资源并且重启任务、负责推测任务的执行、当ApplicationMaster向ResourceManager注册后ApplicationMaster可以提供客户端查询作业进度信息等。
4.2.2.2 Container
Container是Yarn中对系统资源的抽象同时它也是系统资源分配的基本单位它封装节点上多维度资源其中包括CPU、内存、磁盘、网络等。Yarn会为每个任务分配一个Container并且该任务只能够使用该Container中所描述的资源。值得关注的的是Yarn中的Container和MRv1中的Slot是完全不同的Container是一个动态的资源划分单位它是根据实际提交的应用程序所需求的资源自动生成的换句话说Container其里边所描述的CPU、内存等资源是根据实际应用程序需求而变的。而Slot是一个静态的资源抽象单位每一个同类型的Slot所描述的资源信息都是一样的。
五、YARN的工作原理 5.1 工作流程图 5.2 工作流程步骤描述 5.2.1 步骤1
用户向Yarn提交应用程序其中包括用户程序、相关文件、启动ApplicationMaster命令、ApplicationMaster程序等。 5.2.2 步骤2
ResourceManager为该应用程序分配第一个Container并且与Container所在的NodeManager通信并且要求该NodeManager在这个Container中启动应用程序对应的ApplicationMaster。 5.2.3 步骤3
ApplicationMaster首先会向ResourceManager注册这样用户才可以直接通过ResourceManager查看到应用程序的运行状态然后它将为该应用程序的各个任务申请资源并监控它们的运行状态直到运行结束即重复后面4~7步骤。
5.2.4 步骤4
ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
5.2.5 步骤5
一旦ApplicationMaster申请到资源后便会与申请到的Container所对应的NodeManager进行通信并且要求它在该Container中启动任务。
5.2.6 步骤6
任务启动。NodeManager为要启动的任务配置好运行环境包括环境变量、JAR包、二进制程序等并且将启动命令写在一个脚本里通过该脚本运行任务。 5.2.7 步骤7
各个任务通过RPC协议向其对应的ApplicationMaster汇报自己的运行状态和进度以让ApplicationMaster随时掌握各个任务的运行状态从而可以再任务运行失败时重启任务。
5.2.8 步骤8
应用程序运行完毕后其对应的ApplicationMaster会向ResourceManager通信要求注销和关闭自己。
这个需要注意的是在整个工作流程当中ResourceManager和NodeManager都是通过心跳保持联系的NodeManager会通过心跳信息向ResourceManager汇报自己所在节点的资源使用情况。 六、YARN通讯协议
RPC 协议是连接各个组件的“大动脉”了解不同组件之间的 RPC 协议有助于我们更深入地学习 YARN 框架。在 YARN 中任何两个需相互通信的组件之间仅有一个 RPC 协 议而对于任何一个 RPC 协议通信双方有一端是 Client另一端为 Server且 Client 总 是主动连接 Server 的因此YARN 实际上采用的是拉式(pull-based)通信模型。
6.1 RPC通信图 箭头指向的组件是 RPC Server而箭头尾部的组件是 RPC Client 6.2 组件通讯协议描述 6.2.1 ApplicationClientProtocol
JobClient(作业提交客户端)与 RM 之间的协议 JobClient 通过该 RPC 协议提交应用程序、查询应用程序状态等。 6.2.2 ResourceManagerAdministrationProtocol
Admin(管理员)与 RM 之间的通信协议Admin 通过该 RPC 协议更新系统配置文件比如节点黑白名单、用户队列权限等。 6.2.3 ApplicationMasterProtocol
AM 与 RM 之间的协议AM 通过该 RPC 协议向 RM 注册和撤销自己并为各个任务申请资源。 6.2.4 ContainerManagementProtocol
AM 与 NM 之间的协议AM 通过该 RPC 要求 NM 启动或者停止 Container获取各个 Container 的使用状态等信息。 6.2.5 ResourceTracker
NM 与 RM 之间的协议NM 通过该 RPC 协议向 RM 注册并 定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况。 七、资源调度器分类
目前Hadoop 作业调度器主要有三种FIFO、Capacity Scheduler 和 Fair Scheduler。Hadoop 版本 2.6.0-cdh5.14.2 默认的资源调度器是 Fair Scheduler。 7.1 FIFO Scheduler FIFO Scheduler 把应用按提交的顺序排成一个队列这是一个先进先出队列在进行资源分配的时候先给队列中最头上的应用进行分配资源待最头上的应用需求满足后再给下一个分配以此类推。
FIFO Scheduler 是最简单也是最容易理解的调度器也不需要任何配置但它并不适用于共享集群。大的应用可能会占用所有集群资源这就导致其它应用被阻塞。在共享集群中更适合采用 Capacity Scheduler 或 Fair Scheduler这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
7.2 Capacity Scheduler Capacity 调度器允许多个组织共享整个集群每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列然后再为每个队列分配一定的集群资源这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外队列内部又可以垂直划分这样一个组织内部的多个成员就可以共享这个队列资源了在一个队列内部资源的调度是采用的是先进先出(FIFO)策略。
支持多个队列每个队列可配置一定的资源量每个队列都采用 FIFO 调度策略。
为了防止同一个用户的作业独占队列中的资源该调度器会对同一用户提交的作业所占资源量进行限定。
按照作业优先级和提交时间顺序同时考虑用户资源量限制和内存限制对队列内任务排序。多个队列同时按照任务的先后顺序依次执行也就是排在队列前面的最先执行也是同时执行。
7.3 Fair Scheduler 支持多队列多用户每个队列中的资源量可以配置同一队列中的作业公平共享队列中所有资源。
比如有三个队列 queue1、Queue2、Queue3每个队列中的 job 按照优先级分配资源优先级越高分配的资源越多但是每个 job 都会分配到资源以确保公平。在资源有限的情况下每个 job 理想情况下获得的计算资源与实际获得的计算资源存在一种差距这个差距就叫做差额。在同一个队列中job 的资源缺额越大越先获得资源优先执行。作业是按照缺额的高低来先后执行的。在 Fair调度器中我们不需要预先占用一定的系统资源Fair 调度器会为所有运行的 job动态的调整系统资源。
如下图所示当第一个大 job 提交时只有这一个 job 在运行此时它获得了所有集群资源当第二个小任务提交后Fair 调度器会分配一半资源给这个小任务让这两个任务公平的共享集群资源。
今天YARN的相关内容就分享到这里如果帮助到大家欢约大家点赞关注收藏有疑问也欢迎大家评论留言
