2. 核心概念与术语
在构建批流一体特征平台之前，必须统一团队对核心概念的认知。本章将逐一拆解特征、特征组、特征视图、特征存储、在线/离线特征以及特征血缘这六个关键术语，并说明它们之间的层级关系与协作方式。
学习提示： 这六个概念构成了特征平台的“元模型”。后续所有架构设计、API 定义、存储选型都建立在此基础之上。建议对照实际业务场景（如用户画像、商品推荐）来理解每个术语。
2.1 特征（Feature）
特征是平台中最小的数据原子单元，代表一个实体的某种可度量属性。在机器学习场景下，特征通常是模型输入的数值化或类别化表示。
| 属性 | 说明 | 示例 |
|---|---|---|
| 特征名称 | 全局唯一的标识符，通常采用 snake_case 命名 | user_30d_purchase_amount |
| 特征类型 | 数据类型：int64、float64、string、bool、list、map | float64 |
| 实体 ID | 该特征所属的主体标识，如 user_id、item_id | user_id |
| 时间戳 | 特征值生成或采集的时间点 | 2025-03-15 10:30:00 |
| 值域/枚举 | 可选约束，用于校验和异常检测 | [0, 100000] |
关键原则： 特征必须可回溯、可复现。同一个实体 ID + 特征名称 + 时间戳，在任何时间点查询都应得到相同的结果（或可解释的差异）。
2.2 特征组（Feature Group）
特征组是特征的逻辑集合，通常对应一个业务主题或数据源。例如，“用户基础信息”特征组包含性别、年龄、注册渠道等特征；“用户近 7 天行为”特征组包含点击次数、加购次数、下单金额等特征。
- 分组依据： 数据源表、业务域、更新频率、存储位置。
- 组内特征： 共享相同的实体 ID 和主键粒度。
- 版本管理： 特征组整体支持版本化，便于回滚和对比。
- 元数据： 每个特征组包含描述、负责人、标签、SLA 等元信息。
# 特征组定义示例（YAML 格式）
feature_group:
name: "user_behavior_7d"
entity: "user_id"
description: "用户近7天行为聚合特征"
features:
- name: "click_cnt_7d"
type: "int64"
- name: "cart_cnt_7d"
type: "int64"
- name: "order_amt_7d"
type: "float64"
tags: ["behavior", "online"]
owner: "team_recommendation"
2.3 特征视图（Feature View）
特征视图是面向模型训练和在线推理的“特征组装层”。它从一个或多个特征组中选取特征，并定义时间窗口、回溯逻辑、变换函数等。特征视图是特征平台对外暴露的核心接口。
| 维度 | 特征组 | 特征视图 |
|---|---|---|
| 粒度 | 按数据源/业务域组织 | 按模型/场景需求组织 |
| 时间逻辑 | 通常不包含时间窗口 | 必须定义时间回溯窗口 |
| 变换 | 原始特征 | 可包含聚合、归一化、分桶 |
| 使用方 | 特征工程师、数据开发 | 算法工程师、在线服务 |
常见误区： 不要把特征视图和特征组混为一谈。特征组是“有什么数据”，特征视图是“模型需要什么数据”。一个特征视图可以跨多个特征组进行 Join 和窗口计算。
2.4 特征存储（Feature Store）
特征存储是特征平台的数据底座，通常分为离线存储和在线存储两层。离线存储用于批量写入和历史回溯，在线存储用于毫秒级实时读取。
存储选型建议： 离线存储优先选择支持 ACID 和 Time Travel 的湖格式（如 Iceberg）；在线存储根据 QPS 和延迟要求选择 Redis（缓存型）或 HBase（大容量型）。批流一体平台通常还会引入“统一存储抽象层”来屏蔽底层差异。
2.5 在线特征与离线特征
在线特征与离线特征并非两种不同的特征，而是同一特征在不同时间窗口和不同存储介质中的表现形式。这是批流一体特征平台的核心设计理念。
| 对比维度 | 离线特征 | 在线特征 |
|---|---|---|
| 计算时间 | T+1 或小时级批量计算 | 实时流计算或近实时微批 |
| 数据新鲜度 | 截止到昨天/上一小时 | 截止到当前秒级 |
| 存储位置 | 离线存储（HDFS/湖） | 在线存储（KV 数据库） |
| 访问模式 | 批量扫描、全量导出 | 单点查询、小批量点查 |
| 典型用途 | 模型训练、特征回溯、离线评估 | 实时推理、AB 实验、在线监控 |
| 一致性要求 | 最终一致，允许延迟 | 强一致或最终一致（视场景） |
批流一体核心： 同一个特征（如
user_30d_purchase_amount）在离线训练时使用 T-1 的批量计算结果，在在线推理时使用实时流计算结果。平台保证两者计算逻辑完全一致，仅时间窗口不同。
2.6 特征血缘（Feature Lineage）
特征血缘记录了特征从原始数据源到最终特征值的完整加工链路。它是特征平台的可观测性和治理基础。
血缘的价值：
- 问题排查： 特征值异常时，快速定位是数据源问题、加工逻辑问题还是存储同步问题。
- 影响分析： 修改某个原始字段时，自动通知所有下游特征和模型。
- 合规审计： 追溯每个特征的数据来源和加工过程，满足监管要求。
- 成本优化： 识别重复加工的特征，合并计算链路。
2.7 概念关系总结
六个核心概念之间的层级关系可以用以下结构表示：
原始数据源（Kafka / MySQL / HDFS）
│
▼
特征组（Feature Group）—— 按业务主题组织特征
│
├── 特征（Feature）—— 最小原子单元
│
▼
特征视图（Feature View）—— 按模型需求组装特征 + 定义时间窗口
│
├── 离线特征（Offline Feature）—— 批量计算，存入离线存储
├── 在线特征（Online Feature）—— 实时计算，存入在线存储
│
▼
特征存储（Feature Store）—— 统一读写接口
│
▼
特征消费（训练 / 推理 / 回溯）
│
▼
特征血缘（Lineage）—— 贯穿全链路的元数据追踪
实践建议： 在搭建特征平台初期，先定义好这六个概念的元数据模型和 API 规范。后续所有功能（数据接入、特征加工、存储同步、服务发布）都围绕这个元模型展开，避免出现“特征孤岛”和“语义混乱”。