HADOOP 1.0存在的问题
HDFS1.0存在的问题：
- Namenode单点故障：集群的文件都是以“块(block)”的形式存储，并且为了容错，每个block有多个副本。namenode需要记录整个集群所有block及其副本的元数据信息（fsimage：文件目录结构，block和文件的映射关系等）和操作日志（edits），因此，在hadoop1.0框架中，namenode设计为单个节点，通常部署在一台性能强劲的计算机上，客户端上传的所有文件，都要先与namenode进行交互，由namenode管理。这样，namenode的可用性决定整个集群的存储系统的可用性。
- Namenode压力过大，内存受限： 在集群启动时，namenode需要将集群所有block的元数据信息加载到内存，这样，当文件越来越多时，namenode的内存压力也会遇到瓶颈。
MapReduce1.0存在的问题：
- JobTracker单点故障：MapReduce作为hadoop的计算框架，其作业的调度和资源分配是通过JobTracker完成。但是，因为资源管理是全局性的，因此，JobTracker仍然是单个节点，通常部署在一台性能强劲的计算机上。一旦该节点失败，整个集群的作业就全部失败。
- 不支持MapReduce之外的其它计算框架：hadoop1.0仅能支持MapReduce计算框架，随着人们对实时性的要求，spark、storm等计算框架也应运而出，但是hadoop1.0并不能良好地支持。
- JobTracker访问压力大，影响系统扩展性：在hadoop1.0中，JobTracker负责所有作业的调度、各个作业的生命周期、各个作业中所有task的跟踪和失败重启等。因此，当集群中作业很多时，所有作业的map task和reduce task都要与JobTracker进行交互
为解决hadoop1.0中JobTracker单点故障问题，hadoop2.0开始将Hadoop 1.0中的JobTracker的集群资源分配和作业调度分为两个守护进程来控制，分别是Global Resource Manager(以下简称RM)和每个Application的ApplicationMaster(以下简称AM)，这也是YARN最重要的两个组件。
HADOOP 2.X YARN实现
流程图
步骤：
1、Client向RM发出请求
2、RM返回一个ApplicationID作为回应
3、Client向RM回应Application Submission Context（ASC）。ASC包括ApplicationID、user、queue，以及其他一些启动AM相关的信息，除此之外，还有一个Container Launch Context（CLC），CLC包含了资源请求数（内存与CPU），job files，安全token，以及其他一些用以在一个node上启动AM的信息。任务一旦提交以后，client可以请求RM去杀死应用或查询应用的运行状态
4、当RM接受到ASC后，它会调度一个合适的container来启动AM，这个container经常被称作为container 0。AM需要请求其他的container来运行任务，如果没有合适的container，AM就不能启动。当有合适的container时，RM发请求到合适的NM上，来启动AM。这时候，AM的PRC与监控的URL就已经建立了。
5、当AM启动起来后，RM回应给AM集群的最小与最大资源等信息。这时AM必须决定如何使用那么当前可用的资源。YARN不像那些请求固定资源的scheduler，它能够根据集群的当前状态动态调整。
6、AM根据从RM那里得知的可使用的资源，它会请求一些一定数目的container。
7、RM将会根据调度策略，尽可能的满足AM申请的container。然后AM会将任务跑在container上，并监控和管理作业状态。当任务完成之后，AM会通知RM释放container资源。
功能
Resource Manager
- 处理客户端请求
- 启动/监控ApplicationMaster
- 监控NodeManager
- 资源分配与调度
Node Manager
- 单个节点上的资源管理和任务管理
- 处理来自ResourceManager的命令
- 处理来自ApplicationMaster的命令
ApplicationMaster
- 数据切分
- 为应用程序申请资源，进一步分配给内部任务
- 任务监控和容错
Container
- 任务运行资源(节点，cpu，内存)
- 任务启动命令
- 任务运行环境
Spark on yarn
原理图
步骤
1、Spark Yarn Client 向 Yarn 中提交应用程序。
2、ResourceManager 收到请求后，在集群中选择一个 NodeManager，并为该应用程序分配一个 Container，在这个 Container 中启动应用程序的 ApplicationMaster， ApplicationMaster 进行 SparkContext 等的初始化。
3、ApplicationMaster 向 ResourceManager 注册，这样用户可以直接通过 ResourceManager 查看应用程序的运行状态，然后它将采用轮询的方式通过RPC协议为各个任务申请资源，并监控它们的运行状态直到运行结束。
4、ApplicationMaster 申请到资源（也就是Container）后，便与对应的 NodeManager 通信，并在获得的 Container 中启动 CoarseGrainedExecutorBackend，启动后会向 ApplicationMaster 中的 SparkContext 注册并申请 Task。
5、ApplicationMaster 中的 SparkContext 分配 Task 给 CoarseGrainedExecutorBackend 执行，CoarseGrainedExecutorBackend 运行 Task 并向ApplicationMaster 汇报运行的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
6、应用程序运行完成后，ApplicationMaster 向 ResourceManager申请注销并关闭自己。