HDFS分布式文件存储系统详解(架构和设计)
作者:hangge | 2024-06-24 08:27
1,HDFS 的起源
(1)HDFS 源于 Google 在 2003 年 10 月份发表的论文 The Google File System(GFS),它其实就是 GFS 的一个开源简化版本。
(2)HDFS 属于 Hadoop 项目中的核心组件,主要负责海量数据存储。
(3)Hadoop 重要版本的发展历程如下,目前在企业中常用的版本是 2.x 和 3.x。
- 0.x 是 Hadoop 当中最早的一个开源版本,在此基础上演变而来的 1.x 以及 2.x 的版本
- 1.x 版本系列:Hadoop版本当中的第二代开源版本,主要修复 0.x 版本的一些 bug 等
- 2.x 版本系列:架构产生重大变化,引入了 yarn 平台等许多新特性;HDFS 最多支持两个 NameNode(一主一备);
- 3.x 版本系列:最低运行时版本修订为 Java 8,最大改变的是 hdfs,包括 HDFS 支持数据的擦除编码,HDFS 支持多个 NameNode(一主多备)等
![](http://hangge.com/blog_uploads/202401/2024010311191022263.png)
2,HDFS 的原理
(1)HDFS 是一种允许文件通过网络在多台主机上分享的分布式文件系统,可以让多台机器上的多个用户分享文件和存储空间。
(2)HDFS 的典型使用场景是“一次写入,多次读取”。一个文件被创建、写入及关闭之后,其中的内容就不会改变了。
(3)HDFS 是一种适合大文件存储的分布式文件系统,它不适合存储小文件。
提示:5KB、10MB 之类的文件可以被认为是小文件
(4)在向 HDFS 中存储文件时,客户端负责将文件切分成 Block(数据块)。Block 的大小默认是 128MB
(在 Hadoop 1.x 版本中默认是 64MB,在 Hadoop 2.x 和 3.x 版本中默认是 128MB)。即在向 HDFS 中
存储文件时,只要文件大小超过 128MB,就会被切分成多个 Block;如果一个文件不够 128MB,默认
只产生 1 个 Block。
注意:如果 1 个文件只有 10MB,最终只会产生 1 个 Block,这个 Block 并不会占用 128MB 的磁盘空间,它会根据自身的实际大小占用相应的磁盘空间。
![](http://hangge.com/blog_uploads/202401/2024010313562440342.png)
3,HDFS 分布式文件系统的优点
- 通透性:通过网络访问文件的动作,在程序与用户看来就像是在访问本地磁盘。
- 高容错性:即使系统中某些节点宕机,整体来说系统仍然可以持续运作而不会丢失数据。因为 HDFS 中的数据会保存多个副本(默认 3 份),且提供了容错机制,副本丢失也可以自动恢复。
- 性价比高:可以运行在大量的廉价机器上,节约成本。
4,HDFS 分布式文件系统的缺点
- 不适合低延时数据访问:数据延时比较高,无法支持“毫秒”级别的数据存储。
- 不适合小文件存储:HDFS 的主节点(NameNode)的内存是有限的,每个 Block 对应的元数据信息都会在 NameNode 中占用 150 byte 的内存空间。1 个 1MB 的文件对应 1 个 Block,会占用 150 byte。1 个 128MB 的文件也对应 1 个 Block,也只会占用 150 byte。所以,存储大量小文件就没有意义了,这违背了 HDFS 的设计理念。
- 不支持文件并发写入和随机修改:1 个文件同时只能有 1 个线程执行写操作,不允许多个线程同时执行写操作。只支持对文件执行追加操作,不支持对文件执行随机修改操作。
5,HDFS 架构分析
(1)以 Hadoop 3.x 版本为例,HDFS 集群支持主从结构,包括主节点和从节点。
- 主节点上运行的是 NameNode 进程。一般把主节点称为 NameNode 节点。HDFS 集群中支持 1 个或者多个 NameNode 节点。
- 从节点上运行的是 DataNode 进程。一般把从节点称为 DataNode 节点。HDFS 集群中支持 1 个或者多个 DataNode 节点。
- HDFS 集群中还包含 1 个 SecondaryNameNode 进程,从字面意思上来理解它是“第 2 个 NameNode”的意思,其实并不是。
![](http://hangge.com/blog_uploads/202401/2024010314051244808.png)
(2)这 3 种角色(进程)的工作职责如下:
- NameNode:文件系统的管理节点,它主要维护整个文件系统的元数据,包括文件目录树、文件/目录的信息,以及每个文件对应的 Block 列表等。
- SecondaryNameNode:辅助 NameNode 工作,定期合并 NameNode 的元数据信息(Fsimage 和 Edits),然后推送给 NameNode。
- DataNode:文件系统的数据节点,提供真实文件数据(Block)的存储服务。
![](http://hangge.com/blog_uploads/202401/202401031406428994.png)
附一:HDFS 的高可用(HA)
1,HA 实现原理
(1)HDFS 的 HA(High Available),指的是在一个集群中存在多个 NameNode,分别运行在独立的物理节点上。在任何时间点,只有一个 NameNode 是处于 Active 状态,其它的是处于 Standby 状态。 Active NameNode(简写为 Active NN)负责所有的客户端的操作,而 Standby NameNode(简写为 Standby NN)用来同步 Active NameNode 的状态信息,以提供快速的故障恢复能力。
注意:使用 HA 的时候,不能启动 SecondaryNameNode,会出错。之前是 SecondaryNameNode 负责合并 edits 到 fsimage 文件,那么现在这个工作被 standby NN 负责了。
(2)为了保证 Active NN 与 Standby NN 节点状态同步,即元数据保持一致。除了 DataNode 需要向这些 NameNode 发送 block 位置信息外,还构建了一组独立的守护进程“JournalNodes”(简写为 JN),用来同步 Edits 信息。
- 当 Active NN 执行任何有关命名空间的修改,它需要持久化到一半以上的 JNs 上。
- 而 Standby NN 负责观察 JNs 的变化,读取从 Active NN 发送过来的 Edits 信息,并更新自己内部的命名空间。
- 一旦 Active NN 遇到错误,Standby NN 需要保证从 JNs 中读出了全部的 Edits,然后切换成 Active 状态,如果有多个 Standby NN,还会涉及到选主的操作,选择一个切换为 Active 状态。
![](http://hangge.com/blog_uploads/202405/202405291120415124.png)
2,如何使元数据保持一致?
(1)为了保证 Active NN 与 Standby NN 节点状态同步,即元数据保持一致。这里的元数据包含两块,一个是静态的,一个是动态的。
(2)静态的是 fsimage 和 edits,其实 fsimage 是由 edits 文件合并生成的,所以只需要保证 edits 文件内容的一致性。这个就是需要保证多个 NameNode 中 edits 文件内容的事务性同步。这块的工作是由 JournalNodes 集群进行同步的。
(3)动态数据是指 block 和 DataNode 节点的信息。当 DataNode 启动的时候,上报数据信息的时候需要向每个 NameNode 都上报一份。这样就可以保证多个 NameNode 的元数据信息都一样了,当一个 NameNode down 掉以后,立刻从 Standby NN 中选择一个进行接管,没有影响,因为每个 NameNode 的元数据时刻都是同步的。
3,NameNode 切换方式
(1)NameNode 切换可以自动切换,也可以手工切换。如果想要实现自动切换,需要使用到 zookeeper 集群。
(2)使用 zookeeper 集群自动切换的原理是这样的:当多个 NameNode 启动的时候会向 zookeeper 中注册一个临时节点,当 NameNode 挂掉的时候,这个临时节点也就消失了,这属于 zookeeper 的特性。这个时候,zookeeper 就会有一个 watcher 监视器监视到,就知道这个节点 down 掉了,然后会选择一个节点转为 Active,把 down 掉的节点转为 Standby。
附二:HDFS 的高扩展(Federation)
1,HDFS Federation 作用
(1)HDFS Federation 可以解决单一命名空间存在的问题,使用多个 NameNode,每个 NameNode 负责一个命令空间。
(2)这种设计可提供以下特性:
- HDFS 集群扩展性:多个 NameNode 分管一部分目录,使得一个集群可以扩展到更多节点,不再因内存的限制制约文件存储数目。
- 性能更高效:多个 NameNode 管理不同的数据,且同时对外提供服务,将为用户提供更高的读写吞吐率。
- 良好的隔离性:用户可根据需要将不同业务数据交由不同 NameNode 管理,这样不同业务之间影响很小。
2,Federation 与 HA 结合
(1)通常来说 Federation 一般会和前面的 HA 结合起来使用。比如下面架构用到了 4 个 NameNode 和 6 个 DataNode:
- NN-1、NN-2、NN-3、NN-4
- DN-1、DN-2、DN-3、DN-4、DN-5、DN-6
(2)它们作用如下:
- 其中 NN-1、和 NN-3 配置了 HA,提供了一个命令空间 /share,其实可理解为一个顶级目录
- NN-2 和 NN-4 配置了 HA,提供了一个命名空间 /user
(3)这样后期我们存储数据的时候,就可以根据数据的业务类型来区分是存储到 share 目录下还是 user 目录下,此时 HDFS 的存储能力就是 /share和 /user 两个命名空间的总和了。
![](http://hangge.com/blog_uploads/202405/2024052917143111628.png)
附三:常见的分布式文件系统
(1)目前行业内除 HDFS 这个分布式文件系统外,还有 GFS、TFS、S3 等分布式文件系统:
![](http://hangge.com/blog_uploads/202401/2024010314082117659.png)
(2)这些分布式文件系统具备不同的特点,适用于不同的应用场景。
- GFS:全称是 Google File System,是 Google 公司为了存储海量搜索数据而设计的专用文件系统。它适合存储海量大文件,支持多客户端并发写入同一个文件。
- HDFS:全称是 Hadoop Distributed File System,属于 Hadoop 的组件,Apache 的顶级开源项目。HDFS 的设计参考了 GFS,可以认为它是 GFS 的简化开源版本。它适合存储海量大文件,不支持多客户端并发写入同一个文件。
- TFS:全称是 Taobao File Systerm,是淘宝团队开源的分布式文件系统。它作为淘宝内部使用的分布式文件系统,对于海量小文件的随机读写访问性能做了特殊优化,适合存储海量小文件。
- S3:全称是 Simple Storage Service(简单存储服务),是亚马逊提供的云存储解决方案。它是收费的,可以实现海量数据存储。
全部评论(0)