YARN知识梳理，巩固基础

初识YARN

针对MapReduce 1.0在可用性、可扩展性、资源利用率、框架支持等方面的不足，对MapReduce 1.0的架构进行了重新设计，提出了全新的资源管理和调度框架YARN。YARN是Hadoop 2.0的资源管理和调度框架，是一个通用的资源管理系统，在其上可以部署各种计算框架，它可为上层应用提供统一的资源管理和调度，它的引入为集群高可用性、可扩展性、资源利用率和数据共享等方面带来了很大好处。

MapReduce 1.0存在的问题在Hadoop 1.0中

1. MapReduce采用Master/Slave架构，有两类守护进程控制作业的执行过程，即一个JobTracker和多个TaskTracker。JobTracker负责资源管理和作业调度；TaskTracker定期向JobTracker汇报本节点的健康状况、资源使用情况、任务执行情况以及接受来自JobTracker的命令并执行。

2. 随着集群规模负载的增加，MapReduce JobTracker在内存消耗、扩展性、可靠性、性能等方面暴露出各种缺点，具体包括以下几个方面。

（1）单点故障问题。JobTracker只有一个，它负责所有MapReduce作业的调度，若这个唯一的JobTracker出现故障就会导致整个集群不可用。
（2）可扩展性瓶颈。业内普遍总结出当节点数达到4000，任务数达到40000时，MapReduce 1.0会遇到可扩展性瓶颈，这是由于JobTracker“大包大揽”任务过重，既要负责作业的调度和失败恢复，又要负责资源的管理分配。当执行过多的任务时，需要巨大的内存开销，这也潜在增加了JobTracker失败的风险。
（3）资源划分不合理。资源（CPU、内存）被强制等量划分为多个Slot，每个TaskTracker都配置有若干固定长度的Slot，这些Slot是静态分配的，在配置的时候就被划分为Map Slot和Reduce Slot，且Map Slot仅能用于运行一个Map任务，Reduce Slot仅能用于运行一个Reduce任务，彼此之间不能使用分配给对方的Slot。这意味着，当集群中只存在单一Map任务或Reduce任务时，会造成资源的极大浪费。
（4）仅支持MapReduce一个计算框架。MapReduce是一个基于Map和Reduce、适合批处理、基于磁盘的计算框架，不能解决所有场景问题，而一个集群仅支持一个计算框架，不支持其他类型的计算框架如Spark、Storm等，造成集群多、管理复杂，且各个集群不能共享资源，造成集群间资源浪费。

YARN简介

（1）为了解决MapReduce 1.0存在的问题，Hadoop 2.0以后版本对其核心子项目MapReduce的体系架构进行了重新设计，生成了MRv2和YARN。
（2）YARN设计的基本思路就是“放权”，即不让JobTracker承担过多功能，把MapReduce 1.0中JobTracker，分别交给不同的新组件承担。重新设计后得到的YARN包括ResourceManager、ApplicationMaster和NodeManager，其中，ResourceManager负责资源管理ApplicationMaster负责任务调度和任务监控NodeManager负责承担原TaskTracker功能，且原资源被划分的Slot重新设计为容器Container，NodeManager能够启动和监控容器Container。另外，原JobTracker也负责存储已完成作业的作业历史，此功能也可以运行一个作业历史服务器作为一个独立守护进程来取代JobTracker，YARN中与之等价的角色是时间轴服务器Timeline Server。
（3）总之，Hadoop 1.0中，MapReduce既是一个计算框架，又是一个资源管理和调度框架，到了Hadoop 2.0以后，MapReduce中资源管理和调度功能被单独分割出来形成YARN，YARN是一个纯粹的资源管理调度框架，而被剥离了资源管理调度功能的MapReduce变成了MRv2，MRv2是运行在YARN上的一个纯粹的计算框架。
（4）从MapReduce 1.0发展到YARN，客户端并没有发生变化，其大部分API及接口都保持兼容，因此，原来针对Hadoop 1.0开发的代码不需做大的改动，就可以直接放在Hadoop 2.0平台上运行。

YARN与MapReduce 1.0相比优势

（1）可扩展性（Scalability）

与MapReduce 1.0相比，YARN可以在更大规模的集群上运行。当节点数达到4000、任务数达到40000时，MapReduce 1.0会遇到可扩展性瓶颈，瓶颈来源于JobTracker负载过重，既要负责作业的调度和失败恢复，又要负责资源的管理分配。YARN利用ResourceManager和ApplicationMaster分离的架构优点克服了这个局限性，可以扩展到将近10000个节点和100000个任务。另外，YARN Federation联邦机制进一步增强了集群水平横向扩展性。
（2）可用性（Availability）

当守护进程失败时，通常需要另一个守护进程复制接管工作所需的状态以便其继续提供服务，从而可以获得高可用性（High Available）。但是，由于MapReduce 1.0中JobTracker内存中存在大量快速变化的复杂状态，使得改进JobTracker以使其获得高可用性非常困难。

YARN对MapReduce 1.0的体系架构进行了重新设计，ResourceManager和ApplicationMaster分别承担MapReduce 1.0中JobTracker的功能，那么高可用的服务随之称为一个分而治之的问题：先为ResourceManager提供高可用性，再为YARN应用提供高可用性。YARN的ResourceManager HA特性通过Active/Standby ResourceManager保证了YARN高可用性，ResourceManager Restart特性保证了若ResourceManager发生单点故障，ResourceManager能尽快自动重启。

（3）利用率（Utilization）
MapReduce 1.0使用Slot表示各个节点上的计算资源，Slot分为Map Slot和Reduce Slot两种，且不允许共享。对于一个作业，刚开始运行时，Map Slot资源紧缺而Reduce Slot空闲，当Map Task全部运行完成后，Reduce slot紧缺而Map slot空闲。很明显，这种区分Slot类别的资源管理方案在一定程度上降低了Slot的利用率。同时，这种基于无类别Slot的资源划分方法的划分粒度过大，往往会造成节点资源利用率过高或者过低。

YARN中，一个NodeManager管理一个资源池，而不是指定固定数目的Slot。YARN上运行的MapReduce不会出现MapReduce 1.0中由于集群中只有Map Slot可用而导致Reduce Task必须等待的情况。如果能够获取运行任务的资源，那么应用程序就会正常进行。更进一步，YARN中的资源是精细化管理的，这样一个应用程序能够按需请求资源，而不是请求一个不可分割的、对于特定任务而言可能太大（浪费资源）或太小（可能导致失败）的Slot。

（4）多租户（Multitenancy）

在某种程度上可以说，YARN最大的优点是向MapReduce以外的其他分布式计算框架开放了Hadoop，MapReduce仅是许多YARN应用中的一个，Spark、Tez、Storm等计算框架也都可以运行在YARN上。另外，用户甚至可以在同一个YARN集群上运行不同版本的MapReduce，这使得升级MapReduce更好管理。

YARN体系架构

体系架构解释

1.YARN采用主从架构（Master/Slave），其核心组件包括三个：ResourceManager、NodeManager和ApplicationMaster。其中，ResourceManager是主进程，NodeManager是从进程，一个ResourceManager对应多个NodeManager，每个应用程序拥有一个ApplicationMaster。

2.YARN中引入了一个逻辑概念——容器Container，它将各类资源（如CPU、内存）抽象化，方便从节点NodeManager管理本机资源，主节点ResourceManager管理集群资源，如规定<1核，2G>为1个Container。

3.Client
Client向ResourceManager提交任务、终止任务等。

4 ResourceManager
整个集群只有一个ResourceManager，负责集群资源的统一管理和调度。具体承担功能包括：
（1）处理来自客户端请求，包括启动/终止应用程序。
（2）启动/监控ApplicationMaster，一旦某个ApplicationMaster出现故障，ResourceManager将会在另一个节点上启动该ApplicationMaster。
（3）监控NodeManager，接收NodeManager汇报的心跳信息并分配任务给NodeManager去执行，一旦某个NodeManager出现故障，标记该NodeManager的任务，来告诉对应的ApplicationMaster如何处理。

5.NodeManager
整个集群有多个NodeManager，负责单节点资源的管理和使用。具体承担功能包括：
（1）周期性向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态。
（2）接收并处理来自ResourceManager的Container启动/停止的各种命令。
（3）处理来自ApplicationMaster的命令。

6.ApplicationMaster
每个应用程序拥有一个ApplicationMaster，负责管理应用程序。具体承担功能包括：
（1）数据切分。
（2）为应用程序/作业向ResourceManager申请资源（Container），并分配给内部任务。
（3）与NodeManager通信，以启动/停止任务。
（4）任务监控和容错，在任务执行失败时重新为该任务申请资源并重启任务。
（5）接收并处理ResourceManager发出的命令，如终止Container、重启NodeManager等。

7.Container

Container是YARN中新引入的一个逻辑概念，是YARN对资源的抽象，是YARN中最重要的概
念之一。Container封装了某个节点上一定量的资源（CPU和内存两类资源），它与Linux Container没有任何关系，仅仅是YARN提出的一个概念。Container由ApplicationMaster向ResourceManager申请，由ResouceManager中的资源调度器异步分ApplicationMaster；Container的运行是由ApplicationMaster向资源所在的NodeManager发起的，Container运行时需提供内部执行的任务命（可以是任何命令，比如Java、Python、C++进程启动命令等）以及该命令执行所需的环境变量和外部资源（比如词典文件、可执行文件、jar包等）。

另外，一个应用程序所需的Container分为以下两大类：
•
（1）运行ApplicationMaster的Container：这是由ResourceManager和其内部的资源调度器
申请和启动的，用户提交应用程序时，可指定唯一的ApplicationMaster所需的资源。
•
（2）运行各类任务的Container：这是由ApplicationMaster向ResourceManager申请的，并由ApplicationMaster与NodeManager通信以启动之。该类Container上运行的任务类型可以是Map Task、Reduce Task或Spark Task等。
以上两类Container可能在任意节点上，它们的位置通常而言是随机的，即
ApplicationMaster可能与它管理的任务运行在一个节点上。