HDFS中的NAMENODE元数据管理（超详细）

元数据管理

• 元数据是什么
• 元数据管理概述
• • 内存元数据
  • 元数据文件
  • • fsimage内存镜像文件
    • edits log编辑日志
    • namenode加载元数据文件顺序
    • 元数据管理相关目录文件
    • • 元数据相关文件
      • VERSION
      • seen_txid
      • 元数据文件查看（OIV,OEV）
      • SecondaryNameNode介绍
      • • checkpoint机制
        • • SNN Checkpoint--触发机制
          • 元数据文件恢复
          • • namenode存储多目录
            • 从SNN中恢复

              元数据是什么

              • 在HDFS中，元数据主要值得是文件相关的元数据，有namenode管理维护。从广义的角度来说，因为namenode还需要管理众多的DataNode结点，因此DataNode的位置和健康状态信息也属于元数据

                元数据管理概述

                在hdfs中，文件相关的元数据具有两种类型：

                • 文件自身属性信息

                  文件名称、权限、修改时间，文件大小、复制因子、数据块大小

                • 文件块位置映射信息

                  记录文件块和DataNode之间的映射信息，即哪个块位于哪个结点上

                  

                  按照存储形式分别为内存元数据和元数据文件两种，分别存在内存和磁盘上

                  内存元数据

                  • 为了保证用户操作元数据交互高效，延迟低，namenode把所有的元数据都存储在内存中，我们叫做内存元数据。内存中的元数据是最完整的，包括文件自身属性、文件块位置映射信息
                  • 但是内存的致命问题是，断点数据丢失，数据不会持久化。因此namenode又辅佐了元数据文件来保证运输局的安全完整

                    元数据文件

                    元数据文件有两种：fsimage内存镜像文件，Edits log编辑日志

                    fsimage内存镜像文件

                    • 是内存元数据的一个持久化的检查点。但是fsimage中仅包含hadoop文件中文件自身属性相关的元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，是由DataNode启动加入集群的时候，向DataNode进行数据块的汇报得到的，并且后续间断指定时间进行数据块报告
                    • 持久化的动作是数据从内存到磁盘的IO过程。会对namenode正常服务造成一定的影响，不能频繁的进行持久化

                      edits log编辑日志

                      为了避免两次持久化之间数据丢失的问题，又设计了edits log编辑日志文件。文件中记录的是HDFS所有的更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到edits文件中

                      

                      namenode加载元数据文件顺序

                      • fsimage和edits文件都是经过序列化的，在namenode启动的时候，它会昂fsimage文件中的内容加载到内存中，之后再执行edits文件中各项操作，是的内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作，也是最完整的元数据
                      • 当客户端对HDFS中的文件进行新增或者修改操作，操作记录首先被计入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存元数据中。因为fsimage文件一般都很大（GB级别的很常见），如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行的十分缓慢
                      • HDFS这种设计实现着手于：一时内存中的数据更新、查询快，极大缩短操作响应时间；二是内存中元数据丢失风险颇高（断电T_T），因此辅佐元数据镜像文件（fsimage）+编辑日志文件（edits）的备份机制进行确保元数据的安全
                      • namenode维护整个文件系统元数据。因此，元数据的准确管理，影响着HDFS提供文件存储服务的能力

                        元数据管理相关目录文件

                        • namenode元数据存储目录由参数：dfs.namenode.name.dir指定

                        • 格式化完成之后，将会在$hdfs.namenode.name.dir/current目录下创建如下的文件：

                          

                        • dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默认值如下

                          

                          元数据相关文件

                          VERSION

                          • namespaceID/clusterID/blockpollID

                            这些都是HDFS集群的唯一标识符。标识符被用来防止DataNodes意外注册到另一个集群中的namenode上。这些宝石在联邦（federation）部署中特别重要。联邦模式下，会有多个namenode独立工作。每个namenode提供惟一的命名空阿静（namespaceID），并管理一组唯一的文件块池（blockpoolID）。clusterID将整个集群结合在一起作为单个逻辑单元，在集群中所有节点上都是一样的。

                          • storageType

                            说明这个文件存储的是什么进程的数据结构信息。如果是DataNode节点，storageType=DATA_NODE

                          • cTime

                            namenode存储系统创建时间，首次格式化文件系统这个属性是0，当问文件系统升级之后的时间戳

                          • layoutVersion

                            HDFS元数据格式的版本。HDFS升级时会进行更新

                            

                            

                            seen_txid

                            • 包含上一次checkpoint时的最后一个事务ID，这不是namenode接受的最后一个事务ID
                            • seen_txid内容不会在每个事务性操作生都更新，只会在checkpoint时更新
                            • namenode启动时会检查seen_txid文件，以验证它至少可以加载该数目的事务。如果无法验证加载事务，namenode将终止启动

                              

                              元数据文件查看（OIV,OEV）

                              • fsimage文件是hadoop文件系统元数据的一个永久性的检查点，包含hadoop文件系统中的所有目录和文件idnode的序列化信息；对于文件来说，包含的信息有修改的时间、访问时间、块大小和组成一个文件块信息等；而对于目录来说，包含的主要有修改时间，访问控制权限等信息
                              • oiv是offline image viewer的缩写，可将hdfs fsimage文件的内容转储为人类可读的格式
                              • 常用命令：hdfs oiv -i fsiamge_00000000000050 -p XML -o fsimage.xml

                                

                              • edits log文件存放的是hadoop文件系统所有更新的操作记录日志
                              • 文件系统客户端执行的所有写操作首先会被记录到edits文件中
                              • oev是offline edits viewer（离线edits查看器）的缩写，该工具不需要hadoop集群处于运行状态
                              • 命令：hdfs oev -i edits_0000000000000000090-00000000000000000000089 -o edits.xml
                              • 在输出文件中，每个RECORD记录了一次操作，示例如下：

                                

                                SecondaryNameNode介绍

                                • SNN可以减小edits logs文件的大小和得到一个最新的fsimage文件，这样也会减小在namenode上的压力

                                  checkpoint机制

                                  1.checkpoint核心是把fsimage与edits log合并生成一个新的fsimage的过程，然后NN会生成一个新的编辑日志文件：edits new，便于记录后续操作记录

                                  2. SNN会将旧的edits log文件和上次fsimage复制到自己本地（使用HTTP GET方式）

                                  3. SNN首先将fsimage载入到内存，然后一条一条的执行edits文件中的操作，使得内存中的fsimage不断更新，这个过程就是edits和fsimage文件合并。合并结束，SNN将内存中的数据dump生成一个新的fsimage文件

                                  4. SNN将新生的Fimage new文件复制到NN节点。至此刚好是一个轮回，等待下一次checkpoint触发secondarynamenode进行工作，一直这样循环操作

                                  

                                  SNN Checkpoint–触发机制

                                  • core-site.xml

                                    dfs.namenode.checkpoint.period=3600 //两次连续的checkpoint之间的时间间隔。默认一小时

                                    dfs.namenode.checkpoint.txns=1000000 //最大没有执行checkpoint事务的数量，满足将强制执行紧急checkpoint，及时尚未达到检查点周期。默认100万事务数量

                                    元数据文件恢复

                                    namenode存储多目录

                                    • namenode元数据存储目录由参数:dfs.namenode.name.dir
                                    • dfs.namenode.name.dir属性可以配置多个目录，各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处就是当其中一个目录坏了，也不会影响到hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统network filesystem）之上，及时你这台机器损坏了，元数据也得到保存

                                      从SNN中恢复

                                      • SNN 在checkpoint的收会将fsimage和edits log下载到自己本机上本地存储目录下。并且在checkpoint之后也不会删除
                                      • 如果NN中的fsimage真的出问题了，还是可以用SNN中的fsimage替换一下NN中的fsimage，虽然已经不是最新的fsimage，但是我们可可以将损失减小到最少