1. 实时特征工程概述：从离线到实时的演进

大家好，我是这次课程的主讲。在数据这个行当摸爬滚打了十几年，从早期的 Hadoop 批处理做到现在的实时流计算，我最大的感触就是——特征工程这件事，正在经历一场从「静态快照」到「动态脉搏」的质变。

今天这一章，我们先不急着写代码。我想花点时间，把实时特征工程的全貌给你铺开。你想想看，为什么我们放着好好的离线特征不用，非要折腾实时？这背后其实藏着业务对「时效性」的极致追求。

1.1 离线特征的「天花板」

先聊聊离线特征。我早年做推荐系统时，特征基本都是 T+1 生成的。每天凌晨跑一堆 Hive 任务，把用户过去一天的行为聚合成特征，灌到线上。

这种做法有什么问题？说白了，就是慢。

• 用户刚点了一个商品，离线特征要等到明天才能反映这个行为。
• 风控场景里，盗刷团伙几分钟就能完成一轮攻击，T+1 的特征根本来不及响应。
• 推荐场景里，用户刷短视频的即时兴趣，离线特征完全抓不住。

我记得有一次做电商大促，离线特征延迟导致推荐结果全是用户昨天看过的商品，转化率直接掉了 15%。从那以后，我就开始认真琢磨实时特征这条路。

1.2 实时特征的应用场景

实时特征不是万能药，但在几个关键场景里，它是刚需。

场景一：实时推荐

你在抖音刷视频，刚看完一个美食教程，下一秒推荐流里就出现了厨具广告。这背后就是实时特征在起作用：

• 即时行为特征： 刚刚点击、停留时长、滑动方向。
• 短时统计特征： 过去 5 分钟内的点击次数、品类偏好变化。
• 会话特征： 当前 session 的浏览序列、搜索意图。

这些特征的生命周期很短，可能几分钟后就失效了。但正是它们，决定了推荐系统能不能「跟上」用户的思路。

场景二：实时风控

风控对实时性的要求比推荐更苛刻。我参与过一个支付风控项目，要求从交易发生到特征产出，延迟不能超过 200 毫秒。

• 设备指纹特征： IP 归属地、设备型号、浏览器指纹。
• 行为序列特征： 过去 1 分钟内的操作频率、鼠标轨迹异常。
• 关联网络特征： 当前交易是否与已知黑名单设备关联。

嗯，这里要注意。风控场景里，特征延迟直接决定了一笔交易是「放行」还是「拦截」。我曾经见过一个案例，因为实时特征延迟了 500 毫秒，一笔欺诈交易已经完成了结算。

1.3 从离线到实时的演进路径

这个演进过程，我把它分成三个阶段。你可以对照一下自己的团队处在哪个阶段。

阶段	计算模式	典型延迟	存储选型	我见过的坑
离线阶段	Hive/Spark 批处理	T+1 ~ 小时级	HDFS / Hive 表	特征滞后导致模型效果差
准实时阶段	Spark Streaming / Flink 微批	分钟级 ~ 秒级	Redis / HBase	窗口边界处理容易出错
实时阶段	Flink 纯流处理 / Kafka Streams	毫秒级	Redis / 本地状态	状态管理不当导致 OOM

说白了，从离线到实时，不只是换一个计算引擎那么简单。你的数据建模方式、存储选型、运维体系，全都要跟着变。

1.4 课程整体架构预览

这一章的最后，我想给你看看整个课程的地图。一共 30 章，我把它分成了四个模块。

下面这张图，是我亲手画的课程知识体系。你可以把它当成一张导航图，随时回来对照。

这张图里，我特意把四个模块用不同颜色区分开。你会发现，模块一和模块二是「地基」，模块三是「承重墙」，模块四是「精装修」。没有前面的基础，后面的实战就是空中楼阁。

1.5 我的一些心里话

做实时特征这些年，我踩过不少坑。比如：

• 窗口大小设置不合理，导致特征抖动剧烈。
• 状态后端选型错误，线上频繁 OOM。
• 血缘信息缺失，特征出问题后找不到源头。

这些坑，我会在后面的章节里一个一个拆开给你看。你不需要重新走一遍我的弯路。