2. 回放验证基础
2.1 什么是回放验证
回放验证（Replay Validation）是一种离线数据校验方法：将线上真实流量（请求、事件、日志）原样录制下来，在离线环境中对同一批数据重新执行一次或多次，然后将新输出与原始输出（或预期基线）进行逐字段比对，从而发现数据链路中的逻辑差异、字段丢失、类型变更、计算偏差等问题。
核心思想可以概括为：“用同一份输入，看两个版本的处理结果是否一致”。它不依赖构造的测试用例，而是直接使用生产环境的真实数据，因此覆盖度高、真实性强。
关键特征：
- 离线执行：不干扰线上服务，可在任意时间回放。
- 逐字段比对：支持精确匹配、模糊匹配、阈值容忍等多种比对策略。
- 差异可追溯：每条差异记录都可关联到原始输入，便于定位根因。
2.2 回放验证在数据链路中的作用
在分层试验体系中，数据从埋点到最终分析报表需要经过采集、传输、清洗、加工、聚合等多个环节。任何一个环节出现偏差，都会导致试验结论失真。回放验证在数据链路中扮演以下关键角色：
| 数据链路环节 | 常见风险 | 回放验证作用 |
|---|---|---|
| 埋点采集 | 字段缺失、类型错误、枚举值变更 | 验证新版本 SDK 与旧版本输出一致性 |
| 数据传输 | 序列化/反序列化异常、丢字段 | 对比传输前后数据完整性 |
| 数据清洗 | 过滤规则过严/过松、脏数据误判 | 逐条比对清洗前后记录数及字段值 |
| 特征加工 | 计算逻辑变更、聚合口径不一致 | 验证新旧特征工程输出差异 |
| 试验分组 | 分流哈希算法变更、用户重复入组 | 回放验证分组结果与线上一致 |
| 指标计算 | 统计口径变化、异常值处理差异 | 逐指标比对聚合结果 |
实践建议：在分层试验系统中，建议将回放验证作为每次数据链路变更（SDK 升级、ETL 重构、指标口径调整）的必经卡口。只有回放通过率 ≥ 99.9% 且所有差异已确认或修复，才允许上线。
2.3 回放验证与实时验证的对比
实时验证（Online Validation）是在数据产生的同时进行校验，例如在 API 网关层校验请求格式、在数据管道中实时监控延迟和异常。回放验证与实时验证各有适用场景，不能相互替代。下表从多个维度进行对比：
| 对比维度 | 回放验证 | 实时验证 |
|---|---|---|
| 执行时机 | 离线，数据产生后任意时间 | 在线，数据产生时立即执行 |
| 数据来源 | 录制的历史真实数据 | 当前实时数据流 |
| 覆盖范围 | 可覆盖全量历史数据 | 仅覆盖当前及未来数据 |
| 比对基准 | 基线输出（线上原始结果） | 预定义的规则或 schema |
| 延迟容忍 | 高，分钟级到小时级均可 | 低，秒级或毫秒级 |
| 资源消耗 | 可弹性伸缩，不影响线上 | 占用线上资源，需控制开销 |
| 发现的问题类型 | 逻辑差异、口径变更、回归缺陷 | 格式错误、字段缺失、延迟告警 |
| 典型工具 | 自研回放框架、Diffy、DataDiff | Schema Registry、监控告警系统 |
常见误区：不要试图用实时验证替代回放验证。实时验证只能发现格式和规则层面的问题，无法发现逻辑回归、口径变更等深层差异。反之，回放验证也不能替代实时验证的秒级告警能力。两者应协同部署，形成“实时保稳定、离线保正确”的双层防线。