写的不到位的地方,欢迎评论指出不足之处
- HDSF:存储文件
- 存储模型
- 切块、散列
- 分治目的
- 分布式计算
- 分治目的
- 切块、散列
- 实现
- 框架
- 角色 NameNode、DataNode
- 框架
- 特长/特点
- 读写流程很重要
- 存储模型
- MapReduce:批量计算
- 计算模型
- 两阶段:Map 与 Reduce 是一种阻塞关系
- Map
- 单条记录加工和处理
- Reduce
- 按组、多条记录加工和处理
- Map
- 两阶段:Map 与 Reduce 是一种阻塞关系
- 实现 :框架
- 计算向数据移动
- hdfs 暴露数据的位置
- 资源管理
- 任务调试
- hdfs 暴露数据的位置
- 角色
- JobTracker (主)
- 资源管理
- 任务调试
- TaskTracker(主)
- 任务管理
- 资源汇报
- JobTracker (主)
- 逻辑
- Client
- 根据每次的计算数据,咨询 NameNode 元数据 (block)
- 算:split 得到一个切片的清单
- map 的数量就有了
- split 逻辑、block 物理、block 身上有(offset、locations)、split 和 block 是有映射关系
- split 包含偏移量,以及 split 对应的 map 任务应该移动到哪些节点(locations)
- 例:split01 A文件 起始0b 结束500b n1 n3 n5(块的位置)
- 可以支持计算程序向数据移动
- 算:split 得到一个切片的清单
- 生成计算程序未来运行时的相关配置的文件
- 未来的移动应该相对可靠
- Client 会将:jar、split 清单、配置 xml、 上传到 hdfs 的目录中(上传的数据副本数为10)
- Client 会调用 JobTracker,通知要启动一个计算程序了,并且告知文件都放在了 hdfs 的哪些地方
- 根据每次的计算数据,咨询 NameNode 元数据 (block)
- JobTracker
- 从 hdfs 中取回:split 清单
- 根据取到的 TaskTracker 汇报的资源,最终确定每一个 split 对应的 map 应该去到哪一个节点:确定清单
- 未来,TaskTracker 再心跳交互时会取回分配给自己的任务信息
- TaskTracker
- 心跳互动时取回任务后
- 从 hdfs 中下载相关文件 jar、xml...等到本地
- 最终启动任务描述中的 MapTask / ReduceTask
- 最终代码在某一个节点被启动
- 是通过:Client上传、TaskTracker下载:计算向数据移动实现
- 最终代码在某一个节点被启动
- Client
- 计算向数据移动
- 计算模型
- 问题
- JobTracker 三个问题
- 单点故障
- 压力过大
- 集成了【资源管理和任务调度】,两者耦合
- 弊端:未来新的计算框架不能利用资源管理
- 重复造轮子
- 因各自实现资源管理,但部署在同一批硬件上,因为隔离,不能感知对方的情况
- 资源争抢
- 弊端:未来新的计算框架不能利用资源管理
- JobTracker 三个问题
- 思路
- 计算要向数据移动
- 哪些节点可以去呢(需要有整体资源的把控)
- 确定了节点后对方怎么知道呢(任务调度),还有比如有一个失败了,应该重新在哪个节点重试
-
来个 JobTracker 搞定这2件事,但问题也随之暴露