在Hadoop2.x中，为了解决Hadoop1.x的JobTracker存在的问题（可参考https://blog.csdn.net/qq_37865420/article/details/106441382），特别引进了一个牛逼的资源调度框架——Yarn
1：模型
1.1：container容器
1.1.1：抽象理解
可以理解成一个对象，它的属性有
- 是属于那个NodeManager的
- cpu多少
- 内存mem多少
- io量多少
1.1.2：物理上理解
- 可以是一个JVM进程---->操作系统进程
- NodeManager会有线程监控Container资源情况，使用超额后，NodeManager直接kill掉。任务失败会重试，会在其他container中进行任务执行，但是可能申请的container太小，无论挪到哪里都会超额，所以有失败重试次数的限制。最终导致client返回失败，所以写代码，上传任务时要配置好
- 还有种方式使用cgroup的内核技术，在启动jvm进程的时候，由内核kernel约束死，所以这个JVM进程只能使用一个定值的空间，这样就不用上面说到的线程监控了
- *也可以整合docker
1.2：实现的架构/框架
1.2.1：角色进程
- ResourceManager 主节点
- 负责整体资源的管理
- NodeManager 从节点
- 向ResourceManager汇报心跳，提交自己的资源情况
- 向ResourceManager汇报心跳，提交自己的资源情况
1.2.2：框架流程解析
MR运行
- MR-Client（切片清单、配置、jar上传到HDFS），之后client访问RM申请AppMaster
- RM选择一台不忙的节点通知NM启动一个Container，在里面反射一个MRAppMaster这个类
- 启动MRAppMaster，从HDFS下载切片清单，向RM申请资源
- 由RM根据自己掌握的资源情况得到一个确定清单，通知NM来启动container
- container启动后会反向注册到已经启动的MRAppMaster进程中去
- MRAppMaster（其实就是曾经的JobTracker的阉割版，他没有了资源管理的作用）最终将任务发送给container（其实发送的是一个消息，启动mapper还是启动reducer）
- container会反射发送过来的消息里相应的Task类（xxxMapper或者xxxReducer）为对象，调用方法执行，其结果及时我们的业务逻辑代码的执行
- 计算框架都有Task失败重试的机制
对比我之前的MR那篇文章，提出的对于hadoop1.x中jobTracker的三个弊端问题，yarn是怎么解决的呢？
三个问题可以查看我之前的文章
https://blog.csdn.net/qq_37865420/article/details/106441382
- JobTracker单点故障（曾经的JobTracker是全局的，JT挂了，整个计算层都没有了调度了）
yarn：每一个Application由一个自己的AppMaster调度（是计算程序级别的调度，不是全局的调度）
如果调度失败，yarn还支持AppMaster失败重试~！ - JobTracker压力过大
yarn中每个计算程序自有AppMaster，每个AppMaster只负责自己计算程序的任务调度，轻量化了AppMaster。AppMaster是在不同的节点中启动的，默认有了负载的作用 - JobTracker集成了【资源管理】【任务调度】，两者耦合度高
因为Yarn只是资源管理，不负责具体的任务调度
是公立的，只要计算框架继承yarn的AppMaster,大家都可以使用一个统一视图的资源层~~！
感悟
从1.x—>2.x
JT、TT是MR的常服务。。。。
2.x之后没有了这些服务
相对的：MR的调度（AppMaster）是临时服务了