> 很多人第一次接触 HDFS 时都有同样的困惑：它是个"分布式文件系统"，却不能随便改文件、不支持多线程同时写、还特别怕小文件。这些反直觉的"缺点"，恰恰是理解它的钥匙——它从一开始就不是为了替代你电脑上的硬盘，而是为了在一堆廉价机器上，用软件的方式兜住 PB 级数据。

## 一、先想清楚：为什么需要一个"专门的"文件系统

假设你负责一套日志采集系统，每天稳定落 5TB 数据，一个月就是 150TB。单块硬盘装不下，单机柜也很快见底；上 NAS、买存储阵列，扩容成本高得吓人，而且磁盘故障是常态——一块盘坏了，数据还能不能找回来，恢复期间要不要停机？

HDFS（Hadoop Distributed File System，Hadoop 分布式文件系统）就是为这个问题设计的。它是 Apache Hadoop 的核心子项目，设计目标很明确：**在多台普通、廉价的机器组成的集群上，存储 TB 甚至 PB 级的海量文件，提供高吞吐的数据读写，并且高度容错**。对上层用户来说，它又提供统一的访问接口，让你像操作普通文件系统一样读写文件，不需要关心数据具体落在了哪台机器。

理解 HDFS，要抓住它底层的访问模型：**一次写入、多次读取（Write Once Read Many）**。日志、埋点、数据湖里的明细数据，一旦落盘就长期被顺序读取、反复分析，而不是像数据库那样频繁地改某一行。HDFS 的所有设计——块、副本、主从架构、不支持随机修改——几乎都围绕这一假设展开。

## 二、一张图看清主从架构：元数据和数据是两条通路

HDFS 采用典型的主从（Master / Slave）架构，角色不多，却分工清晰：一个 NameNode、若干 DataNode，再加上一个 SecondaryNameNode 和操作入口 HDFS Client。

![HDFS主从架构：NameNode、SecondaryNameNode、DataNode、Client与元数据/数据两条通路](https://developer.qcloudimg.com/http-save/yehe-2482016/e477e83b554e8ddea2d5387189933bf9.png)

图 1　HDFS 主从架构：元数据通路与数据通路分离

最关键的认知是：**NameNode 只管元数据，从来不碰真正的数据；Block 数据全部落在 DataNode 上**。读写时，客户端先找 NameNode 问"这个文件有哪些块、分别在哪台机器"，拿到位置后直接连 DataNode 读写。元数据和数据分成两条通路，NameNode 才不会成为数据传输的瓶颈。

- **NameNode（Master）**：整个 HDFS 的管理者。它在内存中维护文件系统目录树、文件与 Block 的映射、访问权限，决定副本怎么放，并处理客户端的读写请求。元数据主要靠两个组件持久化：`fsimage`（命名空间镜像，记录文件/目录/权限/副本数）和 `edits`（编辑日志，记录每一次增删改操作）。
- **DataNode（Slave）**：真正干活的存储节点。Block 以文件形式存在本地磁盘上，同时保存校验和。DataNode 启动时向 NameNode 注册并汇报 Block 列表，之后每 3 秒发一次心跳、默认每 6 小时做一次全量块汇报；NameNode 若 10 分钟没收到某台 DataNode 的心跳，就判定它失效。
- **SecondaryNameNode（辅助）**：名字有迷惑性，它不是 NameNode 的热备，而是辅助节点，负责定期把 `fsimage` 和 `edits` 合并，避免 `edits` 越滚越大、重启恢复越来越慢。
- **HDFS Client（客户端）**：程序和命令行的入口。上传时负责把文件切成 Block，读时先向 NameNode 取位置、再向 DataNode 取数据，并在下载完成后做校验。

> 这一讲先建立整体心智模型，NameNode 的元数据管理、SecondaryNameNode 的检查点合并、安全模式和完整读写流程，会在后面的主从架构章节逐一展开。

## 三、文件怎么存：Block 切分与三副本

HDFS 不会把整个文件交给一台机器，而是把文件**按字节线性切分成一个个 Block（数据块）**，分散存储到多个 DataNode 上。

![文件按字节线性切分为Block，每个Block按机架感知存三副本](https://developer.qcloudimg.com/http-save/yehe-2482016/ae95b447ade7427f7f97fce33cae922b.png)

图 2　Block 切分与三副本机架放置

### Block 为什么默认是 128M

Block 大小由参数 `dfs.blocksize` 决定：Hadoop 1.x 默认 64M，2.x / 3.x 默认 128M。这个数字不是拍脑袋定的，而是从"寻址时间"推导出来的。

- 磁盘读取一个 Block 的时间 = 寻址时间 + 传输时间。经验上，平均寻址约 10ms，当寻址时间占传输时间的 1% 时整体性能最佳，也就是说一次传输大约 1 秒（10ms ÷ 1% = 1000ms）。
- 按常见机械盘约 100MB/s 的传输速率，1 秒能传约 100MB，再取一个二进制下更友好的 2 的幂，最终定为 **128M**。
- 所以块大小本质上跟磁盘速率走：磁盘约 200MB/s 时通常设 256M，约 400MB/s 时设 512M。

块太大，传输时间远超寻址，处理变慢；块太小，一是 Block 数量爆炸会吃满 NameNode 的内存，二是寻址占比过高，程序一直在找块的起始位置。

这里还有个常见误解：**128M 是"分片上限"，不是预分配**。一个 1KB 的文件上传后只占 1KB，并不会真的占掉 128M；只有大于 128M 的文件才会被切成多个块。

### 三副本与机架感知

每个 Block 默认存 3 个副本（由 `dfs.replication` 控制），并按"机架感知"策略放置：

- **副本 1**：放在客户端所在的 DataNode（本地写最快）；如果是集群外提交，就随机挑一台磁盘不满、CPU 不忙的节点。
- **副本 2**：放在与副本 1 **不同机架**的节点上，保证整机架断电或断网时数据不丢。
- **副本 3**：放在与副本 2 **同一机架的另一节点**，既保证容错，又尽量少跨机架传输、节省网络带宽。
- 更多副本则随机分布。

一旦某个副本或节点丢失，NameNode 检测到副本数不足，会自动在其他节点上补齐，无需人工干预。**容错是靠软件层做的，不是靠买更贵的硬件**。

## 四、六个特点的背后：那些"不支持"都是有意为之

HDFS 的设计特点可以归成两类：它擅长什么、它刻意不做什么。

![HDFS适合与不适合的场景对比](https://developer.qcloudimg.com/http-save/yehe-2482016/4b553918ba6950c1bbe0c85f180101d8.png)

图 3　HDFS 的适用边界

**适合的，是它存在的理由：**

1. **适合大规模数据**：TB、PB 级别，可支撑百万级文件数量，面向一次写入、多次读取的流式访问。
2. **适合大文件**：文件越大，Block 数量越可控，一次顺序 IO 读到的数据越多，越能发挥高吞吐。
3. **高吞吐、横向扩展**：计算尽量向数据靠拢，加上机器就线性增加容量和吞吐。
4. **高容错**：多副本 + 自动恢复，单盘甚至单机故障都不影响数据可用。

**不支持的，是它明确放弃的战场：**

5. **不适合大量小文件**：每个文件、每个 Block 的元数据都要在 NameNode 内存里维护，小文件一多，NameNode 内存首先被撑爆；而且读小文件时寻址时间往往大于读取时间，直接违背了"减少寻址占比"的设计目标。
6. **不支持并发写、也不支持随机修改**：一个文件同一时刻只能有一个写者，不能多个线程同时写；文件一旦写入就不能随机改，只能在末尾 append 追加。这两点共同保证了数据顺序、流式的访问模式，也简化了一致性问题。

记住这个取舍：HDFS 用牺牲"灵活性"的代价，换来了对大文件、顺序访问、高吞吐场景的极致优化。

## 五、三个高频误区，面试和排障都容易踩

**误区一：SecondaryNameNode 是 NameNode 的"备份"。**
不是。它只做检查点合并，NameNode 一旦挂了，SecondaryNameNode 并不能立刻顶上。真正的高可用（HA）方案，在 Hadoop 2.x 以后是再部署一个 Standby NameNode，配合 JournalNode 共享编辑日志、ZooKeeper 做故障切换。

**误区二：HDFS 上的文件能像本地文件一样改。**
不能。HDFS 是 append-only 的，只支持末尾追加，不支持任意位置覆盖写。如果你的业务需要随机改某几行、按 Key 点查，那应该用 HBase 这类系统，而不是硬塞给 HDFS。

**误区三：Block 设得越小，读得越快、越省空间。**
恰恰相反。块太小会让 Block 数量暴涨，NameNode 内存压力和寻址开销都上升，吞吐反而下降。块大小应随磁盘传输速率上调，而不是盲目调小。

## 六、动手看一眼：块和副本到底长什么样

不用死记概念，在自己的测试集群上上传一个文件，就能直观看到 Block 和副本。

先看集群角色是否都在：

```bash
jps
# NameNode / DataNode / SecondaryNameNode 等角色进程
```

上传一个文件并查看：

```bash
# 上传一个大于 128M 的文件，便于观察被切成多个 Block
hdfs dfs -mkdir -p /demo
hdfs dfs -put file.log /demo/
hdfs dfs -ls /demo
```

用 fsck 查看 Block 数量和每个副本的位置：

```bash
hdfs fsck /demo/file.log -files -blocks -locations
# 输出会列出每个 Block 及其副本所在的 DataNode 地址（rack / node）
```

查看各 DataNode 容量与存活状态：

```bash
hdfs dfsadmin -report
```

`fsck` 输出里的 `blk_xxx` 就是 Block，`[DatanodeInfoWithStorage...]` 会显示它的副本落在哪些节点、哪个机架，对照本文的放置策略看一遍，比背十遍概念都管用。

## 写在最后

HDFS 的工程哲学，是**用软件层把一批不可靠的廉价硬件，抽象成一个可靠、可横向扩展的存储系统**。它用 Block 切分解决容量，用多副本和机架感知解决可靠性，用主从架构把元数据和数据通路解耦，再用"一次写多次读、只追加、不并发"这些看似保守的约束，把吞吐和一致性做到极致。

对不同角色的工程师，它的价值也各有侧重：

- **Java 工程师**：HDFS 是一个经典的分布式系统样本——RPC 通信、心跳与故障检测、主从协调、数据校验，理解这些机制对写任何分布式服务都有帮助。
- **大数据工程师**：HDFS 是 Hive、Spark、HBase 等几乎所有离线和数仓组件的存储底座，不懂 Block 与副本，小文件、数据倾斜、扩容等问题很难定位到根上。
- **AI 工程师**：训练数据集、特征、模型快照本质上都是大文件，HDFS 及对象存储是数据湖和特征平台的底层，认清"顺序大文件友好"的边界，才能合理组织训练数据。

建议你亲手走一遍：上传一个超过 128M 的文件，用 `fsck` 数清 Block 和副本位置，再手动停掉一台 DataNode 观察 NameNode 如何自动补齐副本。下一讲我们进入 HDFS 主从架构，把 NameNode、DataNode、SecondaryNameNode 的内部机制和 fsimage / edits 合并彻底讲透。

很多人第一次接触 HDFS 时都有同样的困惑：它是个"分布式文件系统"，却不能随便改文件、不支持多线程同时写、还特别怕小文件。这些反直觉的"缺点"，恰恰是理解它的钥匙——它从一开始就不是为了替代你电脑上的硬盘，而是为了在一堆廉价机器上，用软件的方式兜住 PB 级数据。

HDFS简介：从块、副本到主从架构，一篇讲透

人工智能

HDFS分布式文件系统专为PB级数据设计，采用主从架构与块存储机制，实现高吞吐、高容错。其"一次写入多次读取"模式、128M块切分及三副本策略，虽不支持随机修改，却深度优化了大规模顺序访问场景。本文解析六大设计特性、常见误区及实操验证方法，助您理解数据湖存储核心。

数据管理

代码解释

对象存储

文件系统

数据库

大数据

数据湖

Hadoop 

Spark 

HBase

Java

HDFS

Hive

让每一个 Agent，都跑在云上

bigdata-class

chdfs

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

HDFS简介：从块、副本到主从架构，一篇讲透-腾讯云开发者社区-腾讯云

HDFS简介：从块、副本到主从架构，一篇讲透

HDFS简介：从块、副本到主从架构，一篇讲透

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐