一、实时特征工程概述

大家好，我是老张。做了十几年大数据，从离线批处理一路干到实时流计算，踩过的坑比走过的路还多。今天咱们聊聊实时特征工程——说白了，就是怎么在数据流过的瞬间，把原始数据变成模型能吃的特征。

我记得刚接触实时特征时，总觉得跟离线特征差不多，无非是跑得快一点。后来被线上事故教育了几次，才明白这里面的门道有多深。

1.1 什么是实时特征工程

实时特征工程，就是在数据产生的当下，毫秒级地完成特征提取、转换和拼接。你想想看，用户刚点了一下按钮，系统就得在几百毫秒内判断这个行为是正常操作还是欺诈攻击——这就是实时特征要干的事。

我习惯把实时特征分成两类：

• 基础统计特征：比如过去5分钟的交易次数、最近1小时的登录失败率
• 复杂衍生特征：比如用户行为序列的Embedding、实时图计算得到的风险评分

嗯，这里要注意，不是所有特征都适合实时计算。有些特征计算成本太高，硬要实时化反而会拖垮系统。

1.2 实时特征与离线特征的区别

很多人问我：离线特征和实时特征，不就是计算时间不一样吗？其实远没那么简单。我拿一个风控场景举例：

对比维度	离线特征	实时特征
计算时效	T+1，甚至更久	毫秒~秒级
数据源	Hive/数仓，全量历史数据	Kafka/Pulsar，增量流数据
存储介质	HDFS、Hive表	Redis、内存状态后端
计算引擎	Spark、MapReduce	Flink、Spark Streaming
特征时效性	固定时间快照	持续更新，窗口滑动
容错机制	重跑即可	Exactly-Once语义
典型延迟	小时~天	毫秒~分钟

我曾经在一个项目中，直接把离线特征的计算逻辑搬到实时流上，结果发现窗口对齐完全对不上。离线是固定时间分区，实时是事件时间+水位线，两套逻辑根本不能直接复用。

1.3 实时特征工程的应用场景

实时特征不是炫技，是业务倒逼出来的。我挑三个最典型的场景聊聊。

1.3.1 风控场景

风控是实时特征最刚需的领域。你想想看，一笔交易从发起到返回结果，通常只有几百毫秒。系统要在这段时间内完成：

• 查询用户过去5分钟的登录设备数
• 计算当前交易金额与历史均值的偏离度
• 判断收货地址是否在常用地址库中
• 评估设备指纹与历史行为的匹配度

这些特征全部需要实时计算。我记得在蚂蚁的时候，一个实时风控特征链路涉及20多个算子，延迟必须控制在50毫秒以内。一旦超时，要么降级要么直接放行——但放行可能意味着资损。

1.3.2 推荐场景

推荐系统对实时特征的要求，跟风控不太一样。风控追求的是"准不准"，推荐更看重"新不新"。

举个例子：用户刚搜了"iPhone 15"，你还在给他推"华为Mate 60"，这体验就很糟糕。实时特征要捕捉用户的即时兴趣：

• 当前会话的点击序列
• 最近1分钟的搜索关键词
• 实时曝光但未点击的商品列表
• 用户停留时长超过阈值的页面

我做过一个实验：在推荐系统中加入实时行为特征后，CTR提升了12%，用户平均浏览时长增加了8秒。说白了，用户当下的意图比昨天的历史行为重要得多。

1.3.3 监控场景

监控场景的实时特征，核心是"异常检测"。比如：

• 服务器CPU使用率在过去5分钟的滑动均值
• API接口的P99延迟是否超过阈值
• 订单量相比上周同期的偏离度
• 用户投诉率的实时趋势

这些特征的特点是：数据量大、维度多、对延迟敏感。我习惯用Flink的CEP（复杂事件处理）来做监控特征，能很好地处理时间窗口和模式匹配。

这张图把实时特征工程的三个核心维度串起来了。左边是定义，中间是差异对比，右边是落地场景。我每次给团队做培训，都会先画这张图——先把概念理清楚，再谈技术选型和架构设计。

好了，第一章就聊这么多。实时特征工程的门槛不在于技术有多难，而在于思维方式的转变。后面我们会一步步深入，从数据源接入到特征存储，从窗口计算到模型推理，把每个环节都掰开揉碎了讲。