HDFS

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SingleCluster.html

HDFS概述

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

HDFS全称Hadoop Distributed File System。

HDFS操作

Web管理界面

访问http://localhost:9870/dfshealth.html#tab-overview，其中端口号是根据自己在按照hadoop的时候，文件配置过程中，自己进行配置的
image
通过界面可以直接进行文件上传，下载等操作

如果报错 Couldn't upload the file xxx. 如下图所示，参考：https://blog.csdn.net/qq_22744093/article/details/130379433
image
打开浏览器kong
image
控制台会报错 403

可能的原因

  1. 域名解析问题

  2. 权限问题
    修改 %HADOOP_HOME%\etc\hadoop\hdfs-site.xml 配置文件：

<configuration>
 ...
	<property>  <!--测试环境可以把dfs文件权限关闭（便于不同用户访问）-->
		<name>dfs.permissions</name>
		<value>true</value>
	</property>
 ...
 </configuration>

命令操作

  1. 列出 HDFS 根目录下的文件和目录：hdfs dfs -ls /

[root@localhost hadoop-3.3.0]# hdfs dfs -ls /
Found 3 items
drwxr-xr-x - dr.who supergroup 0 2025-07-31 11:14 /ch4
drwxrwxrwx - root supergroup 0 2025-07-29 12:02 /spark-logs
drwxrwxrwx - root supergroup 0 2025-07-29 12:08 /user

  1. 上传文件到 HDFS
    hdfs dfs -put /local/path/to/file /hdfs/path/to/destination

从 HDFS 下载文件
hdfs dfs -get /hdfs/path/to/file /local/path/to/destination

删除 HDFS 中的文件
hdfs dfs -rm /hdfs/path/to/file

递归删除 HDFS 中的目录
hdfs dfs -rm -r /hdfs/path/to/directory

创建目录
hdfs dfs -mkdir /hdfs/path/to/directory

查看文件内容
hdfs dfs -cat /hdfs/path/to/file

移动文件或目录
hdfs dfs -mv /hdfs/source/path /hdfs/destination/path

复制文件
hdfs dfs -cp /hdfs/source/path /hdfs/destination/path

查看文件或目录的大小
hdfs dfs -du -h /hdfs/path/to/file

查看文件的类型（如文件或目录）
hdfs dfs -stat %F /hdfs/path/to/file

在首次使用 HDFS 时，需要格式化 NameNode
hdfs namenode -format

查看 HDFS 的总体状态和各个节点的健康状况
hdfs dfsadmin -report

递归列出目录下的所有文件和子目录
hdfs dfs -ls -R /hdfs/path/to/directory

基础架构

NameNode and DataNodes

image

文件系统命名空间

HDFS 支持传统的层级文件组织结构。用户或应用程序可以创建目录并在这些目录中存储文件。

文件系统命名空间的层次结构与大多数其他现有文件系统类似；用户可以创建和删除文件、将文件从一个目录移动到另一个目录，或者重命名文件。HDFS 支持用户配额和访问权限。HDFS 不支持硬链接或软链接。
然而，HDFS 架构并不排除实现这些功能。

虽然 HDFS 遵循文件系统的命名约定，但某些路径和名称（例如 /.reserved 和 .snapshot ）是保留的。透明加密和快照等功能使用保留路径。

NameNode 维护文件系统命名空间。对文件系统命名空间或其属性的任何更改都会由 NameNode 记录。应用程序可以指定 HDFS 应维护的文件副本数。文件的副本数称为该文件的复制因子。此信息由 NameNode 存储。

数据备份

Hadoop 具有创建文件块副本的功能，以提供高可用性和容错能力。
HDFS设计的目的是用来在集群中可靠存储大文件，每个文件会被分成很多块（block），每个块在集群中会有备份以增加容错性。一个文件除了最后一个块之外，大小都一样，

NameNode会定期从集群中的每个DataNode接收心跳和块报告。收到心跳信号意味着DataNode运行正常。块报告包含DataNode上所有块的列表。

image

默认情况下，副本因子 (Replication Factor) 为 3，

副本选择机制

为了最大限度地减少全局带宽消耗和读取延迟，HDFS试图满足来自最接近读的副本的读取请求。如果与读节点在同一机架上存在副本，则首选该副本以满足读取请求。如果HDFS集群跨越多个数据中心，那么驻留在本地数据中心的副本比任何远程副本都更可取。

Rack Awareness

参考资料：
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/RackAwareness.html
https://www.geeksforgeeks.org/data-engineering/hadoop-rack-and-rack-awareness/

Rack的概念：
机架是Hadoop集群中节点的物理集合。一个大型Hadoop集群由许多机架组成。借助此机架信息，Namenode选择最近的Datanode以实现最大性能，同时执行读/写信息，从而减少网络拥堵。一个机架可以有多个数据节点来存储文件块及其副本。Hadoop会自动在机架中的2个不同数据节点中写入特定的文件块。

image

同一机架上的数据节点之间的通信速度远快于两个不同机架上的数据节点之间的通信速度。NameNode 保存着 Hadoop 集群中所有机架的 ID, 因此能够查找最近的数据节点，从而提高性能。这种选择最近数据节点来提供服务的概念就是机架感知。让我们通过一个例子来理解这一点。

image
在上图中，Hadoop 集群中有 3 个不同的机架，每个机架包含 4 个 Datanode。现在假设有 3 个文件块 (Block 1、Block 2、Block 3) 想要放置在这个数据节点上。因此 Hadoop 非常智能，它会以最佳的网络带宽方式将块的副本放置在机架中。为此，Hadoop 制定了一些机架感知策略。

  1. 同一个 Datanode 上的副本数不应超过 1 个。
  2. 同一个机架上的单个块的副本数不得超过 2 个。
  3. Hadoop 集群中使用的机架数量必须小于副本数量。

块 1 位于机架 1 的第一个数据节点上，而块 1 的 2 个副本分别位于机架 5 和 6 个数据节点上，总数为 3。同样，我们还有另外 2 个块的副本分布在不同的机架上，并遵循上述策略。在 Hadoop 集群中实施机架感知的优势：

  1. 通过机架感知策略，我们将数据存储在不同的机架中，因此不会丢失数据。
  2. 机架感知有助于最大限度地利用网络带宽，因为数据块在机架内传输。
  3. 可以提高集群性能并提供高数据可用性。

image

块放置策略

当复制因子为 3 时，HDFS 的放置策略是：如果写操作位于 DataNode 上，则将一个副本放置在本地计算机上；否则，放置在与写入器位于同一机架中的随机数据节点上；另一个副本放置在不同（远程）机架中的节点上；最后一个副本放置在同一远程机架中的另一个节点上。如果复制因子大于 3，则第 4 个及之后的副本的放置位置是随机确定的，同时将每个机架的副本数量保持在上限以下（基本上是 (副本 - 1) / 机架 + 2）。此外，HDFS 还支持 4 种不同的可插拔块放置策略。用户可以根据其基础架构和用例选择策略。默认情况下，HDFS 支持 BlockPlacementPolicyDefault。

读数据流程

image

持久化

https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#The_Persistence_of_File_System_Metadata

HDFS 命名空间由 NameNode 存储。NameNode 使用名为 EditLog 的事务日志来持久记录文件系统元数据发生的每一次更改。例如，在 HDFS 中创建一个新文件会导致 NameNode 向 EditLog 中插入一条记录以指示此更改。同样，更改文件的复制因子也会导致在 EditLog 中插入一条新记录。NameNode 使用其本地主机操作系统文件系统中的一个文件来存储 EditLog。整个文件系统命名空间，包括块到文件的映射以及文件系统属性，都存储在一个名为 FsImage 的文件中。FsImage 也以文件形式存储在 NameNode 的本地文件系统中。

NameNode 在内存中保存整个文件系统命名空间和文件块映射的映像。当 NameNode 启动或由可配置阈值触发检查点时，它会从磁盘读取 FsImage 和 EditLog，将 EditLog 中的所有事务应用到 FsImage 的内存表示中，并将此新版本刷新到磁盘上的新 FsImage 中。然后，它可以截断旧的 EditLog，因为其中的事务已应用于持久化的 FsImage。此过程称为检查点。检查点的目的是通过生成文件系统元数据的快照并将其保存到 FsImage 中，确保 HDFS 对文件系统元数据读取的一致性。尽管读取 FsImage 很高效，但直接对 FsImage 进行增量编辑效率不高。我们不是每次编辑都修改 FsImage，而是将编辑持久化到 Editlog 中。在检查点期间，Editlog 中的更改将应用​​于 FsImage。

检查点可以在给定的时间间隔（dfs.namenode.checkpoint.period）（以秒为单位）触发，也可以在累积了给定数量的文件系统事务（dfs.namenode.checkpoint.txns）后触发。如果同时设置了这两个属性，则第一个达到的阈值将触发检查点。

DataNode 将 HDFS 数据存储在其本地文件系统的文件中。DataNode 并不了解 HDFS 文件。它将每个 HDFS 数据块存储在其本地文件系统的单独文件中。DataNode 不会将所有文件都创建在同一目录中。相反，它会使用启发式算法来确定每个目录中的最佳文件数量，并相应地创建子目录。将所有本地文件都创建在同一目录中并非最佳做法，因为本地文件系统可能无法高效地支持单个目录中的大量文件。DataNode 启动时，会扫描其本地文件系统，生成与每个本地文件对应的所有 HDFS 数据块的列表，并将此报告发送给 NameNode。该报告称为“块报告 (Blockreport)”。

fsimage

edits log

hdfs namenode -format
windows系统
\tmp\hadoop-${用户名}\dfs\name\current

HA机制和Secondary NameNode/ ObserverNameNode

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/ObserverNameNode.html

HA机制

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
HA机制是NameNode用来保证高可用的一个策略

在 Hadoop 2.0.0 之前，每个HDFS集群只有一个 NameNode，如果该机器或进程不可用，整个集群将不可用，直到 NameNode 重新启动或在另一台机器上启动为止。

这主要以两种方式影响了 HDFS 集群的整体可用性：

  1. 如果发生意外事件（例如机器崩溃），集群将不可用，直到重新启动 NameNode。
    2.计划内维护事件（例如 NameNode 机器上的软件或硬件升级）会导致集群停机。

HDFS 高可用性功能通过提供在同一集群中以主动/被动配置运行两个（从 3.0.0 开始超过两个）冗余 NameNode 的选项来解决上述问题，该配置具有热备用功能。这可以在机器崩溃时快速故障转移到新的 NameNode，或者在计划维护期间由管理员优雅地启动故障转移。

架构设计

在典型的高可用性 (HA) 集群中，两台或多台独立的机器配置为 NameNode。在任何时间点，只有一个 NameNode 处于活动状态，其他 NameNode 处于备用状态。活动 NameNode 负责集群中的所有客户端操作，而备用节点则充当工作节点，维护足够的状态以便在必要时提供快速故障转移。

为了使备用节点与活动节点保持状态同步，两个节点都与一组称为JournalNode（JN）的独立守护进程进行通信。当活动节点执行任何命名空间修改时，它会将修改记录持久地记录到大多数 JN 中。备用节点能够从 JN 读取编辑，并持续监视它们以查看编辑日志的更改。当备用节点看到编辑时，它会将其应用到自己的命名空间。在发生故障转移时，备用节点将确保已从 JournalNode 读取所有编辑，然后再将自身提升为活动状态。这可确保在故障转移发生之前命名空间状态完全同步。

为了提供快速故障转移，备用节点还需要拥有集群中块位置的最新信息。为了实现这一点，DataNode 会配置所有 NameNode 的位置，并向所有 NameNode 发送块位置信息和心跳。

对于高可用性 (HA) 集群的正常运行至关重要，因为同一时间只有一个 NameNode 处于活动状态。否则，命名空间状态会在两个 NameNode 之间快速变化，从而导致数据丢失或其他错误结果的风险。为了确保此特性并防止所谓的“脑裂”情况，JournalNode 在同一时间只允许一个 NameNode 进行写入。在故障转移期间，即将变为活动状态的 NameNode 将接管向 JournalNode 写入数据的任务，这将有效地阻止另一个 NameNode 继续处于活动状态，从而使新的活动状态能够安全地进行故障转移。

HA集群搭建

NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。在这种情况下就会出现下面一些问题：

edit logs文件会变的很大，怎么去管理这个文件是一个挑战。

NameNode的重启会花费很长时间，因为有很多改动要合并到fsimage文件上。
如果NameNode挂掉了，那我们就丢失了很多改动，因为此时的fsimage文件非常旧。

因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

NameNode需要保持文件系统最新的元数据。

DataNode 工作机制

image

数据完整性

posted @ 2025-07-01 22:49  vonlinee  阅读(23)  评论(0)    收藏  举报