1. 流批一体概述：Lambda 架构与 Kappa 架构对比

大家好，欢迎来到《流批一体数据管道搭建实战》的第一章。

做数据管道这些年，我见过太多团队在「实时」和「批量」之间反复横跳。说实话，我自己也踩过不少坑。今天咱们就从最基础的架构对比开始，把流批一体的来龙去脉理清楚。

1.1 为什么需要流批一体？

先问一个问题：你的数据管道，到底要「快」还是要「准」？

传统做法是两条路：

• 批处理：跑 T+1 离线任务，数据准，但慢。
• 流处理：秒级延迟，但结果可能因为乱序、延迟数据而不够精确。

业务方往往两个都要——既要实时大屏，又要精确报表。这时候，你就得想办法把两条路合并。

1.2 Lambda 架构：经典但沉重

Lambda 架构是 Nathan Marz 提出的。它的思路很简单：

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

听起来很合理对吧？但我第一次在项目里落地 Lambda 时，差点被搞疯。

Lambda 架构的优缺点很明显：

维度	优点	缺点
准确性	批处理保证最终一致	实时层可能因乱序产生偏差
延迟	流处理提供秒级响应	批处理延迟通常数小时
维护成本	架构清晰，各层职责明确	两套代码，逻辑对齐困难
资源消耗	可分别优化各层资源	整体资源开销大，数据重复存储

1.3 Kappa 架构：简化但激进

Kappa 架构是 Jay Kreps 提出的。它的核心思想是：只用一套流处理引擎，搞定所有事情。

怎么做？把所有数据都当作流来处理。历史数据通过「重放」的方式重新处理，不需要单独的批处理层。

Kappa 架构的优缺点：

维度	优点	缺点
简洁性	一套代码，一套引擎	对引擎能力要求高
维护成本	逻辑统一，无需对齐	重放历史数据时性能瓶颈
灵活性	支持实时和离线统一处理	不适合复杂 ETL 和 Ad-hoc 查询
资源消耗	资源利用率高，无重复存储	重放时可能压垮下游

1.4 Lambda vs Kappa：怎么选？

我个人的习惯是：

• 团队小、业务简单：优先 Kappa。少维护一套代码，幸福感提升明显。
• 历史数据量大、对准确性要求极高：Lambda 更稳妥。批处理层可以做数据回溯和校验。
• 混合场景：可以考虑「Lambda 架构 + Kappa 思想」——批处理和流处理共用同一套计算引擎（比如 Flink），但保留独立的批处理链路用于数据修复。

1.5 流批一体核心概念

聊完架构，咱们得统一几个关键概念。这些词在后续章节会反复出现。

• 事件时间 vs 处理时间：事件时间是数据实际发生的时间，处理时间是数据到达系统的时间。流批一体的核心就是「以事件时间为主，处理时间为辅」。
• 水位线：Flink 里用来衡量事件时间进度的机制。说白了，就是告诉系统「等到这个时间点，还没到的数据就别等了」。
• 窗口：把无限的数据流切分成有限的数据块。常见的有滚动窗口、滑动窗口、会话窗口。
• 状态：流处理中需要记住的中间结果。比如计数、求和、去重等。
• 精确一次语义：保证每条数据只被处理一次，不多不少。这是流批一体能替代批处理的基础。

1.6 适用场景分析

流批一体不是万能的。我把它适用的场景分成三类：

场景	典型需求	推荐架构
实时数仓	实时大屏 + 离线报表	Lambda 或 Kappa
实时风控	毫秒级决策 + 事后审计	Kappa
数据湖入湖	流式写入 + 批量回填	Lambda
IoT 数据处理	海量设备数据实时聚合 + 历史分析	Kappa
金融交易	精确结算 + 实时监控	Lambda

你想想看，如果你的业务对数据准确性要求极高（比如金融、医疗），Lambda 架构的批处理层就是你的「安」。如果业务更看重实时性和开发效率（比如推荐系统、监控告警），Kappa 架构会让你轻松很多。

1.7 本章知识体系总览

下面这张图，是我梳理的本章核心逻辑。你可以把它当作后续学习的导航图。

嗯，这张图把本章的核心脉络串起来了。从「快 vs 准」的矛盾出发，引出两种主流架构，再落到核心概念和适用场景。后续章节我们会逐一深入每个环节。

1.8 小结

这一章我们聊了：

• Lambda 架构和 Kappa 架构的核心思想与对比
• 流批一体的关键概念：事件时间、水位线、窗口、状态、精确一次
• 不同场景下如何选择架构

说实话，架构选型没有银弹。我见过用 Lambda 架构跑得飞起的团队，也见过 Kappa 架构翻车的案例。关键还是理解自己的业务需求和数据特征。