YARN.

内部原因
在Hadoop1.x中，MapReduce的主节点是JobTracker，作为主节点的JobTracker在Hadoop1.x中只允许存在1个，容易出现单点故障在Hadoop1.x中，JobTracker给每一个从节点TaskTracker分配完子任务之后，还会监控每一个从节点的执行情况，随着TaskTracker的数量的增多，导致JobTracker的监控压力越来越大。根据官方文档给定，每一个JobTracker最多能够管理4000个TaskTracker
外部原因
Hadoop作为较早的大数据框架，出现的时候，市面上几乎没有其他的大数据框架，因此Hadoop早期在设计的时候，没有考虑过其他框架的资源占用问题随着大数据的发展，产生了越来越多的计算框架，例如Spark，Flink等，这些计算框架在设计的时候都会考虑使用Hadoop集群的资源，导致各个框架之间互相抢占资源

客户端将任务提交给ResourceManager的组件ApplicationsManager所携带的队列中，然后ResourceManager等待NodeManager的心跳

当ResourceManager收到心跳之后，就会在心跳响应中将这个Job任务返回给这个NodeManager

当NodeManager收到Job任务，会在本节点内部来开启一个ApplicationMaster进程，然后将这个Job交给这个ApplicationMaster来进行处理

ApplicationMaster收到任务之后，会对这个任务来进行拆分，拆分成多个子任务。例如如果是一个MapReduce任务，就会将这个任务拆分成MapTask和ReduceTask。拆分完成之后，ApplicationMaster会给ApplicationsManager发送请求，请求获取执行资源

ApplicationsManager收到请求之后，会将请求交给ResourceScheduler。ResourceScheduler收到请求之后，会将所需要的资源的描述信息封装成Container对象返回给ApplicationsManager，然后ApplicationsManager会再将资源描述信息Container对象返回给ApplicationMaster

ApplicationMaster收到资源之后，会将资源进行二次分配，分配给每一个子任务。资源分配完成之后，ApplicationMaster就会将子任务分配到其他的NodeManager来执行。分配完成之后，ApplicationMaster还会监控每一个子任务的执行情况

注意问题

YARN形成了层级结构：ApplicationsManager负责管理ApplicationMaster，ApplicationMaster负责管理具体的子任务每一个Job任务对应一个单独的ApplicationMaster，保证每一个ApplicationMaster之间相互不影响默认情况下，一份资源包含1G内存以及1个CPU核，也就意味着一个任务执行最多能占用1G内存+1个CPU核