1. 流处理概述：实时流处理 vs 批处理、典型应用场景、主流框架对比
各位同学，咱们今天聊聊流处理。说实话，我入行那会儿，大家还在吭哧吭哧跑 T+1 的离线任务。早上到公司第一件事，先看昨天的报表跑完没。要是凌晨调度挂了，整个上午就废了。
后来业务方跟我说：「你能不能让我看到最近 5 分钟的成交趋势？」我当时的反应是——5 分钟？你疯了吧？
嗯，现在回头看，实时流处理已经成了数据架构的标配。今天这一章，咱们把基础打牢。
1.1 实时流处理 vs 批处理：到底差在哪？
先问个问题：批处理和流处理，本质区别是什么？
很多人会说「一个处理历史数据，一个处理实时数据」。这话没错，但太笼统了。我习惯从三个维度去拆解：数据范围、触发方式、延迟要求。
| 对比维度 | 批处理 | 流处理 |
|---|---|---|
| 数据范围 | 有限数据集（已落盘） | 无限数据流（持续到达） |
| 触发方式 | 定时调度（如每小时/每天） | 事件驱动（数据一到就处理） |
| 典型延迟 | 分钟级到小时级 | 毫秒级到秒级 |
| 计算模型 | 全量扫描 + 聚合 | 增量计算 + 状态维护 |
| 容错方式 | 重跑整个任务 | Checkpoint + 精确一次语义 |
你看，批处理面对的是「已经在那里的数据」，你什么时候跑、跑多少次，结果都一样。但流处理面对的是「源源不断涌进来的数据」，你没法等所有数据到齐再动手——因为数据永远不会到齐。
核心认知：批处理是「查询静态数据」，流处理是「持续计算动态数据」。两者不是替代关系，而是互补关系。我见过太多团队一上来就想用流处理干掉所有批处理，结果搞得状态管理一团糟。
1.2 典型应用场景：风控、监控、推荐
聊点实际的。流处理到底能干什么？我挑三个最常见的场景说说。
1.2.1 实时风控
这个我最有发言权。之前在支付公司，每天几千万笔交易。用户刚点完「支付」，我们必须在 100 毫秒内判断这笔交易是不是盗刷。
怎么做？
- 用户过去 1 分钟的下单频率
- 当前设备是否在黑名单里
- 收货地址是否和常用地址匹配
- 金额是否超出历史均值 3 倍
这些判断全部依赖滑动窗口和状态存储。批处理根本做不到——等你跑完离线任务，钱早就被转走了。
避坑提醒：我曾经遇到过一个团队，把风控规则全部写在数据库存储过程里，每来一笔交易就查一次数据库。结果数据库连接池被打爆，整个支付链路都挂了。记住，实时风控的核心是内存计算 + 异步化，别把数据库当计算引擎用。
1.2.2 实时监控与告警
运维监控、业务大盘、IoT 设备状态……这些场景有个共同点：数据量大、时效性要求高、异常需要秒级响应。
举个例子。某次大促，我们监控交易成功率。如果连续 10 秒内成功率低于 95%，就要自动触发降级。用批处理？等 5 分钟跑一次调度，用户早就骂翻天了。
流处理在这里的优势是：
- 数据一到就计算，延迟控制在秒级
- 支持复杂事件匹配（如「连续 3 次失败后触发告警」）
- 可以动态调整告警阈值，不用重启任务
1.2.3 实时推荐
你刷抖音、逛淘宝，看到「猜你喜欢」——背后就是流处理在干活。
用户刚点了一个商品，系统需要：
- 记录这个点击行为
- 更新用户的短期兴趣向量
- 和商品特征做实时匹配
- 在几百毫秒内返回推荐结果
这里有个关键点：实时推荐依赖用户近期的行为序列。如果只用离线训练的模型，用户的兴趣变了你都不知道。流处理能让你「边看边学」。
1.3 主流框架对比：Flink / Spark Streaming / Storm
好，到了大家最关心的环节。市面上这么多流处理框架，到底选哪个？
我这些年三个框架都用过，踩了不少坑。直接上对比表：
| 特性 | Apache Flink | Spark Streaming | Apache Storm |
|---|---|---|---|
| 计算模型 | 真正的逐条流处理 | 微批次（Micro-batch） | 逐条流处理 |
| 延迟 | 毫秒级 | 秒级（批次间隔决定） | 毫秒级 |
| 状态管理 | 内置状态后端（RocksDB/内存） | 依赖外部存储（如 Redis） | 无内置状态，需自己维护 |
| 容错语义 | 精确一次（Exactly-once） | 精确一次（通过 WAL） | 至少一次（At-least-once） |
| SQL 支持 | Table API / SQL 原生支持 | Structured Streaming | 无原生 SQL |
| 社区活跃度 | 极高（阿里、字节等大厂主导） | 高（Databricks 推动） | 较低（已进入维护模式） |
说说我的个人感受。
Flink：我现在的主力框架。它最打动我的一点是「真正的流处理」——数据来一条处理一条，不是攒一批再算。状态管理做得也很成熟，RocksDB 后端能支撑 TB 级状态。如果你要做复杂事件处理、大状态计算，Flink 是首选。
Spark Streaming：如果你团队 Spark 技术栈已经很成熟，不想再引入一套新东西，Spark Streaming 是个稳妥的选择。但要注意，它的微批次模型决定了延迟下限——批次间隔设到 500ms 以下，调度开销就会明显上升。我见过有人设 100ms，结果集群 CPU 全花在调度上了。
Storm：嗯……说实话，Storm 已经有点过时了。它是最早的流处理框架之一，理念很先进，但生态没跟上。没有内置状态管理，容错只能做到 at-least-once，运维成本也高。我个人不建议新项目再用 Storm。
选型建议：如果你从零开始，我建议直接上 Flink。如果团队 Spark 基础好、延迟要求不那么苛刻（秒级即可），Spark Streaming 也能用。至于 Storm……除非是维护老系统，否则别碰。
1.4 流处理核心知识体系
最后，我用一张图把本章的核心脉络串起来。你想想看，流处理到底在解决什么问题？
这张图其实就概括了流处理的全部脉络：数据源 → 核心概念 → 框架选型 → 业务场景。后面的章节，我们会沿着这条线一步步深入。
嗯，第一章就到这里。内容不少，但都是基础中的基础。你把这些概念吃透了，后面学窗口、状态、容错的时候会轻松很多。