大数据 | HDFS 元数据持久化笔记

一、HDFS 架构简单介绍

二、角色功能

三、常用的持久化方案

        很多基于内存的存储，在使用持久化时，持久化方案通常有几种方案，包括日志文件、内存 Dump 和 两种的混合方式。先来说一下比较常用的缓存系统 —— Redis。Redis 的持久化方式分为 AOF、RDB 和 混合方式。Redis 的 AOF 属于日志记录文件，它会记录每条命令到文本文件中，RDB 属于内存 Dump 的方式，它会全量的保存内存的信息，混合方式是 AOF 和 RDB 两者共用的方式。（Redis 为了解决 AOF 体积的问题，提供了 AOF 重写的命令）

四、HDFS 元数据的持久化

        FsImage 严格来讲算不上是一个 内存 Dump，因为 FsImage 的创建是在部署完 HDFS 后格式化时生成的。在 NameNode 第一次启动时读取的是一个空的 FsImage 文件（当然，它可能有它的内部结构，但是此时它不包含元数据等信息）。在之后的 NameNode 启动时，会去读 EditsLog 和 FsImage，此时会将所有的 EditsLog 中的记录作用在内存中的 FsImage 上，并将新版本的 FsImage 从内存中保存到磁盘上，然后删除旧的 EditsLog 文件。通过这种方式，HDFS 的内存中就得到了上次关机时的全量数据。

        FsImage 需要滚动更新，FsImage 的滚动更新并非进行 内存 Dump，而是通过当前 FsImage 文件和增量的 EditsLog 文件形成新的 FsImage 文件，然后将新的 FsImage 替换旧的 FsImage 文件。而增量的 EditsLog 文件则被删除，重新记录新的 EditsLog 文件。

        注意：NameNode 持久化不包含每个文件的块的位置，因为文件块的位置由 DataNode 主动进行上报。

五、Secondary NameNode 的引入

        由于滚动更新 FsImage 文件，也是比较耗时耗力的原因，HDFS 给 NameNode 提供了一个秘书，即 Secondary NameNode。Secondary NameNode 并非是第二个 NameNode，因为它不存储元数据，它的作用是完成 FsImage 和 EditsLog 的合并。通常 Secondary NameNode 和 NameNode 不在同一主机。Secondary NameNode 通过 http get 方式获取 NameNode 主机上的 FsImage 和 EditsLog，合并后通过 http post 方式提交给 NameNode，从而生成新的 FsImage 文件。

        当 Secondary NameNode 将 EditsLog 拉取以后，NameNode 会将将新的日志记录到新的 EditsLog 中。

六、总结

        学习 HDFS 持久化时，想到了 Redis 的持久化，因为很多技术的实现不同，但是它们在理论上几乎是相同的，或者是变通的。这里通过类比的方式，感觉理解其他技术时就会容易一些。上面总结了 HDFS 的 主/从架构，即 NameNode 和 DataNode，其在 HA 模式下还有主备的概念，涉及到选主的一致性算法等知识，之后再进行整理，希望喜欢的读者可以给点赞、关注！