What - Yarn
YARN是Hadoop 2.0中的资源管理系统，它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。
Why - Yarn
随着互联网的高速发展，新的计算框架不断出现，如内存计算框架、流式计算框架、迭代计算资源框架、这几种框架通常都会被用到考虑到资源的利用率运维和数据共享等因素，企业通常希望将所有的计算框架部署到一个 公共集群中，让他们共享集群的计算资源，并对资源进行同意使用，同时又能采用简单的资源隔离方案，这样便催生了轻量弹性计算平台需求Yarn的设计是一个弹性计算平台，不仅仅支持Mapreduce计算框架而是朝着对多种计算框架进行统一管理方向发展。
优点:
- 资源利利用率高，按照框架角度进行资源划分，往往存在应用程序数据和计算资源需求的不均衡性，使得某段时间内计算资源紧张，而另外一种计算方式的资源空闲，共享集群模式则通过框架共享全部的计算资源，使得集群中的资源更加充分合理的利用。
- 运维成本低，如果使用：”一个框架一个集群“的模式，运维人员需要独立管理多个框架，进而增加运维的难度，共享模式通常只需要少数管理员可以完成多个框架的管理。
- 数据共享，随着数据量的增加，跨集群之间的数据不仅增加了硬件成本，而且耗费时间，共享集群模式可以共享框架和硬件资源，大大降低了数据移动带来的成本。
How - Yarn
yarn是内置在Hadoop平台中的，所以在已经搭建好的Hadoop集群中就可以直接使用。对于其他计算框架，在配置文档配置后即可使用，例如spark的任务提交方式在生产环境中，一定是要用yarn方式来提交，例如：
spark-submit –master yarn –class com.xx.xx.classname spark_job_name.jar
Yarn - 组成
YARN总体上仍然是master/slave结构，在整个资源管理框架中，resourcemanager为master，nodemanager是slave。Resourcemanager负责对各个nademanger上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。
YARN的基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件构成。
ResourceManager是Master上一个独立运行的进程，负责集群统一的资源管理、调度、分配等等；
NodeManager是Slave上一个独立运行的进程，负责上报节点的状态；
App Master和Container是运行在Slave上的组件，Container是yarn中分配资源的一个单位，包涵内存、CPU等等资源，yarn以Container为单位分配资源。
Client向ResourceManager提交的每一个应用程序都必须有一个Application Master，它经过ResourceManager分配资源后，运行于某一个Slave节点的Container中，具体做事情的Task，同样也运行与某一个Slave节点的Container中。RM，NM，AM乃至普通的Container之间的通信，都是用RPC机制。
YARN的架构设计使其越来越像是一个云操作系统，数据处理操作系统。
Yarn - 架构
- Resourcemanager
RM是一个全局的资源管理器，集群只有一个，负责整个系统的资源管理和分配，包括处理客户端请求、启动/监控APP master、监控nodemanager、资源的分配与调度。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。
- 调度器（Scheduler）
调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。
- 应用程序管理器（Applications Manager，ASM）
应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。
- ApplicationMaster（AM）
** **
管理YARN内运行的应用程序的每个实例。
功能：
- 数据切分
- 为应用程序申请资源并进一步分配给内部任务。
- 任务监控与容错
- 负责协调来自resourcemanager的资源，并通过nodemanager监视容易的执行和资源使用情况。
- NodeManager（NM）
Nodemanager整个集群有多个，负责每个节点上的资源和使用。
功能：
- 单个节点上的资源管理和任务。
- 处理来自于resourcemanager的命令。
- 处理来自域app master的命令。
- Nodemanager管理着抽象容器，这些抽象容器代表着一些特定程序使用针对每个节点的资源。
- Nodemanager定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态（cpu和内存等资源）
Container
Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。目前为止，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离。
功能：
- 对task环境的抽象
- 描述一系列信息
- 任务运行资源的集合（cpu、内存、io等）
- 任务运行环境
Yarn - 资源管理
- 资源调度和隔离是yarn作为一个资源管理系统，最重要且最基础的两个功能。资源调度由resourcemanager完成，而资源隔离由各个nodemanager实现。
- Resourcemanager将某个nodemanager上资源分配给任务（这就是所谓的“资源调度”）后，nodemanager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础和保证，这就是所谓的资源隔离。
- 当谈及到资源时，我们通常指内存、cpu、io三种资源。Hadoop yarn目前为止仅支持cpu和内存两种资源管理和调度。
- 内存资源多少决定任务的生死，如果内存不够，任务可能运行失败；相比之下，cpu资源则不同，它只会决定任务的快慢，不会对任务的生死产生影响。
#### Yarn - 队列调度策略
Yarn的队列调度策略主要分三种：FIFO、Capacity调度、Fair调度。
- FIFO调度策略：为先进去的任务分配资源，后入的任务等待前面任务完成才能获得资源。(大任务可能导致后续任务饿死)
- Capacity调度策略：将集群资源分为一条条队列，每个队列包含一定百分比资源。每个队列中任务采取FIFO的调度策略。在某些队列资源宽裕的情况下，允许跨队列申请资源，同时允许抢占机制。当其他队列任务使用了当前队列任务资源时，当前队列任务在等待一定时间后，允许抢占该队列资源(将改队列内不属于其他队列任务的Container杀死)。
- Fair调度策略：n个任务情况下，每个任务占据1/n份额的资源。在某任务结束后，该任务资源会被其余资源瓜分，每个任务占据1/(n-1)份资源。与Capacity一样也将集群分为队列且允许抢占机制。不同的是队列内部的资源调度同时允许FIFO和Fair调度。
Yarn - 内存管理
yarn允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上内存会被若干个服务共享，比如一部分给了yarn，一部分给了hdfs，一部分给了hbase等，yarn配置的只是自己可用的，配置参数如下：
- yarn.nodemanager.resource.memory-mb
表示该节点上yarn可以使用的物理内存总量，默认是8192m，注意，如果你的节点内存资源不够8g，则需要调减这个值，yarn不会智能的探测节点物理内存总量。
- yarn.nodemanager.vmem-pmem-ratio
任务使用1m物理内存最多可以使用虚拟内存量，默认是2.1
- yarn.nodemanager.pmem-check-enabled
是否启用一个线程检查每个任务证使用的物理内存量，如果任务超出了分配值，则直接将其kill，默认是true。
- yarn.nodemanager.vmem-check-enabled
是否启用一个线程检查每个任务证使用的虚拟内存量，如果任务超出了分配值，则直接将其kill，默认是true。
- yarn.scheduler.minimum-allocation-mb
单个任务可以使用最小物理内存量，默认1024m，如果一个任务申请物理内存量少于该值，则该对应值改为这个数。
- yarn.scheduler.maximum-allocation-mb
单个任务可以申请的最多的内存量，默认8192m
Yarn - cpu管理
目前cpu被划分为虚拟cpu，这里的虚拟cpu是yarn自己引入的概念，初衷是考虑到不同节点cpu性能可能不同，每个cpu具有计算能力也是不一样的，比如，某个物理cpu计算能力可能是另外一个物理cpu的2倍，这时候，你可以通过为第一个物理cpu多配置几个虚拟cpu弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟cpu个数。在yarn中，cpu相关配置参数如下：
- yarn.nodemanager.resource.cpu-vcores
表示该节点上yarn可使用的虚拟cpu个数，默认是8个，注意，目前推荐将该值为与物理cpu核数相同。如果你的节点cpu合数不够8个，则需要调减小这个值，而yarn不会智能的探测节点物理cpu总数。
- yarn.scheduler.minimum-allocation-vcores
单个任务可申请最小cpu个数，默认1，如果一个任务申请的cpu个数少于该数，则该对应值被修改为这个数
- yarn.scheduler.maximum-allocation-vcores
单个任务可以申请最多虚拟cpu个数，默认是32.
