设计NameNode的元数据管理机制

124 阅读4分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 2 月更文挑战」的第 2 天,点击查看活动详情

设计 NameNode 的元数据管理机制

什么是元数据?

我们都知道在分布式存储系统中的 NameNode 是不会实际存储文件的,NameNode的作用是存储文件系统中的元数据信息,包括文件的名称、位置、权限以及访问者所需的其他信息

元数据可以大致理解为一种逻辑结构,记录着文件的层级关系、位置信息等!

实际的文件数据存储在 DataNode 上,而 NameNode 负责管理 DataNode 上文件的位置和配置。

NameNode确实不会直接存储文件数据,但是它需要跟踪每个文件的元数据;因此它内部还需要维护一棵目录树,来记录每个文件的位置、大小、权限、版本等信息。这样,当NameNode守护进程接收到文件读写请求时,它便可以根据目录树中的信息来指引DataNode守护进程去相应的DataNode节点读取/写入文件了。

NameNode 中的是逻辑目录树,它只是通过了一定的数据结构,如List,Map等,来记录文件的层级关系,而并不会在文件系统中实际创建文件.

NameNode 重启时,恢复元数据

因为元数据是文件逻辑结构在内存中的信息,在 NameNode 关机之后,内存中的信息就被清空了;所以在 NameNode 重启的时候需要想办法重新加载之前的元数据。

元数据是和实际的文件一一对应的,如果元数据丢失了,那么就再也找不到实际文件的位置了(哪怕文件在系统中真实存在)

基于 editslog 机制实现 Master 重启之后的数据恢复

为了保存 NameNode 内存中的元数据,所以我们需要设计一个机制,在合适的时候将元数据持久化。

我们的第一反应应该都是将它存储到磁盘文件中去的,那么这里面应该怎么设计呢?

这里考虑以下几个问题:

  1. editslog 是以什么形式来存储,什么格式(如何序列化?)
  2. editslog 是单文件读写,还是拆分成多文件?
  3. 单纯的 editslog 存在什么问题没有?

问题一:editslog 的存储格式

hadoop 中采用的是它自己独特的序列化机制。。。

基于特殊的序列化的机制,写入磁盘文件的东西看起来跟乱码一样的,在用的时候不是很方便,但是因为经过了压缩处理,所以会很节约磁盘的空间开销。

中间件系统在设计磁盘上的数据存储格式的时候,序列化方式的时候,考虑这个数据有多大,如果数据量很大很大的话,那必须精心设计一套数据存储格式,尽可能用二级制类的bit位来代表很多东西,long很多bit位就可以代表很多信息了,kafka就是这样,每条数据的大小就被压缩到了极致。kafka,磁盘文件日志去存储写入的所有的消息,每天可能上 TB 的,所以说它必须精心设计他的消息格式,序列化的方式,尽可能紧凑的压缩消息的存储,用最少的bit位去存储尽可能多的信息,节约磁盘开销。

但是我们这里考虑到的是分布式文件系统,文件目录树对应的磁盘文件,其实不会太大,如果太大的话,也可以分成几个文件来存放,一般来说都还好。所以说不用过于讲究,直接用简单易用的 JSON 格式,一行放一个 editslog 即可。

问题二:editslog 文件是否需要拆分?

单文件的读写性能是会随着文件变大而下降的,而分布式系统中的 editslog 是不断增长的,所以需要采取分段存储的机制。

先写入一个文件,待文件大到阈值之后,就拆分出一个新文件;一般来说建议单个日志文件的大小不要超过1GB。

问题三:editslog 机制还存在的问题?

对 editslog 文件进行拆分解决了单文件过大读取性能很差的问题,但是在 NameNode 重启时,还是需要读取所有的 editslog 文件,因为所有文件加起来才是完整的元数据;随着系统投入时间的增加,editslog 文件数量可能是巨大的,这样会导致 NameNode 重启时间很久。