2. 整体架构概览：实时特征生产与 Serving 链路的端到端设计
实时特征生产与模型 Serving 链路的核心目标，是将在线业务产生的原始数据在毫秒至秒级延迟内转化为模型可用的特征向量，并完成推理输出。本章从全局视角拆解这条链路的四大核心组件：数据源、特征计算、特征存储与模型推理，并给出端到端的架构图。
2.1 端到端架构总览
下图展示了从业务事件触发到推理结果返回的完整数据流。整个链路采用事件驱动 + 微批处理混合模式，兼顾实时性与系统吞吐。
2.2 核心组件详解
每个组件在链路中承担明确的职责，下表从输入/输出、延迟要求、典型技术选型三个维度进行对比。
| 组件 | 输入 | 输出 | 延迟要求 | 典型技术选型 |
|---|---|---|---|---|
| 数据源 | 业务事件、日志、DB变更 | 结构化消息流 | 秒级 | Kafka、Pulsar、Canal |
| 特征计算 | 原始消息流 + 历史特征 | 实时特征向量 | 毫秒~秒级 | Flink、Spark Streaming、Bytewax |
| 特征存储 | 特征键值对 | 低延迟特征查询 | 微秒~毫秒级 | Redis、HBase、Feast |
| 模型推理 | 特征向量 + 模型 | 推理分数 / 标签 | 毫秒级 | Triton、TorchServe、ONNX Runtime |
2.3 数据源：实时特征的起点
实时特征生产的第一步是接入业务数据。常见的数据源类型包括：
- 消息队列：Kafka / Pulsar 承载用户行为事件（点击、曝光、下单），是实时特征最核心的输入。
- 数据库 CDC：通过 Canal / Debezium 捕获 MySQL/PostgreSQL 的 Binlog 变更，用于特征属性更新。
- 日志采集：Flume / Filebeat 采集服务日志，经 ETL 后进入特征管道。
实践建议：数据源层应统一消息 schema（如 Avro / Protobuf），避免特征计算层频繁处理字段兼容性问题。
2.4 特征计算：实时聚合与特征工程
特征计算层是链路的计算密集型环节，主要完成三类操作：
- 时间窗口聚合：统计用户过去 1 小时 / 1 天的点击次数、消费金额等。
- 特征组合与交叉：将用户画像与物品属性拼接，生成交叉特征。
- 特征回溯拼接：在实时流中关联历史特征（如用户历史偏好），保证特征一致性。
下图聚焦特征计算层的内部处理流程，展示从消息消费到特征产出的关键步骤。
2.5 特征存储：在线与离线的桥梁
特征存储层需要同时满足在线低延迟查询和离线批量同步两种需求。常见的存储策略如下：
| 存储类型 | 在线场景 | 离线场景 | 一致性要求 |
|---|---|---|---|
| Redis / Memcached | 毫秒级 KV 查询 | 不支持 | 最终一致性 |
| HBase / Cassandra | 毫秒~10ms 级宽表查询 | 支持批量导出 | 强一致性（行级） |
| Feast / Tecton | 特征抽象层 + 在线存储 | 自动同步离线特征 | 时间点一致性 |
避坑提醒：特征存储的数据一致性是实时链路中最容易被忽视的问题。在线特征更新延迟可能导致训练与推理时的特征分布不一致，建议使用 Feature Store 的时间点查询（Point-in-Time Join）来对齐。
2.6 模型推理：特征消费的终点
模型推理层负责将特征向量输入模型并返回预测结果。推理引擎需要支持：
- 多模型管理：同时加载多个模型版本，支持 A/B 测试。
- 动态批处理：合并多个请求的推理，提升 GPU 利用率。
- 特征拼接：从特征存储中拉取缺失特征，与实时特征合并。
推理层通常以 REST / gRPC 接口对外暴露，延迟目标控制在 10ms 以内（含网络开销）。
2.7 链路关键指标
评估实时特征生产与 Serving 链路的质量，需要关注以下核心指标：
- 端到端延迟：从事件产生到推理结果返回的总耗时，目标 < 500ms。
- 特征新鲜度：特征从计算完成到可被查询的时间差，目标 < 100ms。
- 特征覆盖率：在线推理时能成功获取的特征比例，目标 > 99.9%。
- 推理吞吐：每秒处理的推理请求数（QPS），取决于模型复杂度与硬件。
本章小结：实时特征生产与 Serving 链路由数据源、特征计算、特征存储、模型推理四个核心组件构成。数据源提供实时事件流，特征计算层完成窗口聚合与特征工程，特征存储层保障在线查询的低延迟与一致性，模型推理层最终产出预测结果。理解各组件之间的数据流与延迟约束，是设计高可靠实时 ML 系统的基础。