分布式文件系统

文件系统是操作系统用来组织磁盘文件的方法和数据结构。

## 本地文件系统

传统的文件系统指的是UNIX平台上的各种文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称为本地文件系统。它们管理着本地的磁盘存储资源，提供文件到存储位置的映射，并抽象出一套文件访问接口以供用户使用。

本地文件系统通常仅位于一个磁盘或者一个磁盘分区上，只能被唯一的主机访问，不能被多个主机共享。

本地文件通常有以下四类信息：

1. 超级块：用来描述文件系统的整体信息，含有整个文件系统的数据块和inode的相关信息。
2. 索引节点（inode）：用来描述文件和目录的属性以及文件块在块设备上的位置信息。
3. 文件内容：用户的数据，无结构。
4. 目录内容：目录项，有结构。

超级块通常位于磁盘（或者分区）上的固定位置，根据文件系统类型可定位超级块，通过超级块可定位根目录的inode，从而读取根目录的内容。

本地文件系统只能访问与主机通过I/O总线直接相连的磁盘数据，当局域网出现后，主机间通过网络互联。如果每台主机都保存一份用户需要的文件，即浪费存储资料又不容易保持各个文件的一致性。

于是就有了文件共享的需求，即一台主机需要访问其他主机磁盘或者文件系统，为了解决这个资源共享的问题，就出现了分布式文件系统。

## 什么是分布式文件系统

分布式文件系统（Distributed File System, DFS）是一种将数据分散存储在多台独立服务器（节点）上，并通过网络实现统一管理和访问的存储架构。

简单比喻：想象一下，传统的文件系统就像你个人电脑上的一个硬盘（C盘、D盘）。而分布式文件系统则像是一个由无数台电脑的硬盘组成的“超级网络硬盘”。对你来说，它看起来仍然是一个统一的、巨大的存储空间，你可以像在本地一样存取文件，但你并不知道你的文件具体被存放在哪台电脑上，也不需要关心。

其核心目标是突破单机存储在容量、性能、可靠性上的限制，满足大数据、云计算、边缘计算等场景下的海量数据处理需求。

## 为什么需要分布式文件系统

随着互联网和大数据时代的到来，数据量呈爆炸式增长，传统存储方式遇到了瓶颈：

1. 容量瓶颈：单台服务器的存储容量和扩展能力有限，无法存储PB（Petabyte）级甚至EB（Exabyte）级的数据。
2. 性能瓶颈：单台服务器的I/O（输入/输出）吞吐量有限，无法同时满足成千上万用户的高并发访问需求。
3. 成本与可靠性瓶颈：使用大型、昂贵的专用存储设备（如高端SAN）来扩展容量和性能，成本极高。同时，单点故障风险大，一台机器宕机可能导致整个服务不可用或数据丢失。

分布式文件系统的设计正是为了解决这些问题，实现：

海量存储：理论上可以无限扩展存储容量。

高并发访问：允许多个客户端同时访问。

高可靠性和高可用性：数据有多个副本，即使部分硬件故障，服务不中断，数据不丢失。

成本效益：使用普通的、廉价的商用硬件来构建大规模存储集群。

## 工作原理

一个典型的DFS通常包含以下三个关键角色：

| 角色 | 功能 | 类比 |
| ------------------- | ------------------------------------------------------------ | -------------------------- |
| 客户端 | 访问DFS的应用程序或用户。它向主节点请求文件位置，然后直接与数据节点交互读写数据。 | 想要借书的读者 |
| 主节点/元数据服务器 | DFS的“大脑”。负责管理文件系统的元数据，包括： • 文件命名空间（目录树结构） • 文件到数据块的映射（一个文件被切成了哪些块） • 数据块的位置信息（每个数据块存储在哪些数据节点上）。 | 图书馆的中央索引系统 |
| 数据节点 | 负责在本地磁盘上存储实际的数据块，并处理客户端的读写请求。一个集群中有成百上千个数据节点。 | 图书馆里存放具体书籍的书架 |

> 一次典型的文件读写流程（以读为例）

查询元数据：客户端向主节点发起请求：“我想读文件 /data/log.txt”。

返回位置信息：主节点查询元数据，告诉客户端：“这个文件被分成了3个块：A, B, C。块A在数据节点1和3上，块B在节点2和4上...”。

直接读取数据：客户端直接与最近的数据节点（如节点1）通信，读取块A的数据。然后继续读取其他块。

组合文件：客户端将从各个数据节点获取的数据块组合成完整的文件。

关键点：主节点只管理元数据，实际的数据传输是在客户端和数据节点之间直接进行的。这避免了主节点成为性能瓶颈。

## 关键技术

数据分块：将大文件分割成固定大小的数据块（例如64MB或128MB），这便于管理、存储和并行处理。

数据冗余与复制：为了保证可靠性，每个数据块都会被复制到多个（通常是3个）不同的数据节点上，即使一个节点宕机或磁盘损坏，数据也不会丢失，可以从其他副本读取。

一致性模型：定义了多个客户端同时读写同一个文件时，系统如何保证数据的一致性。常见模型有：

- 强一致性：任何读操作都能读到最新写入的数据。（实现复杂，性能影响大）
- 最终一致性：在一段时间没有更新后，所有副本最终会变得一致。（实现简单，性能高，是许多DFS的选择）

容错机制：

- 主节点容错：通过主备切换实现。有一个备用主节点，当主节点故障时，备用节点会接管工作。
- 数据节点容错：主节点定期接收数据节点的心跳报告。如果某个数据节点失联，主节点会知道其上的数据块副本数不足，并启动复制流程，在其它健康节点上创建新的副本。

负载均衡：系统会自动将新的数据和客户端请求分散到不同的数据节点上，防止个别节点过热，确保集群整体性能最优。

实现分布式文件系统一般有两种方法：共享文件系统（shared file system approach）和共享磁盘（shared disk approach）

## 集群

分布式文件系统不是将数据放在一块磁盘上，而是存放在服务器集群中，由集群中的服务器各尽其职、通力合作，提供整个文件系统的服务。

在一个经典的分布式文件系统集群中，通常包含三种核心类型的服务器节点，每种节点有不同的硬件要求。

> 主控服务器

核心职责：负责管理元数据，包括：

- 文件系统的命名空间（目录树结构）。
- 文件到数据块的映射关系（如一个1GB的文件被切成了哪些128MB的数据块）。
- 每个数据块副本所在的物理位置。
- 系统运行状态监控（如数据节点的心跳检测）。

硬件要求：

- CPU：需要强大的单核或多核性能，因为元数据操作（如路径解析、块映射）是CPU密集型任务。
- 内存：至关重要。为了极快的元数据访问，通常会将所有元数据完全加载到内存中。因此，内存容量直接决定了文件系统可支持的文件数量。需要大容量、高规格的ECC内存。
- 存储：需要高可靠、高IOPS的存储设备（如SSD RAID）来持久化元数据日志和镜像文件，确保主节点故障后能快速恢复。对容量要求不高。
- 网络：高速网络接口，与所有数据节点和客户端通信。

高可用方案：为避免单点故障，通常会配置主备节点（Active-Standby）。备用主节点实时同步主节点的元数据变更，当主节点故障时自动接管。

> 数据服务器

核心职责：负责实际的数据存储。它们：

- 在本地磁盘上存储数据块。
- 处理客户端的读写请求。
- 执行数据块的创建、删除和复制指令（来自主节点）。
- 定期向主节点发送心跳报告和块列表。

硬件要求：

- 存储：核心要求。需要巨大的存储容量和高吞吐量。通常配备大量（数十块）大容量的SATA或SAS机械硬盘（HDD），并可能用SSD做缓存。追求容量/成本比。
- CPU和内存：要求相对较低，足以处理本地I/O和网络传输即可。
- 网络：需要高带宽网络接口，因为数据需要在数据节点之间以及数据节点与客户端之间大量传输。

> 客户端

这不是集群内的服务器，而是访问文件系统的应用程序或用户终端。它通过分布式文件系统的客户端库与主节点和数据节点交互。

## 数据分布策略

> 数据分块

将大文件分割成固定大小的数据块（例如HDFS默认为128MB或256MB）。

优点：

- 简化存储管理：统一大小的块易于管理。
- 适合并行处理：不同的数据块可以被分发到不同的节点上进行并行计算（如MapReduce）。
- 实现负载均衡：小文件可能只占用一个块，大文件被分散到多个节点，避免了单个节点成为热点。

> 副本放置策略

每个数据块都会被复制多份（默认通常为3份），以实现容错。

副本的放置策略直接影响系统的可靠性和性能。一个经典的机架感知策略如下：

1. 第一个副本：放置在客户端所在的数据节点上（如果客户端不在集群内，则随机选择一个负载较轻的节点）。
2. 第二个副本：放置在与第一个副本不同机架的另一个数据节点上。
3. 第三个副本：放置在与第二个副本相同机架的不同节点上。

策略解读：

- 跨机架放置：防止单个机架断电或网络故障导致数据完全不可用，提供了机架级别的容错能力。
- 同机架放置：减少了跨机架传输的网络带宽消耗，因为读写数据时，同机架内的网络带宽通常更充裕、延迟更低。

## 服务器间协议

> 客户端协议

客户端 ↔ 主节点：

- 查询协议：客户端通过此协议向主节点询问文件的数据块位置（getBlockLocations）。
- 注册协议：客户端创建文件时，通知主节点，并获取可写入的数据节点列表（create, addBlock）。

客户端 ↔ 数据节点：

- 数据交换协议：客户端直接与数据节点通信，读取或写入数据块内容。这是实际数据流的通道，不经过主节点，避免了主节点的网络带宽瓶颈。

> 数据节点协议

数据节点 ↔ 主节点（心跳协议）：

- 定期心跳：数据节点每隔几秒向主节点发送一次心跳信号，报告自己“存活”。
- 块报告：心跳中包含该数据节点当前存储的所有数据块列表。主节点据此构建全局的数据块映射表。
- 指令传达：主节点通过心跳的返回值，向数据节点下达指令，如复制数据块到其他节点、删除本地数据块、或进行数据块恢复等。

> 数据节点间协议

块复制协议：当主节点发现某个数据块的副本数量不足时（如某个数据节点宕机），会命令一个存有该副本的数据节点，将块复制到另一个健康的数据节点上。

数据管道写入协议：客户端写入数据时，如果副本数为3，它可能只将数据发送给第一个数据节点，然后由该节点依次转发给第二个节点，第二个节点再转发给第三个节点，形成一个流水线，提高写入效率。

> 主节点间协议（在高可用设置中）

共享存储协议：主备主节点通过一个共享的存储（如Network Attached Storage - NAS 或 Quorum Journal Manager）来同步元数据变更日志（Edit  Log）。活跃主节点将日志写入共享存储，备用主节点持续读取并应用这些日志，保持状态同步。

租约与锁协议：用于确保在任一时刻，只有一个主节点处于活跃状态，防止“脑裂”现象。

## GFS

### 概述

谷歌文件系统（Google File System, GFS）是谷歌在 2003 年通过技术论文正式发布的分布式文件系统，专为解决 “超大规模数据（PB 级甚至 EB 级）的高效存储、读写与容错” 设计，是谷歌早期大数据技术栈（如 MapReduce、BigQuery）的核心底层支撑，直接服务于谷歌搜索、YouTube、Gmail 等核心业务的数据存储需求。

GFS 的设计完全围绕谷歌的实际业务场景（如大文件批量处理、高吞吐量优先），而非通用分布式场景，因此形成了独特的架构与技术特性。

GFS由几百台甚至几千台普通廉价设备组装的存储机器。

### 架构设计

GFS 采用 “主从（Master-Slave）” 架构，通过三类角色的协同，实现数据的分布式管理与访问，架构图可简化为：Client（客户端） ↔ Master（主节点） ↔ Chunk Server（块服务器）。三者职责明确分离，避免单点瓶颈，同时保障容错性。

| 角色 | 核心职责 | 关键特性 |
| ------------ | -------------------------------------------------- | ------------------------------------------------------------ |
| Master | 管理元数据（非实际数据），负责全局决策 | 1. 不存储实际文件数据，仅存 “文件目录、Chunk 映射、副本位置”； 2. 用内存存储元数据，提升查询速度； 3. 通过 “Checkpoint + 日志” 实现元数据持久化与故障恢复 |
| Chunk Server | 存储实际文件数据，处理 Client 的读写请求 | 1. 将文件分割为64MB/128MB 的 Chunk（数据块）（早期 64MB，后期升级为 128MB）； 2. 每个 Chunk 默认存储 3 份副本（跨机架分布，避免单点故障）； 3. 通过 “心跳机制” 向 Master 汇报状态 |
| Client | 发起文件读写请求，作为用户 / 应用与 GFS 的交互入口 | 1. 与 Master 仅交互元数据（如 “某文件的 Chunk 存在哪些 Server 上”），不通过 Master 读写数据； 2. 直接与 Chunk Server 通信完成数据传输，减少 Master 压力 |

### 设计原则

GFS 的所有设计都围绕谷歌的核心需求 ——“处理大文件、高吞吐量、容忍节点故障”，因此放弃了部分通用文件系统的特性（如低延迟、小文件优化），形成三大核心原则：

> 面向 “大文件” 与 “流式读写” 优化

大文件优先：谷歌的业务场景以 GB 级、TB 级大文件为主（如搜索索引数据、YouTube 视频文件），因此 GFS 将 Chunk 大小设为 64MB/128MB（远大于传统文件系统的 4KB/8KB），好处是：

- 减少元数据总量：1 个 TB 文件仅需约 1 万个 Chunk（1TB/128MB），Master 内存可轻松承载百万级文件的元数据；
- 提升读写效率：单次 IO 可覆盖更大数据量，减少 Client 与 Chunk Server 的交互次数，适合批量处理。

流式读写优先：谷歌的应用（如 MapReduce）多为 “一次写入、多次读取” 的流式场景（而非随机读写），因此 GFS 优化了顺序 IO 的吞吐量，对随机读写支持较弱（无需满足低延迟需求）。

> 牺牲 “强一致性”，换取 “高可用性”

GFS 不追求通用文件系统的 “强一致性”（即所有客户端同时看到相同的数据状态），而是采用 “最终一致性 + 应用层适配” 的策略：

- 写入机制：采用 “租约（Lease）” 机制 ——Master 为某 Chunk 指定一个 “主副本（Primary  Chunk）”，由主副本协调所有副本的写入顺序，确保 “所有副本最终写入相同数据”，但可能存在短暂的不一致（如 Client  重试导致的重复数据）；
- 一致性保障：应用层需自行处理潜在的不一致（如搜索索引构建可容忍重复数据，最终会合并），换取更高的写入吞吐量与容错性。

> 容错设计贯穿全架构

谷歌的集群规模达数千台服务器，节点故障（硬件损坏、网络中断）是常态，因此 GFS 从三个层面保障容错：

Master 容错：

- 元数据持久化：通过 “Checkpoint（快照）” 将内存元数据定期写入磁盘，同时用 “操作日志（Edit Log）” 记录所有修改，故障后可通过 “快照 + 日志” 恢复；
- 影子 Master（Shadow Master）：同步 Master 的日志，可在主 Master 故障时快速切换，避免服务中断。

Chunk Server 容错：

- 多副本存储：默认 3 份副本，跨机架分布（如副本 1 在机架 A，副本 2 在机架 B，副本 3 在机架 C），避免单机架故障导致数据丢失；
- 故障检测与恢复：Master 通过 “心跳包” 检测 Chunk Server 状态，若某 Server 下线，Master 会自动在其他 Server 上重建副本（维持 3 份）。

数据完整性容错：

- 校验和（Checksum）：每个 Chunk Server 为自己存储的 Chunk 计算校验和（如 CRC32），读取时验证校验和，若发现数据损坏（如磁盘错误），则向其他副本读取正确数据并重建。

### 数据写入流程

以 “追加写入” 为例，GFS 最常用的写入方式

Client 请求元数据：Client 向 Master 发送 “追加写入文件 A” 的请求，Master 返回文件 A 对应的 “目标 Chunk（如 Chunk X）” 及其 3 个副本的位置，并为 Chunk X 指定一个 “主副本（Primary）”。

主副本协调顺序：Client 将待写入数据发送给所有 3 个副本（先缓存到副本的内存中），待所有副本确认接收后，Client 向主副本发送 “写入指令”。

副本同步写入：主副本按接收顺序（避免乱序）向所有从副本（Secondary）发送 “写入指令”，从副本完成写入后向主副本确认。

返回结果：主副本收到所有从副本的确认后，向 Client 返回 “写入成功”；若某副本写入失败，Master 会后续重建副本，保证数据最终一致。

### 数据读取流程

Client 请求元数据：Client 向 Master 发送 “读取文件 A 的某段数据” 的请求，Master 返回该数据所在的 Chunk 及对应的 3 个副本位置。

选择最优副本：Client 根据 “网络距离” 选择最近的副本（如同一机架的副本，减少跨机架延迟），直接向该副本发送读取请求。

返回数据：Chunk Server 读取本地磁盘的 Chunk 数据，返回给 Client；若该副本读取失败（如校验和错误），Client 会自动尝试其他副本。

### 元数据管理优化

Master 的元数据是 GFS 的 “大脑”，其管理效率直接决定系统性能，因此 GFS 做了两点关键优化：

元数据全内存存储：Master 将所有元数据（文件目录、Chunk 映射、副本位置）存于内存，避免磁盘 IO 延迟，支持每秒数万次元数据查询；

元数据轻量化：仅存储 “文件 - Chunk” 的映射（而非 “文件 - 字节” 的细粒度映射），且 Chunk 大小大（128MB），因此元数据总量极小（如 100 万个文件，每个文件对应 100 个 Chunk，元数据仅需约 400MB）。

## HDFS

### 概述

HDFS（Hadoop Distributed File System，Hadoop 分布式文件系统）是 Apache Hadoop 生态系统的核心子项目，也是整个 Hadoop 生态的 “存储基石”—— 它专为解决 “PB 级以上海量数据的分布式存储、高可靠容错、高吞吐量读写” 设计，直接支撑  Hadoop 生态中 MapReduce、Spark、Hive、HBase 等计算 / 分析组件的 IO  需求，是大数据离线批处理场景的标配存储方案。

HDFS 的设计理念直接源于谷歌 GFS（Google File System）（参考 2003 年 GFS 论文），但在开源落地过程中，针对通用大数据场景做了适配优化，形成了更贴近企业级需求的架构与功能。

### 定位

在 Hadoop 生态中，HDFS 的核心使命是为所有计算组件提供 “高可靠、高吞吐、可扩展” 的分布式存储服务，其定位可概括为三点：

存储海量数据：支持 PB 级甚至 EB 级数据存储，单集群可扩展至数千个节点，满足企业级大数据的存储规模需求；

适配批处理场景：优化 “一次写入、多次读取” 的流式 IO（而非低延迟随机读写），匹配 MapReduce、Spark 离线计算的 “批量数据处理” 需求；

保障数据可靠：通过多副本、故障自动恢复等机制，确保数据在节点故障（硬件损坏、网络中断）时不丢失，满足生产环境的可靠性要求。

### 架构设计

HDFS 沿用 GFS 的 “主从架构”，但对组件命名和功能做了细化，核心由三类节点组成，职责分工明确，避免单点瓶颈：

| 组件（角色） | 核心职责 | 与 GFS 组件的对应关系 | 关键特性 |
| ------------------------------- | ------------------------------------------------------------ | ------------------------------------- | ------------------------------------------------------------ |
| NameNode（主节点） | 管理元数据（非实际数据），是 HDFS 的 “大脑” | 对应 GFS 的 Master | 1. 存储元数据：文件目录结构、文件与数据块（Block）的映射、DataNode 节点信息； 2. 内存存储元数据：所有元数据加载到内存，提升查询速度（需控制集群规模，避免内存不足）； 3. 不存储实际数据：仅负责决策，不参与数据读写，减少压力。 |
| DataNode（从节点） | 存储实际数据块，处理客户端的读写请求，是 HDFS 的 “存储载体” | 对应 GFS 的 Chunk Server | 1. 数据块存储：将文件分割为默认 128MB 的 Block（可配置，早期为 64MB），每个 Block 存储在本地磁盘； 2. 副本管理：按配置存储 Block 的多副本（默认 3 份），跨机架分布； 3. 状态汇报：通过 “心跳机制”（每 3 秒一次）向 NameNode 汇报自身状态和 Block 信息。 |
| SecondaryNameNode（辅助主节点） | 辅助 NameNode 管理元数据，避免 NameNode 元数据膨胀或故障时数据丢失 | 类似 GFS 的 “影子 Master”（但非热备） | 1. 合并编辑日志：定期（默认 1 小时）从 NameNode 获取 “编辑日志（EditLog）” 和 “镜像文件（FSImage）”，合并生成新的 FSImage，发送回 NameNode，减少 NameNode 重启时的恢复时间； 2. 非高可用角色：不是 NameNode 的热备节点（早期版本），无法直接替代 NameNode 提供服务，仅辅助元数据管理。 |

NameNode 高可用（HA）架构（企业级核心改进）

早期 HDFS 的最大风险是NameNode 单点故障（若 NameNode 宕机，整个 HDFS 不可用）。为解决此问题，Hadoop 2.x 后引入 “NameNode HA” 架构，核心改进是：

- 部署两个 NameNode：一个 “Active（活跃）” 节点（对外提供服务），一个 “Standby（备用）” 节点（实时同步 Active 的元数据）；
- 引入JournalNode 集群：Active 节点的所有元数据修改（如文件创建、Block 映射变更）会实时写入 JournalNode，Standby 节点从 JournalNode 同步修改，确保两者元数据一致；
- 自动故障切换：当 Active 节点宕机时，通过 ZooKeeper 的 “故障检测” 和 “选举机制”，快速将 Standby 节点切换为 Active，恢复服务（切换时间通常 < 1 分钟）。

此时，SecondaryNameNode 的角色被弱化，仅在非 HA 架构中继续使用。

### 设计原则

HDFS 的设计完全围绕 “大数据离线批处理” 的需求，放弃了部分通用文件系统特性（如低延迟、小文件优化），形成三大核心原则：

> 面向 “大文件” 优化

大 Block 设计：默认 Block 大小为 128MB（可配置为 256MB），远大于传统文件系统（4KB/8KB），好处是：

- 减少元数据总量：1 个 1TB 文件仅需 8192 个 Block（1TB/128MB），NameNode 内存可轻松承载（如 100 万个文件，每个对应 100 个 Block，元数据仅需约 400MB）；
- 减少 IO 交互次数：客户端读写大 Block 时，单次 IO 可覆盖更多数据，减少与 DataNode 的连接建立 / 断开开销，提升吞吐量；
- 适配批处理：MapReduce/Spark 等计算框架可按 Block 划分任务，避免任务粒度过小导致的调度开销。

> 优先保障 “高吞吐量”，而非 “低延迟”

HDFS 的设计目标是 “支持每秒数百 MB 甚至 GB 级的批量数据读写”（如 MapReduce 处理 PB 级数据时的 IO 需求），因此牺牲了低延迟（不适合毫秒级响应的场景，如数据库随机读写）；

例如：读取一个 1GB 文件时，HDFS 可通过并行读取多个 Block 的副本，实现高吞吐；但读取一个 1KB 小文件时，延迟会显著高于本地文件系统。

> 一次写入、多次读取”（WORM）与弱一致性

写入特性：支持 “追加写入”（Append）和 “一次性写入”（Write-Once），不支持随机写（如修改文件中间内容）—— 这是因为批处理场景中，数据通常是 “生成后反复分析”，无需频繁修改；

一致性模型：采用 “弱一致性” 而非强一致性：

- 写入成功后，所有客户端不一定能立即看到最新数据（需等待元数据同步）；
- 若写入失败（如节点宕机），可能产生 “部分写入的数据块”，HDFS 会通过后台进程自动清理；
- 这种设计降低了分布式协调的复杂度，提升了写入吞吐量，且批处理应用（如数据分析）可容忍短暂的一致性延迟。

> 机架感知（Rack Awareness）的副本策略

为平衡 “容错性” 和 “读写性能”，HDFS 的副本默认按 “机架感知” 策略分布（需提前配置节点的机架信息）：

- 副本 1：存储在客户端所在的 DataNode（若客户端不在集群内，则随机选一个节点）；
- 副本 2：存储在与副本 1 不同机架的 DataNode（避免单机架故障导致数据丢失）；
- 副本 3：存储在与副本 2 同一机架的不同 DataNode（减少跨机架数据传输，提升读取速度）；
- 更多副本（若配置 > 3）：随机分布在其他机架，确保容错的同时降低网络开销。

### 数据写入流程

以 “创建新文件” 为例：

1. 客户端请求元数据：客户端向 NameNode 发送 “创建文件” 请求，NameNode 检查权限和路径合法性后，返回 “可创建” 的响应，并为文件分配初始 Block ID；
2. 客户端写入数据块：客户端将数据按 128MB 分割为 Block，向 NameNode 请求 “Block 的存储节点列表”（NameNode 根据机架感知返回 3 个 DataNode 地址）；
3. 建立数据传输管道：客户端与第一个 DataNode 建立 TCP 连接，第一个 DataNode 与第二个建立连接，第二个与第三个建立连接，形成 “客户端→DataNode1→DataNode2→DataNode3” 的传输管道；
4. 流式写入数据：客户端将 Block 数据以 “数据包（Packet，默认 64KB）” 为单位，通过管道依次发送给 3 个 DataNode，每个 DataNode 接收后先写入本地缓存，再转发给下一个节点；
5. 确认写入成功：当所有 DataNode 都将 Block 写入磁盘后，依次向客户端返回 “写入成功” 确认，客户端向 NameNode 汇报 “Block 写入完成”，NameNode 更新元数据；
6. 重复直至文件完成：若文件大于 1 个 Block，重复步骤 2-5，直至所有 Block 写入完成，客户端向 NameNode 发送 “关闭文件” 请求，NameNode 标记文件为 “已完成”。

### 数据读取流程

客户端请求元数据：客户端向 NameNode 发送 “读取文件” 请求，NameNode 返回文件对应的所有 Block 列表，以及每个 Block 的 3 个副本所在的 DataNode 地址；

选择最优副本：客户端根据 “网络距离” 选择最近的 DataNode（如同一机架的节点，避免跨机架延迟），直接向该 DataNode 发送 “读取 Block” 请求；

流式读取数据：DataNode 从磁盘读取 Block 数据，以 “数据包” 为单位发送给客户端，客户端接收后拼接成完整文件；

故障重试：若读取的 DataNode 故障（如无响应或数据校验错误），客户端自动切换到其他副本的 DataNode，继续读取，无需中断。

### 故障容错机制

HDFS 通过多层机制确保数据不丢失、服务不中断：

DataNode 故障检测：NameNode 通过 “心跳包”（每 3 秒一次）检测 DataNode 状态，若超过 10 分钟未收到心跳，判定 DataNode 宕机，立即触发 “Block 修复”；

Block 修复：NameNode 检查宕机 DataNode 上的所有 Block，若某 Block 的副本数低于配置值（如默认 3 份→2 份），则调度其他 DataNode 复制 Block，恢复副本数至 3 份；

数据完整性校验：每个 DataNode 为存储的 Block 计算 “校验和（Checksum，默认 CRC32）”，写入 Block 时同时存储校验和；读取时先验证校验和，若发现数据损坏（如磁盘错误），则从其他副本读取正确数据，并重建损坏的 Block；

NameNode 高可用（HA）：通过 Active/Standby NameNode+JournalNode 机制，避免 NameNode 单点故障，确保元数据不丢失、服务可快速恢复。

### 核心角色

HDFS 是 Hadoop 生态的 “存储中枢”，所有计算、分析组件都依赖 HDFS 进行数据交互，典型场景包括：

| 生态组件     | 与 HDFS 的交互方式                                           | 应用场景举例                         |
| ------------ | ------------------------------------------------------------ | ------------------------------------ |
| MapReduce    | 作为输入 / 输出存储：Map 任务从 HDFS 读取数据，Reduce 任务将结果写回 HDFS | 日志离线分析、用户行为统计           |
| Apache Spark | 作为 “持久化存储”：RDD（弹性分布式数据集）可持久化到 HDFS，避免重复计算；读取 HDFS 数据进行批处理 / 流处理 | 大数据机器学习、实时日志分析         |
| Apache Hive  | 将 HDFS 中的结构化数据映射为 “表”，通过 SQL 查询 HDFS 数据，结果写回 HDFS | 数据仓库构建、SQL 化数据分析         |
| Apache HBase | 将 HDFS 作为底层存储：HBase 的 Region 数据（键值对）持久化到 HDFS，确保数据可靠 | 实时查询海量结构化数据（如用户画像） |
| Apache Flume | 将日志数据实时采集并写入 HDFS，作为离线分析的数据源          | 服务器日志、应用日志的实时采集       |

### 总结

HDFS 作为 Hadoop 的核心子项目，是大数据离线批处理时代的 “存储标杆”—— 它继承了 GFS 的分布式架构思想，又通过企业级优化（如 NameNode HA、机架感知）成为稳定可靠的开源方案，支撑了全球无数企业的大数据存储需求，与对象存储、云原生存储形成互补，共同服务于更广泛的大数据场景。