Hadoop学习（5）-- HDFS工作流程与机制

HDFS集群角色与职责

官方架构图

主角色：namenode

• NameNode是Hadoop分布式文件系统的核心，架构中的主角色。
• NameNode维护和管理文件系统元数据，包括名称空间目录树结构、文件和块的位置信息、访问权限等信息。
• 基于此，NameNode成为了访问HDFS的唯一入口。
• NameNode内部通过内存和磁盘文件两种方式管理元数据。
• 其中磁盘上的元数据文件包括Fsimage内存元数据镜像文件和edits log（Journal）编辑日志。
  

从角色：datanode

• DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储。
• DataNode的数量决定了HDFS集群的整体数据存储能力。通过和NameNode配合维护着数据块。

主角色辅助角色： secondarynamenode

• Secondary NameNode充当NameNode的辅助节点，但不能替代NameNode。
• 主要是帮助主角色进行元数据文件的合并动作。可以通俗的理解为主角色的“秘书”。

namenode职责

• NameNode仅存储HDFS的元数据：文件系统中所有文件的目录树，并跟踪整个集群中的文件，不存储实际数据。
• NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。
• NameNode不持久化存储每个文件中各个块所在的datanode的位置信息，这些信息会在系统启动时从DataNode重建。
• NameNode是Hadoop集群中的单点故障。
• NameNode所在机器通常会配置有大量内存（RAM）。

datanode职责

• DataNode负责最终数据块block的存储。是集群的从角色，也称为Slave。
• DataNode启动时，会将自己注册到NameNode并汇报自己负责持有的块列表。
• 当某个DataNode关闭时，不会影响数据的可用性。 NameNode将安排由其他DataNode管理的块进行副本复制。
• DataNode所在机器通常配置有大量的硬盘空间，因为实际数据存储在DataNode中。

HDFS写数据流程（上传文件）

写数据完整流程图

流程如下：

1. HDFS客户端创建对象实例DistributedFileSystem， 该对象中封装了与HDFS文件系统操作的相关方法。
2. 调用DistributedFileSystem对象的create()方法，通过RPC请求NameNode创建文件。NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过，NameNode就会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据。
3. 客户端通过FSDataOutputStream输出流开始写入数据。
4. 客户端写入数据时，将数据分成一个个数据包（packet 默认64k）, 内部组件DataStreamer请求NameNode挑选出适合存储数据副本的一组DataNode地址，默认是3副本存储。DataStreamer将数据包流式传输到pipeline的第一个DataNode,该DataNode存储数据包并将它发送到pipeline的第二个DataNode。同样，第二个DataNode存储数据包并且发送给第三个（也是最后一个）DataNode。
5. 传输的反方向上，会通过ACK机制校验数据包传输是否成功；
6. 客户端完成数据写入后，在FSDataOutputStream输出流上调用close()方法关闭。
7. DistributedFileSystem联系NameNode告知其文件写入完成，等待NameNode确认。因为namenode已经知道文件由哪些块组成（DataStream请求分配数据块），因此仅需等待最小复制块即可成功返回。

最小复制是由参数dfs.namenode.replication.min指定，默认是1。

核心概念–Pipeline管道

• Pipeline，中文翻译为管道。这是HDFS在上传文件写数据过程中采用的一种数据传输方式。
• 客户端将数据块写入第一个数据节点，第一个数据节点保存数据之后再将块复制到第二个数据节点，后者保存后将其复制到第三个数据节点。
• 为什么datanode之间采用pipeline线性传输，而不是一次给三个datanode拓扑式传输呢？
  因为数据以管道的方式，顺序的沿着一个方向传输，这样能够充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时。
• 在线性推送模式下，每台机器所有的出口宽带都用于以最快的速度传输数据，而不是在多个接受者之间分配宽带。
  

核心概念–ACK应答响应

• ACK (Acknowledge character）即是确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。
• 在HDFS pipeline管道传输数据的过程中，传输的反方向会进行ACK校验，确保数据传输安全。

核心概念–默认3副本存储策略

• 默认副本存储策略是由BlockPlacementPolicyDefault指定。
• 第一块副本：优先客户端本地，否则随机
• 第二块副本：不同于第一块副本的不同机架。
• 第三块副本：第二块副本相同机架不同机器。

HDFS读数据流程（下载文件）

读数据完整流程图

1. HDFS客户端创建对象实例DistributedFileSystem， 调用该对象的open()方法来打开希望读取的文件。
2. DistributedFileSystem使用RPC调用namenode来确定文件中前几个块的块位置（分批次读取）信息。对于每个块，namenode返回具有该块所有副本的datanode位置地址列表，并且该地址列表是排序好的，与客户端的网络拓扑距离近的排序靠前。
3. DistributedFileSystem将FSDataInputStream输入流返回到客户端以供其读取数据。
4. 客户端在FSDataInputStream输入流上调用read()方法。然后，已存储DataNode地址InputStream连接到文件中第一个块的最近的DataNode。数据从DataNode流回客户端，结果客户端可以在流上重复调用read（）。
5. 当该块结束时，FSDataInputStream将关闭与DataNode的连接，然后寻找下一个block块的最佳datanode位置。这些操作对用户来说是透明的。所以用户感觉起来它一直在读取一个连续的流。客户端从流中读取数据时，也会根据需要询问NameNode来检索下一批数据块的DataNode位置信息。
6. 一旦客户端完成读取，就对FSDataInputStream调用close()方法。

NameNode 和 SecondaryNameNode

NN 和 2NN 工作机制

思考：NameNode 中的元数据是存储在哪里的？
首先，我们做个假设，如果存储在 NameNode 节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。

这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新 FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦 NameNode 节点断电，就会产生数据丢失。因此，引入 Edits 文件（只进行追加操作，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到 Edits 中。这样，一旦 NameNode 节点断电，可以通过 FsImage 和 Edits 的合并，合成元数据。
但是，如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行 FsImage 和 Edits 的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于 FsImage 和 Edits 的合并。

NameNode工作机制

• 第一阶段：NameNode 启动
  1. 第一次启动 NameNode 格式化后，创建 Fsimage 和 Edits 文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
  2. 客户端对元数据进行增删改的请求。
  3. NameNode 记录操作日志，更新滚动日志。
  4. NameNode 在内存中对元数据进行增删改。
• 第二阶段：Secondary NameNode 工作
  1. Secondary NameNode 询问 NameNode 是否需要 CheckPoint。直接带回 NameNode
     是否检查结果。
  2. Secondary NameNode 请求执行 CheckPoint。
  3. NameNode 滚动正在写的 Edits 日志。
  4. 将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
  5. Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。
  6. 生成新的镜像文件 fsimage.chkpoint。
  7. 拷贝 fsimage.chkpoint 到 NameNode。
  8. NameNode 将 fsimage.chkpoint 重新命名成 fsimage。

Fsimage 和 Edits 解析

Fsimage和Edits概念

NameNode被格式化之后，将在/opt/module/hadoop-3.1.3/data/tmp/dfs/name/current目录中产生如下文件

fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

1. Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目
   录和文件inode的序列化信息。
2. Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先
   会被记录到Edits文件中。
3. seen_txid文件保存的是一个数字，就是最后一个edits_的数字。
4. 每次NameNode启动的时候都会将Fsimage文件读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并。

oiv 查看 Fsimage 文件

1. 查看 oiv 和 oev 命令

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

   hdfs oiv -p XML -i 
   fsimage_0000000000000000025 -o /opt/module/hadoop-3.1.3/fsimage.xml
   

   注意：可以看出，Fsimage 中没有记录块所对应 DataNode，为什么？
   在集群启动后，要求 DataNode 上报数据块信息，并间隔一段时间后再次上报。

2. oev 查看 Edits 文件

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

 hdfs oev -p XML -i
edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-
3.1.3/edits.xml

CheckPoint 时间设置

通常情况下，SecondaryNameNode 每隔一小时执行一次。

[hdfs-default.xml]

<property>
 <name>dfs.namenode.checkpoint.period</name>
 <value>3600s</value>
</property>

一分钟检查一次操作次数，当操作次数达到 1 百万时，SecondaryNameNode 执行一次。

<property>
 <name>dfs.namenode.checkpoint.txns</name>
 <value>1000000</value>
<description>操作动作次数</description>
</property>
<property>
 <name>dfs.namenode.checkpoint.check.period</name>
 <value>60s</value>
<description> 1 分钟检查一次操作次数</description>
</property>

DataNode

DataNode 工作机制

1. 一个数据块在 DataNode 上以文件形式存储在磁盘上，包括两个文件，一个是数据
   本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。

2. DataNode 启动后向 NameNode 注册，通过后，周期性（6 小时）的向 NameNode 上
   报所有的块信息。
   DN 向 NN 汇报当前解读信息的时间间隔，默认 6 小时；

   <property>
   <name>dfs.blockreport.intervalMsec</name>
   <value>21600000</value>
   <description>Determines block reporting interval in 
   milliseconds.</description>
   </property>
   

   DN 扫描自己节点块信息列表的时间，默认 6 小时

   <property>
   	<name>dfs.datanode.directoryscan.interval</name>
   	<value>21600s</value>
   	<description>Interval in seconds for Datanode to scan data directories and reconcile the difference between blocks in memory and on 
   	the disk.
   	Support multiple time unit suffix(case insensitive), as described
   	in dfs.heartbeat.interval.
   	</description>
   </property>
   

3. 心跳是每 3 秒一次，心跳返回结果带有 NameNode 给该 DataNode 的命令如复制块数据到另一台机器，或删除某个数据块。如果超过 10 分钟没有收到某个 DataNode 的心跳，则认为该节点不可用。

4. 集群运行中可以安全加入和退出一些机器。

数据完整性

思考：如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号（1）和绿灯信号（0），但是存储该数据的磁盘坏了，一直显示是绿灯，是否很危险？同理 DataNode 节点上的数据损坏了，却没有发现，是否也很危险，那么如何解决呢？
如下是 DataNode 节点保证数据完整性的方法：

1. 当 DataNode 读取 Block 的时候，它会计算 CheckSum。
2. 如果计算后的 CheckSum，与 Block 创建时值不一样，说明 Block 已经损坏。
3. Client 读取其他 DataNode 上的 Block。
4. 常见的校验算法 crc（32），md5（128），sha1（160）
5. DataNode 在其文件创建后周期验证 CheckSum。

DataNode掉线时限参数设置

需要注意的是hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的单位为毫秒，dfs.heartbeat.interval 的单位为秒。

<property>
 <name>dfs.namenode.heartbeat.recheck-interval</name>
 <value>300000</value>
</property>
<property>
 <name>dfs.heartbeat.interval</name>
 <value>3</value>
</property>