HDFS之基本理论

元数据持久化

• 基本概念：
  1）日志文件：记录实时发生的增删改的操作，是一个文本文件，通过追加的方式进行添加，其优点是完整性好，但其加载回复数据较慢而且占用空间大。
  适用场景：体积小，记录少
  2）镜像/快照/dump：间隔（单位可以是小时，天，10分钟，1分钟，5秒钟），内存全量数据基于某一个时间点做的向磁盘的溢写。 —— 间隔时间不能太短，由于磁盘I/O速度较慢。其优点在于，恢复速度快，但容易丢失一部分数据。
  使用场景：滚动更新快

• HDFS是结合使用的，使用EditsLog日志文件和FsImage镜像/快照。最近时点的FsImage + 增量的EditsLog。例如：现在10点，存在FI： 9点 + 9点到10点的EL。所以只需要：1. 加载FI 2.加载 EL 3. 恢复

• 任何对文件系统元数据产生的修改操作，NameNode都会使用EditsLog日志记录下来。并使用FsImage存储内存中的所有数据

• FI如何更新：
  当Namenode第一次开机的时候，只写一次FI。假设当前8点，则到9点的时候，只需要将8-9点的日志中的记录，更新到8点的FI中，则FI变成了9点的（当前的）FI。 —— 需要寻求另一台机器来做。

• 为什么需要另一台机器合作：
  若不合作，则需要先从FI中读取数据，然后将修改写入，再写入磁盘。不如直接落盘。若加入了另一台机器协作，NameNode就可以直接专注于自身的工作。
  另一方面，若由NameNode直接在时间间隔达到后向磁盘写入，可能出现没有/极少变化，但要重写整个文件内容的情况。

HDFS格式化和启动：

• HDFS搭建的时候会格式化，格式化总会产生一个空的FsImage
• 当NameNode启动时，会从硬盘中读取EditLog和FsImage
• 将所有EditLog中的事务作用于在内存中的FsInage上，并将这个新版本的FsImage从内存保存到本地磁盘，然后删除旧的Editlog事务记录，因为旧的Editlog已经作用在FsImage中

NameNode会存储元数据和block位于哪个DataNode上，但在持久化的时候，文件元数据会持久化，但是文件的每个块的位置不会做持久化；故而在恢复的时候，NameNode会丢失块的位置。

为什么这么设计？
分布式时代，最重要的是数据一致性，若将block的位置信息持久化，虽然client在获取的时候会更快。但若某个DataNode无法正常工作，则返回的block将会是错误的。为保证数据一致性，NameNode不会对数据位置进行持久化，而是等待DataNode向NameNode汇报其位置信息（心跳）。

安全模式