Hadoop

存储模型

• 文件线性按字节切割成块，具有offset，id
• 文件和文件的块的大小可以不一样
• 一个文件除了最后一个块，其他块的大小都一样
• 块的大小应该一句硬件的 I/O 特性调整
• 块被分散存放在集群的节点中，具有location
• 块具有副本，没有主从概念，副本不可能出现在同一个节点
• 副本是满足可靠性和性能的关键
• 文件上传可以指定lock大小和副本数量，上传之后只能修改副本数量
• 一次写入多次读取，不支持修改
• 支持追加数据

架构设计

• HDFS是一个主从 (Master/Slaves) 架构
• 由一个NameNode和一些DataNode组成
• 面向文件包括 : 文件数据 (data) 和一些文件元数据 (metadate)
• NameNode负责存储和管理文件元数据，并维护了一个层次型的文件目录树
• DataNode负责存储文件数据 (block块)，并提供 block 的读写
• DataNode 与NameNode 维持心跳，并汇报自己持有的block信息
• Client和NameNode交互文件元数据 ， 与DataNode交换文件block数据

角色功能

• NameNode
  • 完全基于内存存储文件元数据、目录结构、文件Block的映射
  • 需要持久化方案保证数据可靠性
  • 提供副本放置策略
• DataNode
  • 基于本地磁盘存储 block (文件的形式)
  • 并保存 block 的校验和数据保证 block 的可靠性
  • 与 NameNode 保持心跳，汇报 block 列表状态

元数据持久化

• 任何对文件系统元数据产生修改的操作，NameNode都会用一种叫做EditLog的事物日志记录下来
• 使用FsImage存储内存中所有的元数据状态
• 使用本地磁盘保存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上

HDFS中的SNN

• SecondaryNameNode (SNN)
  • 在非Ha (High avaliable) 模式下，SNN一般是独立的节点，周期完成对 NameNode 的 EditLog 向 FsImage 合并，减少 EditLog 的大小，减少 NameNode 启动时间
  • 根据配置文件设置的时间间隔 fs.checkpoint.period 默认3600秒
  • 根据配置文件设置EditLog大小 fs.checkpoint.size 规定edits文件的最大值 默认64MB

Block的副本放置策略

• 第一个副本：放置在上传文件的DN；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点
• 第二个副本：放置在与第一个副本不同的机架的节点上
• 第三个副本：与第二个副本相同机架的节点
• 更多副本：随机节点

HDFS写流程

• Client 和 NameNode连接创建文件元数据
• NameNode 判断元数据是否有效
• NameNode 触发副本放置策略，返回一个有序的 DateNode 列表
• Client 和 DataNode 建立 Pipeline 连接
• Client 将块切分成 packet(64KB) ，并使用 chunk(512B) + chucksum(4B) 填充
• Client 将 packet 放入发送队列 dataqueue 中，并向第一个 DataNode 发送
• 第一个DataNode收到packet后本地保存并发送给第二个DataNode
• 第二个DataNode收到packet后本地保存并发送给第三个DataNode
• 这一个过程中，上游节点同时发送下一个packet
• （流式也是变种的并行计算）
• HDFS使用这种传输方式，副本数对于Client式透明的
• 当Block传输完成，DataNode各自向NameNode汇报，同时Client继续传输下一个Block
• 所以Client的传输和Block的汇报也是并行的、

HDFS读流程

• 尽量让读取程序读离他近的副本
• 如果在读取程序的同一个机架上有一个副本，那么就读取该副本
• 如果一个HFDS集群跨越多个数据中心，那么客户端也将首先读取本地数据中心的副本
• 语义：下载一个文件：
  • Client和NameNode交互文件元数据获取FileBlockLocation
  • NameNode按照距离策略返回
  • Client尝试下载block并校验数据完整性
• 语义：下载一个文件其实是获取文件的所有的 block 元文件数据，那么子集获取block应该成立
  • HDFS支持client给出文件的offset自定义哪些block的DataNode，自定义获取数据
  • 这个是支持计算层的分治，并行计算的核心

标签：HDFS,副本,EditLog,文件,Hadoop,DataNode,NameNode,概述,block
来源： https://blog.csdn.net/weixin_43410596/article/details/113405325