Appearance
HDFS 整体架构
关键词：分布式硬盘
核心组件说明：
| 组件 | 职责 |
|---|---|
| NameNode | HDFS 主节点，管理文件系统命名空间、维护目录树结构、控制文件块（Block）与 DataNode 的映射关系、处理客户端请求 |
| DataNode | 存储实际数据块（Block，默认 128MB），定时向 NameNode 发送心跳和块报告（Block Report），负责数据块的读写和副本复制 |
| Secondary NameNode | 非 NameNode 热备，定期将 FsImage 与 Edits Log 合并（Checkpoint），防止 Edits Log 过大 |
| Client | 与 NameNode 交互获取元数据，直接与 DataNode 进行数据流式传输 |
数据写入流程：
数据读取流程：
读取关键点：Client 选择 DataNode 时遵循"距离最近"原则（同节点 > 同机架 > 同数据中心），若某个 DataNode 不可用，自动切换到其他副本节点
副本机制（Replication）
副本放置策略（Rack Awareness）：
- 第 1 个副本：优先放在 Client 所在节点，若 Client 在集群外则随机选择
- 第 2 个副本：放在与第 1 个副本不同节点、同机架的 DataNode
- 第 3 个副本：放在与第 1、2 个副本不同机架的 DataNode
这样保证了机架级容灾——即使整个机架故障，数据仍然可从其他机架恢复
Heartbeat 心跳机制
心跳本质：DataNode 每隔 3 秒向 NameNode 发送"我还活着"的信号。NameNode 超过 10 分钟未收到心跳，认为该节点已死，自动将其上的 Block 在其他节点补齐副本数
Block Report 块报告机制
Block Report 本质：DataNode 向 NameNode 汇报"我存了哪些 Block"，让 NameNode 掌握全局数据分布。NameNode 据此判断是否有副本不足或冗余，并做出调度决策
HA 高可用架构
HA 故障转移流程：
- Active NameNode 宕机 → ZooKeeper 会话超时
- ZKFC（ZK Failover Controller）检测到故障
- ZKFC 触发自动切换，Standby NameNode 提升为 Active
- 新 Active 从 JournalNode 同步完最新的 Edits Log 后开始提供服务
- 整个过程自动完成，无需人工干预
一句话总结核心概念：
| 概念 | 类比 | 作用 |
|---|---|---|
| NameNode | 🎖️ 指挥官 | 管理元数据，指挥全局 |
| DataNode | 💂 士兵 | 存储数据块（Block），听令行事 |
| Client | 👤 用户 | 发起读写请求 |
| Block | 🧱 文件切片 | 大文件拆分为固定大小的块（默认 128MB） |
| Replication | 📋 副本机制 | 每个 Block 存 3 份，保证数据可靠性 |
| Heartbeat | 💓 活着证明 | DataNode 定时向 NameNode 报告存活状态 |
| Block Report | 📦 数据清单 | DataNode 汇报自己存了哪些 Block |
| HA | 🔄 双机热备 | Active/Standby 两个 NameNode，主挂备自动接管 |
HDFS 核心设计
Block 数据块设计
Block 大小权衡：
Block 大小 优点 缺点 太小（64MB） 并行度更高 NameNode 内存压力大、寻址开销占比高 太大（256MB+） 元数据更少 小文件浪费空间、MapReduce 切分粒度粗 128MB（默认） 均衡之选 — HDFS 设计目标：存大文件、顺序读，因此 Block 远大于普通文件系统的 4KB
机架感知策略（Rack Awareness）
网络拓扑距离计算：
text距离 = 两个节点到最近公共祖先的跳数之和 同一 DataNode → 距离 0 同机架不同节点 → 距离 2（A → Rack交换机 → B） 不同机架 → 距离 4（A → Rack交换机 → 核心交换机 → Rack交换机 → C）读取时优先选距离最近的副本，减少跨机架网络传输带宽消耗
元数据管理（FsImage + Edits Log）
为什么需要两份？
- FsImage：完整的文件系统元数据快照，体积大，不适合频繁写入
- Edits Log：只追加操作日志，写入快，但随时间增长会越来越大
- 合并（Checkpoint）：Secondary NameNode 定期将两者合并为新的 FsImage，防止 Edits Log 无限膨胀
NameNode 重启恢复流程：加载 FsImage → 回放 Edits Log → 恢复完整元数据到内存
数据完整性校验（Checksum）
两层校验保障：
层级 触发时机 行为 Client 端 每次读取 重新计算 Checksum，不一致则切换副本 DataNode 端 定时后台扫描 发现损坏 Block 自动从其他副本修复 校验粒度：每 512 字节生成一个 CRC-32C 校验和（4 字节），开销极小
数据均衡（Balancer）
Balancer 触发场景：
- 新 DataNode 加入集群 → 初始为空，需要迁入数据
- DataNode 下线/故障 → 剩余节点负载不均
- 手动执行
hdfs balancer -threshold 10（阈值 10%，即各节点使用率差异不超过 10%）迁移原则：只在不同 DataNode 之间复制 Block，副本数不变，迁移完成后删除源副本，确保不影响数据可用性
HDFS 写数据的容错机制
容错关键设计：
- Pipeline 中任一节点失败：Client 收到 ACK 后感知故障，向 NameNode 汇报，重建 Pipeline 继续写入
- 最小副本保证：写入过程中只要
acks >= minReplication（默认 1），就认为写入成功- 异步补齐：NameNode 后台调度将副本数恢复到目标值（默认 3）