一、实时特征计算概述：流批一体、应用场景与技术选型
大家好，我是你们这门课的老朋友。今天咱们聊聊实时特征计算这个事儿。说实话，我刚入行那会儿，批处理和流处理还是两拨人，各玩各的。后来发现，很多场景下你根本分不清数据到底是“流”还是“批”，硬要分开搞，反而把自己绕进去了。
所以，流批一体这个概念就应运而生了。它不是什么玄学，说白了就是：同一套代码，既能处理源源不断的实时数据，也能处理已经落盘的历史数据。你想想看，这多省心。
核心观点：流批一体的本质不是消灭批或流，而是让开发者在逻辑层统一，在物理执行层由引擎自动选择最优策略。
1.1 流批一体到底是个啥？
我记得有一次，一个刚入行的同事问我：“老师，流批一体是不是就是一套代码跑两个地方？”我笑了笑，说：“差不多，但更准确的说法是——同一套逻辑，适应不同的数据节奏。”
咱们用一张图来理解这个事儿：
你看，不管是实时流还是历史批，最终都汇入同一个计算引擎。我个人习惯把这种架构叫做“逻辑统一、物理分离”。什么意思呢？就是你写代码的时候，不用关心数据是快是慢，引擎会自动帮你搞定。
1.2 实时特征计算的应用场景
聊完了概念，咱们看看这东西到底用在哪儿。我这些年踩过的坑，总结下来就三个典型场景：
- 实时推荐：用户刚点了一个商品，下一秒推荐系统就得知道他的兴趣偏移。批处理？等跑完用户都走了。
- 实时风控：我记得有个项目，用户连续输错三次密码，系统必须在 100ms 内判定是否盗号。批处理根本来不及。
- 实时报表：大屏上的 GMV 曲线，每秒钟都在跳。你总不能说“等明天跑完离线再说”吧？
我的经验：判断一个场景是否适合实时特征计算，就一个问题——这个特征在 1 秒内变化，对业务有没有影响？有，就用实时；没有，批处理更省资源。
1.3 技术选型对比：Flink vs Spark Streaming
好，到了大家最纠结的地方了。选 Flink 还是选 Spark Streaming？我当年也纠结过，后来两个都用了，才摸清楚它们的脾气。
咱们直接上表格，看得清楚：
| 对比维度 | Apache Flink | Spark Streaming |
|---|---|---|
| 处理模型 | 真正的流处理（每条记录逐条处理） | 微批处理（将流切分成小批次） |
| 延迟 | 毫秒级（事件驱动） | 秒级（批次间隔决定） |
| 状态管理 | 原生支持，内置 RocksDB 状态后端 | 依赖外部存储（如 Redis） |
| Exactly-Once | 端到端保证（两阶段提交） | 需要额外配置（如 Kafka 幂等） |
| SQL 支持 | 动态表 + 连续查询 | Structured Streaming |
| 批处理能力 | 流批一体（同一套 API） | 批处理强，但流批 API 不统一 |
| 社区活跃度 | 极高（阿里、字节等大厂主导） | 高（Databricks 主导） |
看到这个表，你可能想问：“那我到底选哪个？”
我个人习惯这样判断：
- 如果你的场景对延迟敏感（比如风控、实时推荐），选 Flink。它天生就是为流而生，毫秒级延迟不是吹的。
- 如果你的团队已经重度使用 Spark，且延迟要求不高（秒级可以接受），Spark Streaming 也能用。但要做好心理准备——流批一体在 Spark 里还是有点“拧巴”。
避坑指南：我曾经在一个项目里，为了省事儿，用 Spark Streaming 做实时特征，结果状态管理搞得一团糟。每次重启都要从 Kafka 重放数据，那叫一个痛苦。后来换成 Flink，RocksDB 状态后端一开，世界清净了。
1.4 为什么我推荐 Flink 作为本课程的主线？
嗯，这里我要说点个人偏好了。这门课咱们主要用 Flink，原因有三：
- 流批一体是 Flink 的基因，不是后加的补丁。你写一套代码，跑流跑批都行。
- 状态管理是实时特征计算的灵魂。Flink 的状态后端、Checkpoint、Savepoint，这些机制让特征计算变得可靠。
- 生态成熟。Kafka + Flink + HBase/Redis，这套组合拳在业界已经验证过无数次了。
当然，Spark Streaming 也有它的优势，比如和 MLlib 的集成。但咱们这门课聚焦的是“实时特征计算”，Flink 更对味。
一句话总结：流批一体不是选择题，而是必答题。Flink 给出了目前最好的答案。