HDFS架构

本文将从NameNode，DataNode，SecondaryNameNode，心跳检测，负载均衡五个方面展开讨论HDFS架构。

HDFS整体架构

首先上一张简单的架构图：

hdfs.png

其中：

1. 大多数分布式大数据框架都是主从架构。
2. HDFS也是主从架构(其中，Master称为管理节点，Slave称为工作节点)
   • 主叫NameNode，中文名称为"名称节点"。
   • 从叫DataNode，中文名称为"数据节点"。

NameNode

文件系统

先谈谈文件系统概念。

1. 文件系统(filesystem)概念：操作系统中负责管理文件，存储文件信息的软件。具体地说，它负责为用户创建文件，存入，读取，修改，转储，删除文件等。

再说说与文件系统有关的几个概念。

2. 元数据(metadata)：关于用户或目录的描述信息，如文件所在路径，文件名称，文件类型等等，这些信息被称为文件的元数据信息。如：

   
   
   metadata.png

注意：元数据的概念在其它的的数据框架中也屡有提及。

3. 命名空间

• 文件系统中，为了便于管理存储介质上的，给每个目录、目录中的文件、子目录都起了名字，这样形成的层级结构，称之为命名空间。
• 同一目录中，不能有同名的文件或目录。
• 用处：这样通过目录+文件名称的方式能够唯一的定位一个文件。

HDFS-NameNode

1. HDFS本质上也是文件系统filesystem，所以它也有元数据metadata；
2. 元数据metadata保存在NameNode内存中；
3. NameNode作用
   • HDFS的主节点，负责管理文件系统的命名空间，将HDFS的元数据存储在NameNode节点的内存中。
   • 负责响应客户端对文件的读写请求。
4. HDFS元数据

   • 文件目录树、所有的文件（目录）名称、文件属性（生成时间、副本、权限）、每个文 件的块列表、每个block块所在的datanode列表。

     
     
     metadata.png
   • 每个文件，目录，block占用大概150Bytes字节的元数据；所以HDFS适合存储大文件，不适合存储小文件(1000个1M的文件和1000个150M的文件所占用的元数据内存是一样多的，但是后者在hdfs上存储的文件更多)。

   • HDFS元数据信息以两种形式保存：编辑日志(edits log)和命名空间镜像文件(fsimage)
     (1). edits log：HDFS编辑日志文件 ，保存客户端对HDFS的所有更改记录，如增、删、重命名文件（目录），这些操作会修改HDFS目录树；NameNode会在编辑日志edit日志中记录下来；(类似于MySQL中的binlog)
     (2). fsimage：HDFS元数据镜像文件 ，即将namenode内存中的数据落入磁盘生成的文件；保存了文件系统目录树信息以及文件、块、datanode的映射关系，如下图：

     
     
     edits && fsimage.png

1. hdfs-site.xml中属性dfs.namenode.edits.dir的值决定；用于namenode保存edits log文件。
2. hdfs-site.xml中属性dfs.namenode.name.dir的值决定；用于namenode保存fsimage文件。

DataNode

DataNode数据节点的作用比较简单，主要是存储block元数据到datanode本地磁盘；此处的元数据包括数据块的长度，块数据的校验和，时间戳。

SecondaryNameNode

在解释SecondaryNameNode之前，先看看如下2个问题。

1. 为什么元数据存储在NameNode的内存中?
   答：当HDFS Client需要读写文件时，首先HDFS Client连接到NameNode，获取文件的元数据信息，知道了当前想要访问的文件的block分别存放在哪些DataNode节点上，然后HDFS Client分别连接这些DataNode，然后读写文件。当HDFS Client很多的时候，如果将元数据存储在磁盘上的话，这些Client想要访问这些元数据信息就会特别慢，但是如果将元数据保存在内存中就不一样了。
2. 这样做有什么问题？如何解决？
   答：这样的问题是：一旦NameNode节点系统故障，会导致保存在NameNode节点内存中的元数据丢失。解决方式：edits log已经记录了客户端对HDFS的所有的更改的操作记录(如增，删，改，重命名文件或者目录)。如果系统故障，重启之后，可以从edits log进行恢复(edits log回放这些操作记录)。但edits log日志大小随着时间变得越来越大，导致系统重启根据日志恢复的时候会变得越来越长；为了避免这种情况，引入检查点机制checkpoint，命名空间镜像fsimage就是根据HDFS数据的持久性检查点，即将内存中的元数据落地磁盘生成的文件。NameNode如果重启，可以将磁盘中的fsimage文件读入到内存，将元数据恢复到某一个检查点，然后再回放检查点之后记录的编辑日志，最后完全恢复元数据。但是依然，随着时间的推移，edits log记录的日志会变多，那么当NameNode重启，恢复元数据过程中，会花越来越长的时间执行edits log中的每一个日志；而在NameNode元数据恢复期间，HDFS不可用。

为了解决这个问题，引入了SecondaryNameNode辅助NameNode，用来合并fsimage和edits log。

fsimage和editlog合并过程.png

3. SecondaryNameNode合并fsimage和edits log详细流程如下：

   • SecondaryNameNode首先请求原NameNode进行edits的滚动，这样新的编辑操作就能够进入新的文件中。
   • SecondaryNameNode通过HTTP GET方式读取原NameNode中的fsimage及edits log。
   • SecondaryNameNode读取fsimage到内存中，然后回放edits log中的每个操作，并创建一个新的统一的fsimage文件。
   • SecondaryNameNode通过HTTP PUT方式将新的fsimage发送到原NameNode。
   • 原NameNode用新的fsimage替换旧的fsimage，同时系统会更新fsimage文件到记录检查点的时间。
   • 这个过程结束后，NameNode就有了最新的fsimage文件和更小的edits log文件。

4. SecondaryNameNode定期做checkpoint检查点操作的两大条件：

   • SecondaryNameNode每隔1小时创建一个检查点
   • 另外，SecondaryNameNode每1分钟检查一次，从上一检查点开始，edits log文件中是否已包括100万个事务，如果是，也会创建检查点。

SecondaryNameNode一般部署在另外一台节点上，因为它需要占用大量的CPU时间，并需要和NameNode一样多的内存，来执行合并操作。

5. 查看edits log和fsimage

hdfs oev -i edits_0000000000000000256-0000000000000000363 -o /home/hadoop/edit1.xml
hdfs oiv -p XML -i fsimage_0000000000000092691 -o fsimage.xml

执行以上两个命令后，会将二进制格式的edits log和fsimage转化为xml文件。

6. checkpoint相关属性(参考hadoop官方文档)

属性	值	解释
dfs.namenode.checkpoint.period	3600秒(即1小时)	The number of seconds between two periodic checkpoints.
dfs.namenode.checkpoint.txns	1000000	The Secondary NameNode or CheckpointNode will create a checkpoint of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless of whether 'dfs.namenode.checkpoint.period' has expired.
dfs.namenode.checkpoint.check.period	60(1分钟)	The SecondaryNameNode and CheckpointNode will poll the NameNode every 'dfs.namenode.checkpoint.check.period' seconds to query the number of uncheckpointed transactions.

心跳机制

Image201906211518.png

工作原理

• NameNode启动的时候，会开一个ipc server在那里
• DataNode启动后向NameNode注册，每隔3秒钟向NameNode发送一个"心跳heartbeat"
• 心跳返回结果带有NameNode给该DataNode的命令，如复制块数据到另一DataNode，或删除某个数据块
• 如果超过10分钟NameNode没有收到某个DataNode 的心跳，则认为该DataNode节点不可用
• DataNode周期性（6小时）的向NameNode上报当前DataNode上的块状态报告BlockReport；块状态报告包含了一个该 Datanode上所有数据块的列表。

心跳的作用

• 通过周期心跳，NameNode可以向DataNode返回指令
• 可以判断DataNode是否在线
• 通过BlockReport，NameNode能够知道各DataNode的存储情况，如磁盘利用率、块列表；跟负载均衡有关
• hadoop集群刚开始启动时，99.9%的block没有达到最小副本数(dfs.namenode.replication.min默认值为1)，集群处于安全模式，涉及BlockReport；

心跳相关配置

• hdfs-default.xml

• 心跳间隔

属性	值	解释
dfs.heartbeat.interval	3	Determines datanode heartbeat interval in seconds.

• blockreport

属性	值	解释
dfs.blockreport.intervalMsec	21600000 (6小时)	Determines block reporting interval in milliseconds.

• 查看hdfs-default.xml默认配置文件

  
  
  hdfs-default.xml默认配置.png

负载均衡

• 什么原因会有可能造成不均衡？
  • 机器与机器之间磁盘利用率不平衡是HDFS集群非常容易出现的情况。
  • 尤其是在DataNode节点出现故障或在现有的集群上增添新的DataNode的时候。
• 为什么需要均衡？
  • 提升集群存储资源利用率。
  • 从存储与计算两方面提高集群性能。
• 如何手动负载均衡？

$HADOOP_HOME/sbin/start-balancer.sh -t 5%   # 磁盘利用率最高的节点若比最少的节点，大于5%，触发均衡。

小结：

• NameNode负责存储元数据，存在内存中。
• DataNode负责存储block块及块的元数据。
• SecondaryNameNode主要负责对HDFS元数据做checkpoint操作。
• 集群的心跳机制，让集群中各节点形成一个整体；主节点知道从节点的死活。
• 节点的上下线，导致存储的不均衡，可以手动触发负载均衡。