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

发布了28 篇原创文章 · 获赞 22 · 访问量 1万+

猜你喜欢

转载自blog.csdn.net/dlrb_beautiful/article/details/88376611
今日推荐