📚 课程目录第1章实时特征生产概述

1. 实时特征生产概述

大家好，我是这次课程的主讲。做了这么多年实时计算，我最大的感触就是：实时特征这东西，看着简单，想做好真不容易。

先问个问题——你平时做推荐、做风控，是不是经常遇到这种情况？模型上线前离线跑分挺漂亮，一上线效果就崩了。我遇到过好几次，查到最后，问题都出在特征上。离线特征和实时特征对不上，模型就懵了。

所以这一章，我们先打好基础。把实时特征的定义、应用场景、和离线特征的区别，一次性讲清楚。

说白了，实时特征就是在数据产生的瞬间，立刻计算并输出给模型使用的特征。

举个例子。你在淘宝点了一个商品，下一秒推荐系统就要根据这个点击行为，重新计算你的兴趣向量。这个兴趣向量，就是实时特征。

它的核心特点就三个：

核心要点：实时特征的本质是「流式状态计算」。数据像水流一样不断涌入，我们在内存中维护状态，每来一条数据就更新一次特征值。

我接触过的项目里，实时特征用得最多的就两个方向：推荐系统和风控系统。这两个场景对实时性的要求完全不同，咱们分开聊。

推荐系统里，实时特征主要用来捕捉用户短时兴趣。

你想想看，用户上午搜了「登山鞋」，下午又搜了「帐篷」。如果只用离线特征，模型可能觉得这人喜欢户外运动。但实时特征能告诉你：他正在计划一次露营，现在最需要的是睡袋和防潮垫。

常见的实时特征包括：

我记得有个项目，用户实时点击特征延迟从10秒降到1秒后，推荐点击率直接提升了8%。这就是实时特征的价值。

风控对实时性的要求更苛刻。为什么？因为每一秒的延迟，都可能意味着真金白银的损失。

我做过一个支付风控项目。用户发起一笔转账，系统需要在100毫秒内判断这笔交易是否可疑。这时候用的特征全是实时的：

注意：风控场景的实时特征，对准确率要求极高。误杀一个正常用户，可能比放过一笔欺诈损失更大。我见过一个案例，因为实时特征计算逻辑写错了，把正常大额交易全拦截了，用户投诉电话直接打爆。

很多新手会问：离线特征和实时特征，不都是特征吗？有什么区别？

嗯，区别大了去了。我整理了一张对比表，你看完就明白了。

对比维度	离线特征	实时特征
计算时机	T+1 或周期性批量计算	数据到达即计算
数据范围	全量历史数据	最近窗口内的增量数据
存储介质	Hive、HDFS、数仓	Redis、内存、状态后端
延迟要求	小时级到天级	秒级到毫秒级
计算模式	全量重算	增量更新
一致性	强一致，可回溯	最终一致，可能有延迟
典型框架	Spark、Hive、MapReduce	Flink、Spark Streaming、Kafka Streams

这张表里，我想特别强调两点：

第一，数据范围不同。 离线特征可以看全量数据，比如用户过去一年的购买记录。但实时特征只能看「最近一段时间」的数据，比如过去5分钟、过去1小时。为什么？因为内存有限，不可能把所有历史数据都放在状态里。

第二，一致性模型不同。 离线特征可以做到强一致，你今天跑的结果和明天跑的结果，只要数据没变，就一定一样。但实时特征不行。因为数据到达顺序、网络延迟、机器故障，都可能导致特征值出现短暂的不一致。我刚开始做实时特征时，就被这个坑过——线上特征和离线回溯特征对不上，排查了整整两天。

我的建议：做实时特征时，一定要想清楚你的业务能不能接受「最终一致」。推荐场景通常可以，用户多点一下少点一下差别不大。但风控场景就要小心了，一致性偏差可能导致误判。

说了这么多，实时特征到底是怎么生产出来的？我画了一张流程图，帮你理清整体脉络。

这张图展示了实时特征生产的完整链路。从数据源接入，到实时计算引擎处理，再到特征计算和存储，最后服务于模型推理。注意那个反馈闭环——这是很多团队容易忽略的。

我见过一个做得好的团队，他们把模型预测结果（比如是否点击）实时回流到特征计算中，用来更新用户的「历史点击率」特征。这样特征就能持续自我进化，越用越准。

这一章我们聊了实时特征的核心概念。总结下来就三句话：