Hadoop YARN 架构详解

通过对Hadoop1.0和2.0的架构对比，引出了YARN作为资源调度和管理器的作用。

1、YARN产生的背景

YARN是MRv1基础上演化而来的，克服了MRv1中的各种局限性。在正式的介绍YARN之前，我们先要了解MRv1的一些局限性，这可概括为以下几个方面：

扩展性差：在MRv1中，JobTracker同时兼备了资源管理和作业控制两个功能，这个成为系统的一个最大瓶颈，严重制约了Hadoop集群的扩展性。
可靠性差：MRv1采用的master/slaver结构，其中master节点存在单点故障问题，一旦它出现故障将导致整个集群不可用。
资源利用率低：MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源。此外，Hadoop将槽位分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另一种闲置（比如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置）。
无法支持多种计算框架。

2、什么是YARN？

YARN实际上是一个弹性计算平台，它的目标已经不再局限于支持MapReduce一种计算框架了，而是朝着对多种框架进行统一管理的方向发展。YARN的基本思想是将资源管理和作业调度/监视的功能拆分为单独的守护程序。拥有一个全局的ResourceManager（RM）和每个应用程序的ApplicationMaster（AM）。应用程序可以是单个作业，也可以是作业的DAG。

image-20191117175429041

image-20191117175447804

3、YARN的作用是什么？

3.1、Hadoop v1.0的方式

在Hadoop v1.0的框架中，对数据的处理、资源调度主要依赖MapReduce完成，具体过程如下所示：

image-20191117175531487

从以上图中，我们可以了解到Hadoop v1.0的数据处理方式。在小规模的数据处理过程中，这套方法没有太大问题。但是，在真实的场景中往往需要处理大量数据，这套方法便会遇到以下问题：

由于大量的数据处理Job提交给Job Tracker，且Job Tracker需要协调的Data Node可能有数千台，Job Tracker极易成为整个系统的性能、可用的瓶颈。
无法有效地调配资源，导致资源分配不均。如以下例子，假设有3台Data Node（DN），每个DN的内存为4GB。用户提交了6个Job，每个Job需要1GB内存进行处理，且数据均在DN2上。由于DN2只有4GB内存，所以Job1-4在DN2上运行，Job5和6则在排队等待。但是，此时DN1和3均在闲置的状态下，而未能有效的被利用。

image-20191117175553600

3.2、YARN的方式

基于上述问题，Hadoop在2.0版本上推出了YARN (Yet Another Resource Negotiator)。YARN的核心思想是将资源管理和Job的调度/监控进行分离。YARN的架构如下图所示。

image-20191117175612400

image-20191117175634723

YARN的核心组件可以分为两大部分：

全局组件

Resource Manager（RM）: 作为全局统一的资源管理、调度、分配。Resource Manager由Scheduler（调度器：本质上是一种策略）和Applicatio Manager（应用程序管理器，ASM：负责管理Client用户提交的应用）组成。Scheduler根据节点的容量、队列情况，为Application分配资源；Application Manager接受用户提交的请求，在节点中启动Application Master，并监控Application Master的状态、进行必要的重启。
Node Manager（NM）: 在每一个节点上都有一个Node Manager作为代理监控节点的资源使用情况（cpu, memory, disk, network）并向Resource Manager上报节点状态。

Per-applicaiton组件

Application Master（AM）: 负责数据处理job的执行调度。Application Master与Resource Manager进行沟通，获取资源进行计算。得到资源后，与节点上的Node Manager进行沟通，在分配的Container汇总执行任务，并监控任务执行的情况。（每当 Client 提交一个 Application 时候，就会新建一个 ApplicationMaster 。由这个 ApplicationMaster 去与 ResourceManager 申请容器资源，获得资源后会将要运行的程序发送到容器上启动，然后进行分布式计算。）
Container: 资源的一种抽象方式，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当Application Master向Resource Manager申请资源时，Resource Manager为Application Master返回的资源便是Container。

当YARN接受用户提交的Job时，其工作过程为：

image-20191117175658829

YARN通过以下方式，解决了上述问题。

通过Application Master来解决Job Tracker的瓶颈问题。每当新的job提交进来后，Resource Manager会在恰当的节点启动一个新的Application Master，从而避免在Hadoop v1.0中Job Tracker成为性能瓶颈的尴尬。
更有效的进行资源的调度。Resource Manager可以为Application Master分配空余的资源，帮忙Application Master完成任务。
支持MapReduce以外的数据处理方式，例如：Spark等。

4、YARN和其他的资源管理器的对比

即便Hadoop v2.0应用来YARN的设计思路，也仍有一个难题：当大量的job提交、用尽所有计算资源后，新的job要等待很久才能被处理，即便新的job是非常重要的任务，也只能等待。在YARN中，通过scheduler plugin（例如：FIFO Scheduler、Fair Scheduler、Capacity Scheduler）的方式，配置不同的资源调度规则，来尽量缓解该问题，让重要的job可以优先获得资源调配。

5、参考资料

https://www.jianshu.com/p/952d59b7cbe7

https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html