hdfs

  1. 存储模型
    切换，散列 -> 分治 目的：分布式计算

  2. 实现 -> 框架
    角色 NN，DN
    特长/特点： -> 架构师：【技术选型】
    读写流程就很重要

mapreduce

批量计算 流式计算

  1. 计算模型
    2阶段：map和reduce是一种阻塞关系
    map阶段：
    单条记录加工和处理
    reduce阶段：
    按组，多条记录加工和处理

  2. 实现 -> 框架
    计算向数据移动：
    hdfs暴露数据的位置
    1)资源管理
    2)任务调度

– 角色：
JobTracker：
1,资源管理
2,任务调度
TaskTracker：
任务管理
资源汇报
【Cli：？】

Cli

1，会根据每次的计算数据，咨询NN元数据（block）->算：split 得到一个切片的【清单】，map的数量就有了
split是逻辑的，block是物理的，block身上有（offset，locations），split和block是有映射关系的
结果：split包含偏移量，以及split对应的map任务应该移动到那些节点（locations）
split01 A 0 500 n1 n3 n5
可以支持计算向数据移动～！！！
2，生成计算程序未来运行时的相关配置的文件：*.xml
3，未来的移动应该相对可靠
cli会将jar，split清单，配置xml 上传到hdfs的目录中（上传的数据，副本数10）
4，cli会调用JobTracker，通知要启动一个计算程序了，并且告知文件都放在了hdfs的哪些地方

JobTracker

JobTracker手动启动程序之后：
1，从hdfs中取回【split清单】
2，根据自己收到的TaskTracker汇报的资源，最终确定每一个split对应的map应该去到哪一个节点，【确定清单】
3，未来，TaskTracker在心跳的时候，会取回分配给自己的任务信息～！

TaskTracker

1，在心跳取回任务后
2，从hdfs中下载jar，xml…到本机
3，最终启动任务描述中的MapTask/ReduceTask（最终，代码在某一个节点被启动，是通过，cli上传，TaskTracker下载：计算向数据移动的实现）

问题

JobTracker 3个问题：
1，单点故障
2，压力过大
3，集成了【资源管理和任务调度】，两者耦合
弊端：未来新的计算框架不能服用资源管理
1，重复造轮子
2，因为各自实现资源管理，但是他们部署在同一批硬件上，因为隔离的，所以不能感知对方的使用情况，所以：资源争抢～！！

思路：（因果关系导向学习）

【计算要向数据移动】
->哪些节点可以去呢（需要有整体资源的把控）
->确定了节点后，对方怎么知道呢（任务调度），还有比如有一个失败了，应该重新在哪个节点重试
->拉个JobTracker搞定了这2件事情。。。但是，后来问题也暴露了。。。

hadoop2.x

解决上面的问题

yarn架构

资源管理

yarn
1. 模型：
container容器 不是docker
虚的：
对象：属性：NodeManager cpu mem io量
物理的：
JVM->操作系统进程
1，NM会有线程监控container资源情况，超额，NM直接kill掉
2，cgroup内核级技术：在启动JVM进程，由kernel约束死
整合docker

  1. 实现：架构/框架
    角色：
    ResourceManager 主
    负责整体资源的管理
    NodeManager 从
    向ResourceManager汇报心跳，提交自己的资源情况

MR运行 MapReduce on yarn

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

结论：

问题：
1，单点故障（曾经是全局的，JobTracker挂了，整个计算层没有了调度）
yarn：每一个App有一个自己的AppMaster调度！（计算程序级别）
yarn支持AppMaster失败重试～！
2，压力过大
yarn中每个计算程序自有AppMaster，每个AppMaster只负责自己计算程序的任务调度，轻量了
AppMaster是在不同的节点中启动的，默认有了负载的光环
3，集成了【资源管理和任务调度】，两者耦合
因为yarn只是资源管理，不负责具体的任务调度
是公立的，只要计算框架继承yarn的AppMaster，大家都可以使用一个统一试图的资源层～！！！

总结感悟：
从1.x到2.x
JobTracker，TaskTracker是MR的常服务。。。
2.x之后没有了这些服务
相对的：MR的cli，调度，任务，这些都是临时程序了。。。

Scroll to Top