1. 流批一体概述：概念、背景、价值与对比
大家好，我是这次课程的主讲。做了十几年大数据架构，从 Hadoop 1.0 时代一路摸爬滚打过来，踩过的坑比写过的代码还多。今天咱们聊聊流批一体——这个听起来很酷、做起来很痛、但确实值得搞的方向。
1.1 流批一体到底是什么？
先别急着看定义。我问你个问题：你公司的数据架构，是不是还分着两套系统？一套跑离线批处理，一套跑实时流计算？
如果是，那你就是流批一体的潜在用户。
流批一体，说白了就是用同一套技术栈、同一套 API、同一份数据，同时处理实时数据和离线数据。你写一个 SQL，既能跑在批数据上，也能跑在流数据上。结果还是一样的。
核心定义：流批一体不是把流和批合并成一个东西，而是让它们共享计算引擎、存储层和语义层，消除架构割裂。
我个人习惯把流批一体拆成三个层面来看：
- 存储一体：数据不再分"离线表"和"实时表"，统一存一份
- 计算一体：同一个 SQL 或算子，既能跑批也能跑流
- 语义一体：批和流的结果对用户来说是一致的，不搞两套口径
嗯，这里要注意——很多厂商说自己是流批一体，其实只是把两套引擎拼在一起，底层还是各算各的。那叫"流批拼接"，不叫"流批一体"。
1.2 为什么会有流批一体？
这得从大数据架构的演进说起。我刚开始做大数据那会儿，大家还在用 MapReduce 跑 T+1 报表。后来 Storm 出来了，能处理实时数据了，大家兴奋得不行。
但问题也随之而来。
你想想看，一个公司里，离线团队用 Hive/Spark，实时团队用 Flink/Storm。两套集群、两套运维、两套数据口径。业务方问："昨天的 GMV 是多少？"离线说 1000 万，实时说 980 万。谁对？谁都不对，因为口径不一样。
我在项目中遇到过这种尴尬——老板开会问数据，离线报表和实时大屏差了 5%。我解释了半天"这是两套系统，计算逻辑不同"，老板只回了一句："那你们能不能统一一下？"
这就是流批一体的核心驱动力：业务要的是"一个数字"，不是"两个数字让你猜"。
从技术演进角度看，几个关键节点催生了流批一体：
| 阶段 | 代表技术 | 痛点 |
|---|---|---|
| 离线时代 | Hadoop MapReduce | 延迟高，只能 T+1 |
| 流计算兴起 | Storm、Spark Streaming | 与离线割裂，口径不一致 |
| Lambda 架构 | 批层 + 流层 + 服务层 | 维护两套代码，成本翻倍 |
| Kappa 架构 | 统一流处理 | 批处理能力弱，历史回溯难 |
| 流批一体 | Flink、Spark 3.x | 仍在演进，生态待完善 |
你看，从 Lambda 到 Kappa 再到流批一体，本质上都是在解决"两套系统"的问题。
1.3 流批一体的核心价值
说了这么多背景，到底流批一体能带来什么好处？我总结了几点：
- 开发效率翻倍：一个团队、一套代码、一份 SQL，搞定所有场景。不用再养两个技术栈。
- 数据一致性：批和流的结果对得上。业务方再也不用纠结"该信哪个数"。
- 运维成本降低：一套集群、一套监控、一套告警。你想想看，省了多少运维人力。
- 架构简洁：数据链路变短，中间环节变少，出问题的概率自然降低。
我的经验：流批一体最大的价值不是技术上的，而是组织上的。它让"离线团队"和"实时团队"合并了，减少了沟通成本和扯皮。我曾经见过两个团队因为口径问题吵了三个月，最后架构师出面才解决。流批一体从根上避免了这种内耗。
1.4 与传统架构的对比
咱们拿最常见的 Lambda 架构来对比。Lambda 架构长这样：
数据源 → 批处理层（离线计算） → 批视图
→ 流处理层（实时计算） → 实时视图
↓
服务层（合并结果）看着挺合理对吧？但实际跑起来，问题一堆：
- 批层和流层各写一套逻辑，同样的需求做两遍
- 批视图和实时视图合并时，需要处理时间窗口对齐问题
- 一旦数据回溯，批层重跑，流层也得跟着调整
流批一体架构就简单多了：
数据源 → 统一存储层（消息队列 + 对象存储）
↓
统一计算引擎（Flink / Spark）
↓
统一结果输出说白了，就是把"两条路"走成"一条路"。数据进来之后，先落到统一存储层，计算引擎根据需求选择批模式或流模式，但底层数据是同一份。
我做个表格，方便你对比：
| 维度 | 传统 Lambda 架构 | 流批一体架构 |
|---|---|---|
| 代码复用 | 低，批和流各写一套 | 高，同一套代码 |
| 数据一致性 | 难保证，口径易偏差 | 天然一致 |
| 运维复杂度 | 高，两套集群 | 低，一套集群 |
| 历史回溯 | 批层支持，流层困难 | 统一支持 |
| 实时性 | 流层好，批层差 | 按需切换模式 |
| 学习成本 | 高，需掌握多种技术 | 相对低，聚焦一个引擎 |
注意：流批一体不是银弹。如果你的场景只有纯离线或纯实时，没必要硬上。我见过一些团队为了"技术先进"强行上流批一体，结果把简单问题搞复杂了。选型要务实。
1.5 流批一体的知识体系
为了让你对本章内容有个整体认知，我画了一张图。这张图涵盖了流批一体的核心要素和它们之间的关系：
这张图把流批一体的核心要素串起来了。你看，从"三个一体"出发，对应到具体的驱动因素，再对比传统架构的演进路径。后面几章我们会逐一深入每个层面。
1.6 小结
这一章我们聊了流批一体的概念、背景、价值和对比。说白了，流批一体就是用一套架构解决所有数据处理问题，让离线不再"离线"，实时不再"孤立"。
我个人觉得，流批一体是大数据架构发展的必然方向。虽然现在还有不少挑战——比如状态管理、Exactly-Once 语义、存储选型等——但方向是对的。