1)资源管理
2)任务调度
JobTracker: 资源管理、任务调度（主）
TaskTracker:任务管理、资源汇报（从）
Client:
1.会根据每次计算数据，咨询NN的元数据(block)。算:split 得到一个切片的清单
map的数量就有了
2.split是逻辑的，block是物理的，block身上有(offset,locatios)，split和block是有映射
关系的。
结果：split包含偏移量，以及split对应的map任务应该移动到哪些节点(locations)
可以支持计算向数据移动了~!
生成计算程序未来运行时的文件
3.未来的移动应该相对可靠
cli会将jar,split清单，配置xml，上传到hdfs的目录中（上传的数据，副本数为10）
4.cli会调用JobTracker，通知要启动一个计算程序了，并且告知文件都放在了hdfs的哪个地方
JobTracker收到启动程序后：
1.从hdfs中取回【split清单】
2.根据自己收到的TT汇报的资源，最终确定每个split对应的map应该去到哪一个节点
3.未来TT再心跳的时候会取回分配自己的任务信息
TaskTracker
1.在心跳取回任务后
2.从hdfs下载jar，xml到本机
3.最终启动任务描述中的Map/Reduce Task(最终，代码在某个节点被启动，是通过cli上传，TT下载)
问题:
JobTracker3个问题:
1.单点故障
2.压力过大
3.集成了资源管理和任务调度，两者耦合
弊端:未来新的计算框架不能复用资源管理
1.重复造轮子
2.因为各自实现资源管理，因为他们不熟在同一批硬件上，因为隔离，所以不能感知
所以造成资源争抢
思路:(因果关系导向学习)
计算向数据移动
哪些节点可以去?
确定了节点对方怎么知道，一个失败了应该在什么节点重试
来个JobTracker搞定了2件事。但是，后来，问题暴露了
yarn架构图
查看架构图的方法：
1.确定实主从架构还是无主架构
原文：https://www.cnblogs.com/littlepage/p/11156851.html