什么是YARN？跟HBase和Spark比优势在哪？终于有人讲明白了-轻识

导读：HBase没有资源什么事情也做不了，Spark占用了资源却没有事情可做？YARN了解一下。

作者：朱凯

来源：大数据DT（ID：hzdashuju）

01 概述

随着Hadoop生态的发展，开源社区出现了多种多样的技术组件。有用来构建数据仓库的Hive，也有基于内存的计算框架Spark，还有我们之前介绍过的NoSQL数据库HBase等。

这些技术组件的出现，极大地丰富了大数据的生态体系，但同时也引出了一些新的问题。作为一个大数据底层支撑平台，同时部署Hive、HBase和Spark等多种技术组件是一件十分平常的事情。这些为大数据场景设计的技术组件可以说个个都是消耗资源的大户，这些资源包括服务器的CPU和内存。

通常这些技术组件都有一套自己的资源调度系统用来管理任务的资源分配，但当它们同时部署在一起的时候就出问题了。这时会有两种情况产生，第一种情况是某些组件可能申请不到服务器资源。

比如一台拥有32G内存的服务器同时部署了HBase和Spark，HBase的RegionServer启动时占用了20GB内存，这时Spark开始执行某个任务也需要使用20GB内存，但这时发现没有足够的内存资源使用了。因为从每个组件独立的视角来看他们都认为自己能使用100%的服务器资源，但服务器资源的总量就那么多，不可能同时满足所有组件的需求。

第二种是可能会出现资源分配不合理的情况，导致整体资源使用率偏低。我们同样用刚才的场景举例，Spark启动了一个任务申请使用30GB的内存，但是实际上它的程序逻辑并不需要使用这么多资源。这就出现了一种HBase没有资源什么事情也做不了，但Spark占用了资源却没有事情可做的局面。

为了解决类似的问题，我们需要一种通用的资源调度框架，对整个集群的资源进行统筹管理。

YARN就是一款优秀的集群资源调度框架。YARN是Yet Another Resource Negotiator的缩写，它是Hadoop的第二代集群资源调度框架。

解决了Hadoop第一代集群资源调度框架上可靠性差、扩展性差等一系列问题，同时YARN从MapReduce中完全独立出来，从专门支撑MapReduce任务调度升级成为了一个支持多种应用类型的通用集群资源调度框架。

除了MapReduce之外，Spark、Hive等一系列服务都可以作为应用运行在YARN之上，统一使用YARN为整个集群资源进行宏观的调度与分配，如图2-12所示。

▲图2-12 YARN的逻辑结构

02 资源模型和Container

YARN将服务器资源进行了抽象封装，它使用Container对象代表申请资源的基本单元。

这些资源包括资源名称（服务器名称、机架等）、内存和CPU，YARN通过Container机制将服务器资源进行了隔离。每个应用都可以通过ApplicationMaster向ResourceManager申请资源，当ApplicationMaster向ResourceManager申请资源时，ResourceManager返回的资源使用Container的个数来表示，比如一个Spark计算任务需要5个Container资源。

03 ResourceManager

ResourceManager是一个全局的资源管理器，负责整个系统的资源管理和分配以保证整个集群的高效运行。它会根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。

ResourceManager只负责根据各个应用程序的资源请求进行资源分配，不参与任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。资源分配单位用的是我们刚才介绍过的Container对象。

此外，ResourceManager还支持一个可插拔的调度器插件来支持多种资源调度策略，比如使用公平调度或是容量调度。

04 ApplicationMaster

每一个想要运行在YARN上的应用都必须有一个相应的ApplicationMaster实现，应用将内部的任务调度逻辑和监控都交由它们自己的ApplicationMaster实现类来处理。

ApplicationMaster是YARN的一个创新设计，YARN通过这种机制将自己打造成了一个扩展性极强的通用资源调度框架，因为它允许用户开发自己的ApplicationMaster实现。

ApplicationMaster进程在运行的过程中主要负责与ResourceManager进行通信，以申请执行任务时所需要的资源，在申请到资源之后再进一步执行自身内部的调度任务。同时ApplicationMaster也负责监控自己运行的内部任务状态，在任务失败的时候重新为任务申请相应资源并重启任务。

ApplicationMaster通常作为一个应用的主进程，主要用来扮演拆分子任务、汇总结果数据这类的总体调度，比如Spark的Driver进程。而真正的执行程序业务逻辑的进程是在NodeManager进程上执行的。

05 NodeManager

NodeManager是每个服务器节点上资源管理器，负责管理自己所处服务器Containers的整个生命周期。

在YARN上运行的应用最终的逻辑执行程序（比如Spark的task、MapReduce的job）都会在NodeManager的Container中运行，可以说NodeManager是YARN计算节点的代理，因为ResourceManager只会将任务分配到启动了NodeManager进程的服务器。

当NodeManager进程启动的时候它会向ResourceManager进行注册，并定时汇报自己所在服务器的资源使用情况和Container运行状态，同时它也接受并处理来自ApplicationMaster的Container启动和停止等各种请求。

06 单一集群架构

通过上面的介绍我们不难发现，ResourceManager、NodeManager和Container组件都不关心具体的应用程序或任务的类型，只有ApplicationMaster才是应用类型相关的。

YARN通过使用开放ApplicationMaster的集成方式，允许第三方应用框架便捷的和YARN进行集成。这才有了像MapReduce On YARN、Storm On YARN、Spark On YARN和Tez On YARN等众多第三方应用集成方案的出现。

通过这种资源共享的单一集群架构，我们在企业内部可以实现服务器资源真正的共享使用，以达到降低技术集成成本和增强资源整体利用率的目的。

07 工作流程

接下来我们简单看一下YARN的整个工作过程，如图2-13所示。

用户向YARN中提交应用程序。
ResourceManager为该应用程找到一个可用的NodeManager并分配第一个Container，然后在这个Container中启动应用程序的ApplicationMaster。
ApplicationMaster向ResourceManager进行注册，这样用户就可以通过ResourceManager查看应用程序的运行状态并对任务进行监控。
ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
ApplicationMaster申请到资源后与对应的NodeManager通信，要求它启动Container并为任务设置好运行环境。
应用程序的任务开始在启动的Container中运行，各个任务向ApplicationMaster汇报自己的状态和进度，以便ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
应用在运行的过程中，客户端通过轮询的方式主动与ApplicationMaster通信以获得应用的运行状态、执行进度等信息。
应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。