Hadoop NameNode详解

谁践踏了优雅 2022-06-04 04:44 835阅读 1赞

NameNode在内存中保存着整个文件系统的名字空间和文件数据块的地址映射(Blockmap)。如果NameNode宕机，那么整个集群就瘫痪了  
整个HDFS可存储的文件数受限于NameNode的内存大小  
这个关键的元数据结构设计得很紧凑，因而一个有4G内存的Namenode就足够支撑大量的文件和目录。

一般情况下，单namenode集群的最大集群规模为4000台

NameNode负责：文件元数据信息的操作以及处理客户端的请求
    NameNode管理：HDFS文件系统的命名空间NameSpace。
    NameNode维护：文件系统树（FileSystem）以及文件树中所有的文件和文件夹的元数据信息（matedata） 
            维护文件到块的对应关系和块到节点的对应关系
    NameNode文件：namespace镜像文件（fsimage），操作日志文件（edit log）
            这些信息被Cache在RAM中，当然这两个文件也会被持久化存储在本地硬盘。
    NameNode记录：每个文件中各个块所在的数据节点的位置信息。
            但它并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建。
            从数据节点重建：在nameNode启动时，DataNode向NameNode进行注册时发送给NameNode

**1、NameNode元数据信息**  
文件名，文件目录结构，文件属性(生成时间，副本数，权限)每个文件的块列表。  
以及列表中的块与块所在的DataNode之间的地址映射关系  
在内存中加载文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息)  
数据会定期保存到本地磁盘，但不保存block的位置信息而是由DataNode注册时上报和在运行时维护

**2、NameNode文件操作**  
NameNode负责文件元数据的操作  
DataNode负责处理文件内容的读写请求，数据流不经过NameNode，会询问它跟那个DataNode联系

**3、NameNode副本**  
文件数据块到底存放到哪些DataNode上，是由NameNode决定的，NN根据全局情况做出放置副本的决定  
读取文件的时候，NN尽量让client读取离它最近的datanode上的副本，降低带宽消耗和读取时延

**4、NameNode职责**  
全权管理数据块的复制，周期性的接受心跳和块的状态报告信息（包含该DataNode上所有数据块的列表）  
若接受到心跳信息，NN认为DN工作正常，如果在10分钟后还接受到不到DN的心跳，那么NN认为DN已经宕机  
这时候NN准备要把DN上的数据块进行重新的复制。  
块的状态报告包含了一个DN上所有数据块的列表，blocks report 每个1小时发送一次

**5、NameNode容错机制**  
没有Namenode，HDFS就不能工作。事实上，如果运行namenode的机器坏掉的话，系统中的文件将会完全丢失，因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此，namenode的容错机制非常重要，Hadoop提供了两种机制。

第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统（NFS）。

第二种方式是运行一个辅助的Namenode(SecondaryNamenode)。 事实上SecondaryNamenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。通常，SecondaryNamenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。

但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。

**6、NameNode物理结构**

master节点 /home/wuhuan/hadoopdata/dfs/name,namesecondary 
      name/current,in_user.lock
        in_use.lock  是一个锁，用来保证namenode的唯一性
        current 就是当前namenode存储元数据的目录
        current/edits  --- 对hdfs进行读写操作时产生的元数据的记录文件
        current/fsimage  ---- 镜像文件，是edits经过secondaryNamenode合并后产生的高密度镜像文件。
    
    
    VERSION：
      其中namespaceID是文件系统的唯一标识符，当文件系统第一次被格式化的时候会被创建
      这个标识符也要求所有的DataNode节点和NameNode保持一致
      NameNode会使用它识别新的DataNode，DataNode只有在向NameNode注册后才会获取namespaceID

**Edit Log**

edits为二进制文件，记录对HDFS的各种更新操作，客户端执行所有的写操作都会被记录到editlog中。
    比如创建文件，删除文件。打开、关闭、重命名文件和目录，都会生成一个edit记录。
    
    客户端对hdfs进行写文件时会首先被记录在edits文件中。
    edits修改时元数据也会更新。每次hdfs更新时edits先更新后客户端才会看到最新信息。

**namespace Image**

fsimage为二进制文件，保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件信息。
        对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。
        对于文件来说包括数据块描述信息、修改时间、访问时间等；
    
    简单的说，Fsimage就是在某一时刻，整个hdfs的快照
    就是这个时刻hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，副本个数等。
    【注意】Block的位置信息不会保存到fsimage，由DataNode在向NameNode进行注册时重新加载和定期加载。
    
    一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？
        因为fsimage是namenode的完整的镜像，内容很大
        如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。
    
    把文件和目录的元数据信息持久化地存储到fsimage文件中，每次启动时从中将元数据加载到内存中构建目录结构树
    之后的操作记录在edits log中，定期将edits与fsimage合并刷到fsimage中

**7、NameNode文件结构**

最新格式化的NameNode会创建以下目录结构：
      $ {dfs.name.dir}                    //dfs.name.dir是一个目录列表，是每个目录的镜像
      $ {dfs.name.dir}/current/VERSION     //Java属性文件，其中包含运行HDFS的版本信息
      $ {dfs.name.dir}/current/edits
      $ {dfs.name.dir}/current/fsimage
      $ {dfs.name.dir}/current/fstime
    
    VERSION文件包含的内容：
          #Wed Mar 23 16:03:27  CST 2017
          namespaceID=1064465394    //文件系统的统一标识符，在文件系统第一次被格式化时创建
                                    这个标识符也要求各DataNode节点和NameNode保持一致
                                    NameNode会使用此标识符识别新的DataNode
                                    DataNode只有在向NameNode注册后才会获得此namespaceID。
    
          cTime=0                  //标记了NameNode存储空间创建的时间
                                    当文件系统被更新，它就会更新到一个新的时间戳。
    
          storageType=NAME_NODE     //用于指出此存储目录包含一个NameNode的数据结构
                                    在DataNode中空属性值为DATA_NODE
    
          layoutVersion=-18         //layoutVersion是一个负的整数，定义了HDFS持久化数据结果的版本
                                    每次HDFS的布局发生改变，该版本号就会递减（比如-18之后是-19）
                                    在这种情况下，HDFS就需要更新升级，各节点的版本号要保持一致

**NameNode的存储目录**

包括edits、fsimage、fstime三个文件（二进制文件）。可以通过HadoopWritable对象进行反序列化。
    hdfs的命名空间存储在namenode的内存中，EditLog/FsImage存储在namenode本地的文件系统中
        EditLog事务日志
            记录发生在文件系统元数据上的所有变化。
            编辑日志会在每次成功操作之后，成功代码尚未返回给客户端之前进行刷新和同步。
            对于要写入多个目录的操作，写入流要刷新和同步到所有的副本
            这就保证了操作不会因故障而丢失数据。
    
            比如：
            在文件系统中创建一个文件，namenode就会在EditLog中插入一条记录标记一下。
            同样的，修改一个文件的副本因子同样会在触发EditLog中插入一条记录。
    
        FsImage文件
            是文件系统元数据的持久性检查点checkpoint。
            存放整个系统的命名空间，包括块和文件的映射表，文件系统属性
            一个fsimage文件包含以序列化格式存储的文件系统目录和文件索引
            每个索引表示一个文件或目录的元数据信息，以及文件的副本数、修改和访问时间等信息。
    
            和编辑日志不同，它不会在每个文件系统的写操作后都进行更新
            因为写出fsimage文件会非常慢（fsimage可能增长到GB大小）。这种设计并不会影响系统的恢复力
            如果NameNode失败，可以通过读出磁盘中fsimage文件加载到内存中来进行重建恢复
            然后重新执行编辑日志中的操作。事实上，这也正是NameNode启动时要做的事情。