分布式文件系统（HDFS产生背景及定义 HDFS优缺点 HDFS体系架构 HDFS文件块大小）_分布式文件系统hdfs

HDFS概述

HDFS产生背景及定义

分布式文件系统（Distributed File System，DFS）是指文件系统管理的物理存储资源不一定直接连 接在本地节点上，而是通过计算机网络与节点（可简单的理解为一台计算机）相连；或是若干不同的逻 辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。DFS为分布在网络上任意位置的资源 提供一个逻辑上的树形文件系统结构，从而使用户访问分布在网络上的共享文件更加简便。单独的 DFS 共享文件夹的作用是相对于通过网络上的其他共享文件夹的访问点。

计算机通过文件系统管理、存储数据，而信息爆炸时代中人们可以获取的数据成指数倍的增长，单纯通 过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、容量增长速度、数据备份、数 据安全等方面的表现都差强人意。分布式文件系统可以有效解决数据的存储和管理难题：将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。人们在使用分布式文件系统时， 无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。分布式文件系统是建立在客户机/服务器技术基础之上的，一个或多个文件服务器与客户机文件系统协同操作，这样客户机就能够访问由服务器管理的文件。

分布式文件系统把大量数据分散到不同的节点上存储，大大减小了数据丢失的风险。分布式文件系统具有冗余性，部分节点的故障并不影响整体的正常运行，而且即使出现故障的计算机存储的数据已经损坏，也可以由其它节点将损坏的数据恢复出来。因此，安全性是分布式文件系统最主要的特征。分布式文件系统通过网络将大量零散的计算机连接在一起，形成一个巨大的计算机集群，使各主机均可以充分发挥其价值。此外，集群之外的计算机只需要经过简单的配置就可以加入到分布式文件系统中，具有极 强的可扩展能力。 

Hadoop分布式文件系统（HDFS）是指被设计成适合运行在通用硬件（commodity hardware）上的 分布式文件系统（Distributed File System）。它和现有的分布式文件系统有很多共同点。但同时， 它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分 POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目 的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。

HDFS的使用场景：适合一经写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并 不适合用来做网盘应用。

HDFS优缺点

HDFS优点：

1、高容错性
数据自动保存多个副本。它通过增加副本的形式，提高容错性。 某一个副本丢失以后，它可以自动恢复，这是由 HDFS 内部机制实现的。

2、适合批处理
它是通过移动计算而不是移动数据。

移动数据：从各个只能存的节点上把数据取出来，传输到可以计算的节点上，这是非常消耗机器性能、带宽、时间等等

移动计算：给每个节点装上CPU，内存。然后把计算的逻辑（就是我们写的程序）下发到各个节点上， 让每个节点自己进行计算，这就是移动计算。它会把数据位置暴露给计算框架。

3、适合大数据处理
处理数据达到 GB、TB、甚至PB级别的数据。 能够处理百万规模以上的文件数量，数量相当之大。 能够处理10K节点的规模。

4、流式文件访问
一次写入，多次读取。文件一旦写入不能修改，只能追加。 它能保证数据的一致性。

5、可构建在廉价机器上
它通过多副本机制，提高可靠性。 它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。

HDFS劣势：

1、低延时数据访问
比如毫秒级的来存储数据，它做不到。 它适合高吞吐率的场景，就是在某一时间内写入大量的数据。

2、小文件存储
存储大量小文件(这里的小文件是指小于HDFS系统的Block大小的文件（默认64M）)的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有 限的。 小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。

3、并发写入、文件随机修改
一个文件只能有一个写，不允许多个线程同时写。 仅支持数据 append（追加），不支持文件的随机修改。

体系架构

 HDFS具有主/从架构。所谓主从架构，通俗的讲就是主节点管理从节点，指挥从节点完成工作，从节点 向主节点报告工作状态。HDFS集群由单个NameNode，和多个datanode构成。

 

1. namenode：主/从架构中的主。
    主要职责：

        (1) 管理HDFS的名称空间；

        (2) 配置副本策略；

        (3) 管理数据块映射信息；

        (4) 处理客户端读写请求。

2. datanode：是主/从架构中的从。
    它的职责是：

        (1) 存储实际的数据块；

        (2) 执行数据块的读/写操作。

3. clinet：客户端。
        (1) 文件切分。文件上传HDFS的时候，由客户端切分成一个一个的块，然后上传；

        (2) 与namenode交互，获取文件的位置信息；

        (3) 与datanode交互，读取或者写入数据；

        (4) 客户端提供一些命令来管理HDFS，比如namenode格式化；

        (5) 客户端可以通过一些命令来访问HDFS，比如文件的上传，查看，复制，移动等操作。

4. secondary namenode：次级namenode
        (1) 辅助namenode，分担其工作量，比如定期合并FSimage和Edits，推送给namenode；

        (2) 在紧急情况下，可辅助恢复namenode。但是它不是namenode的备份。

合并过程

1. edits文件记录了客户端对HDFS所做的各种更新操作，客户端所有的写操作都被记录在了此 文件中。 而fsimage文件记录了元数据的文件，这个文件不是实时的，通俗来说，更像是对HDFS的一 个快照，它记录了某个时刻下的HDFS的状态信息。

2. 触发这两个文件合并的条件

        HDFS的重新启动

        edits文件达到指定的大小（默认64M，可更改）

        设置了指定时间促使两文件合并（默认3600s，可更改）

 SecondaryNameNode不是NameNode的热备，但也能起到一定的备份作用，这就说 明在一定情况下可能会产生数据丢失情况，所以在Hadoop2.0完全分布式中，抛弃了 SecondaryNameNode，采用了双NameNode机制来进行热备

edits文件和fsimage文件的合并发生在SecondaryNameNode上是因为这两个文件 比较合并耗时，如果在NameNode上合并可能会导致系统卡顿，所以在 SecondaryNameNode上进行

HDFS文件块大小
磁盘上存储数据的最小单位是扇区，扇区的大小为512字节（新的硬盘也有4KB）。

单一磁盘上的文件系统，以块为其读写数据的基本单位，提高读写效率。如果一个块的大小为4K，则该 文件系统中1个块是由连续的8个扇区组成。

在HDFS中，文件被划分成大小相等的数据块（Block），这些数据块被分布存储在文件系统的不同节点 上。块的大小可以通过配置参数（dfs.blocksize）来规定，默认大小在Hadoop2.x版本中是128M，老 版本中是64M。

为什么设计成块存储？

1、因为一个文件可以特别大，可以大于有个磁盘的容量，所以以块的形式存储，可以用来存储无论大小怎样的文件。

2、简化存储系统的设计。因为块是固定的大小，计算磁盘的存储能力就容易多了

3、以块的形式存储不需要全部存在一个磁盘上，可以分布在各个文件系统的磁盘上，有利于复制和容 错，数据本地化计算

· HDFS块不能设置的太小

HDFS的块设置太小，会增加文件的寻址时间。从文件系统的设计角度看，文件的传输速度往往是 不能控制的，能把控的是如何优化设计来提高文件的寻址时间。增大文件块，从而减少文件块文件 的总块数，从而减少块的寻址次数，提高寻址效率。让寻址时间要远远小于数据的传输时间。

· HDFS块不能设置的太大

块设置的太大会影响数据读写的效率；

块设置的太大会影响数据处理的效率。

注意：在HDFS中，文件块大小不足默认块大小，所占用的实际存储空间就是块大小。

---

原文转自：分布式文件系统（HDFS产生背景及定义 HDFS优缺点 HDFS体系架构 HDFS文件块大小）_G不来也不去的博客-CSDN博客https://blog.csdn.net/weixin_58808338/article/details/123905335?spm=1001.2100.3001.7377&utm_medium=distribute.pc_feed_blog_category.none-task-blog-classify_tag-1.nonecase&depth_1-utm_source=distribute.pc_feed_blog_category.none-task-blog-classify_tag-1.nonecase