1. 特征平台概述：实时特征平台的定义、核心价值、与传统批处理特征平台的区别
各位同学好，我是老张。今天咱们开始聊实时特征平台。说实话，这个主题我准备了很久，因为在实际运维中踩过的坑实在太多了。
先问大家一个问题：你们公司做推荐、做广告、做风控，特征是怎么来的？
我见过不少团队，特征还是每天凌晨跑一次 Hive 任务，第二天早上看结果。用户上午的行为，下午才能体现在模型里。这在几年前还能忍，现在？用户点完广告 3 秒没反应，他就划走了。
所以，实时特征平台不是锦上添花，是刚需。
1.1 什么是实时特征平台
说白了，实时特征平台就是一个能在毫秒到秒级完成特征计算、存储、服务的系统。它把原始数据（比如用户点击、浏览、下单）实时加工成模型能用的特征向量，然后推送给在线推理服务。
我个人的理解是：它像一个实时数据加工厂。原料是源源不断的事件流，产品是特征，客户是模型服务。
核心定义：实时特征平台 = 实时计算引擎 + 特征存储 + 特征服务 API + 运维监控体系
嗯，这里要注意，很多人把 Flink 作业就当成了特征平台。其实 Flink 只是计算引擎那一层。完整的平台还包括特征怎么存、怎么查、怎么保证一致性、怎么监控延迟。
1.2 核心价值：为什么需要它
我总结了三句话：
- 时效性：从 T+1 到秒级，模型能感知实时行为
- 一致性：训练和推理用同一套特征逻辑，避免「训练时用 A，上线变 B」
- 复用性：特征一次开发，多个模型共享，不用每个模型都写一遍 Flink 作业
我在项目中遇到过最典型的场景：某电商大促期间，用户加购行为暴增。批处理特征平台要等到第二天凌晨才能更新特征，模型完全不知道用户刚刚加购了。结果推荐的商品还是昨天的，用户觉得「这 App 是不是傻了」。
换成实时特征平台后，用户加购 5 秒内，特征就更新了。推荐模型立刻感知到「这个用户对某类商品兴趣上升」，实时调整排序。转化率提升了 12%。
我的经验：实时特征平台最大的价值不是「快」，而是「准」。快是手段，准是目的。模型用上实时特征后，预测准确率通常能提升 5%-15%。
1.3 与传统批处理特征平台的区别
这个区别，我画了一张图，大家一看就明白。
我再从几个关键维度展开说说：
| 对比维度 | 批处理特征平台 | 实时特征平台 |
|---|---|---|
| 数据源 | HDFS、Hive 离线表 | Kafka、Pulsar 实时流 |
| 计算引擎 | MapReduce、Spark Batch | Flink、Spark Streaming |
| 处理延迟 | 小时级 ~ 天级 | 毫秒 ~ 秒级 |
| 特征存储 | HBase、Hive 分区 | Redis、HBase、本地缓存 |
| 服务方式 | 离线导出 + 加载 | 在线 API 实时查询 |
| 一致性保证 | 天然一致（全量重算） | 需要精确一次语义 |
| 运维复杂度 | 低（跑完就结束） | 高（7×24 小时在线） |
| 典型场景 | 用户画像、离线报表 | 实时推荐、实时风控、实时搜索 |
避坑指南：我曾经帮一个团队排查线上问题，发现他们的实时特征和离线特征对不上。查了半天，原因是实时作业用的特征逻辑是 2 周前发布的，离线 pipeline 用的是最新代码。这就是典型的「训练/推理不一致」。实时特征平台必须做到特征逻辑统一管理，不能各玩各的。
1.4 实时特征平台的核心能力
一个合格的实时特征平台，我觉得至少要有这四板斧：
- 实时接入：能对接 Kafka、Pulsar 等消息队列，支持多种数据格式（JSON、Avro、Protobuf）
- 实时计算：基于 Flink 做窗口聚合、多流 Join、维表关联，延迟控制在秒级
- 特征存储：支持高并发低延迟的在线读取，通常用 Redis 做缓存 + HBase 做持久化
- 特征服务：提供统一的 HTTP/gRPC 接口，模型服务通过特征 ID 批量获取特征
你想想看，如果这四个环节任何一个出问题，特征就不可用。比如存储挂了，模型拿不到特征，只能 fallback 到默认值，效果直接打折扣。
1.5 我踩过的坑：从批处理迁移到实时的阵痛
记得有一次，我们把一个核心推荐场景从批处理迁移到实时特征平台。上线第一天，一切正常。第二天，特征延迟从 200ms 飙升到 5s。查了半天，发现是 Flink 作业的 Checkpoint 超时了。
为什么会这样？
因为批处理时代，数据量是固定的，跑完就完。实时作业是 7×24 小时跑的，状态会不断累积。我们当时没给状态设置 TTL，结果状态越来越大，Checkpoint 越来越慢，最终导致反压。
后来加了状态 TTL 配置，调整了并行度，才稳定下来。这个教训让我养成了一个习惯：任何实时作业上线前，必须先做压测，模拟 3 倍流量跑 24 小时。
个人建议：从批处理迁移到实时，不要一上来就全量切换。先选一个流量小、影响可控的特征做试点，跑通后再逐步扩展。我一般会先做「双跑」——批处理和实时同时跑，对比结果，确认一致后再切流量。
1.6 小结
实时特征平台不是什么新概念，但要做好、做稳、做省，确实不容易。它跟批处理特征平台最大的区别，说白了就是从「算完再用」变成了「边算边用」。这个转变带来了时效性的提升，也带来了运维复杂度的飙升。
后面的章节，我会详细讲 Flink 作业怎么调优、特征存储怎么选型、线上问题怎么排查、成本怎么控制。这些都是我这些年真金白银换来的经验。