1. 流处理概述：流处理概念、批处理与流处理对比、实时计算应用场景
1.1 什么是流处理？
流处理，说白了就是「数据一边产生，一边处理」。
我刚开始接触这个概念时，总觉得它跟普通的数据处理没什么两样。后来在做一个实时风控项目时，才真正体会到两者的区别——数据就像流水，你不能等水流完了再分析，得在它流经的瞬间就做出判断。
流处理的核心特征有三个：
- 无界数据：数据源源不断，没有终点
- 实时性：数据到达后立即处理，延迟通常在毫秒到秒级
- 持续计算：计算逻辑长期运行，不会停止
我的理解：流处理不是一种技术选型，而是一种思维方式。它要求你从「先存后算」转向「边来边算」。我在做物联网设备监控时，每秒涌入几万条传感器数据，如果等数据落库再分析，告警早就过时了。
1.2 批处理 vs 流处理：到底差在哪？
很多人觉得批处理和流处理只是「快慢」的区别。其实不然。它们的差异体现在多个维度上。
| 对比维度 | 批处理 | 流处理 |
|---|---|---|
| 数据范围 | 有界数据（已知起止） | 无界数据（持续到达） |
| 处理延迟 | 分钟~小时级 | 毫秒~秒级 |
| 触发方式 | 定时调度或手动触发 | 数据到达即触发 |
| 计算模型 | 全量数据扫描 | 增量数据逐条或微批 |
| 状态管理 | 无状态或外部存储 | 内置状态存储 |
| 容错机制 | 重跑整个作业 | 基于 checkpoint 精确恢复 |
| 典型框架 | Hadoop MapReduce, Spark SQL | Kafka Streams, Flink, Storm |
你想想看，批处理就像拍一张照片，记录的是某个时间点的快照。而流处理像一台摄像机，记录的是整个过程。两者没有谁取代谁，关键看场景。
一个经验：我习惯用「数据新鲜度」来判断该用批处理还是流处理。如果业务能接受 5 分钟以上的延迟，批处理往往更简单、成本更低。但如果延迟要求是秒级，那就别犹豫，上流处理。
1.3 实时计算的应用场景
这些年我接触过的实时计算场景，大致可以归为以下几类：
1.3.1 实时监控与告警
这是最常见的场景。服务器日志、业务指标、用户行为……一旦出现异常，需要立刻通知。我记得有一次帮一家电商公司做支付成功率监控，要求 3 秒内发现失败率突增。用批处理根本做不到，只能上流处理。
1.3.2 实时数仓与 ETL
传统数仓是 T+1 的，现在越来越多的业务要求「分钟级」甚至「秒级」的数据可见。Kafka Streams 和 Flink 都可以做实时 ETL，把数据从 Kafka 清洗、转换后写入下游存储。
1.3.3 风控与反欺诈
每一笔交易、每一次登录，都需要在毫秒内判断风险。流处理在这里的优势是：可以维护用户维度的状态（比如过去 5 分钟的登录次数），结合规则或模型实时打分。
1.3.4 实时推荐与个性化
用户刚点了一个商品，下一秒的推荐列表就应该变化。这背后是实时的用户行为流和特征计算。
1.3.5 物联网与边缘计算
设备数据源源不断，而且很多场景下不能等数据回传到中心再处理。流处理框架可以部署在边缘节点，就地分析。
避坑提醒：我曾经在一个项目中，把「实时」理解成了「越快越好」。结果为了追求毫秒级延迟，架构搞得极其复杂，运维成本飙升。后来才明白——实时计算不是万能药，延迟要求越严，代价越大。先问清楚业务到底需要多快，再决定技术方案。
1.4 流处理的核心挑战
做流处理，有几个绕不开的坎：
- 乱序数据：网络延迟、分区不均，数据到达顺序可能跟产生顺序不一致
- 时间语义：用事件时间还是处理时间？差别很大
- 状态管理：流处理是有状态的，状态怎么存、怎么恢复？
- 精确一次语义：数据不丢不重，说起来简单做起来难
这些挑战，正是 Kafka Streams 和 Flink 各自给出不同答案的地方。后面的章节我们会逐一拆解。
1.5 流处理知识体系总览
下面这张图，是我梳理的流处理核心知识结构。你可以把它当作整个课程的地图。
1.6 小结
这一章我们聊了流处理的基本概念，对比了批处理和流处理的差异，也看了几个典型的应用场景。嗯，这里要注意——流处理不是银弹，它有自己的适用边界和代价。
接下来的课程，我们会深入 Kafka Streams 和 Flink 的细节。从 API 使用到状态管理，从时间语义到容错机制，一步步把这两个框架的异同讲清楚。