10. 面试题：特征平台高频考点
一句话理解：特征平台的面试题集中在四个支点——偏斜与泄漏的根因、point-in-time join 的语义、离线/在线存储的分工、以及批流架构的取舍，把 Mini Demo 的六个场景讲清楚，百分之八十的题都能接住。
初级
Q1. 什么是训练/服务偏斜（training-serving skew）？举两个来源。
答：模型训练时看到的特征分布与服务时实际输入的分布不一致。两大来源：
- 双实现：离线 SQL 与在线服务代码是两份实现，窗口/空值/时区口径悄悄漂移；
- 新鲜度：在线特征更新滞后，服务时拿到的是陈旧值，而训练时用的是完整历史计算的正确值。 防控：特征定义中心化 + 数据同源（单管道/物化）+ 上线前偏斜检查（配对比对 + PSI）。
Q2. 什么是数据泄漏（leakage）？特征平台如何系统性防止它？
答：训练样本使用了标签时刻之后才存在的信息（未来函数）。平台防止手段：训练集只能经 PIT join 生成——对每个实体按 event_timestamp <= query_timestamp 取最新值，引擎层面禁止不带时间的 join。
Q3. 离线存储和在线存储的职责分别是什么？为什么必须分开？
答：离线存全量历史（列式、带 event_timestamp、append-only），服务训练集构建与回填；在线存最新快照（KV、毫秒点查、TTL），服务推理。二者访问模式完全不同：前者扫历史、后者点查最新，用一套存储必然两头不讨好。
Q4. event_timestamp 和 ingestion time 有什么区别？为什么强调用前者？
答：event_timestamp 是业务发生时刻，ingestion time 是写入系统的时刻。迟到数据二者会差很久。PIT join 和 TTL 必须基于 event_timestamp，否则重跑/迟到会导致同一历史时刻取到不同的值，训练不可复现。
Q5. 特征平台的 Entity 和 Feature View 是什么？
答：Entity 是主键模型（如 user_id），是特征表间 join 与在线点查的键；Feature View 是一组特征的逻辑定义，绑定实体、数据源、schema 和时间语义，是注册、复用与治理的最小单元。
中级
Q6. 描述 point-in-time join 的算法语义。工程上怎么实现高效？
答：对每个 (entity, query_timestamp)，取该实体 event_timestamp ≤ query_timestamp 的最新记录；超 max_age 置空。高效实现三招：谓词下推（时间范围裁剪）、按实体分区 + 窗口函数取首行（如 ROW_NUMBER() OVER (PARTITION BY entity ORDER BY event_timestamp DESC)）、一次扫描合并多个特征视图。
Q7. Lambda 和 Kappa 架构在特征生产上各有什么优缺点？
答：Lambda = 批层重算全量历史 + 速度层实时写在线：可靠、易回填，但两套代码是偏斜来源。Kappa = 只有流式单管道，历史靠 replay 重建：语义统一，但流作业运维与状态管理重、重放成本高。产业趋势是“一份定义、引擎自动批流一体”（如托管 Feature View、Tecton RIFT）。
Q8. 一个特征的 TTL 应该如何决定？过期后服务该怎么表现？
答：TTL 由业务时效决定：实时行为分钟级、短期画像 1-2 倍计算周期、长期画像无 TTL。过期后应返回 null/默认值并打 STALE 标记，由推理侧决定降级——绝不能静默返回陈旧值。
Q9. 如何检测两条计算链路是否发生了偏斜？给出一个可落地的方案。
答：抽样 N 个实体（≥1000），对每个实体同时取“离线 PIT 重算值”与“在线点查值”，做配对比对（绝对/相对容差）；同时计算两分布的 PSI（<0.1 正常，>0.25 显著漂移）。任一失败即阻断上线。Mini Demo 的 detect_skew 与 psi 即该方案的最小实现。
Q10. 迟到事件怎么处理？离线表为什么不能原地更新？
答：迟到事件按 event_timestamp 归位写入（append-only）；离线表原地更新会破坏历史可复原性——任意历史时刻的状态必须由不可变日志推导。修正历史靠“新记录覆盖语义”（同时间戳更新版本）或对受影响分区重算回填；在线侧由下次物化/流式更新收敛。
高级
Q11. 设计一个支撑 10 万 QPS、P99 < 10ms 特征读取的系统。
答要点：
- 在线层 Redis Cluster（一致性哈希分片、同机房部署、连接池），单请求批量多 key（HMGET/MGET pipeline），进程内短 TTL LRU 兜底；
- 写入层按 key 打散热点，流式特征 Flink 增量写，批特征物化限流错峰；
- 降级链：miss/TTL → 默认值 + STALE 标记 → 兜底模型；全链路压测验证 P99。
Q12. 为什么说“流式 SQL 物化视图可以取代特征平台”？你同意吗？
答：该路线（RisingWave 等）把窗口聚合定义为流式物化视图：历史=视图日志、在线=视图当前值，用通用流式基础设施替代专用系统，对已有强流式团队的组织成本更低。但它不解决特征治理（registry、血缘、复用发现）与 PIT 训练集的产品化。合理结论：实时计算层可以被取代，治理层仍然需要；多数团队二者结合。
Q13. 特征平台与向量数据库是什么关系？embedding 作为特征带来哪些新工程问题？
答：LLM 时代 embedding 成为一等特征，在线侧需要 ANN 检索（向量库与在线 KV 分工或融合，Hopsworks/Tecton 均内置支持）。新工程问题：向量体积大（Redis 成本爆炸 → 独立向量索引/降维）、更新频率高（源数据一变全量重嵌入 → 增量更新与版本管理）、检索质量需监控（召回率/分布漂移与标量特征不同）。
Q14. Databricks 收购 Tecton（2025-08）对特征平台赛道意味着什么？
答：两点：其一，验证了“实时特征是 AI Agent 的关键基础设施”——收购官方理由就是为 Agent Bricks 供给实时上下文；其二，赛道进入整合期，中立商业选项收缩，未被云绑定的团队更倾向 Feast 开源或流式 SQL 自建，治理层成为各家竞争焦点（Unity Catalog 统一血缘/权限是 Databricks 的打法）。
Q15. 特征平台如何支持训练的可复现性审计（“半年前这次训练用了什么数据”）？
答：三层记录：特征定义版本（registry 版本号）、数据快照（离线表按事件时间分区/快照 ID）、训练集指纹（entity_df + 查询时刻集合的哈希）。三者写入实验追踪（如 MLflow run tags），需要时可按同一三元组精确重建训练集。append-only 离线存储 + 定义版本化是前提。
本章小结
- 初级考概念（偏斜/泄漏/双存储分工），中级考机制（PIT join 语义、批流取舍、TTL 设计），高级考架构判断（高并发设计、赛道趋势、可复现审计）。
- 答题的共同骨架：先给定义与根因，再给机制，最后给工程闭环（监控/门禁/降级）。