数据产品经理有必要了解的YARN

       本文是Hadoop组件之YARN的学习总结性文章。因本人非技术出身，所学均来源于网络，难免有不严谨甚至错误之处，恳请大家指正。

       上篇文章我们讲了MapReduce（后简称MR），我们这次要讲的YARN与MR有紧密相关的联系，甚至有很多人把MR2（即MapReduce version2 ）就认为是YARN,在我的理解中他们还是有区别的。所以本文主要来讲解两个方面：MR1、MR2、YARN三者有什么联系？以及YARN是什么？

YARN产生的背景

因MR1存在如下四个局限性：
1.可靠性差：MR1采用的master/slave结构（JobTracker即master），一旦master出现问题，那么整个MR1的集群不可用。
2.扩展性差：JobTracker同时兼备了资源管理和作业控制，当MR任务非常多的时候，会造成很大的内存开销，严重的制约了整个集群的可扩展性。（此处我没理解~有清楚的大佬评论区给解释解释）
3.资源利用率低：MR1采用了槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些闲置的资源。还将槽位分为Map slot与Reduce slot,并且这两种槽位资源不能共享，所以会经常发生一种槽位资源紧张，另外一种资源闲置，比如一个作业刚刚提交时只进行Map Task,而这时的Reduce slot闲置。非技术人员的我们可以简单的理解为：Map、Reduce任务的执行都需要计算机资源（CPU、GPU、磁盘等），且资源是固定的，而MR1采用了很粗糙的资源分配机制，导致集群的资源利用率很低下。举个例子来说明：假设某节点的资源为100，其接收了一个MapReduce的任务，为其分配了50的资源，然后又接收了一个MapReduce任务，也为其分配了50的资源。紧接着又接了一个MapReduce的任务（前面2个任务还在运行），其需要20的资源，但是目前所有资源都分配出去了，所以就需要等待前面的任务跑完，把资源释放后，这个任务才能获得资源。但是实际情况是前面2个任务并没有实际充分利用分给他们的50资源，可能分别会有10资源处于闲置状态。这就造成了资源的使用率低下，造成任务运算效率低。
4.无法支持多种计算框架：就是说MR1主要用于离线计算，但是随着互联网发展这种计算不能满足现实的应用需求，所以出现了一些新的计算框架比如内存计算框架（这种计算框架计算比较快，如上文也提到的Spark、Flink），但是MR1不支持多种计算框架并存。
所以Apache对其进行了改造升级，因此诞生了MR2及YARN。

MR1、MR2、YARN三者的联系

       MR1与MR2的区别是：MR1的资源管理与作业调度均是JobTracker来完成，而MR2则把资源管理这部分工作交给了YARN来完成，自己只需要完成作业调度即可。
       所以到这里，我们可以知道MR2需要借助YARN来完成资源调度，而MR1不需要借助外部就可自身的完成资源调度（但是效率低）。然后YARN是专门用来负责资源管理的系统，它的引入使得集群在利用率、资源统一管理等发面带来了巨大的好处，同时他不仅仅支持MapReduce这种框架也支持Spark、Storm、Tez等计算框架，所以在我们的第一篇文章中可以看到Hadoop生态体系图中有多个计算框架，这使得Hadoop支持的更多计算引擎，从而满足实际的业务需求。

YARN的初衷目的

       YARN作为一个通用的资源管理系统，其目标是将短作业（指可以在一定时间内完成并退出的任务，可能是秒/分/时等级别的任务。比如MapReduce任务、Spark任务）和长服务（指不出意外永久执行的应用程序，通常是一些在线服务）混合部署在一个集群中，并为他们提供统一的资源管理和调度功能。所以其根本目的就是提高集群资源利用率和解决服务自动化部署的问题。

YARN的基本架构

YARN的基本架构

       YARN总体上采用master/slave架构，其中，ResourceManager为master, NodeManager为slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务，由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。

       下面我们将对ResourceManager、ApplicationMaster、NodeManager做个简单的介绍：
ResourceManager：是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用管理器（Applications Manager）。

调度器（Scheduler）：调度器主要功能是根据资源容量，队列等方面的限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个应用程序。而资源的分配是按照Container进行分配的（Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，注意是动态的额，说明分给任务的资源不是一成不变的，而是根据整体资源情况及任务的情况来进行动态分配资源）。
应用管理器（Applications Manager）：负责管理整个系统中的所有应用程序。比如应用程序的提交、与调度器Scheduler）协商资源、启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等工作。

       结合YARN结构图及上文可以看出，ResourceManager对整个系统来说是非常重要的，并且在master/slave架构中充当了master角色。所以为了避免单个ResourceManager出现单点故障导致整个集群不可用，YARN引入主备ResourceManager实现了HA（高可用，即高性能集群），当Active ResourceManager出现故障时，Standby ResourceManager会通过ZooKeeper（一种分布式应用程序协调服务，简称ZK，在分布式系统中扮演着很重要的角色，后面会详细讲解）选举，自动提升为Active ResourceManager。
所以上图中的ResourceManager即是Active ResourceManager，而另外的一个Standby ResourceManager 没画出来，完整的架构图应该还有一个Standby ResourceManager ，和ZooKeeper。

ApplicationMaster：提交的每个应用程序中都会包含一个独立的ApplicationMaster，其主要功能包括：
1.与ResourceManager中的Scheduler协商以获取资源。
2.将得到的资源进一步分配给内部的任务。
3.用于告知NodeManage启动/停止任务。
4.监控所有任务的运行状态，并在任务运行失败时重新为任务申请资源以便重启任务。

NodeManager：是每个节点（即部署了这个服务的服务器或虚拟机）上的资源管理器，它会定时地向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态（这样ResourceManager才能知道整个集群的资源使用情况，实现通观全局的资源管理）。另一方面，它接收并处理来自ApplicationMaster的任务启动/停止等各种请求。在一个集群中，NodeManager通常存在多个，由于YARN内置了容错机制，单个NodeManager的故障不会对集群中的应用程序运行产生严重影响。

为了理解的更透彻，再顺便讲下Container
Container：是YARN中的基本资源分配单位，是对应用程序运行环境的抽象，并为应用程序提供资源隔离环境。它封装了多维度的资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，ResourceManager为ApplicationMaster返回的资源便是用Container表示的。YARN中每个任务均会对应一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MR1中的槽位，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。

接着对ResourceManager、ApplicationMaster、NodeManager、Container之间关系做个不是很严谨的总结（当然不懂或者不喜欢军事的朋友可以忽略，哈哈哈）：

       做一个国土边防的场景，目前需要对东部（台海区域）、西部（西藏区域）、南部（南海区域）、北部（内蒙东北区域）进行国土边防任务，假设分别由对应的东南西北战区负责。我们可以把ResourceManager当成一个后勤总指挥部（管理物资的，比如弹药武器装备等)，负责向各个战区分配资源。把ApplicationMaster看成每个战区的后勤负责人兼作战指挥部，主要负责指挥部队的作战和训练任务，及向后勤总指挥部要后勤资源并把获取的资源分配给各个部队。把NodeManager看成地方守卫部队，主要的责任是执行作战训练任务及向后勤总指挥部汇报物资使用情况（当然此处略微有些不合理，但是就这样认为吧）。
具体例子如下：
       东西南北部战区均担任着守卫国土的任务，但是2020年6月突然在西部发生了中印冲突，西部后勤负责人兼作战指挥部（ApplicationMaster）决定开展军事演习及边防任务（Job），然后根据演习及边防任务情况，向后勤总指挥部（ResourceManager）申请物资（资源）。申请通过后，后勤总指挥部（ResourceManager）向西部后勤负责人兼作战指挥部（ApplicationMaster）发了一个通知（Container），这个通知内告诉他可以使用多少物资。然后西部后勤负责人兼作战指挥部（ApplicationMaster）接到通知后，把这些资源分配给地方守卫部队（NodeManager），并告知你们可以进行进行演习任务了。接着地方守卫部队（NodeManager）开始执行演习任务并不停的告知后勤总指挥部（ResourceManager）分配给自己的物资使用情况。
       等到2021年2月时，中印边境问题得到缓解，但是美国佬又在台海及南海搞事。后勤总指挥部（ResourceManager）通观全局觉得西部战区暂时不需要使用这么资源，就把原来分配给西部战区的资源调度给东部战区、南部战区使用。就是在这种后勤资源有限的情况下，通过后勤总指挥部（ResourceManager）的全局统筹及西部后勤负责人兼作战指挥部（ApplicationMaster）与地方守卫部队（NodeManager）的及时配合，使得后勤物资的被高效的利用，对整个国土边防做出了重大贡献。

YARN的工作流程

YARN的工作流程

1）提交应用程序：用户通过客户端与YARN ResourceManager通信，以提交应用程序，应用程序中需包含ApplicationMaster可执行代码、启动命令和资源需求、应用程序可执行代码和资源需求、优先级、提交到的队列等信息。
2）启动ApplicationMaster：ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster，之后ApplicationMaster的生命周期直接被ResourceManager管理。
3）ApplicationMaster注册：ApplicationMaster启动后，首先，向ResourceManager注册，这样，用户可以直接通过ResourceManage查看应用程序的运行状态，然后，它将初始化应用程序，并按照一定的策略为内部任务申请资源，监控它们的运行状态，直到运行结束，即重复步骤4～7。
4）资源获取：ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
5）请求启动Container：一旦ApplicationMaster申请到资源后，则与对应的NodeManager通信，请求为其启动任务（NodeManager会将任务放到Container中）。
6）启动Container：NodeManager为任务设置好运行环境（包括环境变量、jar包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过ContainerExecutor运行该脚本启动任务。
7）Container监控：ApplicationMaster可通过两种方式获取各个Container的运行状态，以便在任务失败时重新启动任务：
       ❑ ApplicationMaster与ResourceManager间维护了周期性心跳信息，每次通信可获取自己分管的Container的运行状态。
       ❑ 各个Container可通过某个RPC协议向ApplicationMaster汇报自己的状态和进度（视具体应用程序而定，比如MapReduce和YARN均实现了该方式）。
8）注销ApplicationMaster：应用程序运行完成后，ApplicationMaster向ResourceManager注销，并退出执行。

参考资料：《大数据技术体系详解：原理、架构与实践》 作者：董西成

传送门
Hadoop系列文章（一）数据产品经理有必要了解的Hadoop
Hadoop系列文章（二）数据产品经理有必要了解的HDFS
Hadoop系列文章（三）数据产品经理有必要了解的MapReduce