4、时间旅行与特征回溯

在实时与批量特征计算场景中，特征值会随时间不断变化。如果模型训练时使用了当前时刻的特征，而推理时却使用了历史时刻的特征，就会产生 数据泄露（Data Leakage） 或 特征不一致 问题。Feature Store 通过 时间旅行查询 与 特征回溯（Point-in-time Join） 机制，确保每个训练样本只使用该样本标签时刻之前已存在的特征值。

4.1 时间旅行查询

时间旅行查询允许用户查询某个特征在 过去任意时间点 的快照值。其核心原理是 Feature Store 在存储特征时，不仅保存最新值，还保留每条特征记录的 有效时间区间（Valid Time Range）。

时间旅行查询示例（SQL 风格）

-- 查询用户 'user_001' 在 '2024-06-15 10:30:00' 时的信用分
SELECT user_id, credit_score
FROM user_credit_features
FOR SYSTEM_TIME AS OF '2024-06-15 10:30:00'
WHERE user_id = 'user_001';

时间旅行 vs 普通查询

4.2 特征回溯（Point-in-time Join）原理

特征回溯是时间旅行查询在 批量训练数据集构建 中的核心应用。当我们需要将标签表（Label Table）与多个特征表（Feature Tables）关联时，必须保证每个标签行只关联到 该标签事件发生时刻之前 的特征值。

Point-in-time Join 执行流程

1. 输入： 标签表（含 event_timestamp 列） + 特征表（含 feature_timestamp 列）。
2. 排序： 按标签事件时间升序排列标签行。
3. 查找： 对每个标签行，在特征表中查找 feature_timestamp <= event_timestamp 且时间最近的特征版本。
4. 拼接： 将查找到的特征值拼接到标签行上，形成训练样本。
5. 输出： 时间对齐后的训练数据集。

4.3 数据版本管理

数据版本管理是支撑时间旅行与特征回溯的底层基础设施。Feature Store 通常采用 不可变日志（Immutable Log） 或 Delta 存储 模式来管理特征版本。

版本管理策略对比

版本号与时间戳双标识

每个特征版本通常由 版本号（Version ID） 和 有效时间戳（Valid Timestamp） 共同标识。版本号用于精确回滚，时间戳用于时间旅行查询。

-- 特征版本表示例
CREATE TABLE feature_versions (
    feature_name   STRING,
    entity_key     STRING,
    feature_value  DOUBLE,
    version_id     BIGINT,        -- 单调递增版本号
    valid_from     TIMESTAMP,     -- 该版本生效起始时间
    valid_to       TIMESTAMP,     -- 该版本失效时间（NULL 表示当前有效）
    PRIMARY KEY (feature_name, entity_key, version_id)
);

4.4 实践要点与避坑指南

• 时间戳精度对齐： 标签时间戳与特征时间戳必须使用同一时钟源，避免因时区或毫秒级差异导致关联错误。
• 特征延迟处理： 如果特征计算有延迟（例如批处理任务晚点），Point-in-time Join 应设置 grace period，允许关联稍晚到达但时间戳正确的特征。
• 版本清理策略： 不可变日志会持续增长，建议设置 TTL（如保留最近 90 天版本）或定期合并（Compaction）以减少存储开销。
• 测试回溯正确性： 在构建训练集后，随机抽取样本人工验证特征时间戳是否严格小于等于标签时间戳。