Year的资源管理模型
在实际系统中，资源本身是多维度的，包括CPU、内存、网络I/O和磁盘I/O等，因此，如果想精确控制资源分配，不能再有slot的概念，最直接的方法就是是让任务直接向调度器申请自己需要的资源（比如某个任务可申请1GB 内存和1个CPU），而调度器则按照任务实际需求为其精细地分配对应的资源量，不再简单的将一个Slot分配给它，Hadoop 2.0正式采用了这种基于真实资源量的资源分配方案。
Hadoop 2.0最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度/监控分成两个独立的进程。全局的ResourceManager（RM）和与每个应用相关的ApplicationMaster（AM）。
YARN架构设计
ResourceManager(RM)：负责对各NM上的资源进行统一管理和调度。对AM申请的资源请求分配相应的空闲Container。将AM分配空闲的Container运行并监控其运行状态。主要由两个组件构成：调度器和应用程序管理器。
调度器(Scheduler)：调度器根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是Container，从而限定每个任务使用的资源量。Shceduler不负责监控或者跟踪应用程序的状态，也不负责任务因为各种原因而需要的重启（由ApplicationMaster负责）。
调度器是可插拔的，例如CapacityScheduler、FairScheduler。
应用程序管理器(Applications Manager)：应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动AM、监控AM运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。
NodeManager(NM)：NM是每个节点上的资源和任务管理器。它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时会接收并处理来自AM的Container 启动/停止等请求。
ApplicationMaster(AM)：用户提交的应用程序均包含一个AM，负责应用的监控，跟踪应用执行状态，重启失败任务等。AM是应用框架，它负责向RM协调资源，并且与NM协同工作完成Task的执行和监控。MapReduce就是原生支持的一种框架，可以在YARN上运行Mapreduce作业。有很多分布式应用都开发了对应的应用程序框架，用于在YARN上运行任务，例如Spark，Storm等。
Container：是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container 表示的。YARN会为每个任务分配一个Container且该任务只能使用该Container中描述的资源。
YARN工作流程(MapReduce提交应用程序)
1）用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动AM的命令、用户程序等。
2）ResourceManager为该应用程序分配第一个Container，并与对应的Node Manager通信，要求它在这个Container中启动应用程序的AM。
3）AM首先向RM注册，这样用户可以直接通过RM查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
4）AM采用轮询的方式通过RPC协议向RM申请和领取资源。
5）一旦AM申请到资源后，便与对应的NM通信，要求它启动任务。
6）NM为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
7）各个任务通过某个RPC协议向AM汇报自己的状态和进度，以让AM随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向AM查询应用程序的当前运行状态。
8）应用程序运行完成后，AM向RM注销并关闭自己。
当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：第一个阶段是启动AM；第二个阶段是由AM创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。
YARN的资源管理与调优
ResourceManager将某个NodeManager上资源分配给任务（资源调度）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证（资源隔离）。
内存资源
1）yarn.nodemanager.resource.memory-mb 该节点上YARN可使用的物理内存总量：
假设我的这个节点上的内存有48G，其中25%是要给Linux的，而剩余的75%给大数据进程。其中，一般把DN和NM放置在同一个机器上(数据本地化)。默认的DN是给到4个G，而NM是给到3个G。（这两个参数分别是在hadoop-env.sh和yarn-env.sh两个shell脚本当中设置)。
我们的contanier最多也就可以用29个G了， yarn.nodemanager.resource.memory-mb，当这个参数设置成剩余全部内存时意味着我们的NM在执行tasks的时候可以使用到29个G。
2）yarn.scheduler.minimum-allocation-mb 单个任务可申请的最少物理内存量：
一个contnaier最小将分配多少的G，我们生产上一般是设置成2个G，要是机器上剩余的内存达不到2个G，就不再在这个机器上开启container。
3）yarn.scheduler.maximum-allocation-mb 单个任务可申请的最多物理内存量
当一个container开启以后，在上面放置的task不是一下子就使用到最大内存极限的，一般会先个2个G(就是最小内存限制)，如果不够了就是继续增加，直到最大内存限制，还不够就报错。所以最大内存设置一般和整个节点的contanier可用内存设置是一样大。
4.2. CPU资源
vcore：虚拟cpu，yarn自己引入的新概念，因为不同的物理core的性能不同，所以为了每个core的计算能力能一致点，这个时候设置了一个vcore。一般1个物理core对应2个vcore，也有公司是1:1的。
cpu同样也有三组参数：
yarn.nodemanager.resource.cpu-vcores
yarn.scheduler.minimum-allocation-vcores
yarn.scheduler.maximum-allocation-vcores
三组默认值分别是8，1，8。假如物理core是8个话，要考虑究竟要个多少个core给大数据使用。如果是给了6个core预留2个core给其他进程，这样的vcore将有12个。
在Yarn中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，FairScheduler。
FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个 先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
从图中可以看出，在FIFO 调度器中，小任务会被大任务阻塞。
而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
调度器的使用是通过yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class参数进行配置的，默认采用Capacity Scheduler调度器。如果我们要使用Fair调度器，需要在这个参数上配置FairScheduler类的全限定名： org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。