3、实时特征流架构总览：数据源 → 特征计算 → 特征存储 → 在线服务
实时特征流是支撑毫秒级在线推理的核心数据管道。本章从全局视角拆解标准四层架构：数据源（Kafka）→ 特征计算（Flink）→ 特征存储 → 在线服务。每一层承担明确的职责，层间通过序列化协议与一致性语义衔接。理解这个架构是后续缺失回放验证的前提。
3.1 四层架构总览
实时特征流将原始事件转化为可供模型直接读取的特征向量。下图展示了标准分层结构及各层核心组件：
3.2 各层职责与关键组件
下表汇总了每一层的核心组件、数据形态与典型延迟要求，帮助快速建立架构全景认知：
| 架构层 | 核心组件 | 数据形态 | 延迟要求 | 一致性语义 |
|---|---|---|---|---|
| 数据源层 | Kafka / Pulsar | 原始事件（JSON / Avro / Protobuf） | 秒级 | 至少一次 |
| 特征计算层 | Flink / Spark Streaming | 特征向量（Key-Value 结构） | 毫秒～秒级 | 精确一次（端到端） |
| 特征存储层 | Redis / HBase / TiKV | 特征快照（Key: entity_id, Value: feature_map） | 微秒～毫秒级 | 最终一致性 / 读己写 |
| 在线服务层 | 模型推理服务 / 特征 SDK | 模型输入 Tensor / Feature Vector | 毫秒级（P99 < 10ms） | 读时校验 |
3.3 数据流转与序列化契约
数据在层间流转时，必须遵守统一的序列化契约。以 Kafka → Flink → Redis 为例，典型的数据流如下：
- Kafka 生产：业务事件以 Avro 格式写入 Kafka topic，schema 注册在 Schema Registry 中。
- Flink 消费：Flink 作业通过 Kafka Consumer 反序列化事件，执行窗口聚合、多流关联等计算逻辑。
- Flink 输出：计算后的特征向量以 Protobuf 格式写入 Redis，key 为实体 ID，value 为特征 Map。
- 在线服务读取：推理服务通过 Redis 客户端按 key 读取特征，反序列化为模型输入。
序列化契约要点：
- Kafka 与 Flink 之间使用 Avro + Schema Registry，保证 schema 兼容性。
- Flink 与 Redis 之间使用 Protobuf，字段编号固定，避免字段名膨胀。
- 在线服务层必须兼容历史 schema 版本，支持向后读取。
3.4 架构中的关键时间窗口
实时特征流对时间语义高度敏感。下图展示了从事件产生到特征生效的完整时间线，以及各阶段可能出现的延迟与缺失窗口：
3.5 架构设计对缺失回放的影响
不同的架构选型直接影响缺失回放验证的策略与复杂度。以下对比三种常见部署模式：
| 部署模式 | 特征存储 | 计算层状态 | 回放验证难度 | 典型场景 |
|---|---|---|---|---|
| 无状态计算 + 外部存储 | Redis / HBase | 无状态，依赖外部存储 | 中等 | 实时推荐、广告 CTR |
| 有状态计算 + 内部状态 | Flink State + 外部存储 | 有状态，ValueState / MapState | 较高 | 实时风控、交易监控 |
| Lambda 架构 | 批 + 流双链路写入 | 流层有状态，批层无状态 | 高 | 实时数仓、特征回溯 |
架构选型避坑提示：
- 避免将 Flink 内部状态作为唯一特征来源——状态无法被在线服务直接读取，缺失后难以回放。
- 外部存储必须支持 TTL 过期 与 批量写入，否则回放时容易造成存储压力。
- Lambda 架构中流批两套链路必须对齐特征 schema，否则回放验证时会出现特征不一致。
3.6 本章小结
实时特征流架构以 Kafka → Flink → 特征存储 → 在线服务为主线，每一层都有明确的延迟与一致性要求。缺失回放验证的核心在于：
- 确认特征是否在预期时间内写入存储层。
- 确认写入的特征值与计算层输出一致。
- 确认在线服务能正确读取并使用这些特征。