4. 数据采集策略：全量对比 vs 抽样对比、时间窗口选择、异常埋点收集

4.1 现象识别：采集层数据缺口与偏差

在数据异常排查初期，最常见的表象是核心业务指标（如日活、GMV）在不同数据系统间出现无法解释的差异。这种差异通常具有以下特征：

• 趋势背离：系统A的曲线平稳，系统B的曲线出现骤降或骤升。
• 边界失真：每日切换时刻（如00:00:00）的数据归属错误，导致前后两天数据同时偏高或偏低。
• 局部缺失：特定渠道或用户群的数据在报告中呈现“零值”或“空值”。

这些现象直接指向数据采集策略的顶层设计问题——我们需要立刻诊断当前是全量采集还是抽样采集，以及时间窗口是否对齐。

4.2 数据采集：全量 vs 抽样策略矩阵

选择正确的采集策略是问题定位的基石。以下对比表展示了不同策略在排查场景下的适用性：

时间窗口选择是另一个核心维度。常见的窗口策略包括：

• T+1 批次窗口： 强一致性，适合离线对账。
• 滚动窗口（如1小时）： 准实时，适合监控看板。
• 实时滑动窗口（如5分钟）： 高时效，适合告警。

以下是一个典型的时间窗口对齐采集配置示例：

-- 采集脚本：将业务时间强制对齐到标准批次窗口
SET timezone = 'Asia/Shanghai';

INSERT INTO dwd_order_di (batch_date, order_id, amount)
SELECT
    date_trunc('day', order_time) AS batch_date,
    order_id,
    amount
FROM ods_order_rt
WHERE order_time >= current_date - interval '1 day';

4.3 原因定位：基于采集策略的故障树分析

当我们发现数据差异时，可以利用以下判断规则快速收敛原因：

1. 规则一：全量一致 & 抽样不一致 → 抽样策略存在偏差（如随机种子不一致、哈希分桶不均）。
2. 规则二：系统A有数据 & 系统B无数据 → 采集链路中断（埋点未上报、网络拦截、SDK版本不一致）。
3. 规则三：跨天数据不一致 → 时间窗口未对齐（时区设置、截断逻辑差异）。

4.4 修复动作：调整采集参数与重新对齐

根据定位到的原因，执行对应的修复动作：

• 修正抽样策略： 对于需要高精度的场景，临时切换为全量采集兜底。
• 修复时间窗口： 统一全局时区，并在采集作业中强制执行窗口边界。
• 补全异常埋点： 检查客户端SDK上报策略，确保关键事件（如付费、注册）的采集率为100%。

埋点配置修复示例：

{
  "collector": {
    "app_id": "com.example.app",
    "events": {
      "payment_success": {
        "sampling_rate": 1.0,  // 修复：从 0.5 提升至 1.0
        "trigger": "immediate"
      },
      "page_view": {
        "sampling_rate": 0.1,   // 保留抽样
        "trigger": "batch"
      }
    },
    "timezone": "Asia/Shanghai",  // 修复：显式指定时区
    "window_size": "T+0"
  }
}

4.5 复测：数据一致性验证清单

修复完成后，必须执行严格的复测流程，确保采集层已对齐：

• [ ] 行数级验证： 全量对比源表和目标表的记录数是否严格一致。
• [ ] 边界值验证： 检查时间窗口起始点（如 2024-01-01 00:00:00）的数据归属是否正确。
• [ ] 抽样置信度验证： 确保抽样结果在 95% 置信区间内与全量结果无显著差异。
• [ ] 链路连续性验证： 模拟一次完整的业务请求，从客户端上报到数仓落地，校验埋点日志是否持续产生。

4.6 预防：建立采集标准与监控体系

为防止同类问题再次发生，建议落地以下预防方案：

• 采集SLA监控： 对关键事件的采集延迟、空值率、采样率波动设置告警阈值。
• 埋点治理平台： 建立统一的元数据中心，管理每个埋点的采集方式（全量/抽样）和时间窗口。
• 定期演练： 每月进行一次“数据一致性红蓝对抗”，模拟采集链路故障，验证应急切换流程。