2.MapReduce—YARN原理

HDFS：

特征：切块
用途：分治
最终目的：分布式计算
角色：NN--DN（心跳，汇报）
重点关注：读写流程

MapReduce：

计算模型、批量计算

Map和Recude是一种阻塞关系
Map：单条记录加工处理
Reduce：多条记录加工处理

想要实现，就需要计算向数据移动，就需要HDFS暴露自己的位置，这就需要JobTracker和TaskTracker

JobTracker：

1. 资源管理
2. 任务调度

TaskTracker：

1. 任务管理
2. TaskTracker和DN是一一对应关系
3. TaskTracker默认每3秒向JobTracker汇报心跳

客户端

利用JobTracker，将计算程序分配到每个TaskTracker上

流程

客户端：
	1.会根据每次计算数据，咨询NN元数据，取得元数据block。
	2.根据block块来计算切片，最终得到一个切片的清单
	3.因为一个切片对应一个Map，所以Map数量就得到了
	4.split是逻辑的，block是物理的，block上有偏移量和节点位置，split和block是有映射关系
	5.所以split也包含偏移量，以及split对应的map任务应该移动到哪些节点
	6.这样就可以计算向节点移动了

而后会生成相关的配置文件
移动时需要相对可靠(使用HDFS)，客户端会将程序jar、split、xml配置上传到hdfs（副本数默认是10）
客户端也会调用JobTracker，通知要启动一个计算程序，并告知文件都放在hdfs那些地方了.

JobTracker收到程序后：
	1. 从HDFS取出清单
	2. 根据收到的TaskTracker资源，确定每一个split对应的map应该去到哪一个节点，生成一个【确定清单】
	3. JT可以向TT请求，也可以TT向JT汇报
	4. 现在JK使用的是后者，TT再一次心跳时会取回分配给自己的任务信息

TaskTracker心跳取回任务后：
	1.去从hdfs下载jar，xml等到本机
	2.最终去启动任务描述的MapRecude

JobTracker会产生的问题：

1.单点故障
2.压力过大
3.自身集成【资源管理、任务调度】
	弊端：新的计算框架不能复用
		1.重复造轮子
		2.因为他们是各自实现资源管理，虽然部署在同一批硬件上，但是相互隔离

所以：如果拥有多个JobTracker的话，他们互相不清楚对方分配了什么任务，会造成资源的分配不均匀，资源争夺

yarn

1.将资源管理(JT)模块独立出来了
2.并且只是将资源管理提取了出来，任务调度基本不受影响
3.TaskTracker和JobTracker角色被淘汰了
4.客户端请求ResourceManager，创建出角色AppMstr，代替JobTracker
5.曾经JT是常驻服务，而现在AppMstr被请求时才会启动，节约资源

container容器：

container容器可以是虚的也可以是实的:
	1.虚的：
		对象、属性、NM、cpu、mem、io量
	2.实(物理)的：
		JVM操作系统进程
		
容器资源管理：
	1. NN会有线程监控container容器资源情况，超额的话，直接杀死进程，并且会把任务放到其他容器执行，
		可是这个资源都超额，其他的就不会超额吗，还是资源申请的不合适，这种方式太暴力了。
	2. 或是通过内核级技术cgroup，启动jvm进程，由kernel约束死可用的资源容量，不允许它超出可用容量，并且可以整合docker。

Yarn实现：

ResoureManager主节点:
	负责整体资源管理
	
NodeManager从节点:
	向RS汇报心跳，提交自己的资源情况

MapReduce运行

MapRecude on Yarn:

1. MR-client做（切片清单、配置、jar包，上传HDFS）,访问MR申请APPMastar。
2. 由RM选择一台不忙的节点通知NM启动一个container容器，在里面反射一个MRPAppMaster。
3. 启动MRAppMastar从hdfs下载切片清单，向RM申请资源。
4. 由RM根据自己掌握的资源情况得到一个确定清单，通知NM来启动container。
5. container启动后，会反向注册到已启动的MRAppMastar进程。
6. MRAppMastar（曾经的JT阉割版不带资源管理）最终将任务发送给Task发送给container消息。
7. container会反射相应的Task类为对象调用方法。
8. 调用方法执行，结果就是我们的业务逻辑代码执行的过程。
9. 计算框架都有Task失败重试的机制。

问题解决：

1. 单点故障
	Yarn每个APP都有一个自己的AppMaster调度。
	支持失败重试。
2. 压力过大
	Yarn：每个APP都有一个自己的AppMaster，每个AppMaster只负责自己计算程序任务调度，变得轻量级了。
	AppMaster是在不同节点中启动的，默认自带负载光环。
3. 自身集成【资源管理、任务调度】
	因为YARN只是资源管理，不负责任务调度，公立的，只要计算框架继承了Yarn的AppMaster，大家都可以使用一个统一视图的资源层。

总结：

hadoop1.x到2.x，JT和TT都是MR的常驻服务。
	
2.x后没有了这些服务，相对的，MR的client调度任务，都变成临时服务了。