Yarn架构介绍
Yarn/MRv2最基本的想法是将原JobTracker主要的资源管理和job调度/监视功能分开作为两个单独的守护进程。有一个全局的ResourceManager(RM)和每个Application有一个ApplicationMaster(AM),Application相当于map-reduce job或者DAG jobs。ResourceManager和NodeManager(NM)组成了基本的数据计算框架。ResourceManager协调集群的资源使用，任何client或者运行着的applicationMaster想要运行job或者task都得向RM申请一定的资源。ApplicationMaster是一个框架特殊的库，对于MapReduce框架而言，它有自己的AM实现，用户也可以自己实现AM，在运行的时候，AM会与NM一起来启动和监视tasks。
ResourceManager
ResourceManager作为资源的协调者有两个主要的组件：Scheduler和ApplicationManager(AsM)。
YARN基本服务组件
基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。
YARN总体上仍然是master/slave结构，在整个资源管理框架中，resourcemanager为master，nodemanager是slave。Resourcemanager负责对各个nodemanager上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster,它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。
YARN基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件构成。
ResourceManager是Master上一个独立运行的进程，负责集群统一的资源管理、调度、分配等;NodeManager是Slave上一个独立运行的进程，负责上报节点的状态；App Master和Container是运行在Slave上的组件，Container是yarn中分配资源的一个单位，包涵内存、CPU等资源，yarn以Container为单位分配资源。
Client向ResourceManager提交的每一个应用程序都必须有一个ApplicationMaster,它经过ResourceManager分配资源后，运行于某一个Slave节点的Container中，具体做事情的Task，同样也运行于某一个Slave节点的Container中。RM,NM,AM乃至普通的Container之间的通信，都是用RPC机制。
YARN的架构设计实际类似一个操作系统。
1、ResourceManager
RM是一个全局的资源管理器，集群里只有一个，负责整个系统的资源管理和分配，包括处理客户端请求、启动/监控APP master、监控nodemanager、资源的分配与调度。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager,AsM）。
（1）调度器
调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度咄咄逼人是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动国应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container,简称Contrainer）表示，Container是一个动态资源分配单位，它将内存、cpu、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Schduler等。
（2）应用程序管理
应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交，与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。
2、ApplicationMaster(AM)
管理YARN内运行的应用程序的每个实例。
功能：
数据切分
为应用程序申请资源并进一步分配给内部任务。
任务监控与容错
负责协调来自resourcemanager的资源，并通过nodemanager监视任务的执行和资源使用情况。
3、NodeManager(NM)
Nodemanager整个集群有多个，负责每个节点上的资源和使用。
功能：
单个节点上的资源管理和任务。
处理来自于resourcemanager的命令。
处理来自域app master的命令。？？？
NodeManager管理着抽象容器，这些抽象容器代表着一些特定程序使用针对每个节点的资源。
NodeManager定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态（cpu和内存等资源）
4、Container
Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MRv1中的slot，它是一个动态的资源划分单位，是根据应用程序的需求动态生成的。目前为止，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离。
功能：
对task环境的抽象
描述一系列信息
任务运行资源的集合（cpu、内存、io等）
任务运行环境
二、YARN的资源管理
1、资源调度和隔离是yarn作为一个资源管理系统，最重要且最基础的两个功能。资源调度由resourcemanager完成，而资源隔离由各个nodemanager实现。
2、ResourceManager将某个nodemanager上资源分配给任务（这就是所谓的“资源调度”）后，nodemanager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础和保证，这就是所谓的资源隔离。
3、当谈及到资源时，我们通常指内存、cpu、io有一种资源。Hadoop yarn目前为止仅支持cpu和内存两种资源管理和调度。
4、内存资源多少决定任务的生死，如果内存不够，任务可能运行失败；相比之下，cpu资源则不同，它只会决定任务的快慢，不会对任务的生死产生影响。
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