HDFS FsImage、EditLog 和 Checkpoint 是什么关系？
面试怎么回答
FsImage 是 NameNode 命名空间在某个时点的持久化快照，EditLog 追加记录之后的创建、删除、重命名等变更。NameNode 启动时加载最新 FsImage，再重放后续 EditLog。Checkpoint 会定期合并镜像和日志，生成新的 FsImage，控制恢复时间和日志规模。SecondaryNameNode 的核心职责是 Checkpoint，不是热备；真正的 HA 还需要 Active/Standby、共享日志和自动切换机制。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
SecondaryNameNode 不是 NameNode 的热备节点，不能在 Active NameNode 故障后自动顶上去。
它经典职责中的核心，是参与生成 Checkpoint，控制元数据日志的恢复成本。
FsImage 保存某个时点的命名空间镜像，EditLog 记录其后的变更，Checkpoint 把两者合并成新的镜像。
FsImage 是命名空间检查点
FsImage 保存目录树、文件属性、权限和块映射等命名空间状态。它不是每发生一次创建或删除就完整重写，否则元数据更新成本会非常高。
可以把它理解成某个事务 ID 时点的基础快照。
EditLog 记录后续增量变更
创建文件、删除目录、修改权限等命名空间操作会追加到 EditLog。NameNode 内存里维护最新状态，磁盘上通过 FsImage 加后续 EditLog 共同表达最新命名空间。
如果 EditLog 长期增长，NameNode 启动时就要重放更多事务，恢复时间和日志管理压力都会增加。
Checkpoint 负责定期合并
Checkpoint 过程读取最新 FsImage 和对应 EditLog，应用变更后生成新的 FsImage。之后恢复只需要从更近的检查点继续重放日志。
在非 HA 架构中，SecondaryNameNode 或 CheckpointNode 可以承担这项工作；在 QJM HA 架构中，Standby NameNode 通常也会进行 Checkpoint。具体流程要结合版本和部署方式。
Checkpoint 和 HA 解决不同问题
Checkpoint 解决元数据持久化和恢复成本，不负责自动故障接管。HA 需要 Active/Standby、共享 EditLog、故障检测、选主与 Fencing 等完整机制。
所以“有 SecondaryNameNode 就有高可用”是错误的；“已经做 HA 就不用关注 Checkpoint”同样错误。
一个典型场景
某环境 NameNode 重启耗时远超预期，进程并没有卡死，而是在重放大量 EditLog。继续检查发现 Checkpoint 长期失败，但只监控了 NameNode 进程存活，没有监控最近检查点时间和事务差距。
修复 Checkpoint 链路并验证新的 FsImage 后，恢复时间才回到可接受范围。
元数据可靠性不能只看进程是否存活，还要看镜像、日志和检查点是否形成闭环。