HDFS的体系结构

雨点打透心脏的1/2处 2023-10-13 15:14 128阅读 0赞

#### HDFS的体系结构 ####

##### 体系结构解析 #####

> HDFS采用的是master/slaves这种主从的结构模型来管理数据，这种结构模型主要由四个部分组成，分别是Client(客户端)、Namenode(名称节点)、Datanode(数据节点)和SecondaryNameNode。真正的一个HDFS集群包括一个Namenode和若干数目的Datanode。
> 
> Namenode是一个中心服务器，负责管理文件系统的命名空间 (Namespace ),它在内存中维护着命名空间的最新状态，同时并持久性文件（fsimage和edit）进行备份，防止宕机后，数据丢失。namenode还负责管理客户端对文件的访问，比如权限验证等。
> 
> 集群中的Datanode一般是一个节点运行一个Datanode进程，真正负责管理客户端的读写请求，在Namenode的统一调度下进行数据块的创建、删除和复制等操作。数据块实际上都是保存在Datanode本地的Linux文件系统中的。每个Datanode会定期的向Namenode发送数据，报告自己的状态(我们称之为心跳机制)。没有按时发送心跳信息的Datanode会被Namenode标记为“宕机”，不会再给他分配任何I/O请求。
> 
> 用户在使用Client进行I/O操作时,仍然可以像使用普通文件系统那样，使用文件名去存储和访问文件，只不过，在HDFS内部，一个文件会被切分成若干个数据块，然后被分布存储在若干个Datanode上。
> 
> 比如，用户在Client上需要访问一个文件时，HDFS的实际工作流程如此：客户端先把文件名发送给Namenode，Namenode根据文件名找到对应的数据块信息及其每个数据块所在的Datanode位置，然后把这些信息发送给客户端。之后，客户端就直接与这些Datanode进行通信，来获取数据（这个过程，Namenode并不参与数据块的传输）。这种设计方式，实现了并发访问，大大提高了数据的访问速度。
> 
> HDFS集群中只有唯一的一个Namenode,负责所有元数据的管理工作。这种方式保证了Datanode不会脱离Namenode的控制，同时，用户数据也永远不会经过Namenode，大大减轻了Namenode的工作负担，使之更方便管理工作。通常在部署集群中，我们要选择一台性能较好的机器来作为Namenode。当然，一台机器上也可以运行多个Datanode，甚至Namenode和Datanode也可以在一台机器上，只不过实际部署中，通常不会这么做的

![d95443d826781867c3b89781ef1b47be.png][]

##### HDFS进程之NameNode #####

>  *  namenode进程只有一个（HA除外）
>  *  管理HDFS的命名空间，并以fsimage和edit进行持久化保存。
>  *  在内存中维护数据块的映射信息
>  *  实施副本冗余策略
>  *  处理客户端的访问请求

##### HDFS进程之DataNode #####

>  *  存储真正的数据(块进行存储)
>  *  执行数据块的读写操作
>  *  心跳机制（3秒）

##### HDFS进程之SecondaryNamennode #####

>  *  帮助NameNode合并fsimage和edits文件
>  *  不能实时同步，不能作为热备份节点

##### HDFS的Client接口 #####

>  *  HDFS实际上提供了各种语言操作HDFS的接口。
>  *  与NameNode进行交互，获取文件的存储位置（读/写两种操作）
>  *  与DataNode进行交互，写入数据，或者读取数据
>  *  上传时分块进行存储，读取时分片进行读取

##### 映像文件fsimage #####

命名空间指的就是文件系统树及整棵树内的所有文件和目录的元数据，每个Namenode只能管理唯一的一命名空间。HDFS暂不支持软链接和硬连接。Namenode会在内存里维护文件系统的元数据，同时还使用fsimage和edit日志两个文件来辅助管理元数据，并持久化到本地磁盘上。

>  *  fsimage  
>     命名空间镜像文件，它是文件系统元数据的一个完整的永久检查点，内部维护的是最近一次检查点的文件系统树和整棵树内部的所有文件和目录的元数据，如修改时间，访问时间，访问权限，副本数据，块大小，文件的块列表信息等等。  
>     fsimage默认存储两份，是最近的两次检查点
>  *  使用XML格式查看fsimage文件：  
>     \[root@qianfeng01 current\]\# hdfs oiv -i 【fsimage\_xxxxxxx】 -o 【目标文件路径】 -p XML  
>     案例如下：  
>     \[root@qianfeng01 current\]\# hdfs oiv -i fsimage\_00000000052 -o ~/fs52.xml -p XML

##### 日志文件edit #####

集群正常运行时，客户端的所有更新操作(如打开、关闭、创建、删除、重命名等)除了在内存中维护外，还会被写到edit日志文件中，而不是直接写入fsimage映像文件。

> 因为对于分布式文件系统而言，fsimage映像文件通常都很庞大，如果客户端所有的更新操作都直接往fsimage文件中添加，那么系统的性能一定越来越差。相对而言，edit日志文件通常都要远远小于fsimage,一个edit日志文件最大64M，更新操作写入到EditLog是非常高效的。

那么edit日志文件里存储的到底是什么信息呢，我们可以将edit日志文件转成xml文件格式，进行查看

> 查看editlog文件的方式：  
> \[root@qianfeng01 current\]\# hdfs oev -i 【edits\_inprogress\_xxx】 -o 【目标文件路径】-p XML

参考xml文件后，我们可以知道日志文件里记录的内容有：

> 1.  行为代码：比如 打开、创建、删除、重命名、关闭
> 2.  事务id
> 3.  inodeid
> 4.  副本个数
> 5.  修改时间
> 6.  访问时间
> 7.  块大小
> 8.  客户端信息
> 9.  权限等
> 10. 块id等

![64908bcf6059ef568410f4e8f1c8ead2.png][]

### **更多大数据精彩内容欢迎B站搜索“[千锋教育][Link 1]”或者扫码领取全套资料** ###

【千锋教育】大数据开发全套教程，史上最全面的大数据学习视频

[d95443d826781867c3b89781ef1b47be.png]: https://img-blog.csdnimg.cn/img_convert/d95443d826781867c3b89781ef1b47be.png
[64908bcf6059ef568410f4e8f1c8ead2.png]: https://img-blog.csdnimg.cn/img_convert/64908bcf6059ef568410f4e8f1c8ead2.png
[Link 1]: https://space.bilibili.com/146668655?spm_id_from=333.337.0.0