1. 实时特征场景概述

大家好，我是你们这趟课的老朋友。今天咱们聊聊实时特征——这个在风控和推荐系统里绕不开的话题。

先问个问题：你点开一个 App，首页推荐的内容为什么恰好是你想看的？或者，你刚刷了一笔信用卡，银行怎么秒级判断这笔交易有没有风险？

答案就是实时特征。说白了，实时特征就是在数据产生的瞬间，提取出对业务有用的信息。我做了这么多年实时计算，见过太多团队在特征这步栽跟头——要么延迟太高，要么特征质量差。嗯，今天咱们就把这事彻底聊透。

什么是实时特征

实时特征，不是简单的“把离线特征跑快一点”。它有一套自己的方法论。

我个人的理解是：实时特征 = 实时数据 + 特征工程 + 时效性约束。三者缺一不可。

• 实时数据：比如用户点击流、交易流水、设备指纹。数据从产生到进入计算引擎，延迟通常在秒级甚至毫秒级。
• 特征工程：对原始数据做聚合、统计、交叉。比如“过去5分钟用户点击次数”、“最近3笔交易金额均值”。
• 时效性约束：特征必须在业务决策前产出。风控场景要求毫秒级，推荐场景可以放宽到秒级。

举个例子。我在做某头部电商的推荐系统时，团队一开始直接把离线特征搬到实时 pipeline 里，结果延迟飙到 10 秒以上。后来我们重新设计了特征窗口——用滑动窗口替代固定窗口，用 Redis 替代 HBase 做状态存储，延迟才降到 200 毫秒以内。

实时特征在风控中的应用

风控场景对实时特征的要求，可以用一个字概括：快。

你想想看，一笔交易从发起到底层系统返回结果，通常只有几百毫秒。在这段时间里，实时特征要完成数据采集、特征计算、模型推理、决策输出。任何一个环节慢了，用户就会感知到卡顿。

我整理了几个典型的风控实时特征场景：

场景	实时特征示例	时效要求
交易反欺诈	过去1小时同设备交易次数、金额标准差	<100ms
登录风险检测	过去5分钟同IP登录失败次数、设备指纹变化	<200ms
信贷审批	用户近30天多头借贷次数、联系人图谱密度	<500ms
营销反作弊	同一手机号领取优惠券次数、设备关联账号数	<1s

实时特征在推荐中的应用

推荐场景和风控不太一样。风控追求“准不准”，推荐更看重“新不新”。

用户的行为意图变化很快。比如你刚搜了“跑步鞋”，下一秒首页推荐就应该出现运动装备。如果还用离线特征，等模型更新完，用户可能已经切换到别的兴趣点了。

推荐场景里常见的实时特征包括：

• 短期行为序列：用户最近点击的10个商品ID、停留时长
• 实时统计特征：当前 session 内加购次数、收藏率
• 上下文特征：当前时间、地理位置、网络环境
• 实时交叉特征：用户当前浏览类目 × 历史购买类目的匹配度

我记得有一次做短视频推荐，发现用户刷到第5个视频时流失率特别高。后来加了实时特征“当前 session 内视频完播率均值”，模型立刻捕捉到这个信号，把低质量视频往后排，留存提升了 3 个点。

契约设计的核心理念

聊完场景，咱们进入这门课的核心——契约设计。

什么是契约设计？说白了，就是在实时特征的生产者和消费者之间，约定一套明确的接口规范。生产者（比如 Flink 任务）承诺“我产出的特征长什么样”，消费者（比如模型服务）承诺“我按什么格式消费”。

为什么需要契约设计？我见过太多团队因为特征定义不清晰，导致线上事故。比如：

• 特征 A 在离线是“过去7天均值”，在实时变成了“过去7天滑动平均”，结果模型训练和推理不一致
• 特征 B 的字段类型从 int 改成 long，下游消费端没感知，直接抛异常
• 特征 C 的 null 值处理逻辑，生产端用 0 填充，消费端用 -1 填充，模型输出全乱套

契约设计的核心理念可以归纳为三点：

1. 显式化：所有特征的定义、计算逻辑、数据类型、null 处理策略，必须写在契约里，不能靠口头约定
2. 版本化：契约本身要有版本号，变更必须走评审流程，不能偷偷改
3. 可验证：契约要能被自动化工具校验，比如 schema 校验、数据质量监控

下面这张图展示了实时特征契约设计的整体框架：

这张图展示了实时特征从数据源到消费端的完整链路。注意中间那个绿色的“契约层”——它不是可有可无的中间件，而是整个体系的锚点。所有上下游都围绕契约来对齐，而不是靠人肉沟通。

好了，第一章就聊这么多。实时特征不是什么新鲜概念，但真正把它做好、做稳，需要一套系统的方法论。契约设计就是这套方法论的基石。后面的章节，咱们会一步步拆解每个环节的具体实现。