公开数据采集怎么定时自动跑：按日报周报节奏设调度

想让公开数据按固定时间自动更新，不用每次手动触发，做法是给采集任务配一条定时规则，把「什么时候跑、跑几次、失败怎么办」提前写死。日报和周报不要共用一套时间，分开设，重复调用和漏采大多出在这一步。

定时调度本身不复杂，难的是设完之后怎么确认它真的按预期在跑。下面按时间点、频率、重试、核对四件事分开讲，最后给一份可以照着改的配置示例。

先定节奏：日报和周报不是一回事

日报要的是「当天能看到前一天的变化」，周报要的是「一周的汇总口径稳定」。两者的时间点不该一样。

日报建议放在目标站点更新趋于稳定之后。很多公开数据源在凌晨到上午之间刷新，具体时点视情况而定，判断方法是连续几天在同一时间段手动拉一次，看返回内容的日期字段什么时候变。找到相对稳定的窗口，把任务放在窗口之后半小时到一小时，留出缓冲。

周报不建议和日报同一时刻跑。周报通常要覆盖完整七天，如果周一早上和日报一起触发，容易在边界日重复计入。把周报放在周日晚或周一稍晚，和日报错开至少一小时，减少同一时段对同一数据源的集中请求。

一个简单的对照：

任务类型 建议时间 频率 主要风险 日报 数据源刷新后半小时到一小时 每天一次 刷新延迟导致拉到旧数据 周报 与日报错开至少一小时 每周一次 边界日重复或漏计 补采 日报之后单独触发 按需 与主任务撞车

这张表不是标准答案，实际时间要按你盯的那几个源来调。原则只有一条：同一数据源在同一时段尽量只被请求一次。

频率别贪多：一天一次通常够用

公开数据的更新频率有限，多数行业资讯和产品动态类页面一天变不了几次。定时任务设成每小时跑一次，多数时候拉回来的是同一份内容，既增加请求量，也让后续的去重和比对变麻烦。

判断频率的方法很直接：连续几天记录目标页面的更新时间或内容指纹，看它实际多久变一次。变化间隔大于一天，日报级别就够；确实有半天内多次更新的源，再单独给它加一条更密的规则，而不是把所有任务一起调快。

需要提醒的是，平台对请求频率通常有约束，具体条款和阈值以官方最新说明为准。设调度时把间隔留宽一点，比事后被限流再排查要省事。

避免重复调用：三个容易忽略的地方

重复调用往往不是调度本身写错，而是几个任务叠在了一起。

• 手动补跑和定时任务撞车。补采前先确认当天的定时任务是否已执行，或者给补采单独设一个明显不同的时间点。
• 重试机制和正常调度叠加。失败重试如果间隔太短，可能在下一轮正常任务开始前还在跑，形成两条并行的请求。重试次数和间隔要写清楚，比如最多两次、间隔十分钟。
• 多个任务共用同一个数据源。日报、周报、专题监控如果都指向同一批页面，考虑让它们读同一份落地数据，而不是各自去拉。

配置里能写条件的地方尽量写条件，比如「当天已成功则跳过」，比靠人记要可靠。

漏采怎么补：留一条可回查的记录

漏采的原因通常是任务失败没被发现，或者时间点设在了数据源还没更新的空窗。两种情况的处理不一样。

失败类漏采靠日志。每次任务执行记录三样东西：开始时间、结束时间、结果状态。状态不用很细，成功、失败、跳过三类就够。有了这张表，隔几天翻一次，能看出是偶发还是固定时段出问题。

空窗类漏采靠调整时间点。如果日志显示任务成功但拉到的内容和前一天一样，先别急着改逻辑，把执行时间往后挪半小时再看几天。

补采本身也要有规矩：补采只补缺失的那一天，不要顺手把整周重跑一遍，否则容易和历史数据对不上。

一份可以照着改的配置示例

下面是一个通用写法，字段名各家工具不同，按你用的调度工具的文档替换即可。

job: daily_public_data
schedule: "30 9 * * *"      # 每天 9:30，按数据源实际刷新时间调整
timezone: Asia/Shanghai
retry:
  max_attempts: 2
  interval_minutes: 10
skip_if_succeeded_today: true
log:
  start_time: true
  end_time: true
  status: [success, failed, skipped]

周报另起一条，时间错开：

job: weekly_public_data
schedule: "0 20 * * 0"      # 周日 20:00
timezone: Asia/Shanghai
depends_on: daily_public_data

depends_on 这类字段不是所有工具都有，没有的话就靠时间错开，效果接近。

设完之后怎么核对

调度上线后的头一周，每天花几分钟看三件事：任务有没有按点执行、返回内容是不是新的、失败有没有重试成功。一周之后改成每周看一次日志汇总。

核对时不用追求每次都完美。偶发一次失败、重试后成功，属于正常范围；连续两三天同一时段失败，才需要动配置。把判断标准写下来，比每次凭感觉决定要不要改要稳。

最后一句提醒：定时调度解决的是「不用手动触发」，不解决「数据一定对」。拉到之后的口径核对、去重和字段校验，还是要在下游单独做一层。调度设得再细，也替代不了这一步。

本文由 AI 生成