资源管理与调度系统YARN(一)

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/Katherine_hsr/article/details/84990245

hadoop 2.0引入了数据操作系统YARN，YARN能够将资源按需分配给各个应用程序，大大提高了资源利用率，其次，YARN将短作业和长作业混合部署到一个集群中，并提供了容错、自愿隔离及负载均衡等方面的支持，大大简化了作业和服务的部署和管理成本。

why YARN

MRv1 局限性

1. 可靠性差：MRv1采用了master/slave结构，master存在单点故障问题，一旦出现问题可能导致整个集群不可用。
2. 扩展性差：MRv1中JobTracker(master)同时兼备了资源管理和作业控制两个功能，严重制约了Hadoop集群的扩展性。
3. 资源利用率低：MRv1采用了基于槽位的资源分配模型，通常一个任务不用全部用完槽位对应的所有的资源，其他任务也无法使用这些没有使用的资源。另外，Hadoop将槽位划分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另一种槽位闲置的状态(例如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置)。
4. 无法支持多种计算框架：MRv1不能支持多种计算框架并存(例如内存计算框架、流式计算框架和迭代计算框架)。
   MRv2将资源管理功能抽象成了一个独立的通用系统YARN，使得下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。下图展示了MRv1和MRv2的对比：
   
   以MapReduce为核心的协议栈中，资源管理系统是可以替换的，但一旦MapReduce接口发生改变，所有的资源管理系统的实现都需要改变；以YARN为核心的协议栈中，所有框架都需要实现YARN定义的对外接口以运行在YARN之上。

YARN设计动机

YARN作为一个通用的资源管理系统，其目标是将短作业和长任务混合部署到一个集群中，并为他们提供统一的资源管理和调度功能。YARN的设计需要解决以下两类问题。

1. 提高集群资源利用率
   为了存储和处理海量数据，需要规模较大的服务器集群或者数据中心，一般这些集群上运行着数量众多的应用程序和服务，传统的做法是让这些不同类型的作业或任务对应一个单独的集群以避免互相干扰。这样集群被分成若干个小集群，由于不同类型的任务需要的资源不同，所以这些小集群的利用率通常很不均衡，并且集群间的资源无法共享，有些集群资源紧张而有些集群处于闲置状态。为了提高资源整体的利用率，一种解决方式是让这些小集群合并成一个大的集群，让任务可以共享大集群的资源，并由一个资源管理系统统一进行资源管理和分配。
2. 服务自动化部署
   YARN需要提供服务统一管理系统，包括服务资源申请、服务自动化部署、服务容错等功能。

YARN 设计思想

Hadoop1.0中，JobTracker同时负责资源管理和作业控制两部分，如下图所示。这种设计使得JobTracker的功能过多负载过重，未能将资源管理与程序相关的功能分开，造成第一代Hadoop难以支持多种计算框架

Hadoop2.0的基本设计思想是将资源管理和作业控制(包括作业监控、容错等)拆分成两个独立的进程，从而衍生出了一个资源管理统一平台，使得Hadoop不再局限于仅支持MapReduce一种计算模型，而是可以无限融入多种计算框架，并且对这些框架进行统一管理和调度。如下图所示：

资源管理系统与具体的应用程序无关，负责整个集群的资源(内存，CPU，磁盘等)管理，而作业控制进程则是直接与应用程序相关的模块，每个作业控制进程只负责管理一个作业。这样就将原来的JobTracker中的资源管理与作业调度模块分开了，不仅减轻了JobTracker的负载，也使得Hadoop支持更多的计算框架。

YARN 基本架构

YARN采用master/slave架构，其中ResourceManager为master，NodeManager为slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个ApplicationMaster用来向ResourceManager申请资源和启动任务。由于不同的ApplicationMaster被分布到不同的节点上，他们之间不会相互影响。下面是YARN的基本组成结构：

ResourceManager(RM)

RM是一个全局的资源管理器，负责整个系统的资源管理和分配。主要有两个组件构成：调度器(Scheduler)和应用管理器(Application Manager, ASM). 为了避免ResourceManager出现单点故障导致整个集群不可用，YARN引入了两个ResourceManager，当Active ResourceManager出现故障时，Standby ResourceManager会通过ZooKeeper选举，自动提升为Active ResourceManager。

1. 调度器(Scheduler)
   调度器主要功能是根据资源容量和队列等方面的限制，将系统中的资源分配给各个应用程序。YARN中的调度器是一个纯调度器，不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用程序的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些都交给ApplicationMaster来完成。
2. 应用程序管理器(Application Manager, ASM)
   负责管理整个系统的所有的应用程序，包括应用程序提交，与调度器协调资源以启动ApplcationMaster，监控ApplcationMaster运行状态并在失败时重新启动它。

ApplicationMaster(AM)

用户提交的每个应用程序均包含一个独立的AM，其主要功能包括：

1. 与RM调度器协商以获取资源(用Container表示)
2. 得到的资源进一步分配给内部的任务
3. 与NM通信以启动、停止服务
4. 监控所有任务的运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

NodeManager(NM)

NM是每个节点上的资源管理器，它会定时的向RM汇报本节点上的资源使用情况和各个Container的运行状态，另一方面它接收并处理来自AM的任务启动、停止等各种请求。在一个集群中，NodeManager通常存在多个，由于YARN内置了容错机制，单个NodeManager的故障不会对集群中的应用程序的运行产生严重的影响。

Container

Container是YARN中的资源分配单位，是对应用程序运行环境的抽象，并为应用程序提供资源隔离环境。它封装了多维度的资源，如内存、CPU、磁盘、网络等。当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN提供了三种可选的ContainerExecutor：DefaultContainerExecutor，LinuxContainerExecutor，DockerContainerExecutor。

YARN高可用

YARN提供了恢复机制，使得YARN在服务出现故障或人工重启时，不会对正在运行的应用程序产生任何影响。

ResourceManager HA

ResourceManager负责整个集群中资源的调度和应用程序管理，是YARN最核心的组件。由于YARN采用了master/slave架构，为了避免ResourceManager故障导致整个集群不可用，YARN引入了Active/Standby ResourceManager，当Active ResourceManager出现故障时，Standby ResourceManager可通过ZooKeeper选举成为Active ResourceManager，并通过ResourceManager Recovery机制恢复状态。

ResourceManager Recovery

ResourceManager 内置了重启恢复功能，当ResourceManager重启或者出现Acitve，Standby切换时，不会影响正在运行的应用程序。ResourceManager Recovery的工作流程如下：

1. 保存元信息：Active ResourceManager运行过程中会将应用程序的元信息、状态信息以及安全凭证等数据持久化到状态存储系统(state-store)中，YARN支持三种可选的state-store, 分别是：
   (1) 基于ZooKeeper的state-store，只有这种形式能防止脑裂基于ZooKeeper的state-store，只有这种形式能防止脑裂
   (2) 基于FileSystem的state-store
   (3) 基于LevelDB的state-store, 比起前两种方案更加轻量级，LevelDB能更好的支持原子操作，每次更新占用更少的IO资源，生成的文件数目更少。
2. 加载元信息：一旦Active ResourceManager重启或出现故障，新启动的ResourceManager将从存储系统中重新加载应用程序的相关数据，在此过程中，所有运行在各个NodeManager的Container仍正常运行。
3. 重构状态信息：新的ResourceManager重新启动后，各个NodeManager会向它重新注册， 并将所管理的Container汇报给ResourceManager，ResourceManager可动态重构资源分配信息、各个应用程序以及其对应Container等关键数据；同时ApplicationMaster会向ResourceManager重新发送资源请求，以便ResourceManager重新为其分配资源。

NodeManager Recovery

NodeManager 内置了重启恢复功能，当NodeManager就地重启时，之前运行的Container不会被杀掉，而是由新的NodeManager接管并继续正常运行。

YARN 工作流程

运行在YARN上的应用程序主要分为两类：短作业和长服务，短作业是指一定时间内可完成并退出的应用程序：如MapReduce作业、Spark作业；长服务是指不出意外永不终止运行的应用程序，如Storm Service、Hbase Service等。两类应用程序尽管作用不同，但运行在YARN上的流程是相同的。YARN工作流程图如下：

YARN的工作流程分为以下几个步骤：

提交应用程序

用户通过客户端与YARN ResourceManager通信，提交应用程序，应用程序中需包含ApplicationMaster可执行代码、启动命令和资源需求、应用程序可执行代码和资源需求、优先级、提交到的队列等信息。

启动ApplicationMaster

ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster，之后ApplicationMaster的生命周期直接被ResourceManager管理。

ApplicationMaster 注册

ApplicationMaster启动后，会向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后初始化应用程序，并按照一定的策略为内部任务申请资源，监控它们的运行状态，直到运行结束。

资源获取

ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

请求启动Container

一旦ApplicationMaster申请到资源后，则与对应的NodeManager通信，请求为其启动任务。

启动Container

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

Container监控

ApplicationMaster可通过两种方式获取各个Container的运行状态，以便在任务失败时重新启动任务：
(1) ApplicationMaster与ResourceManager间维护了周期性心跳信息，每次通信可获取分管的Container的运行状态
(2) 各个Container可通过某个RPC协议向ApplicationMaster汇报自己的状态和进度

注销ApplicationMaster

应用程序运行完成后，ApplicationMaster向ResourceManager注销，并退出执行。