Yarn结构概览
本文内容总结自《Hadoop技术内幕—深入解析Yarn架构设计与实现原理》
一.关于Yarn
1.1 Yarn是什么？
YARN 是 Hadoop 2.0 中的资源管理系统，它是一个通用的资源管理模块，可为各类应用程序进行资源管理和调度。YARN 不仅限于 MapReduce 一种框架使用，也可以供其他框 架使用，比如Spark、Storm等。 具有很好的通用性。
1.2 Yarn的来源
yarn来自于mr1。但是mr1是有很多缺陷的，其中包括：
❑ 扩展性差。在 MRv1 中，有一个JobTracker的概念，JobTracker 同时兼备了资源管理和作业控制（负责任务分发 管理）两个功能，当任务很多的时候，这 成为系统的一个最大瓶颈，严重制约了 Hadoop 集群扩展性。
❑ 可靠性差。MRv1 采用了 master/slave 结构，其中，master 存在单点故障问题，一旦 它出现故障将导致整个集群不可用。
❑ 资源利用率低。MRv1 采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源 划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空 闲资源。此外，Hadoop 将槽位分为 Map Slot 和 Reduce Slot 两种，且不允许它们之 间共享，常常会导致一种槽位资源紧张而另外一种闲置(比如一个作业刚刚提交时， 只会运行 Map Task，此时 Reduce Slot 闲置)。
❑ 无法支持多种计算框架。随着互联网高速发展，MapReduce 这种基于磁盘的离线计 算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、 流式计算框架和迭代式计算框架等，而 MRv1 不能支持多种计算框架并存。
那么对于以上的缺陷，就提出来了mr2，MR2是apache对其进行的改造，mr2
将资源管理抽象成了一个独立通用的模块yarn。
这样将其独立出来的优势在于：不光mr可以使用，其他的任何计算框架都可以使用。它的目标已经不再局限于支持 MapReduce 一种计算框架，而是朝着对多种框架进行统一管理的方向发展
并且使用yarn，可以将多个框架都部署到 一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用某种资源 隔离方案对各个任务进行隔离 ，这样的优势是资源利用率高，成本低。
Mr主要是三部分组成：编程模型，数据处理引擎，运行时环境。在mr1中，运行时环境就是有一个jobTracker和若干taskTracker组成。Mr2与mr1有相同的编程模型和数据处理引擎，但是运行时环境却发生了变化，变成了通用资源管理yarn和作业控制进程applicatonMaster。
下一代 MapReduce 框架的基本设计思想是将 JobTracker 的两个主要功能，即资源管理 和作业控制(包括作业监控、容错等)，分拆成两独立的进程。资源管理进 程与具体应用程序无关，它负责整个集群的资源(内存、CPU、磁盘等)管理，而作业控 制进程则是直接与应用程序相关的模块，且每个作业控制进程只负责管理一个作业。这样， 通过将原有 JobTracker 中与应用程序相关和无关的模块分开，不仅减轻了 JobTracker 负载， 也使得 Hadoop 支持更多的计算框架。
从资源管理角度看，下一代 MapReduce 框架实际上衍生出了一个资源统一管理平台 YARN，它使得 Hadoop 不再局限于仅支持 MapReduce 一种计算模型，而是可无限融入多 种计算框架，且对这些框架进行统一管理和调度
二. Yarn的结构
YARN 总体上仍然是 Master/Slave 结构，在整个资源管理框架中，ResourceManager 为 Master，NodeManager 为 Slave，ResourceManager 负责对各个 NodeManager 上的资源进行统一管理和调度, NodeManager是每个节点上的资源和任务管理器。
在架构里面，还有一个applicationMaster的概念，当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的 ApplicationMaster（需要用户提供），它负责向 ResourceManager 申请资源，并要求 NodeManger 启动可以占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间 不会相互影响
2.1 ResourceManager(RM)
RM 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件 构成:调度器(Scheduler)和应用程序管理器(Applications Manager，ASM)
1)调度器 调度器根据容量、队列等限制条件(如每个队列分配一定的资源，最多执行一定数量的作业等)，将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度器是 一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪 应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务， 这些均交由应用程序相关的 ApplicationMaster 完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”(Resource Container，简 称 Container)表示，Container 是一个动态资源分配单位，它将内存、CPU、磁盘、网络等 资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件， 用户可根据自己的需要设计新的调度器，YARN 提供了多种直接可用的调度器，比如 Fair Scheduler 和 Capacity Scheduler 等
(2)应用程序管理器 应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它
2.2ApplicationMaster(AM)
用户提交的每个应用程序均包含一个 AM，主要功能包括:
❑ 与 RM 调度器协商以获取资源(用 Container 表示);
❑ 将得到的任务进一步分配给内部的任务;
❑ 与 NM 通信以启动 / 停止任务;
❑ 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
当 前 YARN 自 带 了 两 个 AM 实 现， 一 个 是 用 于 演 示 AM 编 写 方 法 的 实 例 程 序 distributedshell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本 ; 另一个是运行 MapReduce 应用程序的 AM— MRAppMaste 。
ApplicationMaster是yarn的结构不可少的一部分，但是这一部分并不完全是有yarn提供的，不同的计算框架需要提供自己的applicationMaster，yarn只是自带了一些实现，这也是为什么说yarn是一个通用的框架。当然，为了简化applicatipnMaster和客户端的开发，yarn提供了一些编程库。
2.3NodeManager(NM)
NM 是每个节点上的资源和任务管理器，一方面，它会定时地向 RM 汇报本节点上的 资源使用情况和各个 Container 的运行状态;另一方面，它接收并处理来自 AM 的 Container 启动 / 停止等各种请求
三. Yarn组件之间的通信
- Job Client(作业提交客户端)与 RM 之间的协议 — ApplicationClientProtocol : client 通过该协议可实现将应用程序提交到RM，查询应用程序的运行状态或者杀死应用程序等功能。
- Admin(管理员)与 RM 之间的通信协议— ResourceManagerAdministrationProtocol : Admin 通过该 RPC 协议更新系统配置文件，比如节点黑白名单、用户队列权限等。
- AM 与 RM 之间的协议— ApplicationMasterProtocol :AM 通过该 RPC 协议向 RM 注册和撤销自己，并为各个任务申请资源。
- AM 与 NM 之间的协议 — ContainerManagementProtocol :AM 通过该 RPC 要求 NM 启动或者停止 Container，获取各个 Container 的使用状态等信息。
- NM 与 RM 之间的协议— ResourceTracker :NM 通过该 RPC 协议向 RM 注册，并 定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况
3.1 Job Client->RM
yarn job客户端的主要作用是提供一系列访问接口提供用户与yarn交互。客户端提交一个应用程序需要利用该协议，具体如下：
- clinet首先利用该协议（ApplicationClientProtocol），从ResourceManager领取唯一的applicationId。
- client之后利用该协议将applicationMaster提交到RM。提交上去，包含的一些关键参数有：application_id，application_name以及启动applicationMaster需要的相关信息（包括：application启动用户，需要资源cpu和内存，启动shell命令，运行环境，需要的本地资源（这包啊 等等吧））
从图中也可以看到，其实client是需要包等一些文件推到hdfs上的，后面会说到各个节点去取这些hdfs上的文件。
当然client还可以利用该协议向RM·获取application的运行情况，杀死application等等。但是为了减轻RM的压力，在applicationMaster启动之后，也可以直接和AM通信来查询他的运行状况或是kill一个任务。这通常取决于具体的实现。
3.2 AM-RM
AM和利用协议ApplicationMasterProtocol 与RM交互主要是注册自己以及申请资源，涉及到的协议ApplicationMasterProtocol。主要包含:
- AM启动之后，首先需要像RM注册，告知自己启动的host，port等。AM注册成功之后，将会收到可申请的最大资源量等信息。
- AM向RM申请资源，AM将发送：一个资源请求列表（包括一个container所需的资源量以及需要的资源数目），一个释放container列表，应用执行进度。一次资源请求发送的信息不仅包含了需要的资源量，还有一个需要释放的资源量，以便AM认为不需要某些资源时可以及时释放。同事即使AM不需要任务的资源 ，仍然需要周期性地调用这个方法，以便维持心跳信息。
AM调用这个方法后，将会收到分配给该应用程序的container列表；运行完成的container列表 - AM告知RM运行结束，并退出。会报告一个状态：运行成功，运行时失败，被杀死。
3.3 AM-NM
AM 通过协议ContainerManagementProtocol与NM通信，要求 NM 启动或者停止 Container以及获取各个 Container 的使用状态等信息。 也即是AM里面有一个任务的的运行信息。
主要包括：
- AM将申请到的资源分配给内部任务，并通过该协议与对应的NodeMa nager通信，要求对应的NM启动container。请求的信息主要是Container的执行环境，包括需要的本地资源（jar包等）以及所需要的环境变量等等。 将会收到返回值包括运行成功和失败的container列表
- AM可以像NM查询Container的状态，如果发现某个container运行失败，那么AM可尝试重新申请资源等。
- AM可以要求释放这个container
3.4NM-RM
NM通过协议ResourceTracker协议与RM通信，实现NM向RM的注册，汇报节点信息，领取RM下达的命令（清理Container信息等）。
主要包括：
- NM启动时向RM注册，注册信息包括：host，port，可分配资源。
- 定期向RM汇报节点健康情况和container运行状况，并领取命令。这样RM里面是有一个任务的运行信息的。
注：
AM可以要求释放container，也即是释放资源，RM也可以向NM下达命令，要求释放资源。这二者应该是并不冲突的，作用各不相同。
四. Yarn组件
在各个组件的通信方式部分，介绍了各个组件之间的通信协议以及通信内容，从那一部分其实也就可以看出来各个组件的作用和之间的协作。那么，这里再对yarn的几个关键的组件进行说明
4.1client和applicationMaster
这两个部分根据计算框架的不同而不同，也就是说用户可以完全制定自己的client和applicationMaster。要自定义的话，就需要自己去实现这个两个组件和其他组件的交互，也就是文章在通信那一部分描述的，为了简化开发，yarn提供了对应的编程库，这里不再做介绍了
4.2ResourceManager
RM是yarn主从结构中的master，是非常重要的存在。他的功能也较多，包括整个集群的资源管理和调度，应用程序的管理，node的管理等等。
以下是RM的内部架构：
我们可以看到每一个模块（虚线框）都是由好几个服务（每一个服务其实是一个事件处理器，yar是基于状态机管理的）组成，虽然我们前面提到每两个组件之间都是由一个通信来进行交互的，但是在RM内部，同一块由不同的服务来处理不同的需求，这与之前提到的并不冲突。
对几个服务简要说明一下，然后对比一下，也就能知道各个服务大概是做什么的了。
-
User Service：用户管理模块
主要是处理用户的需求。 -
Manage AMs：ApplicationMaster管理
这一部分由三个不同的服务构成，共同管理applicationMaster的生命周期。ApplicationMasterLauncher：这是启动/关闭applicationMaster的。如果收到的是“Launch”事件类型，他与对应的nodeManager通信，从而启动AM。启动之后，这个服务会将启动的AM注册到AMLivelinessMonitor，启动心跳监控。如果是“Cleanup”，他与对应的nodeManager通信，杀死AM。
AMLivelinessMonitor：周期性遍历所有的AM，如果有一个AM在一定时间内没有汇报心跳信息，则认为他死掉了，在他上面运行的所有container都会被认为是失败的。如果AM失败，RM重新为其申请资源，在另一个节点上启动AM（默认重试次数2，用户可设定）。这就是我前面说的RM会管理AM，失败后会重启，之前的资源被释放。
ApplicationMasterService：负责处理AM的请求，包括注册，心跳，清理
-
Manage NMs：NodeManager管理
对比AM的管理。 -
Manage APPs： Application的管理 应用程序访问权限
-
State Machine: 状态机管理
Yarn采用的事件驱动，下图就是RM的一个事件处理图，所有的服务和组件都是有中央异步调度器组织在一起的。
一个对象会有很多的状态组成，每一种状态经过一种特定的事件触发会转换成另外一种状态，状态机管理就是去管理各种状态机 -
Resource Scheduler:资源调度器
资源调度器是RM中的一个服务组件，负责整个集群的资源管理和分配，目前提供了三种调度方式：FIFO，Capacity，Fair。
Yarn采用的双层资源调度模型：第一层RM将资源分配个各个AM；第二层中AM再进一步将资源分配给内部的各个任务。
4.3 NodeManager
NM的一些功能在前面基本都已经阐述了。
前面在客户端的时候，提到了客户端会上传一些jar包等依赖的文件，如果应用程序是第一次在该节点上启动任务，那么NM会首先从HDFS上下载所需要的文件，这个依赖的是Yarn的分布式缓存机制。
五. Yarn任务提交运行流程
- 客户端向 YARN 中提交应用程序，其中包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
- ResourceManager 为该应用程序分配第一个 Container，并与对应的 Node- Manager 通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster。
- ApplicationMaster启动后，首先向 ResourceManager 注册，这样用户可以直接通过 ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运 行状态，直到运行结束，即重复步骤 4~7。
- ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和 领取资源。
- 一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求 它启动任务。
- NodeManager 为任务设置好运行环境(包括环境变量、JAR 包、二进制程序 等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
- 各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以 让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。 在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当 前运行状态。
- 应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己 。
更细一点的话：
- client首先应该是把任务的jar包等需要依赖的文件上传到HDFS。
- client利用协议和RM通信，取得Applicationid。
- client打包所需信息，将ApplicationMaster提交到RM。
- RM收到请求后，向资源调度器申请用以启动AM的资源，申请到资源后，与对应的NodeManager通信，从而启动AM。
- AM启动之后，RM的ApplicationMasterLauncher服务通过事件的形式将AM注册到AM的AMLivelinessMonitor中，用以监测AM。同时AM会先向RM中的ApplicationMasterService注册，汇报自己的host和port。
- AM定期向RM申请资源，该请求同样也作为了心跳信息。
- AM将申请到的资源进行二次分配，与对应的NM通信，要求其启动container。
- NM收到请求后，如果这是该NM收到的来自该AM的第一个启动container请求，则首先进行应用程序初始化这个工作，包括创建日志记录组件，创建工作目录，还有container本地化即从HDFS上下载所需资源。如果不是第一个container，不需要进行应用程序初始化，但是如果这个container发现，前面的container仍然在下载文件，那么该container也会尝试下载未下载文件，以加快速度。之后便运行任务。
- 各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以 让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。 在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当 前运行状态。
- 应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己 。
Yarn的高可用性
在前面MR的地方，单点故障是MR的局限性之一。那么新引入的yarn也是master/slave结构，那么同样也容易出现单点故障的问题。那么yarn为了提高自己的可用性，采取了一些方案。
热备方案：集群中存在一个对外的active master 和若干处于就绪状态的standby master。一旦active出现问题，根据一定的选取策略选择一个standby，以继续提供服务。Hadoop2.0中，hdfs和yarn都是采用了基于共享存储的HA方案，即active会不断地将一些信息写入到一个共享的存储系统中，而standby会不断地读取这些信息，以保持和active同步。
常用的共享存储系统有很多，比如ZK，HDFS，NFS，QJM等。在Hadoop2.0中yarn采用的是ZK。
那么yarn所存储的信息包括：
- Application的状态信息：应用程序提交的描述信息context，提交时间，拥有者。
- Application对应的ApplicationAttempt信息，ApplicationAttempt是一个application的一次运行尝试，一个application可能会有多个运行尝试（如果第一个失败，yarn默认会重试两次）
- 安全令牌相关信息。
Yarn并不会保存已经为每个AM分配的资源信息以及每个NodeManager的资源使用信息。因为这些均可以通过心跳信息恢复出来。也由此，yarn的HA是轻量级的。
一个程序运行结束，他的信息会被清除。
RM重启后，内部的所有的服务都将会被启动，之后会有以下的几个流程：
1． RM收到NM的心跳后，发现该NM并不存在，要求他重启，在它上面运行的所有contianer都将失败。NM重起后会再次向RM注册。
2． RM收到AM的心跳后，发现该AM运行的实例不存在，AM异常退出。
扫一扫
292
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
