MapReduce 1.0 的缺陷
MapReduce 1.0采用Master/Slave架构设计，包括一个JobTracker和若干个TaskTracker，前者负责作业的调度和资源的管理，后者负责执行JobTracker指派的具体任务。这种架构设计具有一些缺陷，具体如下：
- 存在单点故障
MapReduce 1.0由JobTracker负责所有MapReduce作业的调度，而系统中只有一个JobTracker，因此会存在单点故障问题，即这个唯一的JobTracker出现故障就会导致系统不可用。
- JobTracker任务过重
JobTracker即要负责作业的调度和失败恢复，又要负责资源管理分配。JobTracker执行过多的任务，需要消耗大量的资源，例如当存在非常多的MapReduce任务时，JobTracker需要巨大的内存开销，这也潜在地增加了JobTracker失败的风险。正因如此，业内普遍总结出MapReduce 1.0支持主机数目的上限为4000个。
- 容易出现内存溢出
在TaskTracker端，资源的分配并不考虑CPU、内存的实际使用情况，而只是根据MapReduce任务的个数来分配资源。当两个具有较大内存消耗的任务被分配到同一个TaskTracker上时，很容易发生内存溢出的情况。
- 资源划分不合理
资源被强制等量划分成多个槽(Slot)，槽又被进一步划分为Map槽和Reduce槽两种，分别提供Map和Reduce任务使用，彼此之间不能使用分配给对方的槽。也就是说，当Map任务已经用完Map槽时，即使系统中还有大量剩余的Reduce槽，也不能拿来运行Map任务，反之亦然。这就意味着，当系统中只存在单一Map任务或Reduce任务时，会造成资源的浪费。
YARN设计思路
为了克服MapReduce 1.0 版本的缺陷，在Hadoop 2.0以后的版本中对其核心子项目MapReduce 1.0的体系结构进行了重新设计，生成了MapReduce 2.0和YARN。
YARN架构设计思路如图，基本思路就是“放权”，即不让JobTracker这一组件承担过多的功能，对原JobTracker三大功能（资源管理、任务调度和任务监控）进行拆分，分别交给不同的新组件去处理。重新设计后得的YARN包括ResourceManager、ApplicationMaster和NodeManager，其中，由ResourceManager负责资源管理，由ApplicationMaster负责任务调度和监控，由NodeManager负责执行原TaskTracker的任务。
在Hadoop 1.0中，其核心子项目MapReduce 1.0即是一个计算框架，也是一个资源管理调度框架。到了Hadoop 2.0以后，MapReduce 1.0中的资源管理调度功能被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架；而被剥离了资源管理调度功能的MapReduce框架就变成了MapReduce 2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务。
YAAN体系结构
YARN体系结构中包含了3个组件：ResourceManager、ApplicationMaster和NodeManager。
YARN各个组件的功能
| 组件 | 功能 |
| ResourceManager | 处理客户请求 启动/监控ApplicationMaster 监控NodeManager 资源分配与调度 |
| ApplicationMaster | 为应用程序申请资源，并分配给内部任务 任务调度、监控与容错 |
| NodeManager | 单个节点上的资源管理 处理来自ResourceManager的命令 处理来自ApplicationMaster的命令 |
资源管理器
资源管理器（ResourceManager,RM）负责整个系统的资源管理和分配，主要包括两个组件，即资源管理调度器（Resource Scheduler）和应用程序管理器（Applications Manager）。
资源调度器
资源调度器（Resource Scheduler）主要负责资源管理和分配。资源调度器接收来自ApplicationMaster的应用程序资源请求，并根据容量、队列等限制条件，把集群中的资源以“容器”（Container）的形式分配给提出申请的应用程序。容器的选择通常会考虑应用程序所要处理的数据的位置，就近进行选择，从而实现“计算向数据靠拢”。在MapReduce 1.0中，资源分配的单位是“槽”，而在YARN中是以容器作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量。同时，在YARN中调度器被设计成一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器。
应用程序管理器
应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，主要包括应用程序提交、与资源调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。
ApplicationMaster
ApplicationMaster的主要功能是：
（1）当用户作业提交时，ApplicationMaster与ResourceManager协商获取资源，ResourceManager会以容器的形式为AplicationMaster分配资源；
（2）把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配”；
（3）与NodeManager保持交互通信，进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，监控所有任务的执行进行和状态，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；
（4）定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息；
（5）当作业完成时，ApplicatoinMaster向ResourceManager注销窗口，执行周期完成。
NodeManager
NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责容器生命周期管理，监控每个容器的资源（CPU、内存等）使用情况，跟踪节点健康状况，并以“心跳”的方式与ResourceManager保持通信，向ResourceManager汇报作业的资源使用情况和每个容器的运行状态，同时，它还要接收来自ApplicationMaster的启动/停止容器的各种请求。需要说明的是，NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理，因为这些管理工作是由ApplicationMaster完成的，ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态。
在集群部署方面，YARN的各个组件是和Hadoop集群中的其他组件统一部署的。
YARN工作流程
在YARN框架中执行一个MapReduce程序时，从提交到完成需要经历如下8个步骤：
（1）用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
（2）YARN中的ResourceManager负责接收和处理来自客户端的请求。接到客户端应用程序请求后，ResourceManager里面的调度器（Resource Scheduler）会为应用程序分配一个容器。同时，ResourceManager的应用程序管理器（Applications Manager）会与该容器所在的NodeManager通信，为该应用程序在该容器中启动一个ApplicationMaster（图中MR App Mstr）。
（3）ApplicationMaster被创建后会首先向ResourceManager注册，从而使得用户可以通过ResourceManager来直接查看应用程序的运行状态。
（4）ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请资源。
（5）ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源，一旦ApplicationMaster申请到资源，就会与该容器所在的NodeManager进行通信，要求它启动任务。
（6）当ApplicaitonMaster要求容器启动任务时，它会为任务设置好运行环境，然后将任务启动命令写到一个脚本中，最后通过在容器中运行该脚本来启动任务。
（7）各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，让ApplicationMaster可以随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
（8）应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。若ApplicationMaster因故失败，ResourceManager中的应用程序管理器会监测到失败的情形，然后将其重新启动，直到所有的任务执行完毕。
YARN框架与MapReduce 1.0框架的对比
从MapReduce 1.0框架发展到YARN框架，客户端并没有发生变化，其大部分调用API及接口都保持兼容。因此，原来针对Hadoop 1.0开发的代码不用做大的改动，就可以直接在Hadoop 2.0平台上运行。
在MapReduce 1.0框架中的JobTracker和TaskTracker，在YARN框架中变成了3个组件，即ResourceManager、ApplicationMaster和NodeManager。ResourceManager主要负责调度、启动每一个作业所属的ApplicationMaster，监控ApplicationMaster运行状态并在失败时重新启动，而作业里面的不同任务的调度、监控、重启等，不再由ResourceManager负责，而是交给与该作业相关联的ApplicationMaster来负责。ApplicationMaster要负责一个作业生命周期内的所有工作。也就是说，它承担了MapReduce 1.0中的JobTracker的“作业监控”功能。
总体而言，YARN相对MapReduce 1.0具有以下优势：
（1）大大减少了承担中心服务功能的ResourceManager的资源消耗
（2）MapReduce 1.0即是一个计算框架，又是一个资源管理调度框架，但是它只能支持MapReduce编程模型。而YARN是一个纯粹的资源调度管理框架，在它上面可以运行包括MapReduce在内的不同类型的计算框架，默认类型是MapReduce。
（3）YARN中的资源管理比MapReduce 1.0更加高效。YARN以容器为单位进行资源管理和分配，而不是以槽为单位，避免了MapReduce 1.0中槽的闲置浪费情况，大大提高了资源的利用率。
YARN的发展目标
YARN的目标就是实现“一个集群多个框架”，即在一个集群上部署一个统一的资源调度管理框架YARN，在YARN之上可以部署各种计算框架。或发展成为集群中统一的资源管理调度框架，在一个集群中为上层的各种计算框架提供统一的资源管理调度服务。
通过这种方式，可以实现一个集群上的不同应用负载混搭，有效提高集群的利用率。同时，不同计算框架可以共享底层存储，在一个集群上集成多个数据集，使用多个计算框架来访问这些数据集，从而避免了数据集跨集群移动。最后，这种部署方式大大降低了企业运维成本。
YARN的HA方案
YARN中的ResourceManager负责整个集群的资源管理和任务调度，YARN高可用方案通过引入冗余的ResourceManager节点的方式，解决了ResourceManager单点故障问题。
YARN资源管理
每个NodeManager可分配的内存和CPU的数量可以通过配置选项设置(可在Yarn服务配置页面配置)
- yarn.nodemanager.resource.memory. mb:可以分配给容器的物理内存的大小
- yarn.nodemanager.vmem pmem-ratio:虚拟内存跟物理内存的比值
- yarn.nodemanager.resource.cpu vcore:可分配给容器的CPU核数
在Hadoop3.x版本中，YARN资源模型已被推广为支持用户自定义的可数资源类型( support user- defined countable resource types)，而不是仅仅支持CPU和内存。
- 常见的可数资源类型，除了CPU和Memory以外，还包括GPU资源、软件licenses或本 地附加存储器( lally-attached storage )之类的资源，但不包括端口(Port)和标签(Labels)。
YARN的三种资源调度器
在Yarn中，负责给应用分配资源的叫做Scheduler (调度器)。在YARN中，根据不同的策略，共有三种调度器可供选择: .
- FIFO Scheduler:把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配,以此类推。
- Capacity Scheduler: 允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，通过设置多个队列的方式给多个组织提供服务。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了。在一个队列内部，资源的调度是采用的是FIFO策略。
- Fair Scheduler:为所有的应用分配公平的资源(对公平的定义可以通过参数来设置)。
容量调度器Capacity Scheduler
容量调度器使得Hadoop应用能够共享的、多用户的、操作简便的运行在集群上，同时最大化集群的吞吐量和利用率。
容量调度器以队列为单位划分资源，每个队列都有资源使用的下限和上限。每个用户可以设定资源使用上限。管理员可以约束单个队列、用户或作业的资源使用。支持作业优先级，但不支持资源抢占。
在Hadoop 3.x中，OrgQueue 扩展了容量调度器，通过REST API 提供了以编程的方式来改变队列的配置。这样，管理员可以在队列的administer_ queue ACL中自动进行队列配置管理。
资源分配模型
调度器维护一群队列的信息。用户可以向一个或者多个队列提交应用。
每次NM心跳的时候，调度器根据一定的规则选择一个队列，再在队列上选择一个应用，尝试在这个应用上分配资源。
调度器会优先匹配本地资源的申请请求，其次是同机架的，最后是任意机器的。
