核心要点
能定义特征商店统一离线与在线特征
理解 training-serving skew 问题
知道 point-in-time correct join 概念
能举例 Feast/Tecton 等方案
简要回答
特征商店集中定义、计算、存储并 serving 特征，保证训练与在线推理用同一套特征逻辑，避免 training-serving skew。
标准回答
一、先给出结论和背景
- 特征商店（Feature Store）：组织内特征的「单一数据源」——统一定义、版本化、供离线训练与在线推理复用。
- 解决的核心问题：1. Training-Serving Skew：离线用 SQL 算特征，在线用 Java 重写，逻辑不一致导致线上性能暴跌
- 特征重复建设：各团队重复写相同 user_7d_click 特征
- 点-in-time 正确性：训练只能用「预测时刻之前」的特征，防标签泄漏
二、拆开关键步骤和判断点
- 架构组件：- 离线存储：Hive/S3，批量回溯历史特征
- 在线存储：Redis/DynamoDB 低延迟 lookup
- 特征定义层：Python/SQL 声明式 API，一处定义两处 materialize
- 工作流：1. 定义特征 + 转换逻辑
- 离线 backfill 生成训练集（point-in-time join）
- 流/批更新在线 store
- 推理时 low-latency 读取相同特征
三、补上落地边界和取舍
面试里要把 特征商店 放到训练到上线的链路里说：离线指标只是第一步，还要补特征一致性、版本管理、灰度实验、监控漂移和回滚方案。这样能证明你理解的是生产系统，而不是只会背流程图。
回答思路
【定义】用一句话说清「什么是特征商店？在 MLOps 中为何重要」
【原理】讲清关键机制或步骤（2～3 点）
【例子】举一个真实项目、论文或产品中的例子
【对比】与易混淆概念或替代方案比较（如有）
【收尾】总结适用场景 + 一个局限或风险
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：把特征商店当成数据库；不说 training-serving skew；忽视 point-in-time 正确性。
追问
追问 1：什么是 point-in-time join？
训练样本 (user_id, event_time) 只 join event_time 之前可用的特征快照，模拟推理时信息集，防止用未来数据训练（泄漏）。
追问 2：没有特征商店的小团队怎么办？
共享特征库（Python package）+ 训练/推理共用 transform 函数 + 集成测试对比输出 hash。业务复杂后再上 Feast 等。
追问 3：实时特征 vs 批特征如何选型？
实时：风控、推荐需秒级更新（Flink → online store）。批特征：日活统计等 T+1 可接受。成本与复杂度随实时性上升。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习