📚 课程目录第3章特征服务架构

3、特征服务架构：在线特征存储、离线特征计算、特征管道、特征血缘

特征服务是实时计算与机器学习之间的桥梁。在 Flink 特征服务体系中，架构被拆解为四个核心领域：在线特征存储、离线特征计算、特征管道与特征血缘。理解这四者的职责与交互，是构建批次偏移诊断与告警系统的基础。

特征服务架构采用分层设计，每一层解决特定的问题。离线层负责历史数据的大规模批处理与回溯；在线层提供毫秒级特征查询；管道层串联数据流转与特征生成；血缘层则记录特征的来源、变换与依赖关系。

  架构核心原则：离线特征用于模型训练与批量回溯，在线特征用于实时推理；特征管道保证两者计算逻辑一致，血缘层则确保问题可追溯、可复现。

在线特征存储是实时推理的基石。模型在推理时刻需要获取当前样本的最新特征值，这些特征必须能够在毫秒级返回。常见的在线存储选型包括 Redis、HBase、Cassandra 以及专用的特征存储系统（如 FeatHub、Feast）。

实践建议：在线特征存储应支持 TTL（生存时间） 机制，避免过期特征污染推理结果。对于批次偏移诊断场景，建议在特征值中额外存储 更新时间戳，便于判断特征是否滞后。

离线特征计算负责从原始数据中生成历史特征，用于模型训练、离线评估以及批次偏移的基准对比。通常使用 Flink Batch、Hive、Spark 等批处理引擎，按天或小时粒度产出特征快照。

批次偏移风险点：离线特征计算通常基于全量历史数据，而在线特征仅基于实时到达的增量数据。当离线与在线的数据源存在时间差或逻辑差异时，就会产生批次偏移。这是本课程后续诊断与告警的核心关注点。

特征管道是连接离线计算与在线存储的数据高速公路。它负责将离线计算好的特征数据同步到在线存储，同时将实时流中的特征更新写入在线存储。特征管道必须保证数据一致性与低延迟。

特征血缘记录了每个特征从原始数据 → 特征计算 → 特征存储 → 模型使用的完整链路。在批次偏移诊断中，血缘是定位问题根因的关键工具。

血缘维度	记录内容	诊断价值
数据源血缘	特征来源于哪个 Kafka Topic / Hive 表 / 数据库	快速定位数据源变更或延迟
计算逻辑血缘	特征使用的 Flink SQL / UDF / 窗口定义	对比离线与在线计算逻辑是否一致
时间戳血缘	特征值对应的业务时间、处理时间、写入时间	判断特征是否滞后或时间窗口错位
版本血缘	特征计算代码版本、模型版本、存储版本	回滚或复现特定版本的特征

  批次偏移诊断中的血缘应用：当告警系统检测到特征分布偏移时，通过血缘链路可以快速回溯：是离线特征计算逻辑变更？还是在线特征管道延迟？还是数据源时间窗口不一致？血缘让问题定位从“猜测”变为“可追溯”。

以“用户实时点击率预估”为例，展示四层如何协作：

离线特征计算：每天凌晨使用 Flink Batch 计算用户过去 7 天的点击统计特征，写入 Hive 表。
特征管道：Flink 作业读取 Hive 表，将历史特征批量加载到 Redis；同时消费实时点击流，增量更新用户最新点击次数。
在线特征存储：模型服务在推理时，通过 Key（用户 ID）从 Redis 获取特征，延迟 < 2ms。
特征血缘：当发现某个用户的“近 7 天点击率”特征值异常偏低时，通过血缘追溯到：该特征依赖的离线计算窗口被误改为“近 3 天”，导致离线与在线特征不一致，产生批次偏移。

架构设计要点：在 Flink 特征服务中，建议将特征管道与血缘系统深度集成。Flink 作业在写入特征时，同时输出一条血缘日志到元数据中心，记录特征 ID、时间戳、计算逻辑版本、数据源偏移量等信息。这为后续的批次偏移诊断提供了最直接的证据。