1. 特征服务概述

在实时推荐与风控系统中,特征服务是连接原始数据与模型推理的中间层。它负责将分散在多个数据源中的用户、物品、上下文信息,加工成模型可消费的特征向量,并以低延迟、高可用的方式对外暴露。本章从定义、核心价值、与离线特征的对比三个维度,建立对特征服务的整体认知。

1.1 特征服务的定义

特征服务(Feature Service)是一个面向在线推理场景的中间件平台,它封装了特征的定义、计算、存储、获取与更新逻辑,为上层应用提供统一的特征访问接口。其核心职责包括:

  • 特征生产:从实时流(Kafka、Pulsar)或近线存储(Redis、HBase)中提取原始数据,执行因子计算与特征变换。
  • 特征存储:将计算后的特征值按 Key-Value 或向量格式持久化,支持毫秒级查询。
  • 特征获取:通过 RPC 或 SDK 对外暴露 GetFeature、BatchGetFeatures 等接口,屏蔽底层存储差异。
  • 特征生命周期管理:包括特征注册、版本控制、灰度发布、回滚与监控。
关键认知:特征服务不是简单的“缓存+数据库”,而是一个包含实时计算引擎(如 Flink)、特征存储、服务发现、降级熔断的完整系统。它的存在使得模型团队可以专注于特征逻辑,而不必关心数据管道与运维细节。

1.2 在实时推荐与风控中的核心价值

特征服务在实时推荐和风控两个场景中扮演着截然不同但同样关键的角色。下表从多个维度对比其价值体现:

维度 实时推荐 实时风控
核心目标 提升用户点击率、转化率、停留时长 降低欺诈损失、拦截异常交易、控制信用风险
特征时效性 秒级~分钟级(用户最近一次点击、浏览序列) 毫秒级~秒级(设备指纹、IP 风险、交易频次)
特征粒度 用户粒度 + 物品粒度 + 上下文(时间、位置) 用户粒度 + 设备粒度 + 交易粒度 + 环境上下文
典型特征 用户实时兴趣向量、物品实时热度、相似物品 设备历史欺诈标签、IP 关联风险、行为序列异常分
服务要求 高吞吐(万级 QPS)、可接受少量降级 高可用(99.99%)、强一致性、低延迟(P99 < 20ms)
特征服务价值 统一特征口径,避免“特征穿越”,支持实时模型更新 提供实时风险画像,支撑毫秒级决策,降低误杀率

在实时推荐中,特征服务的核心价值在于统一特征口径。离线训练时使用的特征逻辑与在线推理时使用的特征逻辑必须完全一致,否则会出现“训练-推理不一致”问题,导致模型效果大幅下降。特征服务通过注册中心管理特征定义,确保离线与在线使用同一份特征计算代码。

在实时风控中,特征服务的核心价值在于毫秒级风险画像。风控决策通常需要在 100ms 内完成,而特征服务通过预计算+缓存+降级策略,将特征获取延迟压缩到 10ms 以内。同时,风控场景对特征一致性要求极高——如果特征值出现“跳变”或“延迟”,可能导致误杀或漏杀。

实战经验:在风控场景中,特征服务通常需要支持“特征回溯”能力。当模型判定一笔交易为高风险时,风控系统需要回溯该交易发生时刻的特征快照,用于后续模型训练与审计。这要求特征服务不仅提供最新值,还要提供时间戳维度的历史版本。

1.3 与离线特征的区别

离线特征与实时特征在计算模式、存储介质、服务方式上存在本质差异。下表从 8 个关键维度进行对比:

对比维度 离线特征 实时特征(特征服务)
计算引擎 Spark / Hive / MapReduce(批处理) Flink / Kafka Streams / Spark Streaming(流处理)
数据源 HDFS / Hive 表 / 离线日志 Kafka / Pulsar / 数据库 CDC 流
计算频率 天级 / 小时级(T+1 或 T+H) 秒级 / 毫秒级(事件驱动)
存储介质 HDFS / Hive / 对象存储 Redis / HBase / 内存 KV 存储
访问方式 SQL 查询 / 批量导出 RPC 接口 / SDK 调用(毫秒级响应)
特征时效 过去一天/一小时的状态 当前时刻(最近一个事件)的状态
一致性要求 最终一致性(允许延迟) 强一致性或最终一致性(视场景而定)
典型场景 用户画像宽表、物品基础属性、历史统计特征 实时点击序列、设备风险分、实时 CTR 特征

离线特征与实时特征并非互斥关系,而是互补的。一个完整的特征体系通常包含三层:

  • 基础层(离线):用户注册信息、物品类目、历史累计统计等变化缓慢的特征,每天更新一次。
  • 近线层(微批):用户过去 1 小时的行为聚合、物品过去 1 小时的曝光量等,分钟级更新。
  • 实时层(流处理):用户最近一次点击、当前会话序列、设备实时风险分等,秒级/毫秒级更新。

特征服务通常负责近线层与实时层的特征生产与暴露,同时通过特征注册中心与离线特征保持逻辑一致。

常见误区:不要试图将所有离线特征都实时化。实时计算成本远高于离线批处理,且部分特征(如用户 30 天累计消费金额)天然适合离线计算。正确的做法是:按特征更新频率分层,只有对实时性敏感的特征才接入特征服务。

1.4 特征服务架构概览

下图展示了一个典型的特征服务架构,包含实时计算层、特征存储层、服务暴露层与监控管理层:

特征服务架构概览 数据源 Kafka / Pulsar / CDC 离线特征 Hive / HDFS 宽表 近线特征 分钟级聚合任务 实时计算层 Flink 流处理作业 · 因子计算 · 特征变换 窗口聚合 · 维表关联 · 状态管理 · 特征注册 特征存储层 Redis Cluster · HBase · 本地缓存 · 特征快照 服务暴露层 gRPC / HTTP API · SDK · 批量获取 · 降级熔断 监控 管理 特征服务通过注册中心统一管理特征定义,确保离线与在线特征逻辑一致

上图展示了特征服务的四层架构:数据源层(实时流、离线、近线)→ 实时计算层(Flink 作业)→ 特征存储层(Redis/HBase)→ 服务暴露层(API/SDK)。监控与管理贯穿所有层级,确保特征服务的可观测性与运维效率。

1.5 本章小结

  • 特征服务是实时推荐与风控系统的核心中间件,负责特征的生产、存储、获取与生命周期管理。
  • 在实时推荐中,特征服务的核心价值是统一特征口径与实时特征供给;在实时风控中,核心价值是毫秒级风险画像与特征回溯。
  • 离线特征与实时特征在计算引擎、存储介质、访问方式、时效性上存在本质差异,两者互补构成完整特征体系。
  • 特征服务架构通常包含实时计算层、特征存储层、服务暴露层与监控管理层,其中 Flink 是实时计算层的核心引擎。