跳到主要内容

补数与重放操作规范

本文档定义数据中台中历史补数、事件重放、失败批次重试和下游影响控制的操作规则。

1. 适用场景​

本规范适用于：

  • 历史 TLog 补传
  • 历史事件重新导入
  • 原始数据重放
  • 失败批次重试
  • 下游漏数回补

2. 目标​

  • 不影响实时接入
  • 不要求停服
  • 可审计
  • 可回放
  • 可幂等
  • 可向下游解释

3. 基本原则​

  1. 补数与实时链路隔离执行。
  2. 补数优先进入 Raw Layer，再标准化。
  3. 所有补数任务必须有任务 ID 和审计记录。
  4. 补数写入必须幂等。
  5. 下游增量同步以 ingestTime 为准，不以 eventTime 为准。

4. 术语​

4.1 补数​

历史时间范围内数据缺失时，重新导入或补传缺失数据。

4.2 重放​

基于已留存的原始数据重新执行标准化和入库流程。

4.3 重试​

对单个失败批次或失败任务重新执行。

5. 任务分类​

建议将任务分成三类：

  • backfill: 历史缺失数据补录
  • replay: 使用原始数据重新标准化
  • retry: 失败批次重新执行

每个任务应记录：

  • job_id
  • job_type
  • game_id
  • region
  • time_range
  • source_ref
  • triggered_by
  • status
  • created_at
  • started_at
  • finished_at

6. 补数执行流程​

推荐流程：

  1. 创建补数任务
  2. 锁定任务范围
  3. 读取原始来源或补传来源
  4. 写入 Raw Layer
  5. 执行标准化
  6. 幂等写入标准层 / 事实层
  7. 记录结果
  8. 通知下游是否需要刷新

7. 重放执行流程​

推荐流程：

  1. 指定原始批次或时间范围
  2. 读取 Raw Layer 中的原始数据
  3. 重新执行字段映射与标准化
  4. 使用幂等策略写回标准层
  5. 记录重放影响范围

适用场景：

  • 字段映射规则修正
  • 事件定义修正
  • 标准化逻辑修正
  • 下游确认漏数

8. 幂等规则​

补数和重放必须至少满足以下一种幂等策略：

  • 以 event_uuid 去重
  • 以内部稳定组合键去重
  • 以 checkpoint + 原始偏移量去重

不允许：

  • 每次补数都直接追加无去重
  • 依赖人工判断是否重复

9. 对实时链路的影响控制​

补数任务必须与实时链路隔离，至少做到：

  • 单独队列
  • 单独并发限制
  • 单独资源预算
  • 可暂停 / 可恢复

推荐：

  • 高峰期限速
  • 大批量补数走离线窗口
  • 不与在线查询共抢高优先级资源

10. 下游同步影响​

下游必须接受以下事实：

  • 补数数据的 eventTime 可能早于当前日期很多
  • 但其 ingestTime 一定是新的

因此，下游增量同步应使用：

  • ingestTime
  • 必要时附加 eventUuid

推荐增量条件：

WHERE ingest_time > :last_watermark
   OR (ingest_time = :last_watermark AND event_uuid > :last_event_uuid)

11. 补数通知规范​

若补数可能影响下游口径，应通知：

  • 影响的数据集
  • 影响的业务 / 区域
  • 影响的时间范围
  • 影响的数据量
  • 是否需要下游重跑

12. 失败处理​

补数失败时，必须记录：

  • 失败任务
  • 失败批次
  • 失败原因
  • 已成功范围
  • 可恢复位置

失败后的推荐处理：

  1. 若是单批次失败，优先 retry
  2. 若是标准化规则问题，修复后 replay
  3. 若是原始数据缺失，补 Raw 后再 backfill

13. 审计要求​

所有补数和重放任务都应可审计：

  • 谁触发
  • 为什么触发
  • 影响哪些数据集
  • 影响多少数据
  • 是否通知过下游

14. 不建议的做法​

  • 直接在生产表手工改数据
  • 跳过 Raw Layer 直接手工插入
  • 不记录任务上下文
  • 让下游自行猜测补数范围
  • 让补数任务与实时接入抢同一资源池

15. 一句话原则​

补数与重放应当是：

独立任务、先原始后标准化、全程可审计、对下游可解释、对实时链路低干扰。

加载评论中...