1. 流批一体是什么？
大家好，我是你们这门课的老朋友。今天咱们聊聊流批一体最核心的问题——它到底是什么，以及我们为什么非它不可。
说实话，我第一次接触“流批一体”这个概念时，也觉得有点玄乎。但干久了你会发现，它其实没那么复杂。说白了，就是同一份数据，同一份逻辑，两种运行模式。
嗯，这句话我建议你记下来。它是整门课的基石。
传统架构的痛点：Lambda 的“两套代码”噩梦
在讲流批一体之前，咱们得先看看以前是怎么干的。最经典的，就是 Lambda 架构。
Lambda 架构长什么样？它把数据处理分成了两条路：
- 批处理层：处理全量历史数据，追求高吞吐、高准确。比如跑 T+1 的报表。
- 流处理层：处理实时增量数据，追求低延迟。比如做实时大屏。
听起来挺合理，对吧？但我在项目中踩过一个大坑。
问题出在哪？我列给你看：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 代码不一致 | 批处理用 SQL，流处理用 DataStream API，逻辑翻译时容易出错 | 批量和实时结果对不上，业务方天天投诉 |
| 维护成本高 | 改一个业务规则，要改两套代码，测试两遍 | 开发周期翻倍，上线风险也翻倍 |
| 数据口径混乱 | 批处理用“下单时间”，流处理用“支付时间”，口径不统一 | 报表数据打架，没人说得清哪个是对的 |
| 资源浪费 | 两套集群、两套运维、两套监控 | 硬件成本和人力成本都居高不下 |
你想想看，每次业务方问“为什么实时数据和昨天报表对不上”，我们都要花半天去排查。是代码写错了？还是口径变了？还是数据延迟了？这种日子，我过了整整一年。
核心矛盾：Lambda 架构的本质，是用两套不同的技术栈去解决同一个问题。这就像你用左手画圆、右手画方，最后两个都画不圆。
流批一体的核心思想：同一份数据，同一份逻辑，两种运行模式
那流批一体是怎么解决这个问题的？
它的思想其实很朴素：你只需要写一份代码，定义好业务逻辑。然后告诉系统，这次是跑批处理还是流处理，系统自己会选择合适的执行引擎。
我习惯用一个比喻来解释：
- 传统 Lambda：你有一辆汽油车和一辆电动车。去同一个地方，你得开两辆车，还得分别保养。
- 流批一体：你有一辆混动车。它既能烧油跑长途（批处理），也能用电跑市区（流处理）。你只管踩油门，动力系统自己切换。
是不是好理解多了？
具体到技术层面，流批一体的核心包含三个要素：
- 同一份数据模型：不管是批还是流，数据源的表结构、字段定义完全一致。不存在“批处理用 A 表，流处理用 B 表”的情况。
- 同一份计算逻辑：业务逻辑用统一的 API 表达。比如 Flink SQL，你在 SQL 里写一个
SUM(amount)，它既可以在批模式下跑全量数据，也可以在流模式下跑增量数据。 - 两种运行模式：系统根据你的配置，自动选择批执行计划或流执行计划。批模式追求吞吐，流模式追求延迟，但代码本身不用改。
我个人经验：刚开始接触流批一体时，别急着把老系统全推倒重来。我建议你先选一个业务场景做试点，比如“用户行为分析”。用 Flink SQL 写一份逻辑，分别跑批和流，对比结果。等验证通了，再逐步推广。
流批一体的核心逻辑图
下面这张图，我画出了流批一体的核心流程。你可以看到，数据源、计算逻辑、结果输出这三个层次，在批和流两种模式下是如何统一的。
流批一体到底解决了什么问题？
咱们总结一下。流批一体带来的好处，我归纳为三点：
- 开发效率翻倍：只写一份代码，批和流都搞定。改逻辑也只需要改一处。
- 数据一致性有保障：同一份逻辑跑出来的结果，天然对齐。再也不用半夜爬起来对数据了。
- 运维成本降低：一套集群、一套监控、一套部署流程。资源利用率也更高。
一句话总结：流批一体不是要消灭批处理或流处理，而是让它们共用一套“大脑”。你只需要关心业务逻辑怎么写，剩下的交给框架。
嗯，这一章的内容就到这。记住那个核心思想——同一份数据，同一份逻辑，两种运行模式。后面的章节，我们会一步步把它拆开，看看具体怎么落地。