3. Feature Store核心架构

在上一节中，我们已经理解了为什么金融场景需要Feature Store。本节进入架构层面，拆解Feature Store的五大核心组件：离线存储、在线存储、特征注册、特征服务、元数据管理。这五个组件不是简单的模块堆叠，而是一条从原始数据到模型推理的完整链路。理解它们各自的职责与协作方式，是后续动手搭建项目的基础。

一、核心原理：双存储分离与统一注册

Feature Store最核心的设计思想是“一次定义，双端复用”。同一份特征定义，既要能支撑离线训练时的大规模历史回溯，又要能支撑在线推理时的毫秒级读取。这就引出了离线存储与在线存储的分离设计。

离线存储面向批量场景，通常基于数据湖或数仓（如Hive、Iceberg、Delta Lake、Parquet文件），存储全量历史特征值，支持时间旅行查询（Point-in-Time Correctness），保证训练数据不泄露未来信息。在线存储面向实时场景，通常基于Redis、HBase、Cassandra等低延迟KV存储，只保留每个实体最新的特征值，要求P99延迟在10ms以内。

两者之间通过特征注册建立映射：注册时声明特征的数据类型、实体主键、时间戳字段、数据源、TTL等元信息，系统据此自动生成离线表与在线表的同步管道。特征服务则是统一读取入口，训练时走离线路径，推理时走在线路径，对调用方屏蔽底层差异。元数据管理贯穿始终，记录特征版本、血缘、统计指标、访问权限，是可发现、可治理、可审计的关键。

二、方法流程：从特征定义到线上服务的完整链路

五大组件的协作遵循一条清晰的流水线，下面以“用户近30天交易金额均值”这个金融特征为例，说明完整流程：

1. 特征注册：在注册中心声明特征名 user_txn_amt_avg_30d，实体为 user_id，时间戳字段为 event_time，数据类型为 double，数据源指向交易明细表，TTL设为30天。
2. 离线物化：调度系统按天/小时运行Spark或Flink作业，从数据源计算历史特征值，写入离线存储的Parquet分区表，同时记录每行对应的event_time。
3. 在线同步：物化完成后，同步任务将每个user_id的最新特征值推送到在线存储Redis，Key设计为fs:user_txn_amt_avg_30d:{user_id}。
4. 特征服务：训练时通过get_historical_features()做时间点对齐查询；推理时通过get_online_features()批量读取Redis。
5. 元数据管理：全程记录特征版本、物化时间、数据质量指标（空值率、均值漂移）、上下游血缘，供监控与审计使用。

# 特征注册示例（伪代码）
feature_registry.register(
    name="user_txn_amt_avg_30d",
    entity="user_id",
    dtype="double",
    source="ods.txn_detail",
    timestamp_field="event_time",
    ttl_days=30,
    online_store="redis",
    offline_store="iceberg"
)

# 在线读取示例
features = fs.get_online_features(
    features=["user_txn_amt_avg_30d", "user_txn_cnt_7d"],
    entity_rows=[{"user_id": "U10086"}]
)
# 返回: {"user_txn_amt_avg_30d": [3250.75], "user_txn_cnt_7d": [12]}

三、金融场景案例：反欺诈实时特征链路

在信用卡反欺诈场景中，模型需要在用户刷卡瞬间判断是否拦截。此时在线存储必须提供该用户近1小时交易笔数、近24小时异地交易次数、当前设备指纹等特征。离线存储则保存过去两年的全量行为，用于训练XGBoost模型。特征注册确保训练与推理使用完全一致的特征口径，避免“训练用A公式、推理用B公式”导致的线上线下不一致。元数据管理记录每次特征变更，当监管要求解释某笔拦截决策时，可以追溯到当时使用的特征版本与计算逻辑。

四、常见误区与复盘