Big Data（七）MapReduce计算框架

二、计算向数据移动如何实现?

Hadoop1.x(已经淘汰)：

hdfs暴露数据的位置

1)资源管理

2)任务调度

角色：JobTracker&TaskTracker

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件事。但是，后来，问题暴露了

Hadoop2.x yarn的出现

　　　　　　　　　　　　　　　　yarn架构图

查看架构图的方法：

1.确定实主从架构还是无主架构

2.查看如何调度进程

Hadoop2.x yarn:

模型：

　　container 容器不是docker

　　　　虚的

　　　　　　对象：属性：cpu,mem,io量

　　　　　　物理的：JVM->操作系统进程(1,NN会有线程监控container资源情况,超额,NM直接kill掉

　　　　　　1.NM会有线程监控container资源情况，超额，NM直接kill掉

　　　　　　2.cgroup内核级技术：在启动jvm进程，由kernel约束死

架构：架构/框架

　　ResourceManger 主

　　　　负责整体资源的管理

　　NodeManager 从

　　　　向RS汇报心跳，提交自己的资源情况

MR运行 MapReduce on yarn

　　1.MR-cli(切片清单/配置/jar/上传到HDFS)

　　　　访问RM中申请AppMaster

　　2.RM选择一台不忙的节点通知NM启动一个Container，在里面反射一个MRAppMaster

　　3.启动MRMaster，从hdfs下载切片清单，向RM申请资源

　　4.由RM根据自己掌握的资源情况得到一个确定清单，通知NM来启动container

　　5.container启动后会反向注册到已经启动的MRAppMaster进程

　　6.MRAppMaster(曾经的JobTracker阉割版不带资源管理)最终将任务Task发送container（消息）

　　7.container会反射相应的Task类作为对象，调用方法执行，其结果就是我们的业务逻辑代码的执行

结论：

　　问题：

　　1.单点故障(曾经是全局的，JT挂了，整个计算层没有了调度）

　　　　yarn:每一个APP由一个自己的AppMaster调度（计算程序级别）、

　　2.压力过大

　　　　yarn中每个计算程序自由AppMaster，每个AppMaster只负责自己计算程序的任务调度，轻量了

　　　　AppMaster在不同节点中启动的，默认有了负载的光环

　　3.继集成了【资源管理和任务调度】，两者耦合

　　　　因为Yarn只是资源管理，不负责具体的任务调度

　　　　是公立的，只要计算框架继承yarn的AppMaster，大家都可以使用一个统一视图的资源层！！

总结感悟：

　　从1.x到2.x

　　　　JT,TT是MR的常服务

　　2.x之后没有了这些服务

　　　　相对的：MR的cli，调度，任务，这些都是临时服务了。