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

2.2 元数据存储结构

NameNode 在内存中维护了高效的数据结构，支持快速的文件系统操作。这里我们看一个简化版的 Java 类定义，帮助理解其内部逻辑：

// NameNode 核心数据结构（简化版）
public class FSNamesystem {
    // 1. 目录树结构（INode 层次结构）
    private INodeDirectory rootDir;
    
    // 2. 文件到块的映射
    private Map<Long, INodeFile> inodeMap;
    
    // 3. 块到 DataNode 的映射（核心位置信息）
    private BlocksMap blocksMap;
    
    // 4. DataNode 信息
    private Map<String, DatanodeDescriptor> datanodeMap;
}

关键设计：块位置信息不持久化到磁盘，而是在 NameNode 启动时通过 DataNode 的块报告动态构建。这意味着每次重启都需要重新加载元数据快照并等待 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。

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

3.1 核心职责

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

3.2 工作流程

1. 客户端请求写入数据
2. NameNode 返回 DataNode 列表
3. 客户端建立连接
4. 写入数据块
5. DataNode 发送心跳 + 块报告给 NameNode
6. 写入确认

3.3 数据存储结构

DataNode 的磁盘目录结构如下：

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

块文件命名规则：

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

四、Secondary NameNode：NameNode 的'助手'

4.1 核心职责

Secondary NameNode 是 HDFS 的辅助节点，但常被误解为 NameNode 的备份。它的真实作用是定期合并 FsImage 和 EditLog，防止 EditLog 过大导致 NameNode 启动缓慢：

4.2 Checkpoint 工作流程

1. Secondary NameNode 定期检查是否需要 Checkpoint
2. 请求 NameNode 滚动 EditLog
3. 获取 FsImage 和当前 EditLog
4. 加载到内存合并
5. 生成新 FsImage
6. 返回新 FsImage 给 NameNode
7. NameNode 替换旧 FsImage

4.3 与 NameNode 的本质区别

五、HA 架构下的新增组件

5.1 JournalNode：共享日志存储

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

配置示例：

<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 节点上的守护进程，负责监控 NameNode 的健康状态并触发故障转移：

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

六、组件协作流程

6.1 文件写入流程

1. 客户端创建文件请求
2. NameNode 更新元数据，写入 EditLog
3. NameNode 返回 DataNode 列表 [DN1, DN2, DN3]
4. 客户端建立管道连接
5. 数据包转发写入
6. 逐级 ACK 确认
7. 关闭文件，再次写入 EditLog

6.2 文件读取流程

1. 客户端打开文件请求
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 组件，就是理解分布式存储的核心思想——将复杂问题分解，通过分工协作实现大规模数据的高效管理。