📚 课程目录第1章流批一体概述

1. 流批一体概述：从两条路到一条路

大家好，我是这次课程的主讲。在正式开始之前，我想先聊聊我自己的经历。2015年我刚接触大数据时，团队里还在用MapReduce跑离线报表，每天凌晨两点才能看到昨天的数据。那时候谁能想到，几年后我们就能在秒级处理海量数据了？

这一章，我们不讲代码，不讲配置。先把流计算和批处理这两兄弟的来龙去脉理清楚。你只有知道它们从哪里来，才能理解为什么非要搞「流批一体」。

批处理的历史比流计算早得多。上世纪60年代，IBM的System/360就有了批处理的概念。说白了，就是把数据攒起来，等攒够了再一把处理完。

流计算呢？它诞生于对实时性的渴望。2000年代初，华尔街的交易系统需要毫秒级响应，传统的批处理根本扛不住。于是Storm、S4这些早期流计算框架应运而生。

我画了一张图，帮你快速理解这两条技术路线的演进脉络：

你可能会问：为什么批处理先出现？原因很简单——早期的数据量没大到需要实时处理。每天跑一次报表，够用了。但随着互联网爆发，数据像洪水一样涌来，批处理的滞后性成了大问题。

2011年，Nathan Marz提出了Lambda架构。这个架构的初衷是好的：用批处理层保证数据准确性，用速度层保证实时性，最后在服务层合并结果。

听起来很完美，对吧？我在2017年参与过一个电商实时大屏项目，当时就采用了Lambda架构。结果呢？噩梦才刚刚开始。

Lambda架构的核心组成：

我踩过的坑，总结下来主要有这几个：

痛点	具体表现	我遇到的真实案例
两套代码	批处理和流处理各写一套逻辑，维护成本翻倍	同一个UV统计，批处理用Hive SQL，流处理用Flink API，逻辑对不上
数据口径不一致	批处理和流处理的计算结果经常对不上	批处理算出来日活100万，流处理实时显示95万，业务方天天来问
运维复杂度高	需要同时维护两套集群、两套调度系统	凌晨批处理任务挂了，实时任务还在跑，数据对不上只能重跑
数据延迟	批处理结果通常T+1，速度层只能覆盖最近几小时	业务方上午10点想看昨天的完整数据，批处理还没跑完

避坑指南：我曾经在一个项目中，为了对齐批处理和流处理的结果，专门写了一个数据校验脚本。结果这个脚本本身就有bug，导致我们花了三周才定位到问题。如果你现在还在用Lambda架构，我建议你认真考虑迁移到流批一体方案。

说白了，Lambda架构最大的问题就是「两套逻辑」。你想想看，同一个业务需求，要在两个不同的系统里各实现一遍。而且这两个系统用的编程模型、时间语义、状态管理完全不一样。不出问题才怪。

2014年，Jay Kreps（Kafka的作者）提出了Kappa架构。他的想法很激进：为什么不用一套流处理系统搞定所有事情？

Kappa架构的核心思想是：所有数据都当作流来处理。批处理只是流处理的一个特例——把历史数据重新回放一遍而已。

Kappa架构的核心原则：

我记得第一次看到Kappa架构时，心里想的是：这能行吗？历史数据那么多，全从Kafka回放，性能扛得住吗？

后来在实践中发现，Kappa架构确实有它的局限性：

但Kappa架构的价值在于：它打破了「批处理必须用批处理引擎」的思维定式。你想想看，如果流处理引擎能同时处理好批处理和流处理，为什么还要维护两套系统？

流批一体，说白了就是「一套代码，两种运行模式」。同一个作业，在批模式下处理历史数据，在流模式下处理实时数据。结果完全一致，不需要任何数据校验。

我参与过的一个金融风控项目，从Lambda架构迁移到流批一体后，效果非常明显：

维度	Lambda架构	流批一体	提升
代码量	两套代码，约5000行	一套代码，约2000行	减少60%
运维成本	两个集群，4人维护	一个集群，2人维护	减少50%
数据一致性	需要额外校验	天然一致	100%可靠
开发周期	平均2周	平均5天	缩短60%

我的建议：如果你现在正在设计新的数据架构，直接上流批一体。如果是存量系统，建议从非核心业务开始迁移。不要试图一次性把所有业务都迁过来，那样风险太大。

流批一体的核心价值，我总结为三点：

嗯，这里要注意一点：流批一体不是银弹。如果你的业务场景对实时性要求不高，或者数据量特别小，传统的批处理方案可能更合适。但如果你需要同时处理实时数据和历史数据，流批一体是当前的最佳选择。

最后，我用一张图总结本章的核心内容：