YARN产生背景
Hadoop1.x中的MapReduce构成图如下：
在Hadoop1.x中MapReduce是Master/Slave结构，在集群中的表现形式为：1个JobTracker带多个TaskTracker；
JobTracker：负责资源管理和作业调度；
TaskTracker：定期向JobTracker汇报本节点的健康状况、资源使用情况以及任务的执行情况；接收来自JobTracker的命令（启动/杀死任务等）并执行接收到的命令;
1、MapReduce1.0存在的问题：
1）单点故障：JobTracker只有一个，JobTracker挂了整个集群就没办法使用了；
2）JobTracker负责接收来自各个JobTracker节点的RPC请求，压力会很大，限制了集群的扩展；随着节点规模增大之后，JobTracker就成为一个瓶颈；
3）仅支持MapReduce计算框架；
MapReduce计算框架是一个基于Map和Reduce两阶段、适合批处理的、基于磁盘的计算框架；
MapReduce计算框架优点：容错性好；
MapReduce计算框架缺点：性能差；
2、资源利用率
在没有YARN之前，是一个集群一个计算框架。比如：Hadoop一个集群、Spark一个集群、HBase一个集群......
造成各个集群管理复杂，资源的利用率很低；比如：在某个时间段内Hadoop集群忙而Spark集群闲着，反之亦然，各个集群之间不能共享资源造成集群间资源并不能充分利用；
解决思路：
将所有的计算框架运行在一个集群中，共享一个集群的资源，按需分配；Hadoop需要资源就将资源分配给Hadoop，Spark需要资源就将资源分配给Spark，进而整个集群中的资源利用率就高于多个小集群的资源利用率；
3、运维成本
采用“一个框架一个集群”的模式，则需要多个管理员管理这些集群，进而增加运维成本；
而共享集群模式通常需要少数管理员即可完成多个框架的统一管理;
4、数据共享
随着数据量的暴增，跨集群间的数据移动不仅需要花费更长的时间，且硬件成本也会大大增加；
而共享集群模式可让多种框架共享数据和硬件资源,将大大减少数据移动带来的成本;
总结：
1) 源于MRv1的缺陷：扩展性受限、单点故障、难以支持MR之外的计算框架；
2) 多计算框架各自为战，数据共享困难，资源利用率低；
MR: 离线计算框架
Storm：实时计算框架
Spark：内存计算框架
催生了YARN的产生。
YARN基本构成
Master/Slave结构，1个ResourceManager对应多个NodeManager；
YARN由Client、ResourceManager、NodeManager、ApplicationMaster组成；
Client向ResourceManager提交任务、杀死任务等；
ApplicationMaster由对应的应用程序完成；每个应用程序对应一个ApplicationMaster，ApplicationMaster向ResourceManager申请资源用于在NodeManager上启动相应的Task；
NodeManager向ResourceManager通过心跳信息：汇报NodeManager健康状况、任务执行状况、领取任务等；
ResourceManager：整个集群只有一个，负责集群资源的统一管理和调度
1）处理来自客户端的请求（启动/杀死应用程序）；
2）启动/监控ApplicationMaster；一旦某个AM挂了之后，RM将会在另外一个节点上启动该AM；
3）监控NodeManager，接收NodeManager的心跳汇报信息并分配任务到NodeManager去执行；一旦某个NM挂了，标志下该NM上的任务，来告诉对应的AM如何处理；
4）负责整个集群的资源分配和调度；
NodeManager：整个集群中有多个，负责单节点资源管理和使用
1）周期性向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态；
2）接收并处理来自ResourceManager的Container启动/停止的各种命令；
3）处理来自ApplicationMaster的命令；
4）负责单个节点上的资源管理和任务调度；
ApplicationMaster：每个应用一个，负责应用程序的管理
1）数据切分；
2）为应用程序/作业向ResourceManager申请资源(Container)，并分配给内部任务；
3）与NodeManager通信以启动/停止任务；
4）任务监控和容错（在任务执行失败时重新为该任务申请资源以重启任务）；
5）处理ResourceManager发过来的命令：杀死Container、让NodeManager重启等；
Container
对任务运行环境的抽象；
1）任务运行资源（节点、内存、CPU）；
2）任务启动命令；
3）任务运行环境；
任务是运行在Container中，一个Container中既可以运行ApplicationMaster也可以运行具体的Map/Reduce/MPI/Spark Task；
YARN工作原理
1）用户向YARN中提交应用程序/作业，其中包括ApplicaitonMaster程序、启动ApplicationMaster的命令、用户程序等；
2）ResourceManager为作业分配第一个Container，并与对应的NodeManager通信，要求它在这个Containter中启动该作业的ApplicationMaster；
3）ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查询作业的运行状态；然后它将为各个任务申请资源并监控任务的运行状态，直到运行结束。即重复步骤4-7；
4）ApplicationMaster采用轮询的方式通过RPC请求向ResourceManager申请和领取资源；
5）一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；
6）NodeManager启动任务；
7）各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicaitonMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；
在作业运行过程中，用户可随时通过RPC向ApplicationMaster查询作业当前运行状态；
8）作业完成后，ApplicationMaster向ResourceManager注销并关闭自己；
YARN容错性
1、ResourceMananger
基于ZooKeeper实现HA避免单点故障；
2、NodeManager
执行失败后，ResourceManager将失败任务告诉对应的ApplicationMaster；
由ApplicationMaster决定如何处理失败的任务；
3、ApplicationMaster
执行失败后，由ResourceManager负责重启；
ApplicationMaster需处理内部任务的容错问题；
RMAppMaster会保存已经运行完成的Task，重启后无需重新运行。
YARN调度框架
1、双层调度框架
1）ResourceManager将资源分配给ApplicationMaster；
2）ApplicationMaster将资源进一步分配给各个TASK；
2、基于资源预留的调度策略
1）资源不够时，会为Task预留，直到资源充足；
描述：当一个Task需要10G资源时，各个节点都不足10G，那么就选择一个节点，但是某个NodeManager上只有2G，那么就在这个NodeManager上预留，当这个NodeManager上释放其他资源后，会将资源预留给10G的作业，直到攒够10G时，启动Task；
缺点：资源利用率不高，要先攒着，等到10G才利用，造成集群的资源利用率低；
2）与“all or nothing”策略不同（Apache Mesos）
描述：当一个作业需要10G资源时，节点都不足10G，那就慢慢等，等到某个节点上有10G空闲资源时再运行，很可能会导致该Task饿死。
YARN设计目标
通用的统一的资源管理系统：
1）同时运行长应用程序（永不停止的程序：Service、HTTP Server）；
2）短应用程序（秒、分、小时级内运行结束的程序：MR job、Spark job等）；
以YARN为核心的生态系统
在引入YARN之后，可以在YARN上运行各种不同框架的作业：
离线计算框架：MapReduce
DAG计算框架：Tez
流式计算框架：Storm
内存计算框架：Spark
MapReduce2.0与YARN
1、一个MapReduce应用程序需要如下模块：
1）任务管理和资源调度；
2）任务驱动模块（MapTask、ReduceTask）；
3）用户代码（Mapper、Reducer）；
2、MapReduce2.0的组成：
1）YARN（整个集群只有一个）；
2）MRAppMasster（一个应用程序一个）；
3）用户代码（Mapper、Reducer）；
3、MapReducer1.0和MapReduce2.0的区别：
1）MapReduce1.0是一个独立的系统，直接运行在Linux上；
2）MapReduce2.0则是运行在YARN上的框架，且可与多种框架一起运行在YARN之上；
4、MapReduce2.0和YARN的区别：
1）YARN是一个资源管理系统，负责资源管理和调度；
2）MapReduce只是运行在YARN上的一个应用程序；如果把YARN看成是android，那么MapReduce就是运行在android上个一个app；
