1．YARN产生背景
1.1 MapReduce本身存在的问题
- JobTracker单点故障问题；如果Hadoop集群的JobTracker挂掉，则整个分布式集群都不能使用了。
- JobTracker承受的访问压力大，影响系统的扩展性。
- 不支持MapReduce之外的计算框架，比如Storm、Spark、Flink等。
1.2 MRv1
- JobTracker：用户程序提交了一个Job，任务（job）会发给JobTracker，JobTracker是Map-Reduce框架中心，它负责把任务分解成map和reduce的作业（task）；需要与集群中的机器定时心跳(heartbeat)通信；需要管理那些程序应该跑在那些机器上；需要管理所有job失败、重启操作。
- Tasktracker是JobTracker和Task之间的桥梁，Tasktracker可以配置map和reduce的作业操(task slot)。TaskTracker通过心跳告知JobTracker自己还有空闲的作业Slot时，JobTrackr会向其分派任务。它将接收并执行JobTracker的各种命令:启动任务、提交任务、杀死任务。
- TaskScheduler工作再JobTracker上。根据JobTracker获得的slot信息完成具体的分配工作，TaskScheduler支持多种策略以提高集群工作效率。
- 局限性
- 扩展局限性：JobTracker同时要兼顾资源管理和作业控制的两个功能，成为系统的一个瓶颈，制约Hadoop集群计算能力的拓展。（4000节点任务数400000）
- MRv1采用master/slave结构，其中JobTracker作为计算管理的master存在单点问题，它容易出现故障整个MRv1不可用。
- 资源利用率局限。MRv1采用了基于作业槽位（slot）的资源分配模型，槽位时一个粗粒度的资源分配单位，通常一个作业不会用完槽位对应的物理资源，使得其他作业也无法再利用空闲资源。对于一些IO密集，CPU空闲,当作业槽占满之后其他CPU密集型的也无法使用集群。MRv1将槽分为Map和Reduce两种slot，且不允许他们之间共享，这样做会导致另一种槽位资源紧张，另外一种资源闲置。
- 无法支持多种计算框架，随着数据处理要求越来越精细，Mapreduce这种基于磁盘的离线计算框架已经满足不了各方需求，从而出现了新的计算框架，如内存计算框架、流式计算框架、迭代计算资源框架、而MRv1不支持多种计算框架并存。
2. 什么是YARN
2.1 YARN的概念
YARN是Hadoop2.0版本新引入的资源管理系统，直接从MR1演化而来。
核心思想：将MP1中JobTracker的资源管理和作业调度两个功能分开，分别由ResourceManager和ApplicationMaster进程来实现。
- ResourceManager：负责整个集群的资源管理和调度。
- ApplicationMaster：负责应用程序相关的事务，比如任务调度、任务监控和容错等。
YARN的出现，使得多个计算框架可以运行在一个集群当中。
- 每个应用程序对应一个ApplicationMaster。
- 目前可以支持多种计算框架运行在YARN上面比如MapReduce、Storm、Spark、Flink等。
2.2 优势
与旧MapReduce相比，YARN采用了一种分层的集群框架，具有以下几种优势。
- Hadoop2.0提出了HDFSFederation；它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展。对于运行中NameNode的单点故障，通过 NameNode热备方案（NameNode HA）实现 。
- YARN通过将资源管理和应用程序管理两部分剥离开来，分别由ResourceManager和ApplicationMaster进程来实现。其中，ResouceManager专管资源管理和调度，而ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等。
- YARN具有向后兼容性，用户在MR1上运行的作业，无需任何修改即可运行在YARN之上。
- 对于资源的表示以内存为单位（在目前版本的 Yarn 中没有考虑 CPU的占用），比之前以剩余 slot 数目为单位更合理。
- 支持多个框架，YARN不再是一个单纯的计算框架，而是一个框架管理器，用户可以将各种各样的计算框架移植到YARN之上，由YARN进行统一管理和资源分配，由于将现有框架移植到YARN之上需要一定的工作量，当前YARN仅可运行MapReduce这种离线计算框架。
- 框架升级容易，在YARN中，各种计算框架不再是作为一个服务部署到集群的各个节点上（比如MapReduce框架，不再需要部署JobTracker、 TaskTracker等服务），而是被封装成一个用户程序库（lib）存放在客户端，当需要对计算框架进行升级时，只需升级用户程序库即可。
3. YARN的基本架构
YARN采用了Master/Slave结构，在整个资源管理框架中ResourceManager为master，NodeManager为Slave。ResourceManager负责对各个 NodeManager上的资源进行统一的管理和调度，当用户提交一个应用程序时，需要生成以一个用于追踪和管理这个程序即ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定的资源任务，不同的ApplicationMaster会被分不到不同的节点上，他们之间是相互独立的。
3.1 ResourceManager
YARN分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager 将各个资源部分（计算、内存、带宽等）精心安排给基础NodeManager（YARN 的每节点代理）。ResourceManager还与 ApplicationMaster 一起分配资源，与NodeManager 一起启动和监视它们的基础应用程序。在此上下文中，ApplicationMaster 承担了以前的 TaskTracker 的一些角色，ResourceManager 承担了 JobTracker 的角色。
- 处理客户端请求；
- 启动或监控ApplicationMaster；
- 监控NodeManager；
- 资源的分配与调度。
3.2 NodeManager
NodeManager管理一个YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map和Reduce任务的执行，而NodeManager 管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。YARN继续使用HDFS层。它的主要 NameNode用于元数据服务，而DataNode用于分散在一个集群中的复制存储服务。
- 单个节点上的资源管理；
- 处理来自ResourceManager上的命令；
- 处理来自ApplicationMaster上的命令。
3.3 ApplicationMaster
ApplicationMaster管理一个在YARN内运行的应用程序的每个实例。ApplicationMaster 负责协调来自 ResourceManager 的资源，并通过 NodeManager 监视容器的执行和资源使用（CPU、内存等的资源分配）。请注意，尽管目前的资源更加传统（CPU 核心、内存），但未来会带来基于手头任务的新资源类型（比如图形处理单元或专用处理设备）。从 YARN 角度讲，ApplicationMaster 是用户代码，因此存在潜在的安全问题。YARN 假设 ApplicationMaster 存在错误或者甚至是恶意的，因此将它们当作无特权的代码对待。
- 负责数据的切分；
- 为应用程序申请资源并分配给内部的任务；
- 任务的监控与容错。
3.4 Container
对任务运行环境进行抽象，封装CPU、内存等多维度的资源以及环境变量、启动命令等任务运行相关的信息。比如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
要使用一个YARN集群，首先需要来自包含一个应用程序的客户的请求。ResourceManager 协商一个容器的必要资源，启动一个ApplicationMaster 来表示已提交的应用程序。通过使用一个资源请求协议，ApplicationMaster协商每个节点上供应用程序使用的资源容器。执行应用程序时，ApplicationMaster 监视容器直到完成。当应用程序完成时，ApplicationMaster 从 ResourceManager 注销其容器，执行周期就完成了。
4. YARN的原理
4.1 Yarn的工作流程
用户向YARN提交应用程序，其中还包含了ApplicationMaster程序，启动AM的命令，命令参数和用户程序等等；本步骤需要准确描述运行AplicationMaster的unixs进程的所有信息。通常由YarnClient完成。
Resource Manager为该应用程序分配一个Container，和对应的NameNode进行通信，要求他在Container中启动ApplicationMaster；
ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过RM查看程序的运行状态。然后它将为各个任务申请资源，并监控他的运行状态，知道运行结束，重复4~7；
ApplicationMaster采用轮询的方式通过RPC方式向ResourceManager申请和领取资源，资源的协调通过异步方式完成。
ApplicationMaster一旦申请资源后，便开始与对应的NodeManager通信，要求他们启动作业。
NodeManager为作业设置好运行环境（环境变量，jar包，二进制程序）将任务写道一个脚本中，并通过运行该脚本启动作业。
各个作业通过协议RPC方式向ApplicationMaster同步汇报自己当前的进度和状态，AM随时掌握各个作业的运行状态，从而在作业失败的时候重启作业。
应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭。
4.2 YARN资源模型
一个应用程序可以通过ApplicationMaster请求特定的资源需求来满足它的资源需要。调度器会被分配给一个Container来相应资源需求、用于满足ApplicationMaster在ResourceRequst中提出的要求。Container包含5类信息：优先级、期望资源所在节点、资源量、container数目、松弛本地性(是否没有满足本地资源时，选择机架本地资源)
ResourceRequst包含物种信息:
资源名称：期望所在的主机名、机架、用*表示没有特殊要求。
优先级： 程序内部请求的优先级，用来调整程序内部各个ResourceRequst的次序。
资源需求：需要的资源量，表示成内存里，CPU核数的元组(目前YARN仅支持内存和CPU两种资源)
container数：表示 需要container数量，它决定了用该ResourceRequst指定的Container总数。
是否松弛本地性：在本机架资源剩余量无法满足要求是改为只要运行在服务器所在的机架上进行就行。
本质上Container是一种资源分配的形式，是ResourceManager为ResourceRequst成功分配资源的结果。Container授予节点在机器上使用资源（如内存、CPU）的权利，YARN允许的不仅仅是Java的应用程序，概念上Container在YARN分配任务分为两层：第一层为ResourceManage调度器结果分配给用用程序ApplicationMaster，第二层，作为运行环境用ApplicationMaster分配给作业资源。
4.3 YARN的作业运行
4.3.1 作业提交
client调用job.waitForCompletion方法，向整个集群提交MapReduce作业 (第1步) 。 新的作业ID(应用ID)由资源管理器分配(第2步)。作业的client核实作业的输出, 计算输入的split,将作业的资源(包括Jar包, 配置文件, split信息)拷贝给HDFS(第3步)。最后, 通过调用资源管理器的submitApplication()来提交作业(第4步)。
4.3.2 作业初始化
当资源管理器收到submitApplication()的请求时, 就将该请求发给调度器(scheduler), 调度器分配container, 然后资源管理器在该container内启动应用管理器进程, 由节点管理器监控(第5a和5b步)。
MapReduce作业的应用管理器是一个主类为MRAppMaster的Java应用。其通过创造一些bookkeeping对象来监控作业的进度, 得到任务的进度和完成报告(第6步)。然后其通过分布式文件系统得到由客户端计算好的输入split(第7步)。然后为每个输入split创建一个map任务, 根据mapreduce.job.reduces创建reduce任务对象。
4.3.3 任务分配
如果作业很小，应用管理器会选择在其自己的JVM中运行任务。如果不是小作业, 那么应用管理器向资源管理器请求container来运行所有的map和reduce任务(第8步)。这些请求是通过心跳来传输的, 包括每个map任务的数据位置, 比如存放输入split的主机名和机架(rack)。调度器利用这些信息来调度任务, 尽量将任务分配给存储数据的节点, 或者退而分配给和存放输入split的节点相同机架的节点。
4.3.4 任务运行
当一个任务由资源管理器的调度分配给一个container后, 应用管理器通过联系节点管理器来启动container(第9a步和9b步)。任务由一个主类为YarnChild的Java应用执行。 在运行任务之前首先本地化任务需要的资源, 比如作业配置, JAR文件, 以及分布式缓存的所有文件(第10步)。最后, 运行map或reduce任务(第11步)。
YarnChild运行在一个专用的JVM中, 但是YARN不支持JVM重用。
4.3.5 进度和状态更新
YARN中的任务将其进度和状态（包括counter）返回给应用管理器，客户端每秒（通过mapreduce.client.progressmonitor.pollinterval设置）向应用管理器请求进度更新，展示给用户。
4.3.6作业完成
除了向应用管理器请求作业进度外，客户端每5分钟都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion. pollinterval来设置。作业完成之后, 应用管理器和container会清理工作状态, OutputCommiter的作业清理方法也会被调用。作业的信息会被作业历史服务器存储以备之后用户核查。
5. MapReduce on YARN
5.1 MapReduce on TARN
- YARN负责资源管理和调度；
- ApplicationMaster负责任务管理。
5.2 MapReduce ApplicationMaster
- MRAppMaster；
- 每个MapReduce启动一个MRAppMaster；
- MRAppMaster负责任务切分、任务调度、任务监控和容错。
5.3 MRAppMaster任务调度
- YARN将资源分配给MRAppMaster；
- MRAppMaster进一步将资源分配给内部任务。
5.4MRAppMaster容错
- MRAppMaster运行失败后，由YARN重新启动；
- 任务运行失败后，由YARN重新申请资源。
6. YARN HA（高可用）
ResourceManager由一对分别处于Active和Standby状态的ResourceManager组成，它使用基于Zookeeper的选举算法来决定ResourceManager的状态。其中，ZKFC仅为ResourceManager的一个进程服务，不是单独存在的（区别于HDFS，它是独立存在的进程），负责监控ResourceManager的健康状况并定期向Zookeeper发送心跳。ResourceManager通过RMStateStore（目前有基于内存的、基于文件系统的和基于Zookeeper的等，此处使用后者）来存储内部数据、主要应用数据和标记等。
7. YARN 中的调度
7.1 FIFO
简单易懂，不需要任何配置(FIFO Scheduler),容量调度器(Capcity Scheduler)和公平调度器（Fair Scheduler）。FIFO调度器将应用放置在一个队列中然后按照提交的顺序(先进先出)运行应用，首先为队列中的第一个任务请求分配资源。第一个应用的请求被满足后再一次为队列的下一条进行服务。
7.2 Capacity
一个独立的专门队列保证小作业提交就可以启动，由于队列容量是为了那个队列中的作业所保留的。这意味这与使用FIFO调度器相比，大作业执行的事件要长。容量调度器允许多个组织共享一个Hadoop集群，每个组织可以分配到全部集群资源的一部分。每个组织都被配置一个专门的队列，每个队列都被配置为可以使用一定的集群资源。队列可以进一步按层次划分，这样每个组织内的不同用户能够共享该组织队列所分配的资源。在一个队列内，使用FIFO调度政策对应用进行调度。单个作业使用的资源不会超过其队列容量然而，如果队列中由多个作业，并且队列资源不够用，如果仍有可用的空闲资源，那么容量调度器可能会被空余的资源分配给队列的作业，哪怕这超出队列容量。这称之为为“弹性队列”。
7.3 Fair
Fair调度器是一个队列资源分配方式，在整个时间线上，所有的Job平均的获取资源。默认情况下，Fair调度器知识对内存资源做公平的调度和分配。当集群中只有一个任务运行时，那么此任务会占用整个集群的资源。当其他的任务提交后，那些释放的资源就会被分配给新的Job，所以每个任务最终都能够获取几乎一样多的资源。