HDFS架构-元数据分析

技术2022-07-11 109

五.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_00000000000000003312.然后看一下namenode当前最新的fsimage3.SecondaryNameNode获得fsimage(fsimage_0000000000000000330)和edits_inprogress_0000000000000000331之前的edits,我们去secondaryNameNode里看一下可以看到这是同步的namenode的edits文件,和namenode是一样的然后再看snn同步的fsimage文件:然后将同步的这些合并成一个.ckpt后缀的文件, 回传到namenode,回传后改名,将ckpt后缀删除,成为一个最新的fsimage文件

SecondaryNameNode定期做checkpoint检查点操作

属性值解释dfs.namenode.checkpoint.period3600秒(即1小时)The number of seconds between two periodic checkpoints.dfs.namenode.checkpoint.txns1000000The 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.period60(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 心跳机制

工作原理：

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；