4、特征存储系统设计：特征仓库（Feature Store）的概念、离线特征存储（Hive/Parquet）、在线特征存储（Redis/MySQL）、特征元数据管理

在金融风控的 Champion Challenger 回放体系中，特征存储（Feature Store）是连接离线开发与在线推理的核心基础设施。它解决了特征重复开发、训练与上线不一致、以及在线服务延迟高等痛点。一个设计良好的特征存储系统，需要同时管理离线批处理特征与在线实时特征，并维护统一的元数据视图。

4.1 特征仓库（Feature Store）的核心概念

Feature Store 并非简单的存储层，而是一个包含特征定义、存储、计算、服务与治理的中间平台。其核心价值在于：

• 特征复用：避免不同团队重复开发相同的特征逻辑。
• 一致性保证：确保离线训练使用的特征与在线推理时生成的特征在逻辑上完全一致（Training-Serving Skew 消除）。
• 时间旅行（Time Travel）：支持按历史时间点回放特征，这是 Champion Challenger 回放实验的关键能力。
• 低延迟服务：为在线模型提供毫秒级的特征查询能力。

4.2 离线特征存储：Hive / Parquet

离线特征存储主要用于历史数据的批量计算、训练样本生成以及大规模回放实验。在金融风控中，离线特征通常以天或小时为粒度更新。

离线特征存储的典型设计模式：

• 特征宽表（Feature Wide Table）：将同一实体的所有特征合并为一行，以 entity_id + dt 为主键。适用于训练样本生成。
• 特征序列表（Feature Sequence Table）：按时间顺序存储每个实体的特征变化，支持滑动窗口计算。适用于时间序列回放。
• 增量更新：每日通过 Spark 作业计算新特征，写入新的分区，历史分区不可变，保证回放的可复现性。

4.3 在线特征存储：Redis / MySQL

在线特征存储服务于实时推理场景，要求毫秒级响应。在金融风控中，当用户发起申请或交易时，模型需要立即获取最新特征。

在线特征存储的键值设计规范：

# Redis Key 设计模式
# 格式：feature_store:{entity_type}:{entity_id}:{feature_group}
# 示例：用户设备指纹特征
Key: feature_store:user:U12345:device_fingerprint
Value (Hash):
  field: "device_id"       value: "DEVICE_ABC"
  field: "ip_address"      value: "192.168.1.1"
  field: "risk_score"      value: "0.85"
  TTL: 86400  # 1天过期

# MySQL 表设计示例
CREATE TABLE online_features_user (
    user_id VARCHAR(64) PRIMARY KEY,
    feature_json TEXT COMMENT '特征JSON快照',
    update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_update_time (update_time)
) ENGINE=InnoDB;

4.4 特征元数据管理

元数据管理是 Feature Store 的大脑，它记录了每个特征的“身份信息”，是 Champion Challenger 回放实验能够追溯和复现的基础。

元数据管理核心内容：

• 特征定义：特征名称、数据类型、业务含义、所属实体（用户/设备/商户）。
• 计算逻辑：特征生成的 SQL 或 Python 代码，以及版本号。
• 存储映射：离线表名与字段、在线 Redis Key 模式或 MySQL 表结构。
• 血缘关系：特征依赖的原始数据表、中间表、上游特征。
• 时间范围：特征的有效时间区间，用于回放时的时间旅行。

元数据管理在 Champion Challenger 回放中的关键作用：

1. 版本追溯：当回放 Champion 模型时，元数据记录该模型使用的特征版本号，系统自动加载对应版本的计算逻辑和存储路径。
2. 一致性校验：在回放开始前，元数据服务会校验离线特征与在线特征的定义是否一致，避免因特征漂移导致回放失败。
3. 自动化部署：新的 Challenger 模型上线时，通过元数据注册新特征，系统自动完成离线表创建和在线存储预热。