1. 实时特征工程概述
大家好，欢迎来到《实时特征工程与向量化流水线》的第一章。
先聊聊我自己的经历。几年前我接手过一个推荐系统项目，离线特征算得好好的，模型上线后效果却惨不忍睹。排查了半天，发现用户刚点了一个商品，特征库里还是半小时前的状态。你说气不气人？
从那以后，我彻底明白了——特征的新鲜度，有时候比特征本身还重要。这就是我们今天要聊的：实时特征工程。
什么是实时特征工程
说白了，实时特征工程就是在数据产生的瞬间，完成特征的提取、计算和交付。不是跑个离线任务等几小时，而是毫秒级甚至微秒级响应。
举个例子：用户在电商App上浏览了一件商品。实时特征工程要做的是——
- 立刻记录这次浏览行为
- 更新该用户的近期偏好向量
- 计算商品与用户画像的实时匹配度
- 把新特征推送给模型，影响下一次推荐
整个过程，通常在几百毫秒内完成。嗯，这里要注意：不是所有特征都需要实时。只有那些对时效性敏感的特征，才值得你花功夫去做实时化。
核心判断标准：如果特征值在几分钟内就会发生显著变化，且变化直接影响模型输出，那就该考虑实时化。
实时特征工程 vs 离线特征工程
我经常被问到：实时和离线到底差在哪？咱们直接看对比。
| 维度 | 离线特征工程 | 实时特征工程 |
|---|---|---|
| 计算时机 | 定时调度（小时/天级） | 事件触发（毫秒级） |
| 数据源 | Hive、HDFS、数仓 | Kafka、Pulsar、日志流 |
| 存储介质 | HBase、Parquet、ORC | Redis、内存表、向量数据库 |
| 计算引擎 | Spark、MapReduce | Flink、Spark Streaming、KSQL |
| 特征时效 | T+1 或小时级 | 秒级甚至毫秒级 |
| 典型场景 | 用户画像、批量统计 | 实时推荐、在线风控 |
你看，两者不是替代关系，而是互补关系。离线特征负责"全量、稳定、历史"，实时特征负责"增量、新鲜、当下"。
我个人习惯的做法是：离线兜底，实时补新。离线先把基础特征算好，实时流只做增量更新。这样既保证了特征覆盖率，又控制了实时计算的压力。
实时特征工程的应用场景
聊完概念，咱们看看实际中哪些地方离不开它。
推荐系统
这是实时特征工程最典型的战场。你想想看——
- 用户刚搜了"跑步鞋"，下一秒推荐就该出现运动装备
- 用户把商品加入购物车，推荐列表要立刻调整
- 用户连续划走了三个视频，模型要马上感知到兴趣偏移
我在项目中遇到过最极端的案例：某短视频平台要求用户滑动后200毫秒内完成特征更新并返回新推荐。做不到？用户就划走了，再也不回来。
避坑指南：我曾经把实时特征全部放在推荐链路的主路径上，结果一次特征服务抖动，整个推荐接口超时。后来学乖了——实时特征要有降级方案，兜底用离线特征或默认值。
风控系统
风控对实时性的要求，比推荐更苛刻。为什么？因为每一秒的延迟都可能意味着真金白银的损失。
- 登录异常检测：同一IP在1秒内发起10次登录尝试
- 交易反欺诈：用户刚在A地消费，5分钟后在B地又有一笔
- 设备指纹关联：新设备与历史黑产设备存在关联关系
这些特征，离线算出来的时候钱早就没了。必须实时计算，实时决策。
我记得有一次做支付风控，需要计算"过去5分钟内该用户的交易频次"。如果用离线，等跑完任务用户都刷了十几笔了。后来改成Flink滑动窗口，每笔交易进来实时更新计数，延迟控制在50毫秒以内。
注意：实时风控特征要特别关注数据一致性。我曾经因为Kafka消息乱序，导致某个用户的交易频次被少算了一次，放行了一笔本应拦截的交易。后来加了事件时间处理和去重机制才解决。
实时监控与运维
这个场景可能不像推荐和风控那么"性感"，但同样重要。
- 服务器CPU/内存使用率的实时聚合
- API接口响应时间的滑动窗口统计
- 业务指标的异常检测（如订单量突然下跌50%）
这些特征直接服务于告警、自动扩缩容和根因分析。说白了，就是让系统自己知道自己"病了"，而且知道"病在哪"。
知识体系总览
为了让你对本章内容有个整体印象，我画了张图。
这张图把本章的核心脉络串起来了。从定义出发，到离线与实时的对比，再到三大应用场景。后面的章节，我们会逐一深入每个技术细节。
好了，第一章就到这里。记住一句话：实时特征工程不是银弹，但用对了地方，它就是那把最锋利的刀。