3、实时特征平台核心组件：特征存储、特征工程、特征服务、特征监控、特征治理
实时特征平台，说白了就是把「在线推理时用到的特征」管起来。我见过不少团队，特征散落在 Redis、MySQL、甚至本地文件里，每次上线一个新模型，光找特征就要花三天。嗯，这显然不是长久之计。
一个成熟的实时特征平台，通常包含五个核心组件。我习惯把它们分成「存储、生产、服务、观测、治理」五个维度。下面逐个拆开讲。
3.1 特征存储：在线与离线统一的数据底座
特征存储要解决一个核心矛盾：离线训练需要全量历史数据，在线推理需要毫秒级读取最新值。我早期做推荐系统时，离线用 Hive 表，在线用 Redis，两边特征口径经常对不上。后来才意识到，必须搞一个「双写双读」的统一存储层。
现在主流的方案是 特征存储 + 在线缓存 两层架构：
- 离线层：用 Iceberg / Delta Lake 存全量历史快照，支持时间旅行和回溯分析。
- 在线层：用 Redis / HBase / TiKV 存最新特征值，要求 P99 延迟 < 10ms。
- 双写机制：特征计算完成后，同时写入离线表和在线缓存，保证口径一致。
3.2 特征工程：从原始数据到特征的生产流水线
特征工程是实时特征平台最复杂的部分。说白了，就是把原始日志、业务数据库、实时流数据，加工成模型能用的特征。
我把它分为三个层次：
- 实时特征：基于 Flink / Spark Streaming 做滑动窗口聚合，比如「过去5分钟用户点击次数」。
- 离线特征：用批处理计算历史统计量，比如「用户过去30天平均消费金额」。
- 组合特征：把多个基础特征做交叉、拼接、embedding 查询。
这里有个坑——特征回溯。你想想看，离线训练时用的特征值，和在线推理时拿到的特征值，必须严格对齐。否则模型上线后效果会崩。我曾在项目中踩过这个坑，训练时特征窗口是「自然天」，在线服务时窗口变成了「滑动24小时」，结果 AUC 掉了 5 个点。
3.3 特征服务：低延迟的在线特征获取
特征服务是实时特征平台对外的接口层。模型推理时，需要根据请求中的实体 ID（比如 user_id、item_id），快速拿到对应的特征向量。
我常用的架构是：
- 特征网关：接收请求，解析特征名称列表，批量查询特征存储。
- 特征缓存：本地 LRU 缓存 + 分布式缓存（Redis Cluster），减少重复查询。
- 特征计算：对于需要实时计算的特征（比如用户实时行为计数），在服务层用 CEP 或轻量计算引擎完成。
性能上，我一般要求单次特征查询 P99 < 5ms，单次批量查询（50个特征）P99 < 20ms。如果达不到，优先检查缓存命中率和网络开销。
3.4 特征监控：观测特征质量与分布漂移
特征监控经常被忽视，但其实是线上模型稳定的最后一道防线。我见过太多案例：特征源数据变了，模型悄无声息地跑偏，等发现时已经造成了业务损失。
我建议至少监控以下四个维度：
| 监控维度 | 指标 | 告警阈值 |
|---|---|---|
| 延迟 | 特征计算延迟、特征服务 P99 延迟 | > 100ms 告警 |
| 覆盖率 | 特征缺失率、默认值使用率 | > 5% 告警 |
| 分布漂移 | PSI / KL 散度，对比离线训练分布 | PSI > 0.2 告警 |
| 数据新鲜度 | 特征最后更新时间与当前时间差 | > 10 分钟告警 |
我曾经遇到过一个案例：上游数据源切换了字段格式，特征工程没感知，结果特征值全部变成了 null。幸好覆盖率监控及时告警，才没让模型用默认值跑一整天。
3.5 特征治理：管理特征生命周期与血缘
特征治理是平台长期可维护的保障。说白了，就是回答三个问题：
- 特征从哪来？——血缘追踪，从原始数据到特征的全链路。
- 特征被谁用？——特征与模型、特征与服务的关联关系。
- 特征该不该删？——特征生命周期管理，废弃特征自动下线。
我习惯用 特征注册中心 来管理。每个特征在创建时，必须填写元数据：特征名称、类型、计算逻辑、数据源、负责人、SLA。这样后续做血缘分析和影响评估时，就有据可查。
嗯，以上就是实时特征平台的五个核心组件。每个组件单独拎出来都能讲一整天，但实际落地时，最重要的是让它们协同工作。存储、工程、服务、监控、治理，缺一个，平台就容易出现「能跑但不好管」的局面。