检查点如何在 HDFS 中工作？我想弄清楚 fs.checkpoint.period 和 fs.checkpoint.size

Posted 2023-04-18

【中文标题】检查点如何在 HDFS 中工作？我想弄清楚 fs.checkpoint.period 和 fs.checkpoint.size

【英文标题】：How does checkpointing work in HDFS? I would like to get clarity on fs.checkpoint.period and fs.checkpoint.size

【发布时间】：2014-03-22 18:44:37

【问题描述】：

当它说，辅助名称节点检查点每小时（fs.checkpoint.period，以秒为单位）或如果编辑日志达到 64 MB（fs.checkpoint.size 以字节为单位）更快？到底是什么意思？

据我了解，编辑日志存储在本地文件磁盘中。

【问题讨论】：

你读过hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-hdfs/…吗？

【参考方案1】：

HDFS 元数据可以被认为由两部分组成：基本文件系统表（存储在名为 fsimage 的文件中）和列出对基表所做更改的编辑日志（存储在名为 edits 的文件中） .检查点是协调fsimage 与edits 以产生fsimage 的新版本的过程。这样做有两个好处：fsimage 的更新版本和截断的编辑日志。

fs.checkpoint.period 控制触发此对帐的频率。 3600 表示每小时fsimage 将被更新并截断编辑日志。 Checkpiont 并不便宜，因此在过于频繁地运行它和让编辑日志变得太大之间存在平衡。假设您的集群中使用典型的文件系统，应设置此参数以获得良好的平衡。

fs.checkpoint.size 是一个大小阈值，如果达到edits，将立即触发一个检查点，而不管自上一个检查点以来经过的时间。这是在异常繁重的文件系统元数据写入流量下编辑日志变得过大的保险。

【讨论】：

非常感谢您的回复。这解释了很多事情。但我有一个小问题。基本文件系统表是什么意思？基本文件系统表的数量是恒定的吗？如果在进程中创建了新的基本表，那么元数据不会直接写入 fsimage 吗？

那么，如果我没记错的话，我读到的是这个检查点是由辅助名称节点完成的？

主namenode不会将fsimage的最新版本写回磁盘，以在保证一致性的同时最大化吞吐量。这项工作通常被卸载到辅助名称节点（您的直觉在这里是正确的），它必须从旧版本 + 最近的编辑日志重新创建新的 fsimage。

【参考方案2】：

NameNode 在 HDFS 中维护命名空间。所有 DataNode 文件元数据都存储在 NameNode 的 editLog 和 fsImage 中。 fsImage 是给定时间的 HDFS 文件系统的映像，它是集群发生的所有更改的累积。 editLog 包含最近的更改。 Checkpointing是将editLog合并到fsImage中的过程。这个过程是资源密集型的，它会影响 NameNode 上正在进行的请求。

Secondary NameNode 为 HDSF NameNode 做检查点。 它向 NameNode 发出 HTTP 请求并获取最新的 fsImage 日志并将其与 editLogs 中捕获的最新更改合并。 Primary NameNode 请求和Secondary NameNode 回复合并fsImage 和editLog 被截断。

这是一个事件驱动的流程，其中一个事件会根据以下任一条件触发： 1) 以秒为单位的特定时间段 fs.checkpoint.period 2）editLog达到特定大小fs.checkpoint.size

它们中的任何一个都可以在 core-default.xml 中进行配置。 这应该根据可用的网络带宽以及在指定时间内可能发生的变化累积来设置最佳。