实时推荐系统架构：流处理与特征服务

实时推荐系统架构：从批处理到流处理

推荐系统正在从“每天更新一次”的时代，全面转向“实时响应每一次行为”的时代。用户点击、加购、观看、退出——这些行为应在秒级甚至毫秒级内影响后续的推荐结果。本教程将带你系统了解现代实时推荐系统的核心架构，重点解析流处理与特征服务两大支柱。

为什么需要实时推荐？

传统的 T+1 推荐链路存在明显的体验断层：

• 用户刚刚购买了一台手机，首页却还在推荐同类产品。
• 视频平台在你看完一支长视频后，仍根据你昨天的兴趣推荐内容。
• 电商大促期间，热门商品库存告急，推荐链路却毫无感知。

实时推荐的核心目标，是让系统拥有“即时记忆”与“即时反应”能力，将用户当下的上下文和最新的全局信号融合进排序逻辑。

实时推荐系统全景架构

一个典型的实时系统可以分为四层逻辑管道：

1. 行为采集层：采集用户实时交互日志。
2. 流处理层：实时处理并提取行为特征，更新用户画像与模型。
3. 特征服务层：在线高并发低延迟地提供实时特征。
4. 推理与排序层：结合实时特征和模型进行最终排序。

我们将重点聚焦在流处理与特征服务这两个承上启下的关键环节。

流处理：行为事件的实时特征化

数据源与传输通道

用户在前端的每一次点击、滑动、播放，都会被封装成事件，通过 Kafka、Pulsar 等高吞吐的消息队列送入流处理引擎。事件通常包含：

• user_id
• item_id
• event_type（例如 view、click、add_to_cart）
• context（设备、页面位置、referrer 等）
• timestamp

流处理框架选型

对于高可靠的实时推荐，Flink 通常作为主流选择，因为它能够同时支持精确的状态管理和复杂的事件时间窗口。

特征工程在线化

在流处理作业中，我们并非只做简单的计数，而是需要实时计算大量行为特征：

• 短期画像特征：过去 5 分钟、30 分钟的点击/交互类目分布。
• 会话内序列特征：当前会话中最近点击的 N 个商品ID。
• 全局统计特征：某商品的实时 CTR、实时转化率。
• 上下文交叉特征：user_gender × event_time_quantile 等实时交叉。

这些特征往往使用 Flink 的 KeyedState 和 Window Function 来实现。例如，一个滑动窗口（10 分钟，每 1 分钟刷新）计算用户对各种品类的活跃度，并将结果写入下游存储。

流批一体：Lambda 架构的进化

过去 Lambda 架构要求维护批计算与流计算两套代码。现在，Flink + 数据湖（如 Iceberg/Paimon） 的流批一体方案逐渐普及。同一套 Flink 作业既可处理实时增量数据，又可回溯历史存量数据，保证特征的大规模准确性与实时性。

特征服务：低延迟的在线特征供给

流处理产出的实时特征，必须能在毫秒级内被推荐排序服务拿到，这就是特征服务（Feature Serving）的责任。

特征存储的设计要求

• 写吞吐高：每秒可能需要处理上百万的特征更新。
• 读延迟极低：P99 延迟需控制在 5~10ms 以内。
• 支持点查与批量点查：排序服务往往一次请求数千商品，需要一次性取出所有候选商品的实时特征。

常见的特征存储方案：

特征服务的典型推送链路

Flink 实时聚合 → Redis Cluster（热数据层） → 推荐服务在内存中组装特征向量 → 模型推理

为确保极低延迟，推荐服务内部通常会设置两级缓存：本地线程内缓存 + 分布式缓存。需要特别处理缓存一致性，一般通过特征版本号（ttl 或条件更新）来避免脏读。

实体与特征的定义规范

建议所有特征以 实体标识（entity_key） 作为主键进行组织：

• user_12345:rt_click_cate_last_30m
• item_67890:rt_ctr_10min
• context_session:weather_code

同时，为每个特征绑定类型（数值、向量、字符串）和元数据（更新时间、空值策略）。这样有利于测试、监控和自动化特征拼装。

实时排序与模型推理

当实时特征已经就绪，在线推荐服务即可执行：

1. 召回 -> 生成候选集
2. 特征拉取 -> 通过特征服务批量获取实时特征与离线特征
3. 特征变换 -> 拼接、分桶、归一化
4. 模型推理 -> 轻量级实时模型（如基于梯度提升树的模型或小型的深度学习网络）
5. 重排 -> 根据业务规则调整（打散、频控）
6. 返回结果

这里的实时模型可以是：

• 在线学习模型：利用实时样本持续更新参数，如 FTRL 逻辑回归。
• 纯离线训练模型 + 实时特征：模型参数固定，但输入特征包含实时部分，这是目前大多数生产系统的折中方案。

监控与工程保障

实时推荐系统链路长，任一环节异常都可能影响用户体验。需重点监控：

• 流处理延迟：事件从产生到特征入库的端到端延迟。
• 特征更新频率：特征是否按窗口持续产出，有无断流。
• 特征覆盖率：新用户/新商品是否快速获得实时特征。
• 特征服务质量：P99 读取延迟、错误率、空值率。
• 模型预测分布：实时特征变化是否导致模型分值漂移。

建议为每个特征定义 SLO（服务等级目标），并设置自动化告警。

总结与最佳实践

• 从小规模开始：先选取少数关键事件和特征接入实时管道，验证效果后再扩大。
• 特征标准化：统一特征的定义、存储、获取接口，避免散乱。
• 优先解决“实时上下文”问题：用户本次会话的兴趣与意图，远比历史兴趣更重要。
• 流处理与特征存储解耦：不要将 Flink 状态直接当作在线查询存储，它应仅作为计算引擎。
• 保持可回溯性：所有写入特征存储的值应保留事件时间戳，以支撑问题排查和模型样本再造。

实时推荐并非推翻原有离线系统，而是在其基础上增加一层“即时感知”的神经末梢。掌握流处理做计算、特征服务做供给的核心模式，你就有能力设计出响应迅速、体验流畅的下一代推荐系统。