2.1 HDFS架构与组件

2.1 HDFS 架构与组件

本节摘要：HDFS 采用主从架构：NameNode 独占管理元数据（目录树、块映射），DataNode 集群存储实际数据块。本节深入元数据的双文件机制（FsImage 与 EditLog）、Checkpoint 合并、心跳与块报告的通信循环，并用一次 fsck 输出把架构落到可观察的证据上。

主从分工：账房与仓库

把 HDFS 想成一家大型仓储公司。NameNode 是账房先生：全公司每个货架（DataNode）上放着哪些箱子（块）、每个箱子属于哪个订单（文件），账本上一清二楚；但他自己一个箱子都不搬。DataNode 是仓库管理员：实际保管箱子、定期向账房报平安（心跳）、清点库存（块报告）。客户端要存货取货，都得先去账房问路线，再直接找仓库管理员交割。

这个分工带来一个关键推论：DataNode 之间互相不认识。数据块的副本复制、失效迁移全部由 NameNode 根据账本指挥。好处是协议简单、行为可预测；代价是账房先生成为全公司的瓶颈与单点——这是 2.4 节 HA 与联邦要解决的问题。

图 2-1 HDFS 分层架构与通信关系

元数据的双文件机制

NameNode 的账本怎么记？这是 HDFS 架构里最精巧的部分。如果每条变更都直接写入大文件，查询会慢；如果只放内存，断电就全丢。HDFS 的答案是快照加流水账：

• FsImage：某一时刻的全量账本。文件数、目录树、每个文件由哪些块组成（不含块的物理位置，位置由块报告动态维护）。启动时 NameNode 把它完整加载进内存，此后所有查询都打内存，速度极快。
• EditLog：快照之后的所有增量变更，只追加不修改。新建目录、创建文件、追加块、删除文件……每条操作追加一条记录。查询用不到它，但重启恢复时它决定"快照之后发生了什么"。

于是启动流程是：加载 FsImage 到内存 → 逐条回放 EditLog → 账本复原。问题随之而来：集群跑得越久，EditLog 越长，下次重启恢复越慢。解决这个问题的机制叫 Checkpoint：把内存中的账本全量导出为新 FsImage，清空 EditLog。这个导出动作如果由 NameNode 自己做，会长时间占用内存与 CPU，影响服务——于是有了 SecondaryNameNode。

⚠️ 误区警示：SecondaryNameNode 不是 NameNode 的"热备"。它是 Checkpoint 的助手：定期把 FsImage 与 EditLog 拉到自己这里合并成新快照，再推回 NameNode。NameNode 宕机时它没有最新账本，不能直接顶上。真正的热备是 2.4 节的 NameNode HA。

Checkpoint 触发条件（任一满足）：一小时内没有执行过；EditLog 事务数达到 100 万。相关参数：

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>          <!-- 两次checkpoint最小间隔 秒 -->
</property>
<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>       <!-- EditLog达到此事务数触发 -->
</property>
​

心跳与块报告：账实的对账循环

DataNode 用两条消息维持与账房的关系。心跳默认 3 秒一次，捎带磁盘容量、剩余空间、读写负载；NameNode 10 分钟（参数 10 分钟 × 0.5 的判定阈值，实际由配置决定）收不到心跳就把该节点标记为失效，把它上面的所有块标记为"副本不足"，调度其他 DataNode 复制补齐。块报告默认 6 小时全量一次，外加随心跳发送的增量报告——相当于仓库定期盘点，纠正"账上有但货没了"（磁盘坏）或"货在账没有"的漂移。

心跳失效引发的副本风暴值得单独理解：一个 200 节点机架的交换机抖动 11 分钟，NameNode 会认为整个机架下线，立即开始向其他机架疯狂复制这批块；交换机恢复后副本又超量，还得再删。生产上因此把判定阈值调大（如 15 分钟以上），并在监控上把"下线副本数"作为重要告警项。

用 fsck 看见架构

架构描述再细，不如一条命令的输出真实：

hdfs fsck /data/logs/access-2026-08-18.log -files -blocks -locations
​

输出里每一行都对应本章一个概念：文件总字节数对应客户端切分、3 个 blk 编号对应文件到块映射、每个块的 repl=3 与位置列表对应副本放置（由块报告维护）、status 为 HEALTHY 对应校验机制。换句话说，fsck 就是把 NameNode 内存账本的一个切片打印给你看。第 1 章的五条命令里它是最有教学价值的一条，值得反复把玩。

架构的规模边界

主从架构的能力边界可以粗算。NameNode 每个文件/目录/块的元数据约 150 字节，全部驻留内存。假设集群有 1 亿个文件、平均每文件 1.5 个块，元数据约 (1e8 文件 + 1.5e8 块) × 150B ≈ 37.5 GB——已经需要一台上百 GB 内存的专用机器。这就是"小文件问题"的根源：每个 1KB 的小文件同样占用一条块记录，把账本撑爆的速度与大文件相同。对策（合并文件、HAR 归档、SequenceFile、联邦）在 2.4 节展开。

💡 关键直觉：判断一项 HDFS 负载健康度，先看两个数——平均文件大小（决定账本膨胀速度）与每 DataNode 块数（决定块报告与恢复的粒度）。业界经验值是平均文件至少几十 MB 起、单 DataNode 块数控制在数百万以内。

本节要点回顾

• NameNode 管账不管货：目录树与块映射驻留内存，查询极快，但内存量决定文件数上限；
• FsImage 加 EditLog：快照加流水的组合兼顾查询速度与崩溃恢复；
• Checkpoint 与 SecondaryNameNode：定期合并快照，Secondary 是助手不是热备；
• 心跳 3 秒、块报告 6 小时：失效判定触发副本补齐，阈值过小会放大网络抖动为副本风暴；
• 每个元数据约 150 字节：小文件是账本的头号敌人；
• fsck 输出就是账本切片：学习与排障的第一工具。

下一节把镜头对准数据本身：一个字节从客户端到三副本落盘，管线上每一跳发生了什么。