一、Hadoop1.X
从Hadoop1.X中出现的缺点就可以知道，为啥会有Yarn的出现
1、JobTracker：资源管理、任务调度
2、TaskTracker：任务管理、资源汇报
3、Client：
（1）会根据每次的计算数据，咨询NameNode元数据（block），计算split，得到一个切片【清单】，map的数量就有了。
split是逻辑的，block是物理的，block身上有（offset、location），split和block有映射关系，由此可以得出split包含偏移量，以及split对应的map任务应该移动到哪些节点，可以支持计算向数据移动。
（2）生成计算程序未来运行时的相关【配置文件】
（3）未来的移动应该相对可靠：Cli会将split清单、配置xml上传到hdfs的目录中
（4）Cli会调用JobTracker，通知要启动一个计算程序了，并且告知文件都放在了hdfs的哪些地方
4、JobTracker收到启动程序之后：
（1）从hdfs中取回【split清单】
（2）根据自己收到的TaskTracker汇报的资源，最终确定一个split对应的map应该去到哪一个节点【确定清单】
（3）未来，TaskTracker在心跳的时候会取回分配给自己的任务信息
5、TaskTracker：
（1）在心跳取回任务后，从hdfs中下载xml等到本机
（2）启动任务描述中的MapTask/ReduceTask（最终，代码在某一个节点被启动，是通过Cli上传，TaskTracker下载，计算向数据移动的实现）
在Hadoop1.X中，由JobTracker做资源管理、任务调度，有以下三个问题：
1、单点故障
2、压力过大
3、集成了【资源管理和任务调度】，两者耦合，未来新的计算框架不能复用资源管理
二、Hadoop2.X
所以在Hadoop2.X中采用Yarn来做资源管理
1、模型
（1）container容器
可以是虚的：想象成一个对象，有一些属性，NameNode、CPU、内存、IO
也可以是物理的：可以是一个JVM- > 操作系统进程
NodeManager会有线程监控container的资源情况，超额时NodeManager直接杀掉
通过cgroup（内核级技术）：在启动JVM进程时，由kernel约束死（只能使用多大的内存）
2、实现（架构 / 框架）
（1）ResourceManager（主）
负责整体资源的管理
（2）NodeManager（从）
向ResourceManager汇报心跳，提交自己的资源使用情况
3、MapReduce运行：MapReduce On Yarn
（1）MapReduce-Cli 将切片清单 / 配置 / jar 上传到HDFS，访问ResourceManager申请AppMaster
（2）ResourceManager选择一台不忙的节点通知NodeManager启动一个Container，在里面反射一个MapReduce 的AppMaster
（3）启动MapReduce的AppMaster，从hdfs上下载切片清单，向ResourceManager申请资源
（4）由ResourceManager根据自己掌握的资源情况，得到一个确定清单，通知NodeManager启动Container
（5）Container启动后会反向注册到已经启动的MapReduce的AppMaster进程上
（6）由MapReduce的AppMaster（曾经的JobTracker阉割版，不带资源管理）最终将Task发送给Container
（7）Container会反射相应的Task类为对象，调用方法执行，其结果就是业务逻辑代码的执行
（8）计算框架都有Task失败重试的机制
结论
（1）单点故障（曾经是全局的，JobTracker挂了，整个计算层就没有调度）
现在Yarn：每一个APP都有自己的APP Master调度，不是全局的；同时Yarn支持APP Master失败重试
（2）压力过大
Yarn中每个计算程序都有自己的APP Master，每个APP Master只负责自己计算程序的任务调度，更轻量；APP Master是在不同的节点中启动的，默认有了负载的光环
（3）耦合的问题
因为Yarn只是资源管理，不负责具体的任务调度，是中立的，只要计算框架继承Yarn的APP Master，大家都可以使用一个统一视图的资源层。
从HADOOP 1.X 到 2.X
1.X的JobTracker和TaskTracker是常服务
2.X之后没有了这些服务，相对的MapReduce的Cli、调度、任务这些都是临时服务了