Hadoop学习笔记(3)——HDFS(2)

最新推荐文章于 2024-05-05 04:31:28 发布

默萧756

最新推荐文章于 2024-05-05 04:31:28 发布

阅读量154

点赞数

文章标签： hadoop hdfs 学习

本文链接：https://blog.csdn.net/qq_64557330/article/details/126080408

版权

Hadoop 专栏收录该内容

4 篇文章

订阅专栏

本文深入探讨了HDFS的文件写入和读取流程，包括节点距离计算、机架感知的副本存储策略以及DataNode的工作机制。同时，详细解析了NameNode和SecondaryNameNode的角色，Fsimage和Edits文件的作用，以及CheckPoint的时间设置。内容涵盖HDFS的高效数据存储和故障恢复策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

五、NameNode和SecondaryNameNode

四、HDFS的读写流程(面试重点)

1、HDFS写数据流程

1.1 剖析文件写入

1.2 网络拓扑-节点距离计算

在HDFS写数据的过程中，NameNode会选择距离待上传数据最近距离的DataNode接收数据，那么这个最近距离该怎么计算呢？

节点距离：两个节点到达最近的共同祖先的距离总和

1.3 机架感知(副本存储节点的选择)

以上内容有兴趣自行翻译加了解

第一个副本在本地，效率高。第二个副本在另一个机架，保证安全可靠性(相当于多了一个备份)。第三个副本在第二个副本所在机架的随机节点，又兼顾了效率

1.4 HDFS读数据流程

注意：读数据是不能并发读的，要串行读，先读完第一块，再第二块......

五、NameNode和SecondaryNameNode

1、NN和2NN工作机制

思考：NameNode中的元数据是存储在哪里的？

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

这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件（只进行追加操作，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。

但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。

工作流程：

1、HDFS对历史数据进行改写很麻烦，但追加很简单。为了提升效率，使用Edits只负责追加计算过程，但不进行计算结果，使用镜像文件fsimage记录结果。2NN会定期将这俩个文件进行合并(关机再合并效率很低，执行一些写一些效率高)

2、滚动在写的Edits是进入到002，原来的更名为edits_001