2. 特征存储系统：离线特征仓库的架构设计、Hive/ClickHouse/Feast 的角色对比

离线特征仓库是特征回放验证的“数据底座”。回放流程需要从历史时间点精确读取特征快照，这就要求存储系统具备时间旅行、批量扫描和低延迟点查三种能力。单一引擎很难同时满足三者，因此业界通常采用分层混合架构：Hive 负责全量历史存储，ClickHouse 负责高性能分析查询，Feast 负责特征抽象与时间点对齐。

2.1 离线特征仓库的分层架构

下图展示了离线特征仓库的典型三层结构，以及回放验证流程中数据在各层之间的流转路径。

2.2 Hive / ClickHouse / Feast 角色对比

三种系统在离线特征仓库中承担截然不同的职责，不能相互替代。下表从关键维度进行对比：

2.3 各系统的核心职责与选型建议

2.3.1 Hive：离线特征的事实源

• 职责：存储所有原始特征日志，按日期/小时分区，保留完整历史。
• 优势：存储成本低，支持 SQL 全量扫描，适合大规模回溯。
• 局限：查询延迟高，不适合交互式探查；不支持主键点查。
• 回放用法：Feast 通过 offline_store 指向 Hive 表，在回放时执行 SELECT * FROM feature_table WHERE dt = '2024-12-01' 获取快照。

2.3.2 ClickHouse：分析加速与探查引擎

• 职责：对 Hive 中的原始特征进行预聚合、构建宽表，提供秒级分析查询。
• 优势：列式存储 + 稀疏索引，聚合查询比 Hive 快 10~100 倍。
• 局限：不擅长处理频繁的更新删除；历史版本管理需要额外设计。
• 回放用法：用于回放前的数据质量探查——统计特征空值率、分布偏移、异常值等。

2.3.3 Feast：特征抽象与时间点对齐引擎

• 职责：定义特征元数据（Feature View），管理离线/在线存储的映射关系，执行 Point-in-Time Join。
• 优势：统一特征 API，自动处理时间戳对齐，避免特征穿越。
• 局限：不存储实际特征数据，依赖底层存储（Hive / BigQuery / Redshift）。
• 回放用法：用户提供标签数据集（含 entity_id 和 timestamp），Feast 自动从离线存储中拉取对应时刻的特征快照，拼接成训练样本。

2.4 离线特征仓库的典型部署拓扑

下图展示了 Hive、ClickHouse、Feast 三者在生产环境中的协作关系：

2.5 离线特征仓库的选型决策树

根据团队规模和业务场景，推荐以下选型路径：

1. 小团队 / 快速验证阶段：仅用 Hive + Feast，跳过 ClickHouse。Feast 直接读取 Hive 分区表，回放速度可接受（分钟级）。
2. 中等规模 / 需要交互式探查：引入 ClickHouse 作为分析加速层。Hive 保持全量，ClickHouse 存储最近 7 天宽表用于探查。
3. 大规模 / 高频率回放：Hive + ClickHouse + Feast 全量部署。ClickHouse 承担 80% 的探查和抽样查询，Hive 承担全量回溯，Feast 统一特征管理。

2.6 关键配置示例（Feast 离线存储指向 Hive）

# feature_store.yaml
project: my_feature_repo
registry: gs://my-feature-repo/registry.db
provider: gcp

offline_store:
  type: bigquery  # 或 hive / redshift / snowflake
  dataset: my_dataset
  project: my_gcp_project

online_store:
  type: redis
  connection_string: redis://localhost:6379

# 定义特征视图
feature_views:
  - name: user_features
    entities:
      - user_id
    features:
      - name: age
        type: INT64
      - name: membership_days
        type: INT64
    ttl: 0  # 离线特征不过期
    batch_source:
      type: bigquery
      table_ref: my_project.my_dataset.user_features
      timestamp_field: event_timestamp
      created_timestamp_column: created_timestamp