特征网站 · Feature Store 设计

风格说明本篇是 设计型——从支付/交易场景 Feature Store 的定位到离线/在线一致性、Point-in-Time Join、实时 velocity 特征、合规删除。Staff Architect 面试最主要方向之一。

前置阅读../ai-fundamentals/-特征工程-选择与变换.md。其实，后续展开-模型训练-分布式与GPU调度.md； -MLOps-CI-CD-CT流水线.md；怎么说呢，-模型Serving-推理调整与缓存.md。

使用者痛点：支付反欺诈团队多次因特征不一致导致漏放率飙升 %，而 Feature Store 能降低 % 一致性偏差！如何实现，这篇文章解析主要方案...

· Feature Store 在支付 ML 中的定位

一句话定义 Feature Store = 面向 ML 的 特征数据平面 + 元数据控制平面:统一定义特征逻辑、分别物化到离线训练存储与在线低延迟存储。并提供 Point-in-Time Join 防泄露、血缘与质量监控——在支付域，它是风控/反欺诈/路由评分三类模型共享 velocity 特征的唯一可信来源。

支付域为什么「没有 FS 必然翻车」

场景	无 Feature Store	有 Feature Store
	Chargeback 预测	训练用 T+1 标签，特征误用 T+1 商户统计 → AUC 虚高 %PIT join 保证特征时间 ≤ 交易时间
		支付路由个模型各自维护「通道 N 日成功率」注册表复用。改一处全链路生效
	合规审计无法证明「某笔决策用了哪些特征、哪版数据」Lineage: 特征视图 v3. → 模型 fraud_v5 → 部署

graph TD pain --> s1 pain --> s2 pain --> s3 pain --> s4 batchCalc offlineStore trainPath[(PIT join Chargeback T+
servePath[(fraud score P99

>>> 程序关键指标:



最大峰值并发请求
响应时间
错误率日均异常比例行数: