hadoop的Namenode元数据管理运行机制【笔记】

Namenode元数据，那么首先要知道什么是Namenode元数据。

比如，我们这里有4个节点（h0，h1，h2，h3）存放一个数据a.log

这个a.log被切割成了两块（blk_1，blk_2）

我们知道，这些数据由NameNode管理存放在了这些这些节点上的如下面的表格：

为了大家能够更加直观的看懂，我也简单的画了一张图：

[caption id="attachment_1050" align="alignnone" width="800"]Namenode元数据与DataNode[/caption]

那么这个文件的元数据就是这样的

NameNode(/a.log，3，{blk_1,blk_2}，[{blk_1:[h0,h2,h3]},{blk_2:[h0,h1,h2]}])

可以看出来他的元数据格式就是如下格式：

NameNode(FileName，replicas，block-ids，id2host...)

其意思是：

FileName：文件名

replicas：备份

block-ids：文件被切割的块

id2host：文件块被存放在那些节点上

那么综上所示，什么是元数据呢？我自己定义的就是：

包含了这个文件的基本信息：如，文件名，备份数，块数据以及节点数据等信息的数据就叫元数据

下面我们说说他的管理和运行机制，一共分为六步：

第一：客户端请求上传文件

第二：NameNode表示可以上传，并通知客户端按照可以上传文件

第三：客户端上传完毕，通知NameNode

第四：NameNode产生元数据，将元数据保存在内存和edits.log里

为什么保存在内存里，而不是保存在磁盘里（第五提到的FsImage），答案很简单，因为读取内存的数据是最快的。

edits.log是一个小的磁盘文件，对小磁盘文件进行操作对性能损耗要低很多

第五：当edits.log满了的时候就需要将edits.log与磁盘的元数据文件FsInage进行合并

FsImage就是我们的磁盘元数据，这个东西随着时间越久，他的容量会很大

但是当我们将edits.log与FsInage合并时会产生很大的IO操作，这可定是不行的

第六：把合并任务交给Secondary NameNode来处理

处理机制如下：

6.1：按edits.log的容量

6.1.1：当edits.log的容量满了，NameNode产生一个新的edits.new文件，将新的元数据保存在edits.new里

6.1.2：通知Secondary NameNode来下载edits.log和FsImage，并保存到内存操作，为什么是内存！因为快嘛！

6.1.3：当合并完后，产生新的磁盘元数据文件FsImage.chkpoint

6.1.4：通知NameNode删除原来的FsImage，即将下载新的磁盘元数据FsImage.chkpoint，并将这个更名为FsImage

6.1.5：删除edits.log，将edits.new更名为edits.log

6.2：按照时间来处理

思路一样，只是说反过来运行而已，到达到时间后由Secondary NameNode通知NameNodo，后面的都一样

经过以上步骤，NameNode就和之前一样了。

当NameNode启动的时候，就读取FsImage，而FsImage却永远都可以保证是最新的，他可能暂时不是最新的，但他最终的数据却是最全的。