HDFS 主从架构及组件工作原理

HDFS（Hadoop Distributed File System）采用典型的主从（Master/Slave）架构。一个 HDFS 集群包含一个 NameNode（主节点）和多个 DataNode（从节点），同时部署 SecondaryNameNode 以辅助 NameNode 进行元数据维护。下面从作用、职责、工作机制与原理三个维度详细阐述，并通过 Mermaid 图表直观呈现。

---

一、HDFS 整体架构图

流程图：

---

二、NameNode（主节点）

2.1 作用与职责

• 命名空间管理：维护整个文件系统的目录树、文件/目录权限、属性等。
• 元数据管理：记录每个文件对应的数据块列表，以及每个数据块所在的 DataNode 位置。
• 客户端请求处理：接收并调度来自客户端的文件打开、关闭、重命名等操作。
• 集群调度与监控：通过心跳机制管理 DataNode，检测节点存活，触发数据块的复制、删除或修复。

一句话总结：NameNode 是 HDFS 的“大脑”，掌管所有文件的元数据，不存储实际数据。

2.2 工作机制与原理

NameNode 的元数据以内存 + 磁盘两级结构保存，确保高速访问与持久化：

1. 内存元数据：为快速响应客户端请求，完整的元数据始终驻留在 NameNode 的内存中。
2. 磁盘持久化：
   • fsimage：元数据的完整快照（checkpoint），在某个时间点对内存元数据的序列化保存。
   • edits log：记录自上一次 fsimage 以来所有写操作的日志（如创建文件、追加内容等）。每次写操作都会先写入 edits log，然后更新内存元数据。
3. 启动恢复：NameNode 启动时，先将 fsimage 加载到内存，然后回放 edits log 中的操作，恢复至最新状态。
4. SecondaryNameNode 辅助合并：由于 edits log 会不断增长，NameNode 自身不进行合并，而是借助 SecondaryNameNode 定期完成 fsimage 与 edits 的合并，生成新的 fsimage。这避免了 edits log 无限增大导致下次启动恢复时间过长。

注意：NameNode 不直接参与数据块的读写传输，客户端在获取数据块位置后，直接与 DataNode 交互。

---

三、DataNode（从节点）

3.1 作用与职责

• 数据块存储：在本地文件系统上以块（block）的形式实际存储文件数据，默认块大小 128 MB。
• 客户端数据服务：直接响应客户端的读写请求，完成数据的传输。
• 块报告与心跳：
  • 定期（默认 3 秒）向 NameNode 发送心跳，报告自身存活状态。
  • 定期（默认 6 小时）发送块报告，上报其存储的所有块信息。
• 执行 NameNode 指令：根据 NameNode 的调度，完成块的复制、删除或迁移操作。

3.2 工作机制与原理

1. 启动注册：DataNode 启动时，向 NameNode 注册，并发送初始块报告。
2. 持续心跳：每 3 秒一次心跳，如果 NameNode 连续 10 分钟未收到某 DataNode 的心跳，则判定该节点为“死节点”，将其上的数据块标记为缺失，并启动副本重建。
3. 数据读写：
   • 写入：客户端请求 NameNode 创建文件，NameNode 分配数据块及目标 DataNode 列表；客户端以流水线（pipeline）方式将数据包写入第一个 DataNode，再复制到下一个，直至所有副本写入完毕。
   • 读取：客户端请求 NameNode 获取文件块位置，然后选择最近的 DataNode 读取数据。
4. 数据完整性：DataNode 在写入时计算校验和，读取时验证，防止数据损坏。

---

四、SecondaryNameNode（辅助节点）

4.1 作用与职责

• 元数据检查点（checkpoint）生成：定期从 NameNode 拉取 fsimage 和 edits log，在本地合并生成新的 fsimage，再传回 NameNode。
• 减轻 NameNode 恢复压力：避免 edits log 过大，保障 NameNode 重启后能快速完成元数据加载。

重要澄清：SecondaryNameNode 不是 NameNode 的热备或高可用（HA）方案。当 NameNode 故障时，它无法自动接管服务，只能辅助恢复元数据。HDFS HA 需通过 Quorum Journal Manager 或 NFS 实现多个 NameNode。

4.2 工作机制与原理

1. 触发条件：
   • 定时触发（默认 1 小时，由 dfs.namenode.checkpoint.period 控制）。
   • 事务数达到阈值（默认 100 万次操作，由 dfs.namenode.checkpoint.txns 控制）。
2. 合并流程：
   • SecondaryNameNode 通过 HTTP GET 从 NameNode 获取当前的 fsimage 和 edits 文件。
   • 在本地将 fsimage 加载到内存，并回放 edits 中的所有操作，生成一份新的 fsimage。
   • 通过 HTTP PUT 将新 fsimage 传回 NameNode，NameNode 用它替换旧的 fsimage，并清空 edits 文件。
3. 运行位置：通常部署在独立节点上，与 NameNode 分开，避免资源竞争。

---

五、三者协同工作机制（读写示例）

5.1 文件写入流程

1. 客户端向 NameNode 请求创建文件。
2. NameNode 检查命名空间和权限，返回数据块分配信息及 DataNode 列表。
3. 客户端将数据切块，按流水线方式依次写入各个 DataNode（副本）。
4. 每个 DataNode 写入完成后向 NameNode 报告块信息，NameNode 更新内存中的元数据映射。
5. SecondaryNameNode 在后台持续合并 edits，保障下次重启效率。

5.2 文件读取流程

1. 客户端向 NameNode 请求打开文件。
2. NameNode 返回文件对应的所有块及块所在的 DataNode 位置（排序，靠近客户端的优先）。
3. 客户端直接与 DataNode 建立连接，顺序读取各个数据块。
4. 读取完毕，关闭连接。

---

六、总结

组件	核心角色	存储内容	关键行为
NameNode	元数据总管、集群调度者	文件目录树、文件→块映射、块→DataNode 映射	响应客户端请求，管理 DataNode，维护 fsimage 和 edits
DataNode	数据存储节点、实际搬运工	数据块（文件内容）	定期心跳/块报告，执行块的复制/删除，读写数据
SecondaryNameNode	元数据合并助手	合并生成的 fsimage 快照	定期拉取并合并 fsimage 与 edits，传回新快照

三者通过心跳机制、块报告和检查点流程紧密协作，共同实现 HDFS 的高容错、高吞吐分布式存储能力。SecondaryNameNode 虽非 HA 方案，但对单 NameNode 集群的启动恢复速度至关重要，生产环境中通常结合 HDFS HA（如 QJM）来彻底消除单点故障。