一、流批一体概述：数据架构演进、Lambda 与 Kappa 对比、核心价值

大家好，我是这次课程的主讲。做了十几年数据架构，从传统数仓一路摸爬滚打到实时计算，踩过的坑不少。今天咱们先聊聊流批一体到底是怎么回事，它解决了什么问题。

说白了，流批一体不是凭空冒出来的概念。它是数据架构演进到一定阶段的必然产物。你想想看，业务对数据时效性的要求越来越高，传统离线数仓那套 T+1 的模式，在很多场景下已经撑不住了。

1.1 数据架构的演进之路

我刚开始做数据的时候，还是典型的传统数仓架构。那时候数据量不大，业务跑批都在凌晨，第二天出报表就行。架构很简单：ETL 抽数据，分层建模，最后出报表。

后来业务发展快了，老板们开始问：「能不能看到实时的交易数据？」「能不能在用户下单后立刻推荐商品？」这时候传统数仓就有点力不从心了。

于是大家开始尝试两条腿走路：

• 离线批处理：用 Hive、Spark 跑 T+1 的报表，数据量大，延迟高
• 实时流处理：用 Storm、Flink 处理秒级数据，延迟低，但计算能力有限

嗯，这里要注意，两条腿走路本身没问题，问题在于这两条路是分开修的，维护成本极高。

1.2 Lambda 架构：一个时代的妥协方案

为了解决实时和离线数据不一致的问题，Nathan Marz 提出了 Lambda 架构。它的核心思路是：

• 批处理层：处理全量历史数据，保证数据准确性
• 流处理层：处理实时增量数据，保证低延迟
• 服务层：合并批和流的结果，对外提供服务

听起来很合理对吧？但我在实际项目中踩过它的坑。

Lambda 架构本质上是一个妥协方案。它承认了批和流是两套系统，然后用服务层去弥合差异。但代价就是架构复杂度翻倍，运维成本飙升。

1.3 Kappa 架构：流处理的一统江湖

后来 Jay Kreps 提出了 Kappa 架构。他的想法很激进：为什么不用一套流处理引擎搞定所有事情？

Kappa 架构的核心思想：

• 所有数据都走流处理通道
• 历史数据重放时，从消息队列（如 Kafka）重新消费
• 批处理只是流处理的一个特例——数据量大的时候，把并行度调高就行了

我个人习惯用一句话概括：Kappa 架构把批处理变成了「慢流处理」。

但 Kappa 架构也有它的局限性。我举个例子：

1.4 Lambda vs Kappa：一张表说清楚

我整理了一个对比表格，方便你快速理解两者的差异：

对比维度	Lambda 架构	Kappa 架构
处理引擎	批 + 流，两套引擎	一套流引擎
代码维护	两套代码，逻辑重复	一套代码，逻辑统一
数据准确性	批处理保证最终一致	流处理保证精确一次
延迟	流处理低延迟，批处理高延迟	统一低延迟
历史重放	批处理直接读 HDFS	从 Kafka 重新消费
运维复杂度	高，两套系统	低，一套系统
适用场景	数据量大、历史重放频繁	数据量可控、重放不频繁

你可能会问：那到底选哪个？我的建议是：不要非此即彼。现在很多团队在实际落地时，会采用一种混合模式——核心链路用 Kappa，历史重放和全量计算用批处理补充。这就是流批一体的雏形。

1.5 流批一体的核心价值

说了这么多，流批一体到底能带来什么？我总结了三句话：

• 一套代码，两种语义：同一份业务逻辑，既能跑批也能跑流。改一个指标，不用再同步改两个作业了。
• 一份数据，统一视图：批处理和流处理共享同一份数据源，结果天然一致。业务方再也不用问「哪个数据是对的」。
• 一套运维，降低成本：只需要维护一套引擎、一套监控、一套告警。团队从「救火队」变成「建设者」。

下面这张图展示了从传统架构到流批一体的演进路径：

1.6 流批一体的技术基石

要实现流批一体，光有理念是不够的。需要几个关键的技术支撑：

• 统一的计算引擎：比如 Flink，它原生支持流处理和批处理，同一套 API 可以跑两种模式
• 统一的存储层：比如 HDFS 或对象存储，流和批读写同一份数据，避免数据拷贝
• 统一的元数据管理：这就是我们这门课的核心——数据目录。它让流和批能共享表结构、分区信息、数据血缘
• 统一的权限和治理：流和批的数据安全策略一致，避免出现「实时数据能看，离线数据不能看」的尴尬