YARN原理简介

1 YARN产生的背景

（1）MapReduce1.0问题

      ①扩展性受限：JobTracker对任务进行调度，也对资源进行分配，承受的访问压力大，影响系统的扩展性。
      ②JobTracker单点故障问题：如果Hadoop集群的JobTracker挂掉，则整个分布式集群都不能使用了。
      ③不支持MapReduce之外的计算框架，比如Storm、Spark、Flink等。
（2）资源利用率
      由于Haddop1.X版本不支持其他框架的作业，所以导致了我们需要根据不同的框架搭建多个集群。当多个集群同时运行的时候，多个集群会导致服务环境比较复杂，可能出现下图的情况：不同的框架不仅需要搭建不同的集群，而且这些集群很多时候并不是总是在工作，从下图可以看到，Hadoop集群在忙的时候Spark就比较闲，Spark集群比较忙的时候Hadoop集群就比较闲，而MPI集群则是整体并不是很忙。这样就无法高效的利用资源，因为这些不同的集群无法互相使用资源。除此之外，在不同的集群中，文件系统是无法共享的。当需要将Hadoop集群上的HDFS里存储的数据传输到Spark集群上进行计算时，还会耗费相当大的网络IO流量。

（3）运维成本与数据共享
      ①运维成本：如果白用“一个框架一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本，而共享模式通常需要少数管理员即可完成多个框架的统一管理。
      ②数据共享：随着数据量的暴增，跨集群的数据移动不仅需要花费更长的时间，并且，硬件成本也会大大增加，而共享集群模式可让多重框架共享数据和硬件资源，将大大减小数据移动带来的成本。
      综合以上各种各样的问题，才使得YARN得以诞生。

2 YARN的基本构成与资源调度

2.1 YARN的概述

      YARN 是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。ARN是从0.23.0版本开始新引入的资源管理系统，直接从MR1（0.20.x、0.21.x、0.22.x）演化而来，其核心思想：将MapReduce1中JobTracker的资源管理和作业调用两个功能分开，分别由ResourceManager和ApplicationMaster进程来实现：
      （1）ResourceManager：负责整个集群的资源管理和调度；
      （2）ApplicationMaster：负责应用程序相关事务，比如任务调度、任务监控和容错等。

2.2 YARN基本架构

      （1）客户端联系ResourceManager，要求它运行一个ApplicationMaster进程；
      （2）ResourceManager找到一个能够在Container中启动ApplicationMaster的NodeManager。启动NodeManager和Application Master；
      （3）ApplicationMaster通过心跳机制向ResourceManager申请Container（容器可以理解为资源：内存和CPU等），ResourceManager分配Container给ApplicationMaster；
      （4）ApplicationMaster启动能够在Container中启动的NodeManager；
      （5）NodeManager启动相应的Task。

2.2.1 ResourceManager（资源管理器）

      整个集群只有一个，负责集群资源的统一管理和调度。ResourceManager将各个资源部分（计算、内存、带宽等）精心安排给基础NodeManager（YARN 的每节点代理）。ResourceManager还与ApplicationMaster一起分配资源，与NodeManager一起启动和监视它们的基础应用程序。
      功能：①处理客户端请求；②启动/监控ApplicationMaster；③监控NodeManager；④资源分配与调度。

2.2.2 NodeManager

      整个集群有多个，负责单节点资源管理和使用。NodeManager 提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。
      功能：①单个节点上的资源管理和任务管理；②处理来自ResourceManager的命令；③处理来自ApplicationMaster的命令。

2.2.3 ApplicationMaster

      每个应用有一个，负责应用程序的管理。ApplicationMaster负责协调来自 ResourceManager的资源，并通过 NodeManager监视容器的执行和资源使用（CPU、内存等的资源分配）。请注意，尽管目前的资源更加传统（CPU、内存），但未来会带来基于手头任务的新资源类型（比如图形处理单元或专用处理设备）。
      功能：①数据切分；②为应用程序申请资源，并进一步分配给内部任务；③任务监控与容错。

2.2.4 Container

      对任务运行环境的抽象。Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，ResourceManager为ApplicationMaster返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
      用它来描述一系列信息：①任务运行环境（节点、内存和CPU）；②任务启动命令；③任务运行环境。

2.3 YARN容错性

（1）ResourceManager
      ①存在单点故障；
      ②正在基于Zookeeper实现HA。
（2）NodeManager
      ①失败后，ResourceManager将失败任务告诉对应的ApplicationMaster；
      ②ApplicationMaster决定如何处理失败的任务。
（3）ApplicationMaster
      ①失败后，由ResourceManager负责重新启动；
      ②ApplicationMaster需处理内部任务的容错问题；

2.4 YARN调度框架

（1）双层调度框架
      ①ResourceManager将资源分配给ApplicationMaster；
      ②ApplicationMaster将资源进一步给各个Task.
（2）基于资源预留的调度策略
      ①资源不够时，会为Task预留，直到资源充足，可能出现一直等一个任务运行，降低了运行效率；
      ②不会预留资源，满足哪个任务就运行哪个任务，可能出现一个任务长期得不到响应。

2.5YARN资源调度器

      YARN 中有三种调度器可用: FIFO 调度器(FIFO Scheduler) ，容量调度器(Capacity Scheduler)和公平调度器(Fair Scheduler)。
      在一个共享集群中，更适合使用容量调度器或公平调度器。这两种调度器都允许长时间运行的作业能及时完成，同时也允许正在进行较小临时查询的用户能够在合理时间内得到返回结果。

2.5.1FIFO调度器

      FIFO 调度器将应用放置在一个队列中，然后按照提交的顺序(先进先出)运行应用。FIFO 调度器的优点是，简单易懂，不需要任何配置，但是不适合共享集群。大的应用会占用集群中的所有资源，所以每个应用必须等待直到轮到自己运行。
      从下图中可以看出：当使用F IFO 调度器(i)时，小作业一直被阻塞，直至大作业完成。

2.5.2容量调度器

      容量调度器允许多个组织共享一个Hadoop集群，每个组织可以分配到全部集群资源的一部分。每个组织被配置一个专门的队列，每个队列被配置为可以使用一定的集群资源。队列可以进一步按层次划分，这样每个组织内的不同用户能够共享该组织队列所分配的资源。在一个队列内，使用FIFO 调度策略对应用进行调度。
      使用容量调度器时(ii) ，一个独立的专门队列保证小作业一提交就可以启动，由于队列容量是为那个队列中的作业所保留的，因此这种策略是以整个集群的利用率为代价的。这意味着与使用FIFO调度器相比，大作业执行的时间要长（只是分配一些资源给大作业，而不是像FIFO那样将全部资源给大作业）。
      弹性队列：单个作业使用的资源不会超过其队列容量。然而，如果队列中有多个作业，并且队列资源不够用了呢?这时如果仍有可用的空闲资源，那么容量调度器可能会将空余的资源分配给队列中的作业，哪怕这会超出队列容量。
      正常操作时，容量调度器不会通过强行中止来抢占容器(container)。如果一个队列一开始资源够用，然后随着需求增长，资源开始不够用肘，那么这个队列就只能等着其他队列释放容器资源。缓解这种情况的方法是，为队列设置一个最大容量限制，这样这个队列就不会过多侵占其他队列的容量了。
      队列层次结构：

      在root 队列下定义两个队列: prod 和dev， dev 队列进一步被划分成eng 和science 两个队列。如果队列不存在，则在提交时会发送错误。如果不指定队列，那么应用将被放在一个名为default的默认队列。

2.5.3公平调度器

      公平调度器旨在为所有运行的应用公平分配资源。想象两个用户A和B，分别拥有自己的队列(参见下图) A启动一个作业，在B没有需求时A会分配到全部可用资源；当A的作业仍在运行时B启动一个作业，一段时间后，按照我们先前看到的方式，每个作业都用到了一半的集群资源。这时，如果B启动第二个作业且其他作业仍在运行，那么第二个作业将和B的其他作业(这里是第一个)共享资源，因此B的每个作业将占用四分之一的集群资源，而A仍继续占用一半的集群资源。最终的结果就是资源在用户之间实现了公平共享。
      队列放置规则
      第一条规则，specified，表示把应用放进所指明的队列中，如果没有指明，或如果所指明的队列不存在，则规则不匹配，继续尝试下一条规则。primaryGroup规则会试着把应用放在以用户的主Unix组名命名的队列中，如果没有这样的队列，则继续尝试下一条规则而不是创建队列。Default规则是一条兜底规则，当前述规则都不匹配时，将启用该条规则，把应用放进dev.eng队列中。
      抢占：允许调度器终止那些占用资源超过了其公平共享份额的队列的容器，这些容器资源释放后可以分配给资源数量低于应得份额的队列。注意，抢占会降低整个集群的效率，因为被终止的containers 需要重新执行。

2.5.4延迟调度

      在一个繁忙的集群上，如果一个应用请求某个节点，那么极有可能此时有其他容器正在该节点上运行。显而易见的处理是，立刻放宽本地性需求，在同一机架中分配一个容器。然而，通过实践发现，此时如果等待一小段时间(不超过几秒) ，能够戏剧性的增加在所请求的节点上分配到一个容器的机会，从而可以提高集群的效率。这个特性称之为延迟调度(delay scheduling)。容量调度器和公平调度器都支持延迟调度。
      YARN 中的每个节点管理器周期性地(默认每秒一次)向资源管理器发送心跳请求。心跳中携带了节点管理器中正运行的容器、新容器可用的资源等信息，这样对于一个计划运行一个容器的应用而言，每个心跳就是一个潜在的调度机会(scheduling opportunity) 。当使用延迟调度时，调度器不会简单的使用它收到的第一个调度机会，而是等待设定的最大数目的调度机会发生，然后才放松本地性限制并接收下一个调度机会。
      对于容量调度器和公平调度器，都是设置调度机会的数量来决定延迟时间。

2.5.5主导资源公平性

      主导公平性：如果一个用户的应用对CPU 的需求量很大，但对内存的需求量很少；而另一个用户需要很少的CPU，但对内存需求量很大，此时观察每个用户的主导资源，并将其作为对集群资源使用的一个度量。
      想象一个总共有100个CPU和10TB的集群。应用A 请求的每份容器资源为2个CPU 和300GB内存，应用B请求的每份容器资源为6个CPU和100GB内存。A 请求的资源在集群资源中占比分别为2%和3%，由于内存占比(3%)大于CPU占比(2%)，所以内存是A 的主导资源。B 请求的资源在集群资源中占比分别为6%和1%，所以CPU 是B 的主导资源。由于B申请的资源是A的两倍(6% vs3%) ，所以在公平调度下，B将分到总的容器数的1/2，A将获得总的容器数的1/4。

3YARN优点

（1）可扩展性
      与MapReduce 1相比，YARN可以在更大规模的集群上运行。当节点数达到4000，任务数达到40000时，MapReduce 1会遇到可扩展性瓶颈，瓶颈源自于JobTracker 必须同时管理作业和任务这样一个事实。YARN利用其资源管理器和ApplicationMaster分离的架构优点克服了这个局限性，可以扩展到面向将近10000个节点和100000个任务。
（2）可用性
      当服务守护进程失败时，通过为另一个守护进程复制接管工作所需的状态以便其继续提供服务，从而可以获得高可用性。然而，jobtracke内存中大量快速变化的复杂状态(例如，每个任务状态每几秒会更新一次)使得改进JobTracker服务获得高可用性非常困难。
      YARN将资源管理器和ApplicationMaster取代了JobTracker，就可以通过分而治之的思想：先为资源管理器提供高可用性，再为YARN 应用(针对每个应用)提供高可用性。
（3）利用率(UtiI ization)
      MapReduce 1中，每个tasktracker都配置有若干固定长度的slot，这些slot 是静态分配的，在配置的时候就被划分为map slot 和reduce s lot 。一个map slot仅能用于运行一个map 任务，同样，一个reduce slot 仅能用于运行一个reduce 任务。
      YARN 中，一个节点管理器管理一个资源地，而不是指定的固定数目的slot。YARN 上运行的MapReduce 不会出现由于集群中仅有map slot 可用导致reduce任务必须等待的情况，而MapReduce 1会有这样的问题。
      YARN中的资源是精细化管理的，这样一个应用能够按需请求资源，而不是请求一个不可分割的、对于特定的任务而言可能会太大(浪费资源)或太小(可能会导致失败)的slot。
（4）多租户(Multitenancy)
      YARN 的最大优点在于向MapReduce 以外的其他类型的分布式应用开放了Hadoop。
      用户甚至可以在同一个YARN 集群上运行不同版本的MapReduce，这使得升级MapReduce的过程更好管理。(注意，MapReduce的一些部件，例如作业历史服务器和shuftle 句柄，和YARN自身一样，仍然需要在集群范围内升级。)

参考文章：
[1]《Hadoop权威指南》
[2] https://www.cnblogs.com/t1314/p/9630262.html
[3] https://www.cnblogs.com/cxzdy/p/5494929.html