Hadoop 之 YARN 的内部机制

前面两篇文章，我们介绍了 Hadoop 里两个重要的组件MapReduce和HDFS。本文我们一起看一下，作为大数据业内用的比较普遍的 YARN 的内部机制。

Hadoop 1.x 和 2.x 的设计对比

首先让我们从总体上看一下 Hadoop 1.x 和 2.x 设计的不同之处。

从 Hadoop V1 和 V2 的总体设计对比上，可以明显看到几个变化:

• 增加了 YARN 组件。

• 1.x 的 Map Reduce 将资源的管理调度和数据的处理计算进行了拆解，仅保留了数据处理计算的功能，而用 YARN 来进行集群的资源管理和调度工作。

• 平台能够支持除了 MapReduce 以外的其他计算框架，比如 Spark, Flink 等的计算任务。

为什么会出现 YARN?

那么是什么样的原因在 Hadoop 2.x 里引入 YARN 这个如今这么受欢迎的组件呢？接下来，我们从更细的架构及工作机制来了解一下背后的故事。

旧版 MapReduceV1 架构

在 MapReduceV1，采用的是经典的 Master-Slave 架构，可参考下图。

在架构图中存储和计算部署在一个集群里，其中 Master 机器上有 JobTracker 和 NameNode，而 Slave 机器上有 TaskTracker 和 DataNode。其中关于存储部分 NameNode 和 DataNode 在HDFS文章上有介绍，这里就不再赘述。

MapReduceV1 里计算部分由两个重要组件JobTracker和TaskTracker组件:

• JobTracker 职责

* 集群里大脑的角色。

* 负责集群的资源的管理和数据处理任务的调度。

* 负责任务分配与管理: 任务的分发、状态监控、重启等。

• TaskTracker 职责

* 协助 JobTracker 的工作，具体数据处理任务执行的实体。

* 从 JobTracker 处领取要执行的任务。

* 向 JobTracker 发送 heartbeat 汇报机器的资源状态和任务执行情况。

旧版 MapReduceV1 存在什么样的问题？

从上面 V1 架构图来看，整体的 Master-Slave 工作模式还是比较简单清晰，Hadoop 在发布之初也得到业内的快速认可。但随着时间的推移，越来越多的问题凸显出来。

用一个大家熟悉的场景来比喻的话，V1 里的 JobTracker 类似于一个公司的老板，而 TaskTracker 就好比公司里具体干活的每一个员工。在 V1 里，老板需要事无巨细的了解人力资源使用情况，为公司接的每个项目分配人力、需要做所有项目的管理工作、并且需要了解每个项目里每个参与的员工具体的工作执行情况: 进度，是否需要换人等等。另外，公司员工可以做的工作的工种也比较单一，只能做 Map 或者 Reduce 两类工作。

当公司规模比较小的时候，比如刚刚创业时只有几十人时，老板作为这个公司的大脑层，跟的这么细还能承受住。但是当公司越做越大时，比如膨胀到几千人以后，如果老板还需要每天都了解具体每一项小工作的执行情况，肯定会累的吐血....这也是当时总结出来的 V1 最多只能支持 4000 节点的集群规模上限。

总结一下 MapReduceV1 存在的问题:

• JobTracker 是单点瓶颈及故障，负担太重。

• 只支持 Map、Reduce 两类计算 task 类型，和 Hadoop 本身的框架耦合比较重，无法支持其他的计算类型，复用性较差。

• 资源划分是按 Map Slot、Reduce Slot 进行划分，没有考虑 Memory 和 Cpu 的使用情况，资源利用有问题（容易 OOM 或者资源浪费）。

新组件 YARN 的架构

为了解决上面的问题，Hadoop 在 2.x 里重新做了设计，引入新的组件 YARN(Yet Another Resource Negotiator)。其中最重要的变化是把 V1 里 JobTracker 职责资源管理调度和数据计算任务管理两部分进行了拆分，YARN 主要用来负责资源管理调度，与具体的计算任务无关。而2.x里的 MapReduce 只负责 Hadoop 相关的数据处理和计算等相关工作。YARN 组件的出现，极大提升了 Hadoop 组件的复用性，能够很容易支持其他计算框架的任务。

我们具体看一下 YARN 的架构:

YARN 的组件介绍

Resource Manager

职责: 拥有整个集群资源的全局 or 上帝视角，主要负责整个集群的所有应用程序的资源调度，并不负责每个应用程序执行状态的管理。

Resource Manager包含的重要组件:

• ApplicationManager

* 职责: 负责接受客户端或者服务端应用的请求，为应用分配第一个 container ApplicationMaster，并负责监控 ApplicationMaster 的状态，启动及失败重启等操作。

• Scheduler

* 职责: 一个单纯的资源调度服务。根据应用程序需要的资源请求以及集群的资源情况，为应用程序分配对应的资源。并不关心应用本身的执行情况。

* 分类:

* FIFO Scheduler: 先进先出，不考虑应用程序本身的优先级和资源使用情况

* Capacity Scheduler: 将资源分成队列，共享集群资源但需要保证队列的最小资源使用需求

* Fair Scheduler: 公平的将资源分给应用，保证应用使用的资源是均衡的。

Container

概念: YARN 里最小的一组分配的资源粒度，目前主要是针对 CPU 和 Memory 的资源分配。

所有的 MapReduce 任务和其他分布式任务都是跑在 Container 里。

Node Manager

职责:

• 负责监控本机的资源和健康情况，与 Resource Manager 通信机器资源情况和心跳汇报。

• 负责监控并管理 Container 的生命周期

* 响应 Resource Manager 的请求创建 Container

* 监控 Container 的资源使用和健康情况，失败重启或者失控 Kill 等操作

• 不关心具体跑在 Container 里的任务情况。

ApplicationMaster

职责:

• 负责与 Resource Manager 和 Node Manager 沟通协调申请资源以及释放资源

• 负责整个应用的执行情况管理，监控/收集 task 执行进度结果，创建或者重启 task

YARN 的优势

在以上组件的介绍中，可以看到，基本每个组件都是各司其职，不再像 V1.0 里的 JobTracker 一样身上的担子太重成为整个集群的瓶颈。而资源调度组件与计算任务管理分开不再和 MapReduce 部分高度耦合，极大提升了资源调度组件的复用性，因此整个 YARN 的推广就更自然顺畅。因为不同的计算框架任务(Hadoop, Spark, Flink 等)都可以非常方便地由 YARN 来进行调度，只需任务对应的 Application Master 可以跑在 container 即可。

YARN 里应用执行流程

接下来，我们看一下客户端提交应用程序后，在 YARN 里整体执行情况:

① 客户端向 ResourceManager 提交应用请求

② ApplicationManager 为该应用向 NodeManager 申请第一个 Container，在里面创建应用的 ApplicationMaster 并监控其状态

③ ApplicationMaster 在 ApplicationManager 里注册自己

④ ApplicationMaster 向 Scheduler 申请自己需要的资源

⑤ 申请到资源后，ApplicationMaster 会去向对应的 NodeManager 要求创建对应需要的 Container

⑥ NodeManager 创建对应的 Container，并启动容器，运行相应的任务

⑦ 各个容器向 ApplicationMaster 汇报任务执行进度和状态，便于 ApplicationMaster 掌握应用执行情况进行管理(重启 or Kill)

⑧ 任务执行完毕或者失败后，ApplicationMaster 会向 ResourceManager 汇报状态，注销自己并释放资源

YARN 的 HA

YARN 是通过ResourceManager主备双活+Zookeeper锁节点方式来保证 HA 的，是一种常见的 HA 机制，这里不再赘述。稍需要注意的是，ResourceManager 的相关的作业信息是存放在 Zookeeper 中。当发生主备切换时，新的 active 的 ResourceManager 会从 Zookeeper 中读取信息，然后再从 NodeManager 里收集到的机器资源情况，重新构建整体的集群资源情况。

Reference

• Hadoop文档
  

• YARN文档
  

• Hadoop之MapReduce内部机制
  

• Hadoop之HDFS内部机制
  

更多大数据相关分享，可在微信公众号搜索“数据元素”或扫描下方二维码。