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

2.2 元数据存储结构

NameNode 在内存中维护了高效的数据结构，支持快速的文件系统操作：

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

关键设计：块位置信息不持久化到磁盘，而是在 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。

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

3.1 核心职责

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

3.2 工作流程

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

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 的备份。它的真实作用是：

4.2 Checkpoint 工作流程

1. NameNode 定期检查是否需要 Checkpoint。
2. 请求 Secondary NameNode 执行 Checkpoint。
3. Secondary NameNode 滚动 EditLog。
4. 发送 FsImage+EditLog 给 Secondary NameNode。
5. 加载到内存合并。
6. 生成新 FsImage。
7. 返回新 FsImage 给 NameNode。
8. 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 状态。
• 异常检测：触发故障转移。
• ZooKeeper 选举：更新 Active/Standby。

工作机制：

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

六、组件协作流程

6.1 文件写入流程

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

6.2 文件读取流程

1. 客户端向 NameNode 打开文件请求。
2. NameNode 查询元数据，返回 <块，DataNode 列表>。
3. 客户端选择最近的 DataNode。
4. 直接读取数据块。
5. 返回数据。

七、组件监控与运维

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 组件职责总览

8.2 核心设计哲学

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

8.3 最终建议

对于生产环境，建议：

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