Feature Store 架构解析：在线存储、离线存储、特征注册表、特征服务层

Feature Store 的核心架构由四个紧密协作的组件构成：离线存储、在线存储、特征注册表和特征服务层。理解这四者的职责与交互方式，是进行巡检和故障定位的基础。

架构总览：四层职责与数据流

下图展示了 Feature Store 的典型分层架构，以及特征数据从生产到消费的完整生命周期。

1. 离线存储 (Offline Store)

离线存储负责保存全量历史特征数据，主要用于模型训练、批量评估和特征回溯。它是 Feature Store 的“数据湖”，通常基于分布式存储或数据仓库构建。

2. 在线存储 (Online Store)

在线存储为实时推理提供毫秒级特征访问。它只保存最新的特征快照，通常使用键值数据库或内存缓存，以支持高并发、低延迟的读取。

3. 特征注册表 (Feature Registry)

特征注册表是 Feature Store 的元数据中心，存储所有特征的“定义”而非“值”。它记录了特征名称、类型、来源、版本、血缘关系以及 Serving 配置。

• 核心实体： Feature Group (特征组)、Feature View (特征视图)、Feature Version (特征版本)。
• 关键元数据： 特征名称、数据类型 (int/float/string)、维度、描述、创建时间、上游数据源、下游模型列表。
• 存储方案： 关系型数据库 (PostgreSQL/MySQL) 或专门的元数据服务 (如 Hive Metastore)。
• 巡检重点： 元数据完整性 (是否存在孤儿特征)、版本冲突、血缘链路断裂。

# 伪代码：查询未被引用的特征
SELECT f.feature_name
FROM feature_registry f
LEFT JOIN model_feature_mapping m ON f.feature_id = m.feature_id
WHERE m.model_id IS NULL;

4. 特征服务层 (Serving Layer)

特征服务层是 Feature Store 的统一入口，对外提供特征检索 API。它屏蔽了底层离线/在线存储的差异，根据请求上下文自动路由到正确的存储后端。

组件交互流程：一次完整的特征服务请求

下图展示了一个在线推理请求在 Feature Store 内部的完整流转路径。

巡检核心指标速查表

# 伪代码：对比离线与在线特征
offline_value = spark.sql("SELECT feature_a FROM offline_store WHERE entity_id='123'")
online_value = redis_client.get("feature_a:123")
if offline_value != online_value:
    alert("数据不一致: entity_id=123, feature_a")