1. 实时特征平台概述
大家好，我是老赵。做实时计算这些年，我见过太多团队在特征工程上栽跟头。今天咱们聊聊实时特征平台——这个在AI工程化里越来越绕不开的话题。
说白了，实时特征平台就是一套能在线生产、在线更新、在线服务特征的系统。它跟离线特征平台最大的区别在于：数据从产生到变成特征，延迟得控制在秒级甚至毫秒级。
1.1 什么是实时特征平台
我习惯这么定义：实时特征平台是一个端到端的特征工程基础设施，它负责从实时数据源（比如Kafka、Pulsar）接入数据，经过窗口计算、状态聚合、模型变换等处理，最终产出可供在线推理使用的特征向量。
它的核心能力包括：
- 实时接入：毫秒级消费流式数据
- 在线计算：支持滑动窗口、计数、均值等时间敏感算子
- 特征存储：低延迟读写，通常用Redis、HBase或内存引擎
- 特征服务：通过RESTful或gRPC接口对外提供特征查询
- 特征管理：版本控制、血缘追踪、质量监控
核心要点：实时特征平台不是简单的流处理任务，而是一个面向特征生命周期的完整系统。它把特征从“一次性脚本”变成了“可复用、可治理、可在线服务”的企业资产。
1.2 为什么需要实时特征
你想想看，现在的推荐系统、风控系统、广告竞价，哪个不是要求毫秒级响应？离线特征一天更新一次，根本跟不上用户行为的变化节奏。
我举个例子。之前在做一个金融风控项目，用户刚发起一笔交易，我们需要在100毫秒内判断这笔交易是否可疑。如果用离线特征，只能看到用户过去24小时的交易模式。但实时特征能捕捉到：用户过去5分钟内的交易频次、金额突变、地理位置跳跃——这些才是真正的风险信号。
具体来说，实时特征解决了三个核心痛点：
- 时效性：离线特征更新周期通常是T+1，而实时特征能做到秒级更新。对于欺诈检测、实时推荐这类场景，晚一秒可能就意味着损失。
- 准确性：很多特征天然具有时间衰减特性。比如用户兴趣，昨天的点击行为跟今天的点击行为，权重完全不同。实时特征能精确反映当前状态。
- 交互性：在线模型需要根据用户实时反馈动态调整。比如搜索排序，用户刚点击了某个商品，下一个请求就应该提升该商品的权重。
我的经验：判断一个场景是否需要实时特征，有个简单标准——如果特征值在1分钟内的变化会显著影响模型输出，那就必须上实时。否则，离线特征完全够用。
1.3 实时特征与离线特征的区别
很多刚入行的同学会问：实时特征不就是把离线特征的计算频率加快吗？嗯，这里要注意，两者在架构设计、计算语义、存储模型上都有本质区别。
| 对比维度 | 离线特征 | 实时特征 |
|---|---|---|
| 数据源 | Hive/数仓表（批量导入） | Kafka/Pulsar（流式接入） |
| 计算引擎 | Spark/Hive（批处理） | Flink/Spark Streaming（流处理） |
| 时间窗口 | 固定时间分区（如dt=20240101） | 滑动窗口/会话窗口（事件时间） |
| 存储介质 | HDFS/对象存储（高吞吐） | Redis/HBase（低延迟） |
| 更新频率 | 天级/小时级 | 秒级/毫秒级 |
| 一致性模型 | 强一致性（最终一致即可） | 最终一致性（允许短暂不一致） |
| 服务方式 | 批量导出到Hive表 | 在线API查询 |
| 典型延迟 | 数小时到一天 | 毫秒到秒级 |
我曾经踩过一个坑：把离线特征的滑动窗口逻辑直接搬到实时计算里，结果发现数据对不上。为什么？因为离线计算用的是处理时间，而实时计算必须用事件时间。离线可以等数据到齐再算，实时必须处理乱序和延迟数据。这个差异，后面章节我会详细讲。
1.4 典型应用场景
说了这么多理论，咱们看看实际场景。我挑三个最有代表性的：
场景一：实时风控
这是实时特征最刚需的场景。银行、支付、电商都在用。核心特征包括：
- 设备指纹：过去5分钟同一设备关联的账号数
- 交易频次：过去1小时同一IP的交易笔数
- 地理位置：用户当前GPS与常用地址的距离
- 行为序列：用户最近10次操作的路径异常度
场景二：实时推荐
推荐系统从“千人千面”进化到“千人千时千面”。实时特征让推荐能感知用户当下的意图：
- 实时点击序列：用户刚浏览的商品类别
- 搜索意图：当前搜索词与历史偏好的匹配度
- 上下文特征：当前时间、天气、地理位置
- 实时热度：商品在过去5分钟的点击量
场景三：实时竞价（RTB）
广告领域对延迟极其敏感。每次广告请求必须在50ms内完成特征计算和模型推理：
- 用户画像：实时更新的兴趣标签
- 频次控制：用户今天看到该广告的次数
- 上下文匹配：广告内容与页面内容的语义相似度
- 实时出价：基于当前竞争环境的动态调价
避坑提醒：我曾经在一个实时推荐项目里，把所有离线特征都改成了实时计算，结果集群资源被打爆。后来才明白：不是所有特征都需要实时。用户性别、年龄这类稳定特征，离线算好存起来就行。实时特征只应该用在那些高频变化、对时效敏感的维度上。
1.5 实时特征平台的核心架构
下面这张图是我在实际项目中沉淀下来的实时特征平台架构。它把整个链路分成了四层：
这个架构图我用了好几年，每次迭代都会微调。核心思路就是分层解耦——每一层都可以独立扩展、独立升级。比如存储层从Redis换成TiKV，计算层完全不用改代码。
1.6 实时特征平台与Lakehouse的关系
说到这儿，你可能会问：实时特征平台跟Lakehouse有什么关系？
我个人的理解是：Lakehouse是实时特征平台的“数据底座”。实时特征处理的是流式数据，但最终需要跟离线数据做融合、做回溯、做训练。Lakehouse提供了统一的存储和元数据管理，让实时特征和离线特征能在同一个数据湖里共存。
具体来说，Lakehouse在实时特征平台中扮演三个角色：
- 特征存储的冷备层：实时特征写入Redis的同时，异步写入Lakehouse的Delta/Iceberg表，用于历史回溯和模型训练
- 特征回溯的查询引擎：当需要回填历史特征时，直接从Lakehouse读取，避免影响在线服务
- 特征一致性的校验层：通过Lakehouse的ACID事务，保证实时特征和离线特征的数据一致性
我的建议：如果你正在搭建实时特征平台，一定不要把实时和离线割裂开。用Lakehouse做统一存储，你会发现特征治理、模型迭代、数据回溯都变得简单很多。后面章节我会详细讲怎么用Delta Lake做实时特征的冷热分层。