3. 特征平台架构设计：整体架构分层与组件交互流程

一个生产级的特征平台，其核心价值在于为模型 Serving 提供稳定、低延迟、一致性的特征数据。为了实现这一目标，平台架构通常采用清晰的分层设计，将数据接入、计算、存储与在线服务解耦。本章将详细阐述特征平台的四层架构模型及各层之间的核心交互流程。

3.1 整体架构分层

特征平台架构自上而下分为四个核心层次：数据源层、特征计算层、特征存储层和Serving 层。每一层各司其职，共同构成从原始数据到模型在线推理的完整链路。

3.2 组件交互流程与数据流转

特征数据的生命周期始于数据源，终于模型 Serving。下图展示了特征从生产到消费的完整交互流程，重点突出了离线-实时特征一致性与在线存储预热两个关键环节。

3.3 核心交互流程详解

基于上述分层架构，特征平台在模型 Serving 场景下存在三条核心数据流，它们共同决定了特征服务的质量与效率。

3.3.1 实时特征流 (Hot Path)

• 触发条件： 用户行为事件（如点击、曝光）实时产生。
• 流程： 数据源层 (Kafka) → 特征计算层 (Flink 实时聚合) → 特征存储层 (Redis 在线 KV) → Serving 层 (gRPC 读取)。
• 关键要求： 端到端延迟 < 100ms，保证特征新鲜度。

3.3.2 离线特征流 (Cold Path)

• 触发条件： 每日定时任务，用于生成历史特征和训练样本。
• 流程： 数据源层 (Hive) → 特征计算层 (Spark 批处理) → 特征存储层 (Hive 离线表 & Redis 预热)。
• 关键要求： 高吞吐量，保证离线与在线特征的一致性（通过特征版本对齐）。

3.3.3 在线存储预热 (Warm-up)

• 触发条件： 模型版本更新或每日离线特征产出后。
• 流程： 离线特征 (Hive) → 数据导出 Job → 批量写入 Redis 在线存储。
• 关键要求： 预热期间不能影响在线 Serving 的读写性能，通常采用 双缓冲 或 灰度切换 策略。

3.4 组件交互时序图

为了更清晰地展示一次模型推理请求中，各组件之间的调用关系，我们以在线特征获取为例，绘制如下时序图。

3.5 架构设计关键考量

在落地上述分层架构时，需要重点关注以下三个方面的权衡与设计。