1. 特征服务概述
1.1 特征服务的定义
特征服务（Feature Service）是机器学习推理链路中负责特征生产、存储、计算与分发的中间层系统。它将原始数据（用户行为、物品属性、上下文信号）转化为模型可消费的特征向量，并以低延迟、高吞吐的方式提供给在线推理引擎。
在实时计算架构中，特征服务通常位于数据管道与模型服务器之间，承担以下核心职责：
- 特征生产：从实时流（Kafka/Pulsar）和离线数仓（Hive/HDFS）中提取原始数据，完成清洗、聚合、变换。
- 特征存储：将计算后的特征写入高性能在线存储（Redis、HBase、Cassandra），支持毫秒级点查。
- 特征计算：执行窗口聚合、跨特征交叉、实时统计等逻辑，保证特征时效性。
- 特征分发：通过 RPC（gRPC/Thrift）或 REST API 向模型服务提供批量或单条特征。
关键认知：特征服务不是简单的“缓存层”，而是融合了实时流处理、状态管理、在线存储访问的复杂中间件系统。其设计质量直接影响模型推理的准确率与响应时间。
1.2 在推荐/广告/搜索系统中的作用
推荐、广告、搜索（简称“搜广推”）是特征服务最典型、要求最苛刻的应用场景。下表对比了三类系统对特征服务的共性需求与差异：
| 维度 | 推荐系统 | 广告系统 | 搜索系统 |
|---|---|---|---|
| 特征规模 | 千亿级样本，万级特征 | 百亿级请求，千级特征 | 十亿级文档，万级特征 |
| 延迟要求 | P99 < 50ms | P99 < 20ms | P99 < 100ms |
| 特征时效性 | 秒级（用户实时行为） | 毫秒级（出价/点击反馈） | 分钟级（索引更新） |
| 典型特征类型 | 用户画像、物品标签、上下文 | 用户兴趣、广告属性、竞价信号 | 查询意图、文档相关性、排序分 |
| 特征复用度 | 高（多路召回共用） | 中（按广告主隔离） | 高（Query-Doc 交叉） |
特征服务在搜广推系统中的具体作用可归纳为三个层次：
- 特征统一：消除离线训练与在线推理之间的特征不一致（Training-Serving Skew），确保模型上线后效果不衰减。
- 特征加速：通过预计算、缓存、并行拉取等手段，将特征获取延迟从百毫秒级压缩至毫秒级，满足在线服务 SLA。
- 特征复用：同一份特征可被多个模型、多个场景共享，避免重复计算，降低资源消耗。
1.3 低延迟的核心挑战
构建低延迟特征服务面临四大核心挑战，这些挑战直接决定了技术选型与架构设计方向：
| 挑战维度 | 具体问题 | 典型后果 |
|---|---|---|
| 数据新鲜度 | 用户行为发生后，特征需在秒级内反映到模型输入 | 特征滞后导致推荐/广告效果下降 10%~30% |
| 特征膨胀 | 单次请求需拉取数百至数千个特征，跨多个存储源 | 网络开销与存储压力成倍增长 |
| 状态一致性 | 实时流处理中窗口状态、计数器需精确一次语义 | 特征重复或丢失导致模型预测偏差 |
| 资源成本 | 高并发下 CPU/内存/带宽消耗巨大 | 硬件成本失控，运维复杂度飙升 |
实践建议：在特征服务设计初期，应优先定义延迟预算（Latency Budget）。例如：总延迟 50ms 中，特征拉取占 30ms，模型计算占 15ms，网络传输占 5ms。明确预算后，再针对性地优化瓶颈环节。
下图展示了特征服务在搜广推系统中的典型位置与数据流向，以及低延迟挑战的分布：
上图清晰展示了从数据源到模型推理的完整链路，以及每个环节面临的核心挑战。Flink 作为特征计算引擎，承担了实时窗口聚合、状态一致性保障等关键任务，是低延迟特征服务的核心基础设施。
避坑提醒：很多团队在初期只关注特征存储的延迟优化（如选用 Redis 集群），却忽略了特征计算本身的瓶颈。实际上，Flink 作业的 Checkpoint 间隔、状态后端选择、算子链配置等，往往成为特征延迟的“隐形杀手”。本课程后续章节将逐一深入这些技术细节。