NameNode元数据管理机制

1.namenode的元数据放在内存加磁盘中。
为什么要放在内存中？ 因为客户端经常要做一些操作。
那么namenode放在内存中是什么东西？ 是一颗树，这个树其实就是一个对象。我们可以估计一下这个对象的大小。每记录一个块，就要耗费大概150Byte。假如我们存10个块，就是1.5k，存10000个块就是1.5M,再扩大1000倍就是1.5G。这里只是namenode的大小，如果一个块128M则整个文件将会达到P级别。当然真正的数据会存到datanode上。所以namenode要求的机器内存一般要32G以上。所以如果我们每个文件都很小，每个块都是128M,机器会耗费大量内存去记元数据，但是文件本身的体积又不大，这个时候的效率就比较低。所以hdfs不适合存储大量的小文件。存大文件才划算。
2.万一有一天namenode宕机了，元数据就会全丢掉，这样就不安全了。既然namenode中存放的是对象，就代表可以序列化到磁盘。万一文件中有属性做了修改，我们又要重新覆盖一遍文件。做一点点修改，就要覆盖一遍。这样做机器早就卡死了，所以我们也不能这样做。**
3**.假如我们修改了数据，内存中的数据好改，但是磁盘中的镜像文件（磁盘中的镜像文件是由hadoop namenode-format生成的叫做fsimage）不好改，那么我们怎么做呢？我们就不改。客户端做的操作，内存中会立刻修改，同时会在磁盘中记录日志(这个日志也有名字：edits)。这样假如namenode宕机了，我们也可以根据日志记录恢复，如果数据过多，会让启动时间变长。所以namenode就会有一个助理secondary namenode,他会定期的将日志文件下载过来，而且第一次下载的时候会把镜像文件fsimage下载过来secondary namenode会有元数据计算引擎。它会把fsimage（镜像）加载到内存中变为内存元数据对象，然后元数据计算引擎会解析edits日志文件。一边加载，一边解读，一边修改元数据。等加载完之后这批数据就是比较新的了。接着secondary namenode要把元数据重新序列化成fsimage镜像文件,将其上传给namenode.这样做的话如果namenode宕机之后，它只要下载最新编号的镜像文件即可，而secondary namenode不必每次都下载镜像文件，因为它本身就拥有最新编号的镜像文件。它只需要下载最新编号的日志文件。但是是不是每次上传的日志以及镜像都会保存？当然不会，因为这样太占空间，对于镜像文件他会保留最近的两个，对于日志会多保留几个，但是过期的日志也不会马上删掉。

---------------------**
作者：爱米酱
来源：CSDN
原文：https://blog.csdn.net/qq_37050372/article/details/81484232