NameNode功能：
- 完全基于内容存储文件元素据、目录结构、文件block的映射
- 需要持久化方案保证数据可靠性
- 提供副本放置策略
DataNode功能：
- 基于本地磁盘存储block(文件的形式)
- 并保存block的校验和数据保证block的可靠性
- 与NameNode保持心跳，汇报block列表状态
元数据持久化
- 任何对文件系统元数据产生修改的操作，NameNode都会使用一种称为EditLog的事务日志记录下来
- 使用FsImage存储内存所有的元数据状态
- 使用本地磁盘保存EditLog和FsImage
- EditLog具有完整性、数据丢失少，但恢复速度慢，并有体积膨胀风险
- FsImage具有恢复速度快，体积与内存数据相当，但不能实时保存，数据丢失多
- NameNode使用了FsImage+EditLog整合的方案，滚动将增量的EditLog更新到FsImage，以保证更近时点的FsImage和更小的EditLog体积
安全模式
- NameNode启动后会进入一个称为安全模式的特殊状态
- 处于安全模式的NameNode是不会进行数据块复制的
- NameNode从所有的DataNode接收心跳信号和块状态的报告
- 每当NameNode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全的
- 在一定百分比(这个参数可配置)的数据块被NameNode检测确认是安全之后(加上一个额外的30秒等待时间),NameNode将退出安全模式状态
- 接下来他会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他DataNode上
- HDFS搭建的时候会格式化，格式化操作会产生一个空的FsImage
- 当NameNode启动时，它从硬盘中读取EditLog和FsImage
- 将所有EditLog中的事物作用在内存中的FsImage上
- 并将这个新版本的FsImage从内存中保存到本地磁盘上
- 然后删除旧的EditLog，因为这个就的EditLog的事物都已经作用在FsImage上了
HDFS中的SNN(SecondaryNameNode)
- 在非Ha模式下，SNN一般是独立的节点，周期完成对NN的EditLog向FsImage合并，减少EditLog大小，减少NN启动时间
- 根据配置文件设置时间间隔fs.checkpoint.period 默认3600秒
- 根据配置文件设置EditLog大小fs.checkpoint.size规定edits文件的最大值默认为64MB
HDFS写流程
- client和NN连接创建文件元素据
- NN判定元素据是否有效
- NN触发副本放置策略，返回一个有序的DN列表
- Client和DN建立Pipeline连接
- Client将块切分成packet(64KB),并使用chunk(512B)+chucksum(4B)填充
- Client将packet放入发送队列dataqueue中，并向第一个DN发送
- 第一个DN收到packet后本地保存并发送第二个DN
- 第二个DN收到packet后本地保存并发送第三个DN
- 这一过程中，上游节点同时发送下一个packet
- 生活中类比工厂的流水线，结论：流式其实也是一种并行计算
- HDFS使用这种传输方式，副本数对于client是透明的
- 当block传输完成，DN们各自向NN汇报，同时client继续传输下一个block
- 所以，client的传输和block的汇报也是并行的
HDFS读流程
- 为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离他最近的副本。
- 如果在读取程序的同一个机架上有一个副本，那么就读取该副本
- 如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。
- 语义：下载一个文件：
client和NN交互文件元数据获取fileBlockLocation
NN会按照距离策略排序返回
Client尝试下载block并校验数据完整性 - 语义：下载一个文件其实是获取文件的所有block元数据，那么子集获取某些block应该成立
Hdfs支持Client给出文件的offset自定义连接哪些block的DN，自定义获取数据
这个是支持计算层的分治、并行计算的核心
Block的副本放置策略
- 第一个副本：放置在上传文件的DN，如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点
- 第二个副本：放置在与第一个副本不同机架的节点上
- 第三个副本：与第二个副本相同的机架的节点
- 更多副本：随机节点
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
