YARN框架概述与集群部署_yarn部署

1 Apache Hadoop YARN框架概述

1.1 YARN产生和发展简史

背景：

• 数据、程序、运算资源（内存、CPU）三者组在一起，才能完成数据的计算处理过程。在单机环境下，三者之间协调配合不是太大问题。

• 为了应对海量数据的处理场景，Hadoop软件出现并提供了分布式处理思想。分布式环境下的三者如何协调好将成为关键。

• 通过对Hadoop版本演进的简单回顾，可以让我们知道YARN的产生和发展简史，洞悉YARN发展进程。

• 很多Hadoop的早期用户使用Hadoop的方式与在众多主机上运行桌面应用程序类似。

​ 在少量几个节点上手工建立一个集群；

​ 将数据载入Hadoop分布式文件系统（HDFS）；

​ 通过运行MapReduce任务来运算并获得结果；

​ 然后拆掉集群。

• 这种方式的一部分原因是没有在Hadoop HDFS上持久存储数据的迫切需求，另一部分原因是没有共享数据和计算结果的动机。

1.2 Hadoop演进阶段

Ad Hoc集群：

• Ad Hoc应当理解为专用的、特定的意思（数仓领域中常理解为即席）。Ad Hoc集群时代标志着Hadoop集群的起源，集群以Ad Hoc、单用户方式建立。
• 后来，随着私人集群的使用和Hadoop容错性的提高，持久的HDFS集群出现，并且实现了HDFS集群的共享，把常用和感兴趣的数据集载入HDFS共享集群中。当共享HDFS成为现实，还没实现共享的计算平台就成为关切对象。
• 不同于HDFS，为多个组织的多个用户简单设置一个共享MapReduce集群并非易事。尤其是集群下的物理资源的共享很不理想。

HOD集群：

• 为了解决集群条件下的多租户问题， Yahoo发展并且部署了称为“Hadoop on Demand”的平台。
• Hadoop On Demand (HOD)是一个能在大规模物理集群上供应虚拟Hadoop集群的系统。
• 在已经分配的节点上， HOD会启动MapReduce和HDFS守护进程来响应用户数据和应用的请求。

​ 特点：用户可以使用HOD来同时分配多个MapReduce集群。

​ 缺点：无法支持数据本地化、资源回收效率低、无动态扩容缩容能力，多租户共享延迟高等。

共享计算集群：

• 共享MapReduce计算集群就是Hadoop 1.x版本里的主要架构模型。

• 主要组件：

​ JobTracker：一个中央守护进程，负责运行集群上的所有作业。

​ TaskTracker：系统里的从进程，根据JobTracker的指令来执行任务。

• 主要弊端：

​ JobTracker身兼多职、压力大（作业数据管理、作业状态记录、作业调度）、可靠性和可用性欠缺（JobTracker单点故障）、计算模型单一（不能万物皆MapReduce）。

• 且MapReduce框架本身需要迭代优化。但是计算和资源管理绑定在了一起，使得MapReduce的演变比较困难。

YARN集群：

• 针对共享计算集群，JobTracker需要彻底地重写，才能解决扩展性的主要问题。但是，这种重写即使成功了，也不一定能解决平台和用户代码的耦合问题，也不能解决用户对非MapReduce编程模型的需求。如果不做重大的重新设计，集群可用性会继续被捆绑到整个系统的稳定性上。
• 拆分MapReduce，剥离出资源管理成为单独框架，YARN闪亮登场，MapReduce专注于数据处理，两者解耦合。
• YARN被设计用以解决以往架构的需求和缺陷的资源管理和调度软件。

对YARN的需求：

• 可扩展性：可以平滑的扩展至数万节点和并发的应用。
• 可维护性：保证集群软件的升级与用户应用程序完全解耦。
• 多租户：需要支持在同一集群中多个租户并存，同时支持多个租户间细颗粒度地共享单个节点。
• 位置感知：将计算移至数据所在位置。
• 高集群使用率：实现底层物理资源的高使用率。
• 安全和可审计的操作：继续以安全的、可审计的方式使用集群资源。
• 可靠性和可用性：具有高度可靠的用户交互、并支持高可用性
• 对编程模型多样化的支持：支持多样化的编程模型，需要演进为不仅仅以MapReduce为中心。
• 灵活的资源模型：支持各个节点的动态资源配置以及灵活的资源模型。
• 向后兼容：保持现有的MapReduce应用程序的向后兼容性。

1.3 YARN简介

概述：

• Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的Hadoop资源管理器。

• YARN是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度。

• 它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

• 可以把Hadoop YARN理解为相当于一个分布式的操作系统平台，而MapReduce等计算程序则相当于运行于操作系统之上的应用程序，YARN为这些程序提供运算所需的资源（内存、CPU等）。

• Hadoop能有今天这个地位，YARN可以说是功不可没。因为有了YARN ，更多计算框架可以接入到 HDFS中，而不单单是 MapReduce，正式因为YARN的包容，使得其他计算框架能专注于计算性能的提升。

• HDFS可能不是最优秀的大数据存储系统，但却是应用最广泛的大数据存储系统， YARN功不可没。

问：如何理解通用资源管理系统和调度平台？

• 资源管理系统：集群的硬件资源，和程序运行相关，比如内存、CPU等。
• 调度平台：多个程序同时申请计算资源如何分配，调度的规则（算法）。
• 通用：不仅仅支持MapReduce程序，理论上支持各种计算程序。YARN不关心你干什么，只关心你要资源，在有的情况下给你，用完之后还我。

1.4 YARN与MRv1区别

概述：

• Hadoop从1到2的过程中，最大的变化就是拆分MapReduce，剥离出新的单独组件：YARN。Hadoop3系列架构整体和2系列一致。
• 在Hadoop1中，MapReduce（MRv1）负责:数据计算、资源管理，身兼多职。
• 在Hadoop2中，MapReduce（MRv2）负责数据计算，YARN负责资源管理。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nm7BCXIG-1668434421972)(assets/image-20221113163048876.png)]

MRv1介绍：

• MRv1包括三个部分：运行时环境（JobTracker和TaskTracker）、编程模型（MapReduce）、数据处理引擎（Map Task和Reduce Task）.
• JobTracker 负责资源和任务的管理与调度， TaskTracker 负责单个节点的资源管理和任务执行。
• MRv1将资源管理和应用程序管理两部分混杂在一起，使得它在扩展性、容错性和多框架支持等方面存在明显缺陷

YARN介绍：

• MRv2 重用了MRv1中的编程模型和数据处理引擎。但运行时环境（resourcemanager、nodemanager）被完全重写,由YARN来专管资源管理和任务调度。
• 并且YARN将程序内部具体管理职责交给一个叫做ApplicationMaster的角色。自己专心于集群资源管理，成为一个通用的资源管理系统。

2 YARN集群介绍

2.1 YARN集群角色、部署规划

集群角色概述：

• Apache Hadoop YARN是一个标准的Master/Slave集群（主从架构）。其中ResourceManager（RM） 为Master， NodeManager（NM） 为 Slave。
• 常见的是一主多从集群，也可以搭建RM的HA高可用集群。

ResourceManager（RM）：

• RM是YARN中的主角色，决定系统中所有应用程序之间资源分配的最终权限，即最终仲裁者。
• RM接收用户的作业提交，并通过NodeManager分配、管理各个机器上的计算资源。资源以Container形式给与。
• 此外，RM还具有一个可插拔组件-scheduler，负责为各种正在运行的应用程序分配资源，根据策略进行调度。

NodeManager（NM）：

• NM是YARN中的从角色，一台机器上一个，负责管理本机器上的计算资源。
• NM根据RM命令，启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况。

2.2 YARN RM重启机制

概述：

• ResourceManager负责资源管理和应用的调度，是YARN的核心组件，存在单点故障的问题。

• ResourceManager Restart重启机制是使RM在重启动时能够使Yarn集群正常工作的特性，并且使RM的出现的失败不被用户知道。

• 重启机制并不是自动帮我们重启的意思。所以说不能解决单点故障问题。

• 不开启RM重启机制：如果RM出现故障重启之后，之前的信息将会消失。正在执行的作业也会失败。

设置命令：

Non-work-preserving RM restart
不保留工作的RM重启，在Hadoop 2.4.0版本实现。

Work-preserving RM restart
保留工作的RM重启，在Hadoop 2.6.0版本中实现。
1
2
3
4
5

保留工作与不保留工作的区别：

• 不保留工作RM重启机制只保存了application提交的信息和最终执行状态，并不保存运行过程中的相关数据，所以RM重启后，会先杀死正在执行的任务，再重新提交，从零开始执行任务。
• 保留工作RM重启机制保存了application运行中的状态数据，所以在RM重启之后，不需要杀死之前的任务，而是接着原来执行到的进度继续执行。

Non-work-preserving RM restart：

• 当Client提交一个application给RM时，RM会将该application的相关信息存储起来，具体存储的位置是可以在配置文件中指定的，可以存储到本地文件系统上，也可以存储到HDFS或者是Zookeeper上，此外RM也会保存application的最终状态信息(failed，killed，finished),如果是在安全环境下运行，RM还会保存相关证书文件。
• 当RM被关闭后，NodeManager(以下简称NM)和Client由于发现连接不上RM，会不断的向RM发送消息，以便于能及时确认RM是否已经恢复正常，当RM重新启动后，它会发送一条re-sync(重新同步)的命令给所有的NM和ApplicationMaster(以下简称AM)，NM收到重新同步的命令后会杀死所有的正在运行的containers并重新向RM注册，从RM的角度来看，每台重新注册的NM跟一台新加入到集群中NM是一样的。
• AM收到重新同步的命令后会自行将自己杀掉。接下来，RM会将存储的关于application的相关信息读取出来，将在RM关闭之前最终状态为正在运行中的application重新提交运行。

Work-preserving RM restart：

• 与不保留工作不同的地方在于，RM会记录下container的整个生命周期的数据，包括application运行的相关数据，资源申请状况，队列资源使用状况等数据。
• 当RM重启之后，会读取之前存储的关于application的运行状态的数据，同时发送re-sync的命令，与第一种方式不同的是，NM在接受到重新同步的命令后并不会杀死正在运行的containers，而是继续运行containers中的任务，同时将containers的运行状态发送给RM，之后，RM根据自己所掌握的数据重构container实例和相关的application运行状态，如此一来，就实现了在RM重启之后，紧接着RM关闭时任务的执行状态继续执行。

RM状态数据的存储介质：

RM的重启机制本质上是将RM内部的状态信息写入外部存储介质中。

在RM启动时会初始化状态信息的目录，当Application运行时会将相关的状态写入对应的目录下。

如果RM发生故障切换或者重启，可以通过外部存储进行恢复。

RM状态存储的实现是RMStateStore抽象类。

ZKRMStateStore：

• RM的所有状态信息存储在ZooKeeper的/rmstore/ZKRMStateRoot下；
• 主要保存了RM资源预留信息、应用信息，应用的Token信息，RM版本信息。

配置：yarn-site.xml 配置启用RM重启功能，使用Zookeeper进行转态数据存储。

<property>
    <name>hadoop.zk.address</name> 			 				<value>node1.itcast.cn:2181,node2.itcast.cn:2181,node3.itcast.cn:2181</value>
</property>
<property>
    <name>yarn.resourcemanager.recovery.enabled</name>    <value>true</value>
</property>
<property>
    <name>yarn.resourcemanager.store.class</name>    <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
</property>
1
2
3
4
5
6
7
8
9

2.3 YARN HA集群

背景：

• ResourceManager负责资源管理和应用的调度，是YARN的核心组件，集群的主角色。
• 在Hadoop 2.4之前，ResourceManager是YARN群集中的SPOF（Single Point of Failure，单点故障）。
• 为了解决RM的单点故障问题，YARN设计了一套Active/Standby模式的ResourceManager HA架构。

架构：

• Hadoop官方推荐方案：基于Zookeeper集群实现YARN HA。
• 实现HA集群的关键是：主备之间状态数据同步、主备之间顺利切换（故障转移机制）
• 针对数据同步问题，可以通过zk来存储共享集群的状态数据。因为zk本质也是一个小文件存储系统。
• 针对主备顺利切换，可以手动，也可以基于zk自动实现。

故障转移机制：

• 手动故障转移

​ 管理员使用命令手动进行状态切换。

• 自动故障转移

​ RM可以选择嵌入基于Zookeeper的ActiveStandbyElector来实现自动故障转移。

​ YARN的自动故障转移不需要像HDFS那样运行单独的ZKFC守护程序，因为ActiveStandbyElector是一个嵌入在RM中充当故障检测器和Leader选举的线程，而不是单独的ZKFC守护进程。

故障转移原理（基于zk自动切换）：

• 创建锁节点：在ZooKeeper上会创建一个叫做ActiveStandbyElectorLock的锁节点，所有的RM在启动的时候，都会去竞争写这个临时的Lock节点，而ZooKeeper能保证只有一个RM创建成功。创建成功的RM就切换为Active状态，没有成功的RM则切换为Standby状态。
• 注册Watcher监听：Standby状态的RM向ActiveStandbyElectorLock节点注册一个节点变更的Watcher监听，利用临时节点的特性（会话结束节点自动消失），能够快速感知到Active状态的RM的运行情况。
• 准备切换：当Active状态的RM出现故障（如宕机或网络中断），其在ZooKeeper上创建的Lock节点随之被删除，这时其它各个Standby状态的RM都会受到ZooKeeper服务端的Watcher事件通知，然后开始竞争写Lock子节点，创建成功的变为Active状态，其他的则是Standby状态。
• Fencing(隔离)：在分布式环境中，机器经常出现假死的情况（常见的是GC耗时过长、网络中断或CPU负载过高）而导致无法正常对外进行及时响应。如果有一个处于Active状态的RM出现假死，其他的RM刚选举出来新的Active状态的RM，这时假死的RM又恢复正常，还认为自己是Active状态，这就是分布式系统的脑裂现象，即存在多个处于Active状态的RM，可以使用隔离机制来解决此类问题。

​ YARN的Fencing机制是借助ZooKeeper数据节点的ACL权限控制来实现不同RM之间的隔离。创建的根ZNode必须携带ZooKeeper的ACL信息，目的是为了独占该节点，以防止其他RM对该ZNode进行更新。借助这个机制假死之后的RM会试图去更新ZooKeeper的相关信息，但发现没有权限去更新节点数据，就把自己切换为Standby状态。

3 YARN角色组件、架构

官方构架图

• MR作业状态汇报 Container（Map|Reduce Task）–>Container（MrAppMaster）
• MR作业提交 Client–>RM
• 节点的状态汇报 NM–>RM
• 资源的申请 MrAppMaster–>RM

3.1 YARN组件及功能

3.1.1 ResourceManager

概述：

• YARN集群中的主角色，决定系统中所有应用程序之间资源分配的最终权限，即最终仲裁者。
• 接收用户的作业提交，并通过NM分配、管理各个机器上的计算资源。

主要组件：

• 调度器（Scheduler）：根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
• 应用程序管理器（Applications Manager）：负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。

3.1.2 NodeManager

概述：

• YARN中的从角色，一台机器上一个，负责管理本机器上的计算资源。
• 根据RM命令，启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况。

NodeManager是每个节点上的资源和任务管理器。

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

3.1.3 ApplicationMaster

概述：

• 用户提交的每个应用程序均包含一个AM。
• 应用程序内的“老大”，负责程序内部各阶段的资源申请，监督程序的执行情况。

职责：

• 与 RM 调度器协商以获取资源（用 Container 表示）；
• 将得到的任务进一步分配给内部的任务；
• 与 NM 通信以启动 / 停止任务；
• 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

当前YARN自带了两个AM实现

• 一个是用于演示AM编写方法的例程序distributedshell；
• 另一个是运行 MapReduce 应用程序的 AM—MRAppMaster。

3.1.4 Container容器

概述：

• Container 是YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当 AM 向 RM 申请资源时， RM 为 AM 返回的资源便是用 Container表示的。YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。需要注意的是， Container 不同于 MRv1 中的 slot（槽位），它是一个动态资源划分单位，是根据应用程序的需求动态生成的。
• 当下YARN仅支持CPU和内存两种资源，底层使用了轻量级资源隔离机制Cgroups进行资源隔离。

3.2 YARN通信协议

概述：

• 分布式环境下，需要涉及跨机器跨网络通信，YARN底层使用RPC协议实现通信。
• RPC是远程过程调用（Remote Procedure Call）的缩写形式。基于RPC进行远程调用就像本地调用一样。
• 在RPC协议中，通信双方有一端是Client，另一端为Server，且Client总是主动连接 Server 的。因此，YARN实际上采用的是拉式（pull-based）通信模型。

RPC协议组成：

• JobClient（作业提交客户端 ）与 RM 之间的协议–ApplicationClientProtocol

​ 客户端通过该 RPC 协议提交应用程序、查询应用程序状态等。

• Admin（管理员）与 RM 之间的通信协议–ResourceManagerAdministrationProtocol

​ Admin通过该 RPC 协议更新YARN集群系统配置文件，比如节点黑白名单、用户队列权限等。

• AM 与 RM 之间的协议–ApplicationMasterProtocol

​ AM 通过该 RPC 协议向RM注册和撤销自己，并为各个任务申请资源。

• AM 与 NM 之间的协议–ContainerManagementProtocol

​ AM 通过该 RPC 要求NM启动或者停止 Container，获取各个 Container 的使用状态等信息。

• NM 与 RM 之间的协议–ResourceTracker

​ NM 通过该 RPC 协议向 RM 注册，并定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况。

4 YARN交互流程

Yarn上应用类型：

• 短应用程序：指一定时间内（可能是秒级、分钟级或小时级，尽管天级别或者更长时间的也存在，但非常少）可运行完成并正常退出的应用程序，比如 MapReduce 作业、 Spark 作业等；
• 长应用程序：指不出意外，永不终止运行的应用程序，通常是一些服务，比如 Storm Service（主要包括 Nimbus 和 Supervisor 两类服务）， Flink（包括 JobManager和 TaskManager两类服务） 等，而它们本身作为一个框架提供了编程接口供用户使用。

​ 尽管这两类应用程序作用不同，一类直接运行数据处理程序，一类用于部署服务（服务之上再运行数据处理程序），但运行在 YARN 上的流程是相同的。

整体概述：

当用户向 YARN 中提交一个应用程序后， YARN 将分两个阶段运行该应用程序 。

• 第一个阶段是启动 ApplicationMaster；
• 第二个阶段是由 ApplicationMaster 创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。

MR提交YARN交互流程：

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

第2步、ResourceManager 为该应用程序分配第一个Container，并与对应的 NodeManager通信，要求它在这个 Container中启动应用程序的 ApplicationMaster。

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

第4步、ApplicationMaster 通过 RPC 协议向 ResourceManager 申请和领取资源。

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

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

第7步、各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状态。

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