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