4. 特征回放概念:回放的定义、回放的目的与在线服务的区别
4.1 特征回放的定义
特征回放(Feature Replay / Feature Backfill) 是指将历史上某个时间点的原始数据,按照当前(或指定)的特征计算逻辑重新加工,生成与当时在线请求完全一致的特征向量的过程。其核心公式可概括为:
特征回放结果 = f(历史原始数据, 当前特征逻辑, 时间戳对齐)
回放不是简单的数据拷贝,而是对历史数据的“再计算”。它要求特征计算引擎能够精确还原出在历史时刻,如果使用当前的特征工程代码,会产出什么样的特征值。
关键区别: 离线ETL批量加工 ≠ 特征回放。离线ETL通常使用T+1的全量数据,而特征回放必须严格对齐在线请求的时间窗口和特征依赖。
4.2 特征回放的目的
特征回放在机器学习工作流中承担三个核心目的,分别对应模型生命周期的不同阶段:
| 目的 | 适用阶段 | 核心要求 | 典型场景 |
|---|---|---|---|
| 模型训练 | 离线开发 | 大规模、高吞吐、可重复 | 使用过去30天的用户行为特征训练CTR模型 |
| A/B测试 | 实验评估 | 一致性、公平性、可回溯 | 新特征逻辑上线前,回放历史数据对比实验组/对照组 |
| 线上仿真 | 预发布验证 | 低延迟、高保真、端到端 | 模拟线上流量,验证特征管道在峰值QPS下的表现 |
4.2.1 模型训练
回放为离线训练提供大规模的历史特征样本。训练数据需要覆盖足够长的时间跨度(如7天、30天),且特征值必须与线上请求时刻对齐,避免数据泄露(Data Leakage)。例如,计算用户“过去1小时点击次数”时,回放必须使用该请求发生时刻之前的数据,而非全量数据。
4.2.2 A/B测试
在特征工程迭代中,A/B测试需要对比新旧特征逻辑的效果。通过回放,可以在不干扰线上流量的情况下,用同一批历史请求分别计算旧特征和新特征,然后训练模型并评估指标差异。这种方式避免了线上分流带来的流量成本和风险。
实践建议: A/B测试回放时,务必保证实验组和对照组使用完全相同的样本ID和时间戳,否则对比结果无效。
4.2.3 线上仿真
线上仿真(Shadow Testing / Replay Testing)是回放最接近生产环境的用途。它将线上真实请求的日志作为输入,通过特征回放管道重新计算特征,并与线上实际产出的特征进行比对。仿真回放关注的是:
- 特征一致性: 回放结果与线上结果是否完全一致?
- 延迟分布: 回放管道的P99延迟是否满足线上要求?
- 资源消耗: 回放过程中的CPU、内存、IO是否在预期范围内?
4.3 回放与在线服务的区别
特征回放虽然复用了在线特征逻辑,但在架构、数据源、延迟要求和一致性模型上存在本质差异。下表从多个维度进行对比:
| 对比维度 | 在线服务 | 特征回放 |
|---|---|---|
| 触发方式 | 用户实时请求驱动 | 离线调度任务 / 脚本触发 |
| 数据源 | 实时流(Kafka、实时DB) | 历史日志存储(HDFS、S3、Hive) |
| 延迟要求 | 毫秒级(P99 < 50ms) | 分钟级 ~ 小时级(可接受批处理) |
| 一致性模型 | 最终一致性 / 读己之写 | 强一致性(必须精确还原) |
| 计算规模 | 单次请求计算少量特征 | 批量计算百万~亿级特征 |
| 容错策略 | 快速失败 + 降级 | 重试 + Checkpoint + 断点续传 |
| 输出目标 | 模型推理 / 业务决策 | 训练样本表 / 对比报告 / 仿真日志 |
常见误区: 不要认为回放只是“把在线代码在离线跑一遍”。在线服务依赖实时状态(如Redis中的用户画像),而回放必须从历史快照中重建这些状态,否则会产生特征漂移。
4.4 特征回放架构示意
下图展示了特征回放与在线服务在架构层面的核心差异。在线服务从实时数据源获取特征,而回放系统从历史存储中读取数据,并通过时间戳对齐引擎还原历史状态。
4.5 回放一致性等级
根据业务场景的不同,特征回放对一致性的要求可分为三个等级:
- 精确回放(Exact Replay): 回放结果必须与线上结果完全一致,适用于模型训练和A/B测试。要求特征逻辑、依赖数据、时间窗口完全对齐。
- 近似回放(Approximate Replay): 允许微小偏差(如浮点精度、统计近似),适用于大规模离线分析或探索性实验。
- 语义回放(Semantic Replay): 只保证特征语义一致(如“用户活跃度”这个特征的含义一致),不要求数值完全一致,适用于跨版本特征对比。
选型建议: 模型训练和A/B测试必须使用精确回放;线上仿真可以使用近似回放来评估性能瓶颈;跨版本特征演进分析适合语义回放。