Yarn产生的原因
直接源于MRv1在几个方面的缺陷
扩展性受限
单点故障：JobTracker 完成了太多的任务，造成了过多的资源消耗
难以支持MR之外的计算
多计算框架各自为战，数据共享困难
YARN
即在一个集群上部署一个统一的资源调度管理框架YARN,在YARN之上可以部署其他各种计算框架
由YARN为这些计算框架提供统一的资源调度管理服务，并且能够根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩
离线计算框架：MapReduce
DAG计算框架：Tez 有向无环图 适合编写有依赖关系的作业
流式计算框架：Storm
内存计算框架：Spark【不读磁盘而直接在内存上计算】
图计算框架：Giraph
YARN的结构
ResourceManager：整个集群只有一个，负责集群资源的统一管理和调度
NodeManager：单个节点上的资源管理
ApplicationMaster：每个应用有一个，任务调度、监控与容错
ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理器（Applications Manager）
调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”
应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，启动applicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等
容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁。等资源，从而限定每个应用程序可以使用的资源量
ApplicationMaster的主要功能是：
资源的二次分配 RM-AM-NM
向NodeManager通信来掌握各个任务的执行状态
以“心跳”的方式向ResourceManager报告资源的使用情况和应用的进度信息；
NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责：
容器生命周期管理，监控每个容器的资源（CPU、内存等）使用情况
向ApplicationMaster汇报各个任务的执行情况
以“心跳”的方式向ResourceManager汇报资源使用情况和每个容器的运行状态
需要说明的是，NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理，因为这些管理工作是由ApplicationMaster完成的，ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态
YARN的容错和调度机制
Hadoop YARN容错
ResourceManager
存在单点故障；
正在基于ZooKeeper实现HA。
NodeManager
失败后，RM将失败任务告诉对应的AM,AM决定如何处理失败的任务。
ApplicationMaster
失败后，由RM负责重启；AM需处理内部任务的容错问题；
。
双层调度框架
RM将资源分配给AM
AM将资源进一步分配给各个Task
基于资源预留的调度策略
资源不够时，会为Task预留，直到资源充足