1. 课程导学与架构总览：实时特征平台的价值、技术选型与整体架构
大家好，欢迎来到《从零搭建实时特征平台》的第一章。
做实时特征这件事，我最早接触是在几年前的一个风控项目里。当时业务方提了个需求：用户点击按钮后，500 毫秒内要判断这笔交易是不是欺诈。传统的离线特征根本来不及，等特征算出来，钱早就转走了。嗯，从那时起我就意识到——实时特征不是锦上添花，而是很多场景的刚需。
1.1 为什么需要实时特征平台？
说白了，实时特征就是「数据还在路上，特征就已经算好了」。它跟离线特征最大的区别在于时效性。
| 对比维度 | 离线特征 | 实时特征 |
|---|---|---|
| 计算延迟 | 小时级 / 天级 | 秒级 / 毫秒级 |
| 数据范围 | 全量历史数据 | 滑动窗口 + 最新事件 |
| 典型场景 | 用户画像、推荐召回 | 实时风控、动态定价、在线推荐 |
| 存储介质 | Hive / HDFS | Redis / 内存 KV |
你想想看，一个推荐系统如果只能每天更新一次用户兴趣，那用户上午搜了「机械键盘」，下午还在推「办公鼠标」——体验能好吗？实时特征就是来解决这类问题的。
核心价值总结：
- 降低决策延迟：从小时级降到秒级
- 提升模型效果：特征新鲜度直接影响 AUC
- 支撑在线业务：风控、推荐、搜索都离不开
1.2 技术选型：为什么是 Flink + Kafka + Redis？
选型这件事，我踩过不少坑。最开始我们试过用 Spark Streaming 做实时特征，但延迟始终压不到 100ms 以内。后来换了 Flink，才真正把端到端延迟降下来。
下面说说我这套选型的理由：
1.2.1 Kafka —— 消息队列的「硬通货」
Kafka 在实时数据管道里几乎是标配。它提供高吞吐、持久化、可重放的消息队列。我个人习惯把 Kafka 当作实时特征的「数据总线」——所有原始事件先进 Kafka，下游各取所需。
1.2.2 Flink —— 真正的流计算引擎
Flink 跟 Spark Streaming 最大的区别在于：Flink 是真正的逐条处理，而不是微批次。这意味着延迟更低，而且支持精确一次语义。我在项目中遇到过因为 checkpoint 配置不当导致特征重复计算的问题，后来调整了 Flink 的 exactly-once 模式才解决。
1.2.3 Redis —— 特征存储的「快车道」
特征算出来之后放哪？不能放 HBase，延迟太高。Redis 的纯内存操作，单次读写通常在 1ms 以内。我们通常用 Redis 的 Hash 结构存储用户特征，用 Sorted Set 存储滑动窗口计数。
| 组件 | 选型理由 | 替代方案 |
|---|---|---|
| Kafka | 高吞吐、持久化、可重放 | Pulsar、RocketMQ |
| Flink | 真正流计算、低延迟、状态管理 | Spark Streaming、Storm |
| Redis | 毫秒级读写、丰富数据结构 | Memcached、Tair |
避坑指南： 我曾经在选型时忽略了 Redis 的内存容量规划，结果上线后特征数据量暴涨，Redis 内存被打满，导致服务 OOM。后来加了淘汰策略和容量预警才稳住。
1.3 整体架构图
下面这张图展示了我们这门课要搭建的实时特征平台的整体架构。它分为四层：数据接入层、计算层、存储层和服务层。
这张图看起来简单，但每一层都有不少细节。比如 Kafka 的 topic 分区策略怎么设计？Flink 的 state backend 选 RocksDB 还是 Heap？Redis 的 key 结构怎么规划才能避免热 key 问题？这些我们后面都会一一展开。
1.4 课程内容概览
这门课一共 30 章，我把它分成了四个阶段：
- 基础搭建（第 1-8 章）：环境准备、Kafka 集群部署、Flink 开发环境、Redis 配置
- 核心开发（第 9-18 章）：实时特征计算逻辑、滑动窗口实现、维表关联、状态管理
- 性能优化（第 19-25 章）：反压处理、checkpoint 调优、Redis 性能优化、数据倾斜解决
- 生产实践（第 26-30 章）：监控告警、灰度发布、容量规划、线上问题排查
注意： 这门课不是纯理论，每一章都有可运行的代码和配置。我建议你跟着动手敲一遍，光看是学不会的。我曾经带过的新人里，动手实践的和只看不练的，三个月后差距非常明显。
1.5 你需要准备什么？
硬件方面，一台 8G 内存的电脑就够了。我们会用 Docker Compose 搭建集群，所以不需要多台服务器。
软件方面，你需要安装：
- JDK 8 或 11
- Maven 3.6+
- Docker & Docker Compose
- IntelliJ IDEA 或 VS Code