HDFS
带着疑问学!
分布式文件系统那么多为什么Hadoop项目中还要开发出一个hdfs文件系统?
理论知识点
- 存储模型
- 架构设计
- 角色功能
- 元数据持久化
- 安全模式
- 副本放置策略
- 读写流程
- 安全策略
存储模型
- 文件线性按字节切割成块,具有offset,id
- 文件与文件的block的大小可以不一样
- 一个文件除最后一个block,其他block大小一致
- block的大小一句硬件的I/O特性调整
- block被分散存放在集群的节点中,具有location
- Block具有副本,没有主从概念,副本不能出现在同一个节点
- 副本是满足可靠性和性能的关键
- 文件上传可以指定block大小和副本数,上传后只能修改副本数
- 一次写入多次读取不支持修改
- 支持追加数据
架构设计
- HDFS是一个主从( Master/Slaves)架构
- 由一个 NameNode和一些 DataNode组成
- 面向文件包含:文件数据(data)和文件元数据(metadata)
- NameNode负责存储和管理文件元数据,并维护了一个层次型的文件目录树
- DataNode负责存储文件数据(bock块),并提供 block的读写
- DataNode与 Namenode维持心跳,并汇报自己持有的block信息
- Client和NameNode交互文件元数据和DataNode交互文件block数据
角色功能
NameNode
- 完全基于内 目录结构、文件 block的映射
- 需要持久化方案保证数据可靠性
- 提供副本放置策略
DataNode
- 基于本地磁盘存储bock(文件的形式)
- 并保存 block的校验和数据保证block的可靠性
- 与 NameNode保持心跳,汇报 block列表状态
元数据持久化
- 任何对文件系统元数据产生修改的操作, Namenode都会使用一种称为 EditLog的事务日志记录下来
- 使用 Fslmage存储内存所有的元数据状态
- 使用本地磁盘保存 EditLog和 Fslmage
- EditLog具有完整性,数据丢失少,但恢复速度慢,并有体积膨胀风险
- Fslmage具有恢复速度快,体积与内存数据相当,但不能实时保存,数据丢失多
- NameNode使用了 Fslmage+EditLog整合的方案;
- 滚动将增量的 EditLog更新到 Fslmage,以保证更近时点的 Talmage和更小的 EditLog体积
安全模式
-
HDFS搭建时会格式化,格式化操作会产生一个空的 Fslmage
-
当 Namenode启动时,它从硬盘中读取 Editlog和 FsImage
-
将所有EditLog中的事务作用在内存中的 Fslmage上,并将这个新版本的 Fslmage从内存中保存到本地磁盘上 然后删除旧的 Editlog,因为这个旧的 Editlog的事务都已经作用在 Fslmage上了
-
Namenode启动后会进入一个称为安全模式的特殊状态。
-
处于安全模式的 Namenode是不会进行数据块的复制的。
-
Namenode从所有的 Datanode接收心跳信号和块状态报告。
-
每当 Namenode检测确认某个数据块的副本数目达到这个最小值,那么该数据块就会被认为是副本安 全( safely replicated)的,在一定百分比(这个参数可配置)的数据块被Namenode检测确认是安全之后(加上一个额外的30秒 等待时间),Namenode将退出安全模式状态。
-
接下来它会确定还有哪些数据块的副本没有达到指定数目,并将这些数据块复制到其他 Datanode上
HDFS中的SNN
Secondary Node (SNN)
- 在非高可用HA(High Availability)模式下,SNN一般是独立的节点,周期完成对NN的 EditLog向Fslmage合并,减少EdtitLog大小,减少NN启动时间
- 根据配置文件设置的时间间隔 fs.checkpoint.period 默认3600秒
- 根据配置文件设置 edits log大小 fs.checkpoint size规定edits文件的最大值默认是64MB
Block的副本放置策略
- 第一个副本:放置在上传文件的DN;如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点。
- 第二个副本:放置在于第一个副本不同的机架的节点上。
- 第三个副本:与第二个副本相同机架的节点。
- 更多副本:随机节点。
HDFS写流程
NameNode--NN;DateNode--DN
- Client和NN连接创建文件元数据
- NN判定元数据是否有效
- NN触发副本放置策略,返回一个有序的DN列表
- Client和DN