> 上一篇我们建立了 HDFS 的整体印象：Block 切分、三副本、主从架构。但不少同学合上文章还是会问：NameNode 到底把元数据放在哪？重启一次为什么那么慢？SecondaryNameNode 名字里带个"NameNode"，为什么 Master 挂了它却顶不上？这一篇就钻进主从架构内部，把四个角色的家底翻出来看。

## 一、从一次 NameNode 重启说起

先还原一个线上常见场景：某台 NameNode 因为一次运维操作重启，重启的几分钟里，集群里数据明明还在磁盘上，作业却报"只读"甚至找不到文件，整个集群像被按了暂停键。

这不是数据丢了，而是 HDFS 的"大脑"还在恢复中。重启 NameNode 时，它要做两件事：

1. 把磁盘上的命名空间镜像 `fsimage` 加载进内存，重建目录树和文件到 Block 的映射；
2. 再把编辑日志 `edits` 里的操作一条条重放，把状态追平到宕机前那一刻。

集群跑了几个月，`edits` 可能已经累积了几十万条操作，光重放就要很久。更麻烦的是，**Block 具体落在哪台 DataNode，NameNode 并不持久化**，这部分信息只能等 DataNode 启动后重新汇报。在汇报达标之前，NameNode 处于安全模式，集群只读。

这一连串现象，恰好把主从架构最核心的三个问题串了起来：元数据怎么存、从节点怎么证明自己活着、日志怎么不至于越滚越大。下面逐个角色拆开。

## 二、四个角色的协同：谁在什么时候、拿什么数据

HDFS 是一个 NameNode（Master）加若干 DataNode（Slave），外加一个 SecondaryNameNode 和一个客户端 Client。上一篇给过架构总览，这张图只盯"内部机制"：每个角色内存 / 磁盘里放什么、彼此之间在传什么。

![HDFS四角色内部机制：NameNode内存元数据与fsimage/edits，DataNode心跳与块汇报，SNN检查点](https://developer.qcloudimg.com/http-save/yehe-2482016/359fd4865ca2498774eac6a80328670a.png)

图 1　主从四角色的内部数据与四条通路

记住四条通路：Client 向 NameNode 问元数据（RPC）、Client 直连 DataNode 读写数据（数据不经过 NameNode）、DataNode 周期性向 NameNode 发心跳和块汇报、SecondaryNameNode 定期与 NameNode 做检查点合并。下面把每条通路背后的存储和机制讲清楚。

## 三、NameNode：内存里的目录树，磁盘上的 fsimage 和 edits

NameNode 是 HDFS 的唯一管理者，它的元数据管理是理解整个架构的钥匙。

### 元数据主要放内存，而不是磁盘

NameNode 把文件系统的**目录树结构、文件到 Block 的映射、访问权限**等元数据全部维护在内存中。这是 HDFS 能做到低延迟响应的根本原因——查一个文件有哪些块，本质是内存查表，毫秒级返回。

但代价也由此而来：

- 内存容量有上限，所以每个文件、每个 Block 都要占内存，**小文件一多，NameNode 内存先被撑爆**；
- 元数据全压在一个 Master 上，NameNode 就是单点（非 HA 集群），这也是它不能随便挂的原因。

### fsimage 和 edits：内存状态的两种持久化

光放内存，断电就没了。NameNode 用两个磁盘文件给元数据兜底：

- **fsimage（命名空间镜像）**：HDFS 文件系统元数据的完整快照，记录所有目录、文件的名称、路径、权限、副本数、修改和访问时间等。NameNode 启动时首先把它整体加载进内存。
- **edits（编辑日志）**：记录文件系统的每一次写操作（创建、重命名、删除等）。客户端的每个写操作，都会先追加写进 `edits`，再更新内存——这和数据库的 WAL（Write-Ahead Log，预写日志）是同一个思路。

重启恢复时，NameNode 加载 fsimage 后，再依次重放 edits 里的操作，就能把状态恢复到宕机前，做到元数据不丢。

### 一个关键细节：Block 位置不在 fsimage 里

fsimage 里**不记录每个 Block 存放在哪台 DataNode**。这是有意为之：DataNode 可能宕机、磁盘可能损坏、副本可能被重新调度，如果把位置写死在 fsimage 里，很快就会和真实情况脱节。

所以 Block 位置信息在每次 NameNode 启动后，由 DataNode 通过块汇报重新上报、在内存中重建。代价就是前面说的重启后需要等待（进入安全模式），换来的是位置信息永远反映真实状态，没有陈旧数据。

NameNode 的职责可以归纳为四条：内存中维护文件元数据、目录结构和文件到 Block 的映射；提供元数据持久化与管理（fsimage/edits）；提供副本放置策略；处理客户端读写请求。

## 四、DataNode：Block 在磁盘上长什么样，Master 怎么知道它还活着

DataNode 是干活的从节点，Block 真正以文件形式躺在它的本地磁盘上。

![DataNode上每个Block由数据文件与.meta校验和文件组成，心跳3秒、块汇报6小时、10分钟判死](https://developer.qcloudimg.com/http-save/yehe-2482016/6f42c14c6d3fc53060f998167879f7b7.png)

图 2　DataNode 的磁盘存储与心跳 / 块汇报机制

### 一个 Block 是两个文件

每个 Block 在 DataNode 上对应两个文件：一个是**数据文件本身**（`blk_<id>`），另一个是**元数据文件**（`blk_<id>_<genstamp>.meta`），里面记录 Block 长度、校验和（checksum）和时间戳。数据和校验分开存，读的时候才能用校验和判断这个 Block 有没有静默损坏。

DataNode 启动时先向 NameNode 注册，把自己持有的 Block 列表汇报上去，之后通过两种周期机制持续保持同步：

- **心跳（Heartbeat）**：每隔 3 秒发一次（`dfs.heartbeat.interval` 默认 3s），告诉 NameNode"我还活着"；如果 NameNode 超过 10 分钟没收到某台 DataNode 的心跳，就判定它失效，开始在其他节点上补齐副本。
- **块汇报（Block Report）**：每隔一段时间（`dfs.blockreport.intervalMsec` 默认 21600000ms，即 6 小时），把自己持有的全部 Block 信息完整汇报一次，用来校正 NameNode 内存里的 Block 位置。

要分清这两件事：**心跳证明"我活着"，块汇报告诉"我有什么"**。心跳是高频小包，块汇报是低频全量。

DataNode 的职责因此也很明确：基于本地磁盘存储 Block 数据；保存校验和保证可靠性；与 NameNode 保持心跳并周期性汇报 Block 列表。再次强调，真正的数据读写发生在 Client 和 DataNode 之间，NameNode 不参与数据搬运。

## 五、SecondaryNameNode：给 edits 减负的检查点

名字最容易误导人的就是 SecondaryNameNode。它不是 NameNode 的热备，它的唯一职责是**定期把 fsimage 和 edits 合并成一个新的 fsimage**，即做检查点（Checkpoint）。

### 为什么需要它

如果一直不合并，edits 会无限增大，NameNode 每次重启都要重放海量日志，恢复时间越来越长。SecondaryNameNode 的价值就是在 NameNode 运行期间就把"旧 fsimage + 现有 edits"归并成新 fsimage，让 edits 始终保持很小，把重启恢复时间控制在可接受范围。

### 合并的完整过程

![SecondaryNameNode检查点合并：滚动edits、HTTP下载、内存合并、PUT回传新fsimage](https://developer.qcloudimg.com/http-save/yehe-2482016/646e23dc0eb485ff618123dc851d9c37.png)

图 3　fsimage 与 edits 的检查点合并流程

1. 集群首次启动时，NameNode 上创建一个空的 fsimage，之后的操作都记进 edits。
2. 触发检查点时，SecondaryNameNode 先请求 NameNode 滚动出新的 edits 文件，此后新的写操作进入新 edits，老的 edits 被"冻结"。
3. SecondaryNameNode 通过 HTTP GET 把当前的 fsimage 和（冻结的）老 edits 下载到本地。
4. 它把 fsimage 加载进自己的内存，逐条重放老 edits，更新内存中的命名空间，再把结果写成一个新的 fsimage。
5. SecondaryNameNode 通过 HTTP PUT 把新 fsimage 发回 NameNode，NameNode 先存为 `.ckpt` 临时文件。
6. NameNode 重命名该临时文件，替换旧 fsimage；此时它手里是一个新的 fsimage 加上一个很小的新 edits（合并期间产生的操作在里面，不会丢）。
7. 之后周期性重复以上过程。

### 两个触发条件，先到先合并

检查点不是只看时间，而是时间和事务数两条线，谁先到谁触发：

```bash
# 时间周期：默认 3600 秒（1 小时）触发一次
dfs.namenode.checkpoint.period = 3600

# 每 60 秒检查一次 edits 累积的事务数
dfs.namenode.checkpoint.check.period = 60

# 事务数达到 100 万条，也会立即触发一次合并
dfs.namenode.checkpoint.txns = 1000000
```

### 它为什么不能当热备

两点原因决定了它无法故障切换：一是它平时只在检查点时刻才和 NameNode 同步，**手上的 fsimage 永远落后于 NameNode 的实时状态**；二是它不对外提供服务、不参与心跳和读写，NameNode 宕机时它不会接管。它上面的 checkpoint 文件只能用于**冷恢复**（且会丢失最后一次检查点之后的元数据）。真正的高可用，是 Hadoop 2.x 起再部署一个 Standby NameNode，配合 JournalNode 共享编辑日志、ZooKeeper 做自动故障切换。

## 六、Client：被忽视的"第四个角色"

很多人讲架构只讲三个守护进程，其实 Client 同样是架构的一环，它承担了不少实质性工作：

- 与 NameNode 交互，获取文件的 Block 位置；
- 与 DataNode 交互，直接读写 Block 数据；
- 上传时负责把文件切成 Block，下载完成后做校验和验证；
- 提供命令行和编程接口，供文件操作与集群管理。

对 Java 工程师来说，这一点尤其具体：你写的 Spark、Flink 作业，调用 HDFS API 时就是 Client，Block 切片、流水线写入、就近读取这些逻辑都在客户端库里完成。理解了 Client 这一层，才理解"为什么计算要向数据靠拢"——读取位置由 NameNode 按网络距离排序返回，客户端优先读最近的副本。

## 七、几个误区，与动手验证

这一篇的误区集中在元数据，面试和排障都常考：

1. **SecondaryNameNode 是 NameNode 的备份。** 不是，它只做检查点合并，状态有延迟、不能接管，只适合冷恢复。
2. **NameNode 里存着每个 Block 的位置。** 没有，Block 位置在 fsimage 之外，每次启动由 DataNode 块汇报重建。
3. **edits 会被立刻清空。** 不会，它只是在检查点时被"滚动"——合并掉的旧操作并入新 fsimage，合并期间的新操作仍在新 edits 里。
4. **读数据要经过 NameNode。** 不经过，NameNode 只给位置，数据在 Client 与 DataNode 之间直连传输。

不用死记，起一个测试集群就能看到这些文件。先看角色进程：

```bash
jps
# 应能看到 NameNode、DataNode、SecondaryNameNode
```

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

```bash
hdfs dfsadmin -report
```

在 NameNode 的持久化目录（`dfs.namenode.name.dir` 指向的 `current/`）里，能直接看到 fsimage、edits 和事务游标：

```bash
ls -l $HADOOP_HOME/data/dfs/name/current/
# fsimage_0000000000000000123 # 检查点镜像
# fsimage_0000000000000000123.md5
# edits_inprogress_0000000000000000124 # 当前正在写入的编辑日志
# seen_txid # 最近一次事务 ID
# VERSION
```

还可以用 Hadoop 自带的离线查看器，把二进制的 fsimage 和 edits 转成可读 XML，直观核对元数据和操作日志：

```bash
# 离线查看 fsimage 镜像（Offline Image Viewer）
hdfs oiv -i fsimage_0000000000000000123 -o fsimage.xml -p XML

# 离线查看 edits 编辑日志（Offline Edits Viewer）
hdfs oev -i edits_inprogress_0000000000000000124 -o edits.xml
```

`fsimage.xml` 里能看到目录、文件、权限和副本数，翻遍它也找不到 Block 落在哪个 DataNode——这就是"Block 位置不持久化"最直接的证据；`edits.xml` 里则是一条条增删改事务，对应 WAL 里的操作序列。

## 写在最后

HDFS 主从架构的设计，本质上是三组取舍：**元数据与数据分离**，让 NameNode 专心做内存级元数据调度、不碰数据传输，从而不成为吞吐瓶颈；**内存换性能、日志换可靠**，用 fsimage 快照加 edits 预写日志，既保证查询快，又保证宕机后元数据可追平；**用辅助检查点换恢复时间**，让 SecondaryNameNode 周期性归并日志，把重启重放时间控制住，但它不承担高可用的职责。

对三类工程师，这一篇的价值各有侧重：

- **Java 工程师**：fsimage + edits 就是教科书级的 WAL 与快照实践，和数据库的 checkpoint、Redis 的 RDB/AOF 是相通的；理解这套机制，做任何需要"内存态 + 持久化 + 快速恢复"的服务都有参照。
- **大数据工程师**：小文件问题、NameNode 内存调优、重启慢、安全模式卡住，根因都在这一篇的元数据机制里；排查时第一反应应该是去看 edits 大小、块汇报和 `dfsadmin -report`。
- **AI 工程师**：数据集、模型快照最终都要过 HDFS 这类存储，理解 NameNode 的单点特性和元数据成本，才能在组织海量训练文件时避免小文件泛滥拖垮"大脑"。

建议你亲手做一遍：找到 `current/` 目录，用 `oiv`、`oev` 把 fsimage 和 edits 导出成 XML，对照着再看一次检查点合并；然后重启一次 NameNode，观察它等待 DataNode 块汇报、进入再退出安全模式的过程。下一讲我们就专门讲安全模式，以及生产环境里 NameNode 高可用（HA）到底是怎么用 Standby、JournalNode 和 ZooKeeper 把单点问题解决掉的。
 `oiv`、`oev` 把 fsimage 和 edits 导出成 XML，对照着再看一次检查点合并；然后重启一次 NameNode，观察它等待 DataNode 块汇报、进入再退出安全模式的过程。下一讲我们就专门讲安全模式，以及生产环境里 NameNode 高可用（HA）到底是怎么用 Standby、JournalNode 和 ZooKeeper 把单点问题解决掉的。

上一篇我们建立了 HDFS 的整体印象：Block 切分、三副本、主从架构。但不少同学合上文章还是会问：NameNode 到底把元数据放在哪？重启一次为什么那么慢？SecondaryNameNode 名字里带个"NameNode"，为什么 Master 挂了它却顶不上？这一篇就钻进主从架构内部，把四个角色的家底翻出来看。

一文讲透HDFS主从架构：NameNode、DataNode与检查点

人工智能

本文深入剖析HDFS主从架构内部机制，详解NameNode元数据存储、fsimage与edits持久化、DataNode心跳与块汇报、SecondaryNameNode检查点合并原理，并澄清常见误区，助你彻底理解HDFS核心设计。

数据管理

文件系统

代码解释

数据库

大数据

Hadoop 

Redis

Spark 

Java

HDFS

让每一个 Agent，都跑在云上

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

一文讲透HDFS主从架构：NameNode、DataNode与检查点-腾讯云开发者社区-腾讯云

一文讲透HDFS主从架构：NameNode、DataNode与检查点

一文讲透HDFS主从架构：NameNode、DataNode与检查点

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐