大数据学习之路8-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宕机之后，它只要下载最新编号的镜像文件即可，而secondar