Hadoop | HDFS 学习笔记（三）HDFS 读写流程 | NN、2NN、DN 工作机制 | FsImage与Edits的合并

Hadoop | HDFS 学习笔记（三）HDFS 读写流程 | NN、2NN、DN 工作机制 | FsImage与Edits的合并

文章目录

参考资料运行环境一、HDFS 体系结构二、HDFS 存储原理

2.1 冗余数据保存2.2 数据存取策略

2.2.1 数据存放2.2.2 数据读取 2.3 数据错误与恢复

2.3.1 NN出错2.3.2 DN出错2.3.3 数据出错 三、HDFS 读写过程

3.1 读流程

过程与分析 3.2 写流程

3.2.1 过程与分析3.2.2 网络拓扑-节点NN与DN之间的距离计算3.2.3 机架感知（副本存储节点选择） 3.3 NN和2NN的工作机制3.4 NN与2NN的工作机制步骤图

3.4.1 第一阶段：NN启动3.4.2 第二阶段：2NN工作 四、Fsimage和Edits的概念

4.1 oiv命令查看 Fsimage文件4.2 oev 命令查看 Edits 文件4.3 CheckPoint 时间设置 五、DN 工作机制

5.1 DN保证数据完整性5.2 DN掉线的时限制参数设置

参考资料

---

《大数据技术原理与应用（第3版）》——林子雨 版本

视频资料

运行环境

---

JDK8Hadoop3.1.3 一、HDFS 体系结构

---

HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点（NameNode）和若干个数据节点（DataNode）
所有的HDFS通信协议都是构建在TCP/IP协议基础之上的
名称节点和数据节点之间则使用数据节点协议进行交互

二、HDFS 存储原理

---

2.1 冗余数据保存

HDFS采用多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分不到不同的DataNode节点。优点有：

加快数据传输速度容易检查数据错误保证数据可靠性 2.2 数据存取策略 2.2.1 数据存放

第一个副本：放置在上传文件的数据节点，若是集群外提交，则随机挑选资源相对充足的节点
第二个副本：放置在与第一个副本不同的机架的节点上
第三个副本：防止在于第二个副本相同机架的其他节点上
更多副本：随机节点

2.2.2 数据读取

HDFS提供一个API可确定数据节点的机架ID，Client可以通过调用API查询。

当 Client读取HDFS数据时，从NN获得Block不同副本的存放位置列表，列表包含了副本所在的DN，然后可调用API确定Client和这些DN所属的机架ID

当发现某个Block副本的机架ID和Client对应的 机架ID相同时就优先选择该副本读取数据，若没有就随机选择一个副本。

2.3 数据错误与恢复 2.3.1 NN出错

NN存储了FsImage和EditLog信息，若损坏则根据2NN中的FsImage和Editlog数据进行恢复。

2.3.2 DN出错

每个DN会定期向NN发送“心跳”信息，以汇报自身的状态当DN故障，会被标记为“宕机”，NN不会再发送I/O请求NN会定期检查，防止出现Block的副本数小于冗余因子的情况，若发生就数据冗余复制，生成新副本。

HDFS与其他分布式文件系统最大区别就是：可调整冗余数据的位置。

2.3.3 数据出错

可能造成的原因： 网络传输问题 或 磁盘错误 等

Client读取数据后会采用 校验算法（crc、mdk5等）对文件进行校验，以确定读取到正确数据

Client 读取HDFS文件时，先读取信息文件，利用该文件对每个读取的Block进行校验

若出错，那么Client会请求到另一个DN读取该文件的Block，并且向NN报告该Block有错

NN会定期检查并重新复制这些 Block

三、HDFS 读写过程

通过HDFS Java API 的实现来理解HDFS读写流程，可参考文章 【Hadoop | HDFS 学习笔记（二）| HDFS Java API 环境搭建 | Java *** 作HDFS文件系统 | 多案例】

实现代码（uri为在HDFS需 *** 作的文件路径）：

Configuration conf = new Configuration();                          
conf.set("fs.defaultFS","hdfs://localhost:9000");                        
conf.set("fs.hdfs.impl","org.apache.hadoop.hdfs.DistributedFileSystem");
FileSystem fs = FileSystem.get(conf);
FSDataInputStream in = fs.open(new Path(uri));
FSDataOutputStream out = fs.create(new Path(uri));

首先了解这几个类的作用：

类名描述FileSystem通用文件系统的抽象基类，可被分布式文件系统集成，支持Hadoop文件系统相关 *** 作DistrubutedFileSystem是FileSystem在HDFS文件系统中的具体实现类FSDataInputStreamHDFS的输入流对象，用于获取HDFS文件的数据FSDataOutputStreamHDFS的输出流对象，用于将数据写入到HDFS文件

在3.x版本中，输入输出流对象的使用都封装到了 org.apache.hadoop.fs.FileUtil里，比如在执行CopyFromLocalFile方法时，笔者通过调试发现了底层调用的部分：

通过调试能更好的理解这个调用的流程，不过由于目前的知识面比较浅，暂时只能粗略调试。

3.1 读流程 过程与分析

主要分为4个步骤：

Client 通过 DistributedFileSystem 向 NN 请求读取/下载文件，NN通过查询元数组，找到Block所在的DN地址
2.Client 挑选一台DN服务器（就近原则，然后随机），请求读取数据DN 开始 传输数据给 Client（从磁盘读取数据输入流，以Packet为单位做校验）Client以 Packet 为单位接收，先在本地缓存，然后写入目标文件。

3.2 写流程 3.2.1 过程与分析

主要分为9个步骤：

Client 通过 DistributeFileSystem类向 NN 请求上传文件，NN检查文件是否已存在，父目录是否存在NN响应此次请求，返回是否可以上传Client向 NN 请求上传第一个 BlockNN 根据选择策略（本机架当前节点 > 其他机架节点 > 本机架其他节点 > 随机节点） ，返回3个存储文件副本的DN节点，DN1、DN2、DN3获取到DN节点后，Client通过 FSDataOutputStream 类向DN1请求上传数据，DN1收到请求后会继续调用DN2、DN2又调用DN3，建立成一个通信管道。DN1、DN2、DN3 逐级应答客户端建立通信管道后，Client 开始往 DN1 上传 第一个Block，先从磁盘读取数据放到一个本地内存进行缓存，以 Packet为单位，DN1收到后就传给DN2、DN2收到后就传给DN3，DN1每传一个Packet就会放入一个应答队列等待应答当一个Block 传输完成之后，Client 再次请求 NN上传到下个Block的服务器，重复执行3-8部分最后传输完毕，Client将处理的信息提交给 NN

3.2.2 网络拓扑-节点NN与DN之间的距离计算

在HDFS写数据过程，NN会选择距离待上传数据最近距离的DN接收，这个节点距离等于两个节点到达最近的共同祖先的距离总和。 以尚硅谷机构提供的这张图为例：

集群分为d1、d2，机架又分为r1、r2、r3、r4、r5、r6，而集群节点都称为n1、n2、n3。可以把它们看成是多叉树里的一个节点。

3.2.3 机架感知（副本存储节点选择）

首先回顾 HDFS的写流程，首先，Client向NN申请上传文件，NN检查文件用户是否有权限、然后再检查是否存在，若符合就响应Client提示允许上传，接着Client请求上传第一个Block，此时NN就需要根据一个策略来选择元数据里的DN负责存储这个副本了，在API中是在 BlockPlacementPolicyDefault类的chooseTargetInOrder方法实现的。
对应包的 Maven 依赖

    org.apache.hadoop
    hadoop-hdfs
    3.1.3

    final int numOfResults = results.size();
    
    if (numOfResults == 0) {
      DatanodeStorageInfo storageInfo = chooseLocalStorage(writer,
          excludedNodes, blocksize, maxNodesPerRack, results, avoidStaleNodes,
          storageTypes, true);

      writer = (storageInfo != null) ? storageInfo.getDatanodeDescriptor()
                                     : null;
      
      if (--numOfReplicas == 0) {
        return writer;
      }
    }
  
    final DatanodeDescriptor dn0 = results.get(0).getDatanodeDescriptor();
     
    if (numOfResults <= 1) {
      chooseRemoteRack(1, dn0, excludedNodes, blocksize, maxNodesPerRack,
          results, avoidStaleNodes, storageTypes);
      if (--numOfReplicas == 0) {
        return writer;
      }
    }
    
    if (numOfResults <= 2) {
      final DatanodeDescriptor dn1 = results.get(1).getDatanodeDescriptor();
      
      if (clusterMap.isOnSameRack(dn0, dn1)) {
        chooseRemoteRack(1, dn0, excludedNodes, blocksize, maxNodesPerRack,
            results, avoidStaleNodes, storageTypes);
      } else if (newBlock){
        
        chooseLocalRack(dn1, excludedNodes, blocksize, maxNodesPerRack,
            results, avoidStaleNodes, storageTypes);
      } else {
        chooseLocalRack(writer, excludedNodes, blocksize, maxNodesPerRack,
            results, avoidStaleNodes, storageTypes);
      }
      if (--numOfReplicas == 0) {
        return writer;
      }
    }
    chooseRandom(numOfReplicas, Nodebase.ROOT, excludedNodes, blocksize,
        maxNodesPerRack, results, avoidStaleNodes, storageTypes);
    return writer;

官方说明：点击查看
摘：
For the common case, when the replication factor is three,HDFS’s placement policy is to put one replica on the local machine if the writer is on a datanode, otherwise on a random datanode, another replica on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure;
译：
对于常见情况，当复制系数为3时，HDFS的放置策略是，如果写入程序位于datanode上，则将一个副本放置在本地计算机上，否则放置在随机datanode上，另一个副本放置在不同（远程）机架中的节点上，最后一个副本放置在同一远程机架中的不同节点上。此策略减少机架间写入通信量，这通常会提高写入性能。机架故障的概率远小于节点故障的概率；

3.3 NN和2NN的工作机制

NN 经常响应客户请求，所以元数据需存放在内存，提高效率，为了防止NN受损，丢失数据，此时需要有备份元数据的角色，即FsImage。

NN 光有FsImage备份元数据，并不能满足同步更新，此时需要有进行元数据更新的角色，即 Edits，它负责存储追加或更新 *** 作的元数据。

NN有了FsImage和Edits以后还存在一个问题，Edits无法保存过多文件，同时二者又会定期合并，所以需要有负责合并的角色2NN 即 SecondaryNameNode，专门用于FsImage和Edits的合并。

3.4 NN与2NN的工作机制步骤图

3.4.1 第一阶段：NN启动

NN启动主要进行以下4个步骤：

第一次启动NN格式化后，创建 Fsimage 和 Edits 文件。若不是第一次启动就直接加载编辑日志和镜像文件到内存。Client对元数据进行增删改的请求。NN记录 *** 作日志，更新滚动日志。NN 在内存中对元数据进行增删改。

3.4.2 第二阶段：2NN工作

2NN工作主要进行以下8个步骤：

2NN询问 NN 是否需要 CheckPoint，直接带回NN是否检查结果。2NN 请求执行 CheckPointNN 滚动正在写的 Edits 日志NN 将滚动前的编辑日志和镜像文件拷贝到2NN2NN 加载编辑日志和镜像文件到内存，并合并2NN生成新的镜像文件 fsimage.chkpoint2NN将fsimage.chkpoint拷贝到NNNN将fsimage.chkpoint重新命名成fsimage

四、Fsimage和Edits的概念

参考Hadoop集群的配置文件hdfs-site.xml，比如笔者指定了 dfs.namenode.name.dir参数，即NN元数据存储位置，如下所示：

        dfs.namenode.name.dir
        file:/opt/module/hadoop/namenode_dir

官方默认的配置内容是：点击查看

  dfs.namenode.name.dir
  file://${hadoop.tmp.dir}/dfs/name
  ...

以笔者的配置为例，NN格式化后，将在hadoop目录的 namenode_dir/current目录生成以下文件

fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

关于这些文件的说明：

fsimage_xxxx文件：HDFS 文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和 inode的序列化信息edits_xxxx文件：存放 HDFS 文件系统的所有更新 *** 作的路径，文件系统客户端执行的所有写 *** 作首先会被记录到 Edit文件中。（第一次进入后，未进行保存 *** 作所以没有生成该文件）seen_txid：保存的是一个数组，即最后一个edits_xxxx的数字NN每次启动时，都会将Fsimage读入内存，加载 Edits里面的更新 *** 作，保证内存中的元数据信息是最新的、同步的，可以看成NN启动的时候就将 Fsimage和Edits文件进行了合并。 4.1 oiv命令查看 Fsimage文件

查看命令提示：

在启动HDFS后，输入hdfs命令会提示可 *** 作的一些命令，现可以用grep过滤其中的提示信息，将oiv提取出来，或者直接hdfs oiv 查看

[root@hadoop101 current]# hdfs | grep oiv
oiv                  apply the offline fsimage viewer to an fsimage
oiv_legacy           apply the offline fsimage viewer to a legacy fsimage

基本语法：

hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

案例： 将 fsimage镜像文件转化为 XML 文件，并cat查看
（笔者之前进行过HDFS的 *** 作，所以有edits和fsimage文件）

hdfs oiv -p XML -i fsimage_0000000000000013555 -o ./fsimage_visted.xml
 
 cat ./fsimage_visted.xml

查看结果：

有时候Fsimage中没有记录块对应的DN

原因是：集群未启动，只有在集群启动后，NN要求DN上传Block信息，并且是间隔一段时间才会再次上报。

4.2 oev 命令查看 Edits 文件

基本语法：

hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径

案例： 将edits日志转化为XML并查看

hdfs oev -p XML -i edits_0000000000000000001-0000000000000000001 -o ./edits-visted.xml

cat ./edits-visted.xml

4.3 CheckPoint 时间设置

通常情况下，2NN每隔一小时刷新一次

hdfs-default.xml点击查看

  dfs.namenode.checkpoint.period
  3600s
  ...

1分钟检查1次 *** 作次数，当 *** 作次数达到100万时，2NN执行1次
hdfs-default.xml点击查看

  dfs.namenode.checkpoint.txns
  1000000
  ... *** 作动作次数



  dfs.namenode.checkpoint.check.period
  60s
  ...1分钟检查1次的 *** 作次数

五、DN 工作机制

一个Block数据块在DN上以文件形式存储在磁盘，包括两个文件，一个是数据本身，另一个是元数据，包括数据块的长度、块数据的校验和以及时间戳。DN启动后向NN注册，通过后，DN周期性（6小时1次）得向NN上报所有的块信息，这时间来自配置文件：

hdfs-default.xml点击查看

  dfs.blockreport.intervalMsec
  21600000
  ...DN向NN汇报当前解读信息的时间间隔，默认6小时1次



  dfs.datanode.directoryscan.interval
  21600s
  ...DN扫描自己节点块信息列表的时间，默认6小时1次

DN的心跳是每3秒一次，心跳返回结果带有 NN给该DN的命令，比如复制块数据到另一台机器，或者删除某个Block，如果超过10分钟NN没有收到某个DN的心跳，则认为该DN节点不可用。集群运行过程中可以安全进入和退出一些机器。

5.1 DN保证数据完整性

DN保证数据完整性的方法：

当DN读取 Block时，会计算CheckSum若计算后的CheckSum 与 Block 创建时值不一样，说明 Block已损坏。Client读取其他的 DN 上的 Block常见校验算法，crc（32），MD5（128），sha1（160）DN 在其文件创建后会周期验证 CheckSum

5.2 DN掉线的时限制参数设置

DN进程死亡或网络故障造成DN无法与NN通信。NN不会立即把该节点判定会死亡，要经过一段时间，这段时间暂称作超时时长。HDFS 默认的超时时长为 10 分钟 + 30秒。若定义超时时间为 TimeOut，则它的计算公式为：

T i m e O u t = 2 ∗ r e c h e c k I n t e r v a l + 10 ∗ i n t e r v a l TimeOut = 2 * recheckInterval +10 * interval TimeOut=2∗recheckInterval+10∗interval

其中， r e q c h e c k I n t e r v a l reqcheckInterval reqcheckInterval 取值为 dfs.namenode.heartbeat.recheck-interval，默认为5分钟，

i n t e r v a l interval interval 取值为dfs.heartbeat.interval，默认为3秒，若需要自定义的话就修改hdfs-site.xml配置文件。

参考默认配置文件：[hdfs-default.xml] 点击查看

  dfs.namenode.full.block.report.lease.length.ms
  300000
  ..DN验证时间



  dfs.heartbeat.interval
  3s
  ..DN心跳时间