3. Feature Store 核心架构：在线存储与离线存储、特征注册中心、特征服务层、元数据管理
金融 Feature Store 的架构设计需要同时满足离线批处理（模型训练）与在线实时推理（风控、交易）两种截然不同的性能与一致性要求。本章深入剖析四大核心组件：离线存储、在线存储、特征注册中心与特征服务层，以及贯穿全流程的元数据管理。
3.1 离线存储与在线存储
离线存储与在线存储承担着不同的数据生命周期角色。下表对比了二者的核心差异：
| 维度 | 离线存储 | 在线存储 |
|---|---|---|
| 典型技术 | Apache Hive / Iceberg / Delta Lake / Parquet on HDFS / S3 | Redis / Aerospike / Cassandra / TiKV |
| 数据格式 | 列式存储（Parquet / ORC），高压缩比 | Key-Value 结构，支持 TTL 与过期策略 |
| 写入模式 | 批量写入（Spark / Flink 批作业），不可变快照 | 实时 Upsert / 流式写入（Kafka → 在线表） |
| 查询延迟 | 秒级到分钟级（全表扫描 / 分区裁剪） | 毫秒级（< 10ms P99） |
| 主要用途 | 训练数据集生成、历史回溯、特征回溯验证 | 实时推理、线上特征获取、低延迟决策 |
| 数据一致性 | 最终一致性，支持时间旅行（Time Travel） | 强一致性或最终一致性（取决于存储选型） |
| 金融合规要求 | 审计日志、数据保留策略、不可变历史 | 数据加密、访问控制、实时审计 |
离线存储与在线存储之间的数据同步通常通过批流一体管道实现：离线作业每日生成特征快照写入离线表；流式作业（如 Flink）实时计算最新特征值并 Upsert 到在线存储。Feature Store 需要保证同一特征在离线与在线两侧的计算逻辑完全一致，避免训练/推理偏差。
3.2 特征注册中心（Feature Registry）
特征注册中心是 Feature Store 的“大脑”，负责管理所有特征的定义、版本、血缘、权限与生命周期。它确保数据科学家、工程师与业务方对同一特征有统一理解。
特征注册中心的核心实体包括：
- Feature Group（特征组）：逻辑上相关的特征集合，例如“用户基础画像特征组”包含年龄、性别、注册时长等特征。
- Feature（特征）：单个特征的定义，包括名称、类型、描述、来源表、计算逻辑（SQL / Python UDF）、版本号。
- Feature View（特征视图）：面向特定模型或场景的特征组合，是训练/推理时实际使用的特征集合。
- Transformation（转换逻辑）：特征从原始数据到最终值的计算过程，支持窗口聚合、时间差计算、编码映射等。
注册中心通常提供 REST API 或 gRPC 接口，供上下游系统进行特征的注册、检索、版本对比与废弃。金融场景下，注册中心还需记录特征的数据敏感等级（如 PII、财务数据）与审批流状态。
3.3 特征服务层（Feature Serving Layer）
特征服务层是 Feature Store 面向在线推理的高性能网关。它屏蔽底层存储细节，提供统一的特征获取接口，并承担缓存、降级、限流等治理职责。
特征服务层的核心能力：
- 统一 API：提供
GetOnlineFeatures(entity_keys, feature_refs)接口，支持单实体与批量实体查询。 - 多级缓存：本地缓存（Caffeine / Guava）→ 分布式缓存（Redis）→ 在线存储，逐级回退。
- 特征路由：根据特征元数据自动路由到对应的在线存储或实时计算引擎。
- 降级与熔断：当在线存储故障时，自动降级到离线快照或默认值，保障业务连续性。
- 监控与可观测性：记录每次特征获取的延迟、命中率、错误率，输出 Prometheus 指标。
// 特征服务层核心接口示例（伪代码）
public interface FeatureServingService {
// 获取单个实体的多个特征
Map<String, Object> getOnlineFeatures(
String entityId,
List<String> featureRefs,
RequestContext context
);
// 批量获取多个实体的特征
Map<String, Map<String, Object>> getOnlineFeaturesBatch(
List<String> entityIds,
List<String> featureRefs,
RequestContext context
);
}3.4 元数据管理
元数据管理是 Feature Store 的“神经系统”，贯穿离线存储、在线存储、注册中心与服务层。它负责记录数据从哪里来、如何计算、存储在哪里、被谁使用。
元数据管理的关键维度：
| 元数据类型 | 内容示例 | 金融场景要求 |
|---|---|---|
| 技术元数据 | 存储路径、分区信息、数据格式、Schema 版本 | 支持数据生命周期管理（TTL、归档策略） |
| 业务元数据 | 特征业务含义、所属部门、合规标签、审批人 | 必须记录 PII/PCI 标识，支持数据脱敏策略 |
| 血缘元数据 | 特征 ← 转换逻辑 ← 原始表 ← 上游系统 | 支持全链路血缘追踪，满足监管审计要求 |
| 运行元数据 | 特征计算时间、数据新鲜度、在线存储命中率 | 实时监控数据延迟，触发告警与自动修复 |
元数据管理通常基于 OpenMetadata、Apache Atlas 或自研元数据服务实现。在金融 Feature Store 中，元数据服务需要与数据治理平台、模型管理平台深度集成，形成从数据源到模型推理的完整闭环。
3.5 核心架构总览
下图展示了 Feature Store 四大核心组件之间的协作关系：
上图展示了核心组件之间的数据流与元数据流：特征注册中心向离线与在线存储推送特征定义；特征服务层从两侧拉取特征值，并向上层模型提供统一接口；元数据管理贯穿所有组件，记录全链路信息。
3.6 架构设计要点总结
金融 Feature Store 架构设计需重点关注以下要点：
- 一致性保障：离线与在线特征计算逻辑必须一致，建议通过注册中心统一管理转换代码，并自动生成离线批处理与在线流处理两套执行计划。
- 高可用设计：在线存储与特征服务层必须多机房部署，支持跨机房故障切换；缓存层需设置合理的过期时间与降级策略。
- 数据新鲜度：金融场景对特征新鲜度要求极高（如实时交易特征延迟需 < 1s），需监控在线存储的写入延迟，并设置延迟告警阈值。
- 审计与合规：所有特征的定义变更、数据访问、模型使用记录必须留存审计日志，元数据管理需支持全链路血缘追溯。
- 成本控制：离线存储采用列式压缩格式与分区裁剪策略降低存储成本；在线存储合理设置 TTL 与淘汰策略，避免冷数据占用热存储资源。