3. 特征回放原理：时间旅行（Time Travel）机制与 SQL 实现逻辑

特征回放（Feature Replay）是离线验证的核心能力，它要求特征系统能够“回到过去”，在历史时间点精确还原特征值。这种能力依赖于 时间旅行（Time Travel） 机制和基于时间分区的 特征回溯 SQL 实现。本章深入剖析其原理与工程实现。

3.1 时间旅行（Time Travel）机制

时间旅行机制的核心思想是：特征数据不可原地覆盖，而是以时间版本的形式存储。查询时，通过指定时间戳，系统自动路由到该时间点对应的数据快照。

3.1.1 时间旅行 vs. 普通查询

3.1.2 时间旅行实现模式

业界主流实现模式包括以下三种：

1. 增量日志 + 状态快照（Delta Log + Snapshot）：记录每次特征变更的增量日志，查询时从基准快照重放增量到目标时间点。适用于高频更新场景。
2. 全量分区 + 时间分区裁剪（Full Partition + Partition Pruning）：按时间（如天/小时）存储全量特征快照，查询时直接定位到对应分区。适用于低频更新或批量特征。
3. 双时态模型（Bi-Temporal Model）：同时记录“业务时间”和“系统时间”，支持修正历史数据后的重新回放。适用于金融风控等强审计场景。

3.2 特征回溯的 SQL 实现逻辑

在离线数仓（如 Hive、Spark SQL）中，特征回溯通常通过 时间分区过滤 和 AS OF 语义 实现。以下展示两种核心实现模式。

3.2.1 基于时间分区的回溯查询（全量快照模式）

假设特征表按天分区，分区字段为 dt，每条记录包含特征生成时间 feature_time。回放到时间点 2025-03-15 10:30:00 的特征值：

-- 特征回溯 SQL：全量快照模式
SELECT
    entity_id,
    feature_name,
    feature_value
FROM
    feature_daily_snapshot
WHERE
    dt = '2025-03-15'           -- 分区裁剪，快速定位
    AND feature_time <= '2025-03-15 10:30:00'  -- 时间点过滤
    AND entity_id IN ('user_1001', 'user_1002');

3.2.2 基于增量日志的回溯查询（Delta 重放模式）

当特征变更频繁且存储全量快照成本过高时，采用增量日志 + 基准快照的方式。基准快照按周存储，增量日志按小时存储。

-- 特征回溯 SQL：增量重放模式
WITH base_snapshot AS (
    -- 1. 获取基准快照（最近一次全量快照）
    SELECT
        entity_id,
        feature_name,
        feature_value,
        snapshot_time
    FROM
        feature_weekly_snapshot
    WHERE
        dt = '2025-03-10'  -- 最近一次全量快照日期
        AND entity_id = 'user_1001'
),
delta_logs AS (
    -- 2. 获取基准快照之后、目标时间点之前的增量变更
    SELECT
        entity_id,
        feature_name,
        feature_value,
        change_time
    FROM
        feature_delta_log
    WHERE
        dt BETWEEN '2025-03-10' AND '2025-03-15'
        AND change_time > '2025-03-10 00:00:00'
        AND change_time <= '2025-03-15 10:30:00'
        AND entity_id = 'user_1001'
),
merged_features AS (
    -- 3. 合并：用增量覆盖基准快照中的对应特征
    SELECT
        COALESCE(d.entity_id, b.entity_id) AS entity_id,
        COALESCE(d.feature_name, b.feature_name) AS feature_name,
        COALESCE(d.feature_value, b.feature_value) AS feature_value,
        COALESCE(d.change_time, b.snapshot_time) AS effective_time
    FROM
        base_snapshot b
    FULL OUTER JOIN
        delta_logs d
    ON
        b.entity_id = d.entity_id
        AND b.feature_name = d.feature_name
)
-- 4. 取每个特征的最新一条（按 effective_time 排序）
SELECT
    entity_id,
    feature_name,
    feature_value
FROM (
    SELECT
        *,
        ROW_NUMBER() OVER (
            PARTITION BY entity_id, feature_name
            ORDER BY effective_time DESC
        ) AS rn
    FROM merged_features
) ranked
WHERE rn = 1;

3.3 时间旅行 SQL 的通用模板

为简化特征回溯的编写，建议封装通用模板，通过参数化方式支持不同存储模式：

-- 通用时间旅行 SQL 模板（snapshot 模式）
SELECT
    e.entity_id,
    f.feature_name,
    f.feature_value
FROM
    ${entity_table} e
LEFT JOIN
    ${feature_table} f
ON
    e.entity_id = f.entity_id
    AND f.${partition_field} = DATE_FORMAT(e.replay_time, 'yyyy-MM-dd')
    AND f.${time_field} <= e.replay_time
WHERE
    f.feature_name IS NOT NULL;

3.4 时间旅行机制的工程挑战

• 数据一致性：分布式环境下，特征写入顺序与时间戳可能乱序，需要引入 水位线（Watermark） 机制，确保回放时不会读到“未来”写入的数据。
• 存储成本：全量历史版本存储开销巨大。常用策略包括：时间衰减采样（近期保留全量，远期保留快照）、冷热分层（热数据 SSD，冷数据对象存储）。
• 查询延迟：跨多分区的回溯查询可能变慢。解决方案：预计算特征时间索引，或使用 物化视图 缓存常用时间点的特征快照。
• 时区处理：特征时间戳必须统一为 UTC 存储，回放时根据实体所在时区进行转换，避免因夏令时或时区偏移导致数据错位。