Apache Nutch 2.3.1 checkpointing不生效，-resume恢复行为不符预期

你的观察其实是Nutch 2.3.1中-resume选项的正常行为，并非集群配置或故障导致的问题——你对“恢复未完成抓取URL”的预期和Nutch实际的实现逻辑存在一点偏差，咱们来详细拆解下：

1. -resume选项的核心运作逻辑 #

Nutch的-resume并不是“从故障断点处直接继续抓取未完成的URL子集”，而是基于作业状态和URL抓取状态的双重检查机制：

• 首先，它会跳过已经完全执行完成的作业阶段（比如如果之前的Generate作业已经完成，就不会重新运行Generate）
• 对于当前未完成的阶段（比如Fetch或Parse），它会遍历同批次ID下的所有URL，但逐个检查每个URL的状态：
  • 已成功完成抓取/解析的URL，会直接跳过（也就是你日志里看到的「Skipping express.pk; already fetched」）
  • 仅对处于unfetched、fetching（故障中断时正在处理的URL）或抓取失败状态的条目，进行重新尝试

2. 为什么看起来像是“重新抓取所有URL”？ #

这是因为Nutch在-resume模式下不会修改作业的输入URL集合（即同批次ID对应的全部URL列表），而是在执行过程中实时过滤已完成的条目。这种遍历+状态检查的方式，和你预期的“直接只处理未完成URL子集”表现形式不同，但本质效果是一致的——真正发起抓取请求的只有未完成的URL。

你可以通过以下方式验证这一点：

• 统计日志中「Skipping ... already fetched」的条目数量，对比实际出现「Fetched ...」的条目数量，差值就是本次-resume实际处理的未完成URL数
• 查看HBase中webpage表的status列：执行scan 'webpage', {COLUMNS => 'status'}，已成功抓取的URL状态为fetched，未完成的则为unfetched或fetching

3. 可选的配置验证与优化 #

如果你想确认配置是否正确，可以检查以下几点：

• 检查nutch-site.xml中的db.fetch.interval.default：这个配置控制URL的常规重新抓取间隔，但在-resume模式下，已完成抓取的URL会被优先跳过，不受该间隔影响
• 确认HBase的webpage表状态正常：确保集群重启后HBase数据没有丢失，URL的状态信息能被正常读取和更新

总结 #

你的理解偏差在于对-resume“恢复”方式的预期——Nutch并非直接从断点处继续，而是通过状态检查来跳过已完成的工作。你看到的“重新遍历同批次所有URL”是正常的执行流程，而日志中的跳过信息恰恰是-resume机制生效的证明。

内容的提问来源于stack exchange，提问作者Hafiz Muhammad Shafiq