HDFS 核心组件深度解析：分布式文件系统架构

关键设计：块位置信息不持久化到磁盘，而是在 NameNode 启动时通过 DataNode 的块报告动态构建。

2.3 内存与持久化

NameNode 将元数据同时保存在内存和磁盘中：

内存估算公式：

NameNode 内存 ≈ 文件数 × 150 字节 + 块数 × 100 字节 + 节点数 × 100 字节 

例如：1 亿文件 × 150 字节 = 15GB，3 亿块 × 100 字节 = 30GB，总计约 45GB。规划资源时需以此为依据。

2.4 单点故障问题

NameNode 是 HDFS 的单点故障（SPOF）。如果 NameNode 宕机，整个 HDFS 将无法访问，且需要人工恢复（非 HA 集群）。恢复时间取决于 EditLog 的大小。

解决方案：Hadoop 2.x 引入的 NameNode HA 架构，使用 Active/Standby 两个 NameNode 配合 ZKFC 实现自动切换。

三、DataNode：HDFS 的'数据仓库'

3.1 核心职责

DataNode 是 HDFS 的工作节点，相当于存储数据的仓库管理员：

• 数据块存储：在本地磁盘以文件形式存储数据块。
• 读写请求处理：直接为客户端提供数据，流式传输。
• 心跳汇报：每 3 秒向 NameNode 报告状态。
• 块报告：启动和定期上报本地所有块信息。
• 数据复制：执行 NameNode 的复制指令，管道式复制。

3.2 工作流程

写入流程通常如下：

1. 客户端请求写入数据给 NameNode。
2. NameNode 返回可用的 DataNode 列表。
3. 客户端建立连接，写入数据块。
4. DataNode 间进行管道复制。
5. 写入确认并更新元数据。

读取流程则更直接：

1. 客户端请求打开文件。
2. NameNode 返回块与 DataNode 列表。
3. 客户端选择最近的 DataNode 读取数据块。

3.3 数据存储结构

DataNode 的磁盘目录结构通常如下：

$ dfs/data/current/
├── BP-1873625140-192.168.1.100-1582000000000/
│   ├── current/
│   │   ├── blk_1073741825       # 数据块文件
│   │   ├── blk_1073741825_1001.meta # 校验和文件
│   │   └── VERSION              # 版本信息
│   └── VERSION                  # DataNode 版本

块文件命名规则：

• blk_<块 ID>：存储实际数据。
• blk_<块 ID>_<世代戳>.meta：存储校验和。

四、Secondary NameNode：NameNode 的'助手'

4.1 核心职责

Secondary NameNode 常被误解为 NameNode 的备份，其实它的真实作用是辅助检查点（Checkpoint）：

• 合并 FsImage 和 EditLog：定期执行（默认 1 小时）。
• 生成新 FsImage：创建元数据快照。
• 清理 EditLog：控制日志文件大小。
• 辅助恢复：提供上次 Checkpoint 数据，用于 NameNode 故障时的快速恢复。

4.2 Checkpoint 工作流程

1. Secondary NameNode 定期检查是否需要 Checkpoint。
2. 请求 NameNode 滚动 EditLog。
3. NameNode 发送 FsImage 和 EditLog 给 Secondary。
4. Secondary 加载到内存合并，生成新 FsImage。
5. 返回新 FsImage 给 NameNode 替换。

4.3 与 NameNode 的本质区别

五、HA 架构下的新增组件

5.1 JournalNode：共享日志存储

在 HA 集群中，JournalNode 负责存储 EditLog，确保两个 NameNode 的元数据一致：

• 数量要求：奇数个（3、5、7）。
• 写策略：写入多数节点才算成功。
• 读策略：从最新节点读取。
• 网络要求：低延迟，高带宽。

配置示例：

<property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>qjournal://jn1:8485;jn2:8485;jn3:8485/mycluster</value>
</property>

5.2 ZKFC：故障转移控制器

ZKFC（ZooKeeper Failover Controller）是部署在 NameNode 节点上的守护进程，负责健康监控和故障转移：

1. 每个 NameNode 节点运行一个 ZKFC。
2. ZKFC 监控本地 NameNode 的健康状态。
3. 通过 ZooKeeper 进行领导者选举。
4. 故障时自动触发切换。

六、组件协作流程

6.1 文件写入流程

1. 客户端向 NameNode 发起创建文件请求。
2. NameNode 更新元数据，写入 EditLog。
3. NameNode 返回 DataNode 列表（如 DN1, DN2, DN3）。
4. 客户端建立管道连接，转发数据包。
5. DataNode 依次写入并 ACK。
6. 关闭文件，再次写入 EditLog。

6.2 文件读取流程

1. 客户端向 NameNode 查询元数据。
2. NameNode 返回块与 DataNode 列表。
3. 客户端选择最近的 DataNode 读取数据块。
4. 直接返回数据给客户端。

七、组件监控与运维

7.1 关键监控指标

# 查看 NameNode 状态
hdfs haadmin -getServiceState nn1

# 查看 DataNode 存活情况
hdfs dfsadmin -report | grep "Live datanodes"

# 查看 JournalNode 状态
hdfs dfsadmin -metaSave /tmp/metasave.txt

# Web UI 访问
# NameNode: http://namenode:9870
# DataNode: http://datanode:9864

7.2 常见问题排查

八、总结：HDFS 组件体系的核心设计

8.1 组件职责总览

• NameNode：元数据大脑，请求入口，决策中心。
• DataNode：数据仓库，读写执行，状态汇报。
• Secondary NameNode：Checkpoint 助手，合并日志，辅助恢复。
• JournalNode：日志共享，同步桥梁，多数派写入。
• ZKFC：健康哨兵，故障切换，选举协调。

8.2 核心设计哲学

1. 职责分离：NameNode 专注元数据，DataNode 专注数据，各司其职。
2. 冗余设计：数据多副本，服务 HA，消除单点故障。
3. 计算向数据移动：客户端直接与 DataNode 交互，减少 NameNode 负载。
4. 最终一致性：块位置动态构建，适应分布式特性。
5. 自动恢复：心跳检测、副本复制、故障转移，全自动化。

8.3 最终建议

对于生产环境，建议遵循以下原则：

1. 必须启用 HA：生产环境务必配置 NameNode HA。
2. 监控是关键：建立完善的组件监控体系。
3. 定期演练：演练故障转移流程，确保 HA 有效。
4. 资源规划：根据文件数估算 NameNode 内存需求。
5. 网络优化：确保组件间通信低延迟、高带宽。

理解 HDFS 组件，就是理解分布式存储的核心思想——将复杂问题分解，通过分工协作实现大规模数据的高效管理。