一、大数据技术基础——分布式文件系统HDFS

百颂伊

已于 2022-06-04 20:58:44 修改

阅读量1.3k

点赞数 1

分类专栏：大数据技术基础学习笔记文章标签： hadoop 大数据

于 2022-06-04 20:58:01 首次发布

本文链接：https://blog.csdn.net/FengTingT/article/details/125122432

版权

大数据技术基础学习笔记专栏收录该内容

3 篇文章 2 订阅

订阅专栏

3.3.NameNode维护文件：fsimage与editlog

3.4.DataNode

3.5.HDFS1.0架构的局限性

3.6. SecondaryNamenode

1.引入

1.1.传统存储系统面临的难题

① 海量数据存储，如何统一管理和统一调度

② 大容量并发读写，设备性能成为瓶颈

③ 设备故障须及时修复，维护成本激增

④ 不同的应用系统间数据难以融合

1.2.解决之道

① 提供分布式文件系统，数据调度与存储分离

② 将单打独斗升级为团队作战

③ 由及时维护转变为定期维护

④ 将各种数据融合，提供统一接口

2.Hadoop集群架构

图2-1 Hadoop集群架构

NameNode和DataNode为存储节点（HDFS) JobTracker和TaskTracker为计算节点(MapReduce)

NameNode存储元数据，管理文件系统的命名空间(包括文件目录组织、属性维护、访问控制信息、文件操作日志记录、文件到块的映射信息、块当前所在的位置等)，DataNode存储实际的数据。

JobTracker将任务拆分为多个小的任务，TaskTracker完成分配到的小任务。

3.HDFS 1.0

3.1.概念

HDFS是一种可以运行在低廉的设备组成的集群上，并且是通过流式数据访问的方式进行超大文件存储的分布式文件（存储管理）系统。

图3-1 HDFS的结构

HDFS通常的部署是NameNode程序单独运行于一台服务器节点上（主服务器），其余的服务器节点每台运行一个DataNode程序。

3.2.Block块

物理磁盘中有块的概念，磁盘的物理Block是磁盘操作最小的单元，读写操作均以Block为最小单元，一般为512 Byte。

文件系统在物理Block之上抽象了另一层概念，文件系统Block物理磁盘Block的整数倍，通常为几KB。

HDFS的Block块比一般单机文件系统大得多，默认为64MB。（从2.7.3版本开始，blocksize由默认64 MB变成128 MB）。

图3-2 名称节点和数据节点

3.3.NameNode维护文件：fsimage与editlog

NameNode存在内存中，当断电后就丢失，因此也要进行持久化存储。

fsimage就是在某一时刻，整个HDFS的快照，就是这个时刻HDFS上：所有的文件块和目录，分别的状态，位于哪些个DataNode ，各自的权限，各自的副本个数。

Editlog记录客户端对HDFS所有的更新操作，比如说移动数据，或者删除数据。

NameSpace镜像文件（fsimage），操作日志文件（edit log）这些信息被Cache在RAM内存中，这两个文件也会被持久化存储在本地硬盘。

比如，在1:00:00时刻记录了一个快照fsimage，那么从1:00:00到1:59:59期间的所有对HDFS更新的操作都会记录在editlog中。当NameNode发生故障时，重启服务器，Fsimage加上Editlog的数据就会恢复元数据。

3.4.DataNode

每个DataNode会周期性的向Namenode发送心跳消息，报告自己所在DataNode的使用状态和block信息。

如果在一定时间后还接受不到DN的心跳，那么NN认为DN已经宕机，这时候NN准备要把DN上的数据块进行重新的复制。
DN还会向NN发送当前节点的使用状态以便NN进行DN选择策略。

两种策略类型：轮询（round-robin）和可用空间（available space ）：

①轮询策略在可用磁盘上均匀分配新块。

②可用空间策略优先将数据写入具有最多可用空间（按百分比）的磁盘。

DN向NN发送Block信息：有可能DN上的数据块会被修改，需告知NN会进行相应的同步修改。

3.5.HDFS1.0架构的局限性

表3-1 HDFS 1.0和HDFS 2.0架构对比

• 隔离的问题

由于HDFS仅有一个NameNode，无法隔离各个程序，因此HDFS上的一个实验程

序就很有可能影响整个HDFS上运行的程序。

• 性能的瓶颈

由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单

个NameNode的吞吐量。

3.6. SecondaryNamenode

Hadoop1.x中的NameNode容错机制：

NameNode节点断电，可以合并FsImage和editlog，合成元数据。

存在问题：

长时间添加数据到editlog中，会导致该文件数据过大，效率降低。
恢复元数据时间过长。
NameNode节点完成，效率过低。

因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和editlog的合并。

SecondaryNamenode不是NN的备份节点而是助手节点。通常，SecondaryNamenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。
触发SecondaryNameNode的CheckPoint的两个机制：定时时间到、edit log中数据写满；