HDFS

Hadoop-HDFS

 

1、存储模型：字节

• 文件线性切割成块（Block），偏移量（假设100bytes切割成10块，偏移量为0，10，20…，作用就是知道数据在哪里，方便管理）
• Block分散存储在集群节点中
• 单一文件Block大小一致，文件与文件之间可以不一致
• Block可以设置副本，副本无序分散在不同节点上，且副本数不能超过节点数量。（设置副本是为了保证在一台服务器出现问题时，其他服务器还能继续工作，不超过节点数量是因为没有意义）
• 文件上传可以设置Block大小和副本数
• 已上传的文件Block副本数可以调整，大小不变（因为如果大小变了，那么偏移量就要变，所有的索引都要变，工作量很大）
• 只支持一次写入多次读取，同一时刻只有一个写入者
• 可以append追加数据，在末尾添加

 

2、架构模型

• 文件元数据MetaData：元数据保存的不是数据本身，而是数据的信息，比如数据的大小，数据的偏移量等
• (主节点）NaneNode节点保存文件元数据：单节点（单个服务器存储）
• (从节点）DataNode节点保存文件Block数据：多节点
• DataNode与NameNode保持心跳，NameNode提交Block列表（当DataNode里面的数据发生变化时，应该主动向NameNode提交Block列表信息，NameNode可以及时更新信息）
• HdfsClient与NameNode交互元数据信息（HdfsClient只与NameNode一次交互，因为Client拿到元数据之后就不需要再访问NameNode了，直接去与DataNode交互就可以了）
• HdfsClient与DataNode交互文件Block数据
• DataNode利用服务器本地文件系统存储数据块（分发给DataNode的数据都是存储在服务器本地的）

 

总结：NameNode相当于图书馆管理员，HdfsClient只要去NameNode拿到图书信息，就可以去找到想要的DataNode里面的数据了。NameNode要与DataNode保持联系，DataNode数据发生变化需要向NameNode回报。 

3、NameNode（NN）

 

— 基于内存存储

• 只存在内存中
• 持久化（NameNode只存在内存中会出现一个问题，那就是内存会满或者断电，所以需要定期持久化操作，将数据存入磁盘中，这是单向的）

— NameNode主要功能

• 接受客户端的读写操作
• 收集DateNode汇报的Block列表信息

— NameNode保存metadata信息包括

• 文件ownership和permissions
• 文件大小，时间
• Block列表：Block偏移量，位置信息（持久化不存）
• Block每个副本的位置（由DataNode上传）

— NameNode持久化

• NameNode的metadata信息在启动后会加载到内存
• matedata存储到磁盘文件为“fsimage”（时点备份，因为不需要不停的备份，这样内存跟磁盘又在交互，速度会下降。）

 

4、NameNode持久化

   （将内存中的元数据信息永久的保存在磁盘之上）

• NameNode的metadata信息在启动后会加载到内存
• metadata存储到磁盘文件名为“fsimage”（磁盘镜像快照，是一个序列化的过程，转换成二进制文件，方便传输以及跨平台使用，恢复的时候只要做反序列化操作即可，且速度很快。时点备份）
• Block的位置信息不会保存到fsimage
• edit记录对metadata的操作日志—>Redis（写的时候速度很快，但是文件大的话，恢复就会很慢）

 

总结：fsimage写很慢，恢复快；edits写很快，恢复慢，所以可以结合两者的优势。

 

合并方法：在hadoop集群还没有开始跑起来的时候，就进行格式化操作，在格式化操作后，会产生fsimage文件以及edits的日志文件，将两者合并生成一个新的fsimage文件。

fsimage + edits —> fsimage

由于edits生成的文件比较大，且恢复很慢，所以定期重复上述的合并操作，生成fsimage文件。因为fsimage文件恢复快，所以当需要恢复时，只是恢复fsimage文件，速度很快。

 

谁做合并工作？

答：SecondaryNameNode（SNN）hadoop1.0有。

它不是NN的备份（但是可以做备份），它的主要工作时帮助NN合并edits log，减少NN启动时间。

SNN执行合并时机

• 根据配置文件设置时间间隔，默认为3600秒
• 根据配置文件设置edit log大小 fs.checkpoint.size规定edits文件的最大值默认为64MB

5、DataNode（DN）

• 本地磁盘目录存储数据（Block），文件形式
• 同时存储Block的元数据信息文件（仅本磁盘数据信息）
• 启动DN时会向NN汇报block信息
• 通过向NN发送心跳保持与其联系（3s/次），如果NN 10 分钟没有收到DN的心跳，则认为其已经lost，并copy其上的block到其它DN（为什么要等10分钟，因为文件可能比较大，如果很短时间就copy的话花费比较大，可能NN是发生了断网或者其他情况，等待10分钟会比copy的代价小很多） 

6、HDFS的优点

— 高容错性

• 数据自动保存多个副本
• 副本丢失后，自动回复

— 适合批处理

• 移动计算而非数据（将计算框架移到数据身边，因为移动数据成本太大）
• 数据位置暴露给框架（Block偏移量）

— 适合大数据处理

• GB、TB、PB数据
• 百万规模以上文件数量

— 可构建在廉价机器上

• 通过多副本提高可靠性
• 提供容错恢复机制 

7、HDFS的缺点

— 低延迟数据访问

• 比如毫秒级
• 低延迟与高吞吐量

— 小文件存取

• 占用NameNode大量内存
• 寻道时间超过读取时间

— 并发写入、文件随机修改

• 一个文件只能有一个写者
• 仅支持append 

8、Blcok的副本放置策略

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

9、HDFS写流程

 

— Client

• 切分文件Block
• 按Block线性和NN获取DN列表（副本数）
• 验证DN列表后以更小的流式传输数据（各节点两两通信确认可用）
• Block传输结束后：

           — DN向NN汇报Block信息

           — DN向Client汇报完成

           — Client向NN汇报完成

• 获取下一个Block存放的DN列表
• 。。。。。
• 最终Client汇报完成
• NN会在写流程更新文件状态 
  

10、HDFS读流程

— Client：

• 和NN获取一部分Block副本位置列表
• 线性和DN获取Block，最终合并为一个文件
• 在Block副本列表中按距离择优选择服务器
• MD5验证完整性 
  

总结:

角色（NameNode）= = 进程

— NameNode

• 数据的元数据
• 内存存储，不会有磁盘的交换
• 持久化（fsimage、edits log）

        不会持久化block位置信息

• block不可调整大小，hdfs不支持修改文件

— DataNode

• block块
• 本节点元数据
• 磁盘
• 面向文件，大小一样，不可调整
• 副本数，可调整（备份，高可用，容错/可以调整很多歌，为了计算向数据移动）

— SNN

— NN&DN

• 心跳机制
• DN向NN汇报block数据
• 安全模式