HDFS元数据更新机制

我们知道NameNode是记录文件元数据的,那么他是如何保证数据的完整性和准确性的呢?
咱们来大概了解一下
前言:
1.首先在大规模数据量的前提下,元数据的数量是以亿计的,为了提高查询效率,所以都会在内存中操作.
2.每条元数据150byte,无论datanode上占有多少内存,元数据的大小都一样,所以为了提高内存的利用率,建议不要存放过多小文件,避免因为元数据的溢出但是datanode上内存反而没有充分利用.

更新机制:
1.当客户端向namnode发送请求,查询或者更新元数据的时候
2.namenode会实时把更新的日志文件存放在edits_inprofress上,机制被触发,该文件就会滚动生成edits日志文件,并且又有新的edits_inprofress生成
3.准确的说负责更新元数据是在SecondaryNameNode上进行的,会有一个触发机制,SecondaryNameNode会定时向NameNode请求是否更新数据
4.如果条件允许,达到了一定的时间或者是edits文件数量达到了上限,就会触发更新机制
5.在更新元数据之前namenode会把edits_inprogress文件进行一次滚动,生成edits文件,为了更多的进行更新操作
6.在edits_inprogress文件滚动生成edits文件按的时候会更新一个记录,这个数字用于在更新元数据的时候确定哪些edits序号是旧的edits,是可以进行更新的文件
7.当一切都符合更新条件的时候,SecondaryNameNode会从namenode上下载元数据的镜像文件image以及那些需要被更新的edits文件
8.当文件下载完成,就会在SecondaryNameNode的内存上进行更新,把日志文件重放,把更改的日志记录重新扫描进行更新
9.更新完成就会dump成一个新的镜像文件image_checkpoint,存在SecondaryNameNode中
10.把新的镜像文件image_checkpoint上传至NameNode上
11.NameNde把新的文件重命名成原来的名字,覆盖掉旧的文件即可

文件恢复:
当涉及到namenode文件损坏的时候如何恢复数据?
1.第一种方式可以从namenode上的日志文件和镜像文件上恢复,但是会损失部分数据,那些来不及滚动的edits_inprogress文件没有被序列化出来
2.最坏的方式就是从secondarynamenode上恢复,但是这样损失的数据相对更大