备忘
Cli：
1、会根据每次计算的数据，咨询NN元数据（block）计算：split得到一个切片清单；
这样map的数量就有了。Split时逻辑的，block是物理的。block身上有（offset,location）,split和block之间有映射关系。
结果：split包含偏移量，以及split对应的map任务应该移动到哪些节点上（locations）
例如：split01 A 0 500 n1 n2 n3
可以支持计算向数据移动了~~~
2、生成计算程序未来运行时相关的配置文件xml
3、未来的移动应该相对可靠，什么可靠呢？HDFS可靠，所以cli会将jar,
split清单、配置xml，上传到HDFS目录中（上传的数据副本数10）
4、cli会调用JobTracker，通知要启动一个计算程序了，并且告知文件存在HDFS的什么位置上
JobTracker 收到启动程序后
1、从HDFS中拉取Split清单
2、根据自己收到的TT汇报的资源，最终确定每一个split对应的map应该到哪一个节点中去【确定的清单】
3、TaskTracker会在心跳的时候取回分配给自己的任务信息
TaskTracker在心跳取回任务信息后
1、从HDFS中下载jar包，xml到本地
2、最终【启动】任务描述中的mapTask/reduceTask
[ 最终代码在某一个节点被启动，通过Cli上传，TT下载 ]
JobTracker 存在的问题：
1、单点故障
2、压力过大
3、集成了资源管理和任务调度，两者耦合【线程和进程】
弊端：
1、重复造轮子
2、多种计算框架各自实现资源管理，部署在同一批硬件上，进程隔离，造成资源争抢
========================================================
Hadoop 2.x 出现了Yarn 【线程进程，一脉相承】
1、Cli提交任务，RM会在一台不太忙的NM中启动APP Master--相当于被阉割过的JobTRacker【只管任务调度，不管资源管控】。
2、APP Master从HDFS上取回切片清单，再向RM申请Container.
3、RM根据自己掌握的资源情况，在一些合适的节点上启动Container.
4、Container需要向App master 反向注册，APP Master知道了有多少资源可用。就通过消息(而不是任务代码)将任务分配给Container；
5、Container 从HDFS上拉取Jar，执行任务。
Container
虚拟的：
对象：属性：CPU、mem、IO量
物理的：
JVM->操作系统进程
1、NM会有线程监控container资源情况，如果超额则直接杀死；
2、CGroup内核级技术：在启动JVM进程的时候，由Kernel直接约束死资源量；
实现架构：
RM：负责整体资源的管理；
NN：汇报心跳，提交自己的资源情况；
MR 运行：
1、CLi（切片清单/配置/jar/上传到HDFS），访问RM申请AppMaster；
2、RM选择一台不忙的节点通知NM启动一个Container，在里面反射一个MRAppMaster
3、启动MRAppMaster，从HDFS下载切片清单，向RM申请资源启动Container；
4、RM根据资源状况得到一个确定的清单，通知NM启动Container；
5、Container 会反向注册到MRAppMatser进程；
6、MRAppMatser可以认为阉割版的JobTracker，最终将任务【消息】发送给Container；
7、Container会反射相应的类，调用方法，运行得到结果。