4. 特征存储与元数据管理

特征存储是金融知识图谱特征巡检的“数据底座”。选型不当会导致特征计算延迟高、存储成本失控、元数据混乱。本章从存储选型、元数据定义、版本管理三个维度，给出可落地的工程方案。

4.1 特征存储选型

金融场景下特征数据具有高维稀疏、实时写入、批量回刷、图关联查询等特点。三种主流存储引擎的适用场景差异明显：

4.2 特征元数据定义

元数据是特征的可信“身份证”。缺少元数据管理，特征会退化为“黑盒变量”，导致巡检结果不可解释、不可复现。一套完整的特征元数据应包含以下核心字段：

• 基础标识： 特征名称、特征 ID（全局唯一）、所属特征组、创建人、创建时间。
• 计算逻辑： 特征 SQL / 脚本路径、依赖上游表或特征列表、计算窗口（如 T-1 日、近 30 天滑动窗口）。
• 存储属性： 存储引擎类型（HBase / Redis / Graph）、存储 Key 模板、TTL 过期时间、序列化方式（Avro / Protobuf / JSON）。
• 质量约束： 空值率阈值、值域范围（如 [0, 1] 或枚举值列表）、分布漂移告警规则。
• 血缘关系： 上游原始字段、下游模型或报表引用列表。

4.3 特征版本管理

特征迭代过程中，同一特征名可能对应多个版本（如 v1 使用 30 天滑动平均，v2 改为 60 天指数加权）。版本管理不当会造成模型训练与线上推理特征不一致，引发“特征穿越”事故。

版本管理需覆盖以下环节：

1. 版本号规范： 采用语义化版本 major.minor.patch，major 变更代表计算逻辑不兼容，minor 代表新增参数，patch 代表 Bug 修复。
2. 版本注册： 每次特征变更前，先在元数据系统创建新版本记录，锁定旧版本不可修改。
3. 版本回刷： 新版本上线前，需对历史时间窗口执行回刷任务，生成对应版本的离线特征快照。
4. 版本对齐： 模型训练时记录使用的特征版本号，推理时强制加载同一版本，避免“训练-推理”特征漂移。

# 特征版本注册示例（Python SDK 伪代码）
feature_meta = FeatureMeta(
    name="user_30d_avg_trans_amt",
    version="2.1.0",
    compute_sql="SELECT user_id, AVG(trans_amt) FROM trans_log WHERE dt >= date_sub(now(), 30) GROUP BY user_id",
    storage_engine="HBase",
    ttl_days=90,
    quality_rules={"null_rate": 0.05, "range": [0, 1000000]}
)
register_feature(feature_meta)

4.4 特征存储与元数据架构总览

下图展示了特征存储与元数据管理的整体架构，涵盖存储层、元数据层、版本控制层与特征服务层的协作关系：

4.5 特征元数据定义示例

以下表格展示一个金融知识图谱中“企业担保圈层特征”的完整元数据定义，供实际项目参考：