1. 实时特征平台概述：架构演进、核心组件、数据流全景图

大家好，我是这次课程的主讲。在开始讲故障排查之前，我觉得有必要先把实时特征平台这个「战场」的全貌讲清楚。你想想看，如果连地图都没看明白，怎么去排雷？

实时特征平台，说白了就是为机器学习模型在线提供特征的「水龙头」。模型推理的时候，需要最新的用户行为、环境状态、业务指标，这些数据不能从离线数仓慢慢拉，必须毫秒级地从实时流里算出来。我见过不少团队，一上来就扎进代码里调优，结果发现瓶颈根本不在代码，而在架构设计上。所以，这一章我们先站高一点，看看这个平台到底长什么样。

1.1 架构演进：从单体到流批一体

实时特征平台的架构不是一天建成的。我大概经历了三个阶段，每个阶段都有血泪教训。

阶段	核心特点	典型问题
V1.0 单体时代	Flink + Redis，所有逻辑写在一个大作业里	耦合严重，一个特征变更要重启整个作业；Redis 内存爆炸
V2.0 微服务化	特征计算拆分到独立服务，引入消息队列解耦	服务间调用链路过长，延迟抖动；数据一致性难保证
V3.0 流批一体	Flink SQL + 实时数仓，离线/实时共用一套口径	运维复杂度高，但解决了「线上线下不一致」的顽疾

我个人习惯把 V3.0 称为「理想态」。为什么？因为它解决了实时特征最头疼的问题——特征口径不一致。我记得有一次排查线上模型效果暴跌，最后发现是离线训练用的特征和在线推理用的特征，计算逻辑差了 3 行代码。嗯，从那以后，我坚决推动流批一体。

1.2 核心组件：你必须要认识的几个角色

一个成熟的实时特征平台，通常由以下组件构成。我把它们比作一个「流水线工厂」：

• 数据源层：Kafka / Pulsar。这是原料入口。我建议所有业务日志必须走统一的消息队列，不要搞「点对点直连」，否则后期排查数据丢失会让你崩溃。
• 计算引擎层：Apache Flink。这是核心加工车间。Flink 负责做窗口聚合、维表关联、状态管理。我在项目中遇到过因为 Checkpoint 超时导致整个作业反压的案例，后面会详细讲。
• 存储层：Redis / HBase / Cassandra。这是成品仓库。特征计算完要存起来，供模型在线读取。选型要看你的特征大小和 QPS。我个人偏爱 Redis Cluster，但要注意大 Key 问题。
• 服务层：特征获取服务 (Feature Store Service)。这是出货口。模型通过 RPC 或 HTTP 来拉特征。这里要关注超时和限流。
• 元数据中心：特征注册表。这是工厂的「图纸」。记录每个特征的定义、来源、口径、版本。没有这个，排查问题就像盲人摸象。

1.3 数据流全景图：一条特征的生命周期

光说组件太抽象，我们画一张图。下面这张 SVG 展示了从「用户点击」到「模型拿到特征」的完整链路。

这张图里，我特意标出了几个「常见故障点」。你仔细看，从 Kafka 到 Flink，从 Flink 到 Redis，每一步都可能出问题。我曾经遇到过一个案例：Flink 作业正常运行，但 Redis 的某个特征 Key 因为业务增长变成了大 Key，导致读写延迟从 1ms 飙升到 200ms，最终拖垮了整个模型推理。排查了整整两天，最后发现是上游数据量暴增，但特征设计没考虑分桶。

1.4 核心数据流：实时 vs 离线

很多同学会混淆「实时特征」和「离线特征」。我简单做个对比：

维度	实时特征	离线特征
时效性	毫秒 ~ 秒级	小时 ~ 天级
计算引擎	Flink / Spark Streaming	Hive / Spark SQL
存储	Redis / HBase	HDFS / Hive 表
典型场景	推荐、广告、风控	报表、分析、模型训练
故障影响	直接影响线上推理	影响模型更新

这里有个坑：实时特征和离线特征的计算口径必须一致。我见过最离谱的案例是，实时特征用「过去 1 小时点击次数」，离线特征用「过去 24 小时点击次数」，模型训练时混在一起用，结果线上效果一塌糊涂。所以，流批一体不仅仅是架构上的统一，更是语义上的统一。

1.5 本章小结

这一章我们快速过了一遍实时特征平台的架构、组件和数据流。你不需要记住所有细节，但脑子里要有一张「全景图」：数据从哪里来，经过谁处理，存在哪里，最终被谁消费。故障排查的本质，就是在这张图上找到「断点」或「瓶颈」。