一、流批一体概述：概念、为什么需要它、以及架构演进
大家好，我是这次课程的主讲。在数据架构这个领域摸爬滚打了十几年，我见过太多团队在“实时”和“批量”之间反复横跳。今天咱们聊的流批一体，说白了就是想把这两套东西合二为一。别急，咱们一步步拆开看。
1.1 流批一体到底是什么？
先给个最直白的定义：流批一体，就是用同一套技术栈、同一套代码逻辑，同时处理实时流数据和离线批量数据。你写一个作业，既能跑在实时数据流上，也能跑在历史大表上，结果还是一样的。
我习惯把它理解成“数据处理的统一语言”。以前你得学两门方言——Spark Streaming 一套，Hive/MapReduce 另一套。现在好了，Flink 或者 Spark Structured Streaming 让你只用一种表达方式。
核心要点：流批一体不是“流处理”和“批处理”的简单叠加，而是从计算引擎、存储格式、API 接口到运维监控的全链路统一。
举个例子。你在做 API 数据服务时，用户查一个订单的实时状态，这是流；用户跑上个月的销售报表，这是批。如果两套系统，数据口径对不上，那可就麻烦了。流批一体就是要解决这个“口径分裂”的问题。
1.2 为什么我们需要流批一体？
这个问题，我当年在做一个电商大促项目时体会特别深。白天实时大屏要秒级刷新，晚上离线报表要 T+1 产出。两套代码，两拨人维护，数据还经常对不上。你说头疼不头疼？
总结下来，核心驱动力有这么几点：
- 数据一致性：流和批用同一套逻辑，计算结果天然对齐，不再有“实时说 100，离线说 99”的尴尬。
- 开发效率：一套代码搞定两种场景，不用维护两套作业，人力成本直接砍半。
- 运维简化：监控、告警、资源调度都统一了，不用再盯着两套集群。
- 时效性升级：以前只能 T+1 的报表，现在可以做到分钟级甚至秒级，业务决策更快。
我的经验：我曾经在一个金融风控项目里，把离线模型训练和实时特征计算统一到 Flink 上。原来模型上线要两周，现在一天就能搞定。说白了，流批一体最大的价值不是技术炫酷，而是让数据真正“快”起来。
1.3 流批一体 vs Lambda 架构 vs Kappa 架构
聊架构演进，咱们得先看看前辈们是怎么做的。我画了一张对比图，方便你理解。
1.4 三种架构的详细对比
光看图可能还不够，咱们用表格把关键差异列出来。这样你面试或者做技术选型时，直接拿来用。
| 对比维度 | Lambda 架构 | Kappa 架构 | 流批一体 |
|---|---|---|---|
| 代码维护 | 两套代码（流+批） | 一套代码（纯流） | 一套代码（流/批模式切换） |
| 数据口径 | 容易不一致 | 天然一致 | 天然一致 |
| 历史重算 | 批处理直接跑 | 需要重放 Kafka | 批模式直接读存储 |
| 资源消耗 | 高（两套集群） | 中（一套集群） | 中（一套集群，弹性调度） |
| 实时性 | 秒级 | 秒级 | 秒级 |
| 批处理性能 | 优（专用引擎） | 差（重放慢） | 优（批模式优化） |
| 典型代表 | Storm + Hive | Kafka + Flink | Flink / Spark Structured Streaming |
避坑指南：我曾经在一个项目中盲目选择 Kappa 架构，结果历史数据重放时 Kafka 积压严重，批处理跑了一天都没跑完。后来改成了流批一体，用 Flink 的批模式直接读 HDFS，问题才解决。所以选型时一定要评估你的历史数据量和重放频率。
1.5 流批一体的核心优势
说了这么多，总结一下流批一体到底好在哪。我个人觉得，最核心的就三点：
- 逻辑统一：同一套 SQL 或 API，既能处理实时流，也能处理离线批。开发人员不用再学两套东西。
- 结果一致：流和批用相同的算子、相同的状态管理，计算结果天然对齐。你想想看，这得省多少对账的功夫。
- 运维简单：一套监控、一套告警、一套资源调度。不用再半夜爬起来看两套集群的健康状态。
嗯，这里要注意一点。流批一体不是银弹。如果你的场景里实时和批处理完全独立，没有交集，那强行合并反而增加复杂度。但如果你在做 API 数据服务，既要实时查询又要离线报表，那流批一体是首选。
1.6 本章小结
这一章咱们把流批一体的概念、为什么需要它、以及它与 Lambda、Kappa 架构的对比都过了一遍。说白了，流批一体就是让数据处理从“分裂”走向“统一”。