存储模型
- 文件线性按字节切割成块（block），具有offset、id
- 文件与文件的block大小可以不一样
- 一个文件除最后一个block，其他block大小一致
- block的大小依据硬件的I/O特性调整
- block被分散存放在集群的节点中，具有location
- block具有副本（replication），没有主从概念，副本不能出现在同一个节点
- 副本满足可靠性和性能
- 文件上传可以指定block大小和副本数，上传后只能修改副本数
- 一次写入多次读取，不支持修改
-
架构设计
HDFS是一个主从架构
- 由一个NameNode和一些DataNode组成
- 面向文件包含：文件数据（data）和文件元数据（metadata）
- NameNode负责存储和管理文件元数据，并维护了一个层次型的文件目录树
- DataNode与NameNode维持心跳，并汇报自己持有的block信息
- Client和NameNode交互文件元数据和DataNode交互文件block数据
角色功能（角色即进程）
NameNode
- 完全基于内存存储文件元数据、目录结构、文件block的映射
- 需要持久化方案保证数据可靠性
-
DataNode
基于本地磁盘存储block（文件的形式）
- 并保存block的校验和数据，保证block的可靠性
-
元数据持久化（checkpoint）
任何对文件系统元数据产生修改的操作，NameNode都会用EditLog（日志文件）事务记录
- 使用FsImage（镜像、快照）存储内存所有元数据状态
- 使用本地磁盘保存EditLog和FsImage
- EditLog具有完整性，数据丢失少，恢复数据快，但有体积膨胀风险
- FsImage具有恢复速度快，体积与内存数据相当，但不能实时保存，数据丢失多
- NameNode使用FsImage+EditLog整合方案
滚动将增量的EditLog更新到FsImage，以保证更近时点的FsImage和更小的EditLog体积安全模式
启动流程
- HDFS搭建时会格式化，格式化操作会产生一个空的FsImage
- 当NameNode启动时，它从磁盘中读取FsImage和EditLog
- 将所有EditLog中的事务作用在内存中的FsImage上
- 并将这个新版本的FsImage从内存中保存到本地磁盘上
- 然后删除旧的EditLog，因为旧的EditLog的事务已经作用在FsImage上
NameNode启动特殊状态
- NameNode启动后就进入一个安全模式的特殊状态
- 处于安全模式下NameNode不会进行数据块的复制操作
- NameNode从所有的DataNode接收心跳信号和块状态报告
- 每当NameNode检测确认某个数据块的副本数目达到这个最小值，name该数据块就会被认为副本是安全的
- 在一定百分比（参数可配置）的数据块被NameNode检测确认是安全之后（加上一个额外等待30秒时间），NameNode将退出安全模式
接下来它还会确认有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他DataNode
Secondary NameNode(SNN)
在非HA模式下，SNN一般是独立节点，周期完成对NN的EditLog向FsImage合并，减少EditLog大小，减少NN启动时间
- 根据配置文件设置时间间隔fs.checkpoint.period 默认3600秒
根据配置文件设置EditLog大小fs.checkpoint.size规定文件最大默认值是64M
副本放置策略（Block）
第一个副本：放置在上传文件的DataNode，如果是集群外提交，则随机挑选一台磁盘不太满，cpu不太忙的节点
- 第二个副本：必须不同于第一个副本的机架
- 第三个副本：必须跟第二个副本一个机架
- 更多副本：随机放置
HDFS读写流程
写流程
- Client和NameNode连接创建文件元数据
- NameNode判断元数据是否有效
- NameNode触发副本放置策略，返回一个有序的DataNode列表
- Client和DataNode建立Pieline连接
- Client将块切分成packet（64kb），并使用chunk（512b）+chunksum（4b）填充
- Client将packet放入发送队列dataqueue，并向第一个DataNode发送
- 第一个DataNode收到packet后本地保存并发送给第二个DataNode
- 第二个DataNode收到packet后本地保存并发送给第三个DataNode
- 这一过程中，上游节点同时发送下一个packet（类比工厂流水线：流式其实也是变种的并行计算）
- HDFS使用这种传输方式，副本数对于Client来说是透明的
- 当Block传输完成，DataNode各自向NameNode汇报，同时Client继续传输下一个Block，所以Client传输和Block的汇报也是并行的
读流程
- 为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本
- 如果在读取程序的同一个机架上有一个副本，那就读取该副本
- 如果一个集群跨越多个数据中心，那个客户端也将首先读取本地数据中心的副本
语义：下载一个文件
Client和NameNode交互文件元数据获取fileBlockLocation
NameNode会按距离策略排序返回
Client尝试下载block并校验数据完整性
语义：下载一个文件其实是获取文件所以Block元数据，那么子集获取某些block应该成立
HDFS支持Client给出文件的offset自定义连接那些Block的DataNode获取数据
这是支持计算层的分治、并行计算的核心
主从架构带来的问题？
Hadoop 2.x 只支持一主一备，3.x支持最多一主五备，但推荐一主三备
主单点故障
高可用方案：HA
多个NN，主备切换；Active和Standby状态，Active对外提供服务；
增加journalnode角色（>3台），负责同步NN的EditLog，最终一致性
增加zkfc角色（与NN同一台），通过Zookeeper集群协调NN的主从选举和切换事件回调机制
解决方案：
压力过大，内存受限
联邦机制：Federation（元数据分片）
多个NN，管理不同的元数据
解决方案：
- 元数据分治，复用DN存储
- 元数据访问隔离性
- DN目录隔离Block
若有收获，就点个赞吧
0 人点赞
