五.HDFS架构

       

 

• 大多数分布式大数据框架都是主从架构

• HDFS也是主从架构Master|Slave或称为管理节点|工作节点

  • 主叫NameNode，中文称“名称节点”

  • 从叫DataNode，中文称“数据节点”

5.1 NameNode

5.1.1 文件系统

• file system文件系统：操作系统中负责管理文件、存储文件信息的软件

  • 具体地说，它负责为用户创建文件，存入、读取、修改、转储、删除文件等

• 读文件 =>>找到文件 =>> 在哪 + 叫啥？

• 元数据

  • 关于文件或目录的描述信息，如文件所在路径、文件名称、文件类型等等，这些信息称为文件的元数据metadata

  • 注意：元数据的概念在其他的大数据框架中也屡有提及

• 命名空间

  • 文件系统中，为了便于管理存储介质上的内容，给每个目录、目录中的文件、子目录都起了名字，这样形成的层级结构，称之为命名空间

  • 同一个目录中，不能有同名的文件或目录

  • 用处：这样通过目录+文件名称的方式能够唯一的定位一个文件

  • 

 

5.1.2 HDFS-NameNode

• HDFS本质上也是文件系统filesystem，所以它也有元数据metadata；

• HDFS元数据metadata保存在NameNode内存中

• NameNode作用

  • HDFS的主节点

  • 负责管理文件系统的命名空间，将HDFS的元数据存储在NameNode节点的内存中

  • 负责响应客户端对文件的读写请求

• HDFS元数据

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

    • 

 

• 每个文件、目录、block占用大概150Byte字节的元数据；所以HDFS适合存储大文件，不适合存储小文件

• HDFS元数据信息以两种形式保存：①编辑日志edits log②命名空间镜像文件fsimage

  • edits log：

    • HDFS编辑日志文件 ，保存客户端对HDFS的所有更改记录，如增、删、重命名文件（目录），这些操作会修改HDFS目录树；

    • NameNode会在编辑日志edit日志中记录下来；

  • fsimage：

    • HDFS元数据镜像文件 ，即将namenode内存中的元数据落入磁盘生成的文件；

    • 保存了文件系统目录树信息以及文件、块、datanode的映射关系，如下图

 

说明：

①为hdfs-site.xml中属性dfs.namenode.edits.dir的值决定；用于namenode保存edits.log文件

②为hdfs-site.xml中属性dfs.namenode.name.dir的值决定；用于namenode保存fsimage文件

5.2 DataNode

• DataNode数据节点的作用

  • 存储block以及block元数据到datanode本地磁盘；

  • 此处的元数据包括数据块的长度、块数据的校验和、时间戳

5.3 SecondaryNameNode

• 为什么引入SecondaryNameNode

  • 为什么元数据存储在NameNode在内存中？

  • 这样做有什么问题？如何解决？

  • HDFS编辑日志文件 editlog：在NameNode节点中的编辑日志editlog中，记录下来客户端对HDFS的所有更改的记录，如增、删、重命名文件（目录）；每次更改对应一个事务，每个事务有一个事务编号；事务编号递增

  • 作用：一旦系统出故障，可以根据editlog恢复元数据；

  • 但editlog日志大小会随着时间变的越来越大，导致系统重启，根据日志恢复元数据的时间会越来越长；

  • 为了避免这种情况，引入检查点机制checkpoint，命名空间镜像fsimage就是HDFS元数据的持久性检查点，即将内存中的元数据落磁盘生成的文件；

  • 此时，namenode如果重启，可以将磁盘中的fsimage文件读入内容，将元数据恢复到某一个检查点，然后再执行检查点之后记录的编辑日志editlog，最后完全恢复元数据。

  • 但是依然，随着时间的推移，editlog记录的日志会变多，那么当namenode重启，恢复元数据过程中，会花越来越长的时间执行editlog中的每一个日志；而在namenode元数据恢复期间，HDFS不可用。

  • 为了解决此问题，引入secondarynamenode辅助namenode，用来合并fsimage及editlog

              

                                                            图1-secondarynamenode辅助namenode示意图

• 下面根据上图所示看一下在文件系统里的过程
  • 先看下hdfs-site.xml是怎么配置的
  • 
    • 1.滚动生成日志:根据dfs.namenode.data.dir的配置,到对应目录下,可以看到已经滚动生成的日志,现在是生成到edits_inprogress_0000000000000000331
    • 
    • 2.然后看一下namenode当前最新的fsimage
    • 
    • 3.SecondaryNameNode获得fsimage(fsimage_0000000000000000330)和edits_inprogress_0000000000000000331之前的edits,我们去secondaryNameNode里看一下
    • 可以看到这是同步的namenode的edits文件,和namenode是一样的
    • 
    • 然后再看snn同步的fsimage文件:
    • 
    • 然后将同步的这些合并成一个.ckpt后缀的文件, 回传到namenode,回传后改名,将ckpt后缀删除,成为一个最新的fsimage文件

• SecondaryNameNode定期做checkpoint检查点操作

  属性	值	解释
  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.

  • 创建检查点checkpoint的两大条件：

    • SecondaryNameNode每隔1小时创建一个检查点

    • 另外，Secondary NameNode每1分钟检查一次，从上一检查点开始，edits日志文件中是否已包括100万个事务，如果是，也会创建检查点

    • checkpoint相关属性（hdfs-site.xml）

  • Secondary NameNode首先请求原NameNode进行edits的滚动，这样新的编辑操作就能够进入新的文件中

  • Secondary NameNode通过HTTP GET方式读取原NameNode中的fsimage及edits

  • Secondary NameNode读取fsimage到内存中，然后执行edits中的每个操作，并创建一个新的统一的fsimage文件，有ckpt后缀

  • Secondary NameNode通过HTTP PUT方式将新的fsimage发送到原NameNode

  • 原NameNode用新的fsimage替换旧的fsimage，同时系统会更新fsimage文件到记录检查点的时间。

  • 这个过程结束后，NameNode就有了最新的fsimage文件和更小的edits文件

• SecondaryNameNode一般部署在另外一台节点上

  • 因为它需要占用大量的CPU时间

  • 并需要与namenode一样多的内存，来执行合并操作

• 如何查看edits日志文件

  hdfs oev -i edits_0000000000000000256-0000000000000000363 -o /home/hadoop/edit1.xml

• 如何查看fsimage文件

  hdfs oiv -p XML -i fsimage_0000000000000092691 -o fsimage.xml  

5.4 心跳机制

             

 

工作原理：

1. NameNode启动的时候，会开一个ipc server在那里

2. DataNode启动后向NameNode注册，每隔3秒钟向NameNode发送一个“心跳heartbeat”

3. 心跳返回结果带有NameNode给该DataNode的命令，如复制块数据到另一DataNode，或删除某个数据块

4. 如果超过10分钟NameNode没有收到某个DataNode 的心跳，则认为该DataNode节点不可用

5. DataNode周期性（6小时）的向NameNode上报当前DataNode上的块状态报告BlockReport；块状态报告包含了一个该 Datanode上所有数据块的列表

心跳的作用：

1. 通过周期心跳，NameNode可以向DataNode返回指令

2. 可以判断DataNode是否在线

3. 通过BlockReport，NameNode能够知道各DataNode的存储情况，如磁盘利用率、块列表；跟负载均衡有关

4. hadoop集群刚开始启动时，99.9%的block没有达到最小副本数(dfs.namenode.replication.min默认值为1)，集群处于安全模式，涉及BlockReport；

相关配置项

• hdfs-default.xml

属性	值	解释
dfs.heartbeat.interval	3	Determines datanode heartbeat interval in seconds. 心跳间隔
dfs.blockreport.intervalMsec	21600000 (6小时)	Determines block reporting interval in milliseconds. 上传块报告时间间隔

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

5.5 负载均衡

• 什么原因会有可能造成不均衡？

  • 机器与机器之间磁盘利用率不平衡是HDFS集群非常容易出现的情况

  • 尤其是在DataNode节点出现故障或在现有的集群上增添新的DataNode的时候

• 为什么需要均衡？

  • 防止热点出现，提升集群存储资源利用率

  • 从存储与计算两方面提高集群性能

• 如何手动负载均衡？下边命令无需重启hadoop

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

• 停止负载均衡

$HADOOP_HOME/sbin/stop-balancer.sh