白话聊聊Hadoop的Namenode是怎么管理元数据的？

      什么是元数据呢？百度百科的解释是这样的，描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录，为了达到编制目录的目的，必须在描述并收藏数据的内容或特色，进而达成协助数据检索的目的。说了这么了多，简单地说，就是管理数据的数据。

      在hadoop中有两个角色，namenode(一个主节点),datanode（多个从节点），datanode主要是存储数据的，namenode一是管理文件系统文件的元数据信息（包括文件名称、大小、位置、属性、创建时间、修改时间等等），二是维护文件到块的对应关系和块到节点的对应关系，三是维护用户对文件的操作信息（文件的增删改查）。

      现在我们假设一下，如果元数据仅以文件的形式存储在namenode本地硬盘，这样行不行？因为大批量的客户端同时在进行上传、下载等各种操作时，都要对元数据进行读写及修改操作，仅仅以文件的形式来存储元数据显然不行，因为无法做到对各种操作的快速响应，把元数据放在内存中呢，确实能够提高系统响应速度，但是一旦断电就完全丢失了，这肯定也不行，那么如果把内存的数据定期flush到磁盘文件的方法行不行呢？一旦断电，没来得及的刷到磁盘的内存数据肯定也是要丢失的，显然也不行，那么在实际环境中，hadoop是怎么管理元数据的呢？

      首先，磁盘确实有块空间，对元数据进行持久化存储的，名为fsimage,如果直接读取磁盘文件，速度肯定跟不上，内存中也要放一些元数据信息，虽然很容易丢失，但可以提供查询服务，实际上就是读写分离，由读写分离就有了数据一致性的问题，因为写入数据，没有写入内存中，最新的元数据记录在哪呢？实际上是记录在一个很小的文件中，这个文件不提供修改，只提供追加，以日志的形式记录，一直都保持着几十兆大小，名为edits***.log，比如在上传一个文件时，先对NAMENODE进行询问，往哪里写，NAMENODE一边分配一边记录，将空间分配信息记录edits**.log，当完成一个副本的写入工作后，通知NAMENODE,被认为是写入成功，这时，将edits**.log的数据更新至内存，此时，内存中的数据是最新的，即使现在断电，最新的元数据在edits**.log也有保存。

      回顾一下这个过程

      1、  客户端写入文件时，NAMENODE首先往edits**.log文件中记录元数据操作

      2、  客户端开始上传文件，完成后成功信息给NAMENODE,NAMENODE就在内存中写入这次上传操作的新产生的元数据信息，edits**.log文件大小有一定的范围，比较小， fsimage文件就是内存的镜像文件，fsimage是最全的，edits**.log是最新的，更新的顺序是先edits**.log,其次是内存，最后是fsimage，那fsimage什么时候更新呢，内存和fsimage如何保持一致性？只要edits**.log在没有写满时不需要同步，这里提一下check point操作，是指每当edits**.log写满时，需要将这一段时间的新的元数据刷进fsimage，将edits**.log与fsimage合并

      3、  为防止影响响应速度，由SecondaryNamenode来做edit**.log与fsimage的合并工作，当edits**.log写满时，通知SecondaryNamenode进行checkpoint操作，停止往edits文件中写数据，SecondaryNamenode下载fsimage和edits文件，合并生成新的fsimage,将新的内存镜像上传给Namenode,替换老的fsimage,删除老的edit**.log,将edits new文件命名为edits**.log

      通过上述操作，可以看出在任务进行时，在任务时间点断电，都不会丢失数据了。