一、流批一体概述：什么是流批一体、为什么需要流批一体、流批一体的核心价值

1.1 从一个真实的“半夜电话”说起

我记得那是 2019 年双十一后的第三天。

凌晨两点，我被值班同事的电话吵醒。他说离线报表跑不出来，因为凌晨的实时数据管道把 Hive 表锁死了。我揉了揉眼睛，打开电脑一看——实时任务在写同一张表，离线任务也在读同一张表，两边互相等，谁也动不了。

这种场景，做过大数据的应该都不陌生。实时和离线，就像两个住在同一屋檐下却从不说话的室友。你用你的 Flink，我用我的 Hive/Spark，数据要存两份，代码要写两套，出问题了还要互相甩锅。

说白了，这就是典型的“流批分离”架构带来的痛点。

1.2 什么是流批一体

流批一体，不是让你把流处理和批处理写成一样的代码就完事了。

它的核心思想是：用同一套技术栈、同一套 API、同一份数据存储，同时支撑实时和离线两种计算模式。你写一次逻辑，既能在流模式下跑，也能在批模式下跑，甚至能混着跑。

举个例子。你写一个计算用户 PV 的 SQL：

SELECT user_id, COUNT(*) AS pv
FROM click_events
GROUP BY user_id;

在流批一体架构下，这段 SQL 可以直接提交到 Flink 上跑实时，也可以提交到 Spark 上跑离线。底层存储可能是 Kafka + HDFS 的组合，但上层用户感知不到差异。

1.3 为什么需要流批一体

你想想看，传统架构下我们是怎么做的？

• 实时链路： Flink 消费 Kafka，计算结果写入 Redis/ES，用于实时大屏和在线服务。
• 离线链路： 同一份数据落 HDFS，凌晨跑 Hive/Spark 任务，产出报表和 T+1 指标。

两条链路，两套代码，两份存储。问题来了：

1. 数据口径不一致。 实时算出来的 GMV 和离线算出来的 GMV 对不上，业务方天天找你对账。
2. 资源浪费严重。 同样的数据要存两份，同样的计算要跑两遍。我见过一个公司，实时集群和离线集群各自 200 台机器，利用率都不到 40%。
3. 运维成本高。 实时任务出问题要找 Flink 的人，离线任务出问题要找 Spark 的人，中间数据对不上还要找数据开发的人。一个故障排查下来，三个团队来回扯皮。

1.4 流批一体的核心价值

流批一体能解决上面这些问题吗？能，但也不是银弹。它的核心价值主要体现在三个方面：

价值维度	具体表现	我看到的实际效果
资源复用	同一份数据、同一套集群、同一份代码	某电商平台将实时和离线集群合并后，机器数量从 400 台降到 250 台
降本增效	减少重复开发、降低运维复杂度、提升数据一致性	某金融公司流批一体改造后，数据对账时间从 3 天缩短到 2 小时
架构简化	统一技术栈、统一元数据、统一调度	团队从 3 个合并成 1 个，沟通成本大幅下降

资源复用：别让机器闲着

说白了，资源复用就是让同一批机器既能跑实时任务，也能跑离线任务。白天实时任务忙，离线任务可以少跑点；晚上离线任务忙，实时任务可以降级。这样机器的利用率能提升 30%-50%。

我见过最夸张的一个案例：某公司实时集群 200 台机器，白天利用率 70%，晚上降到 10%；离线集群 200 台机器，白天利用率 20%，晚上飙到 80%。合并之后，300 台机器就搞定了，省了 100 台。

降本增效：少写代码，少加班

降本增效不是口号，是实实在在的收益。

• 开发成本降低： 原来实时和离线各写一套代码，现在写一套。我算过，至少节省 40% 的开发工作量。
• 运维成本降低： 统一监控、统一告警、统一排查。原来一个故障要拉三个群，现在一个群搞定。
• 数据一致性提升： 实时和离线用同一份数据源、同一套计算逻辑，口径对不上的问题基本消失。

1.5 流批一体的知识体系总览

下面这张图是我自己整理的流批一体知识体系。你可以把它当成整个课程的地图，后面每一章都会对应到其中的一个模块。

1.6 流批一体不是什么

最后我想澄清几个常见的误解：

• 流批一体 ≠ 只用 Flink。 你可以用 Flink，也可以用 Spark，甚至可以用 Kafka Streams。关键是统一，不是绑定某个引擎。
• 流批一体 ≠ 实时替代离线。 有些场景就是适合跑批，比如 T+1 的财务对账。流批一体是让两者共存，不是让一个消灭另一个。
• 流批一体 ≠ 一蹴而就。 我见过一个团队花了一年才完成改造。别急，慢慢来，先把基础设施搭好，再逐步迁移业务。