特征平台与 ML 基础设施 — 训练与推理共用一份特征的工程学Feature Platform & ML Infra: Dual Store, Point-in-Time Correctness, Model Serving, Experimentation

问题场景 + 需求约束

设计一个支撑外卖/风控级别的特征平台：100+ 模型（配送 ETA、门店排序、欺诈识别）共用一套特征，在线推理峰值 1000 万次特征读/秒、单次预测要取 200 个特征、p99 < 10ms；同时离线要能为几十亿样本回溯出「当时那一刻」的特征做训练。这就是 DoorDash、Uber 真实的量级。

核心矛盾：训练用离线批处理（吞吐优先），推理用在线低延迟（延迟优先），但两边必须是同一个特征值——否则模型线下 AUC 0.85、线上掉到 0.79，这就是臭名昭著的 training-serving skew。平台要解决三件事：存哪、怎么保证一致、怎么服务与验证。

• 特征新鲜度：账户余额类特征要秒级，用户 30 天累计消费可以小时级——不同新鲜度不同代价。
• 读写比：DoorDash 公开过其在线特征「写只占读的 0.1%」，是极端读多写少，决定了选 Redis/KV 而非通用 DB。
• point-in-time 正确：训练标签在 T 时刻产生，特征只能用 T 之前的值，否则标签泄漏。
• 可复用/可发现：Uber Palette 托管 2 万+ 特征供全公司复用，避免每个团队重复造轮子。

高层架构

graph LR
    SRC["数据源
事件流 / 数仓 / DB CDC"]
    subgraph 计算层
      BATCH["批计算
Spark / SQL"]
      STREAM["流计算
Flink"]
    end
    REG["特征注册表
定义 + 版本 + 血缘"]
    OFF[("离线 Store
Parquet / 数仓")]
    ON[("在线 Store
Redis / DynamoDB")]
    TRAIN["训练
PIT join 取样本"]
    SERVE["模型服务
取特征 + 推理"]

    SRC --> BATCH & STREAM
    REG -.约束定义.-> BATCH & STREAM
    BATCH --> OFF
    BATCH -->|物化 materialize| ON
    STREAM --> ON
    OFF --> TRAIN
    ON --> SERVE

    classDef src fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    classDef comp fill:#0e2030,stroke:#5eead4,color:#e8eef5
    classDef store fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    classDef sink fill:#1a1a30,stroke:#ffb450,color:#e8eef5
    class SRC src
    class BATCH,STREAM,REG comp
    class OFF,ON store
    class TRAIN,SERVE sink

同一份特征定义（注册表）驱动批与流两条管道，分别落离线/在线两个 Store，喂给训练与推理

组件职责：注册表是唯一真相源，声明特征的实体键、类型、转换逻辑与新鲜度 SLA；批计算做重回溯与 T+1 特征、流计算做秒级新鲜特征；离线 Store按时间分区保留全历史（供 point-in-time 取数），在线 Store只存每个实体的最新值（供毫秒读）。这就是业界共识的双 Store（dual-store）架构。

关键技术点

1. 双 Store：离线仓库 vs 在线 KV，一个定义两处物化

原理：训练要「几十亿样本 × 每样本回溯历史特征」，是吞吐型全表扫描，天然属列存数仓（Parquet/Iceberg，按 event_ts 分区）。推理要「给定一个用户，10ms 内取 200 个特征」，是点查型随机读，天然属内存 KV。同一个特征在两个引擎各物化一份，靠注册表保证语义一致。

# 在线取数：一次 pipeline 批量拉 200 个特征键，避免 200 次 RTT
def fetch_online(entity_ids, feature_names):
    keys = [f"{fn}:{eid}" for eid in entity_ids for fn in feature_names]
    vals = redis.mget(keys)          # 单次往返，200 键 ~1ms
    return assemble(entity_ids, feature_names, vals)

# 物化 materialization：批管道把最新值刷进在线 Store
# 只写「每实体最新」，不保留历史 → 在线 Store 体积可控

2. Point-in-Time 正确性：杜绝标签泄漏的核心机制

原理：训练样本是「(实体, 标签时刻 T, 标签)」，为它拼特征时，只能用 event_ts ≤ T 的最新特征值。若图省事直接 join 特征表的当前值，就把「未来」信息喂给了模型——线下指标虚高、线上崩盘。正确做法是 point-in-time join（as-of join）：对每个样本按实体键找「T 之前最近一条」特征。

# Point-in-time join 伪代码（as-of join，防标签泄漏）
# labels: (entity_id, label_ts, y)   features: (entity_id, event_ts, value)
for row in labels:
    cand = features[entity_id == row.entity_id
                    and event_ts <= row.label_ts]   # 严格 ≤ 标签时刻
    row.feature = cand.sort_by(event_ts).last()      # 取当时最新的一条
# 引擎实现：Spark 按 entity_id 分区 + event_ts 排序做 merge as-of join

3. 模型服务：特征拉取 + 推理的延迟预算切分

原理：一次线上预测的 p99 预算（如 30ms）要在「取特征 + 前处理 + 模型前向 + 后处理」间分配。经验上取特征常占一半以上延迟——200 个特征散在多个实体、多个 Store。优化点：批量 pipeline 取数、把同请求的特征并发拉取、对高频实体做本地 L1 缓存。

4. A/B 实验平台：让「模型上线」变成可度量的因果实验

原理：新模型不能因线下 AUC 涨就上线——线下指标和业务指标（下单率、GMV）常背离。要用随机分流的在线实验建立因果：一致性哈希把用户稳定分到 control/treatment，跑够样本量后比较业务指标的统计显著性，同时盯 guardrail 指标（延迟、错误率、退款率）防止「主指标涨、副作用炸」。

# 稳定分桶：同一 user 永远落同一组（可复现、无闪烁）
def bucket(user_id, exp_key, treat_ratio=0.5):
    h = hash_u64(f"{exp_key}:{user_id}")   # 加实验名做盐，各实验独立正交
    return "treatment" if (h % 10000) / 10000 < treat_ratio else "control"

扩展与优化

• 特征新鲜度分级：秒级走 Flink 流、分钟级走微批、天级走 Spark T+1，按业务价值分配算力，别一刀切实时（成本爆炸）。
• 特征监控与漂移检测：对每个特征持续统计分布，线上分布 vs 训练分布漂移了就告警——skew 常是「无声」发生的。
• 成本治理：在线 Store 内存最贵，用 protobuf/量化压缩、TTL 淘汰冷实体、只物化真被模型引用的特征（靠血缘剪枝）。
• embedding 特征：向量类特征（用户/物品 embedding）单独走向量存储，与标量特征分层管理。

常见陷阱 + 面试问题

• 为什么需要双 Store？能不能用一个引擎同时服务训练与推理？各自瓶颈在哪？
• 解释 training-serving skew 的三种成因，各给一个修法。
• 一次预测要取 200 个特征、p99 < 10ms，你怎么切分延迟预算、怎么优化取数？
• 双边市场（外卖）里普通用户随机 A/B 为什么会失效？换什么实验设计？
• 热实体（顶流门店）特征 QPS 单点过高，怎么扛？（联想 Day 2 缓存热 key）

深入资源

• DoorDash：Building a Gigascale ML Feature Store with Redis——在线 Store 选型与压缩实战。
• Uber：Michelangelo Palette Meta Store Journey——特征注册、复用与元数据。
• Airbnb：Chronon: Airbnb's ML Feature Platform (Open Source)——一份定义生成批/流管道 + PIT 回溯。
• Google：Rules of Machine Learning（Zinkevich）——training-serving skew 的权威论述。
• 《Designing Data-Intensive Applications》（Kleppmann）：批处理/流处理与派生数据章节，是理解双 Store 物化的基础。

深入思考（点击展开答案）