1. 流处理基石

大家好，欢迎来到《实时流处理性能调优实战》的第一章。

做实时计算这些年，我见过太多团队一上来就追新框架、调参数，结果连最基础的概念都没对齐。说白了，地基没打牢，楼盖得再高也是危房。这一章，咱们就把流处理的几个核心基石夯实了。

1.1 实时计算到底是什么？

先问个问题：你理解的「实时」是多快？

有人觉得秒级响应就算实时，有人要求毫秒级，还有人认为只要数据产生后能尽快看到结果就行。其实，在工程领域，实时计算指的是数据从产生到被处理并输出结果，整个延迟在可接受的短时间范围内（通常是秒级甚至毫秒级）。

我习惯把实时计算拆成三个关键特征：

• 低延迟：数据流动快，处理速度快，不积压。
• 持续处理：数据源源不断，系统7x24小时运行。
• 事件驱动：每条数据到来都会触发计算逻辑。

举个例子，你在电商网站点了个「立即购买」，后台的实时风控系统必须在几百毫秒内判断这笔交易有没有风险。这就是典型的实时计算场景。

1.2 Lambda 架构 vs Kappa 架构

聊到实时计算，绕不开两个经典架构：Lambda 和 Kappa。我在2016年第一次给公司设计实时数仓时，就踩过 Lambda 的坑，后来才切到 Kappa。咱们来对比一下。

1.2.1 Lambda 架构

Lambda 架构把数据流拆成两条路：

• 批处理层：处理全量历史数据，保证准确性，但延迟高。
• 流处理层：处理实时增量数据，保证低延迟，但可能有误差。

最后通过一个「合并层」把两边的结果拼起来给用户。

听起来很完美对吧？但我在项目中遇到过一个问题：维护两套代码。批处理用 Hive/Spark SQL，流处理用 Flink/Storm，同样的业务逻辑要写两遍，还经常对不上结果。每次排查数据不一致，都像在破案。

1.2.2 Kappa 架构

Kappa 架构就简单多了——只用一套流处理引擎。所有数据都走实时流，历史数据重算时，直接从消息队列的源头重新消费一遍。

它的核心假设是：消息队列（如 Kafka）能保存足够长的历史数据，并且流处理引擎能处理全量数据。

对比维度	Lambda 架构	Kappa 架构
代码维护	两套代码（批+流）	一套代码（纯流）
数据一致性	容易产生偏差	天然一致
历史重算	批处理层直接重算	重新消费 Kafka 数据
运维复杂度	高（两套系统）	低（单一引擎）
适用场景	对历史数据准确性要求极高	大部分实时数仓场景

我个人更倾向 Kappa 架构。你想想看，如果 Kafka 能保留7天甚至30天的数据，配合 Flink 的状态后端，大部分场景根本不需要批处理层。当然，如果你的业务要求对几年前的数据做精确回溯，Lambda 可能还是逃不掉。

1.3 流处理与批处理的核心差异

很多人觉得流处理和批处理只是「处理方式不同」，其实它们的底层思维模型完全不一样。

1.3.1 数据视角不同

• 批处理：数据是「有界的」。你知道数据集有多大，什么时候结束。
• 流处理：数据是「无界的」。你不知道下一秒会来多少数据，也不知道什么时候结束。

这个差异决定了后续所有的设计选择。

1.3.2 时间语义不同

批处理通常只关心「处理时间」——什么时候跑任务。但流处理必须区分：

• 事件时间：数据实际发生的时间。
• 处理时间：数据到达系统的时间。
• 摄入时间：数据进入消息队列的时间。

我记得有一次做用户点击流分析，用处理时间做窗口，结果因为网络延迟，凌晨的数据被算到了早上8点的窗口里。嗯，从那以后我再也不敢忽略事件时间了。

1.3.3 容错机制不同

批处理失败了大不了重跑整个任务。流处理呢？系统跑了三天三夜，突然挂了，重启后怎么保证数据不丢不重？

流处理需要状态一致性机制，比如 Flink 的 Checkpoint + 精确一次语义。这比批处理的「重跑」复杂得多。

1.4 本章知识体系总览

下面这张图，我把本章的核心知识点串了起来。你可以把它当作一张「地图」，后面每章都会在这张图上展开。

1.5 本章小结

这一章我们聊了三件事：

1. 实时计算的本质是低延迟、持续处理、事件驱动。
2. Lambda 和 Kappa 架构各有优劣，我个人推荐新项目优先 Kappa。
3. 流处理与批处理的核心差异在于数据边界、时间语义和容错机制。

这些概念看起来简单，但它们是后续所有性能调优决策的「坐标系」。比如，你为什么要调优？因为流处理的无界特性导致状态膨胀。你往哪个方向调？取决于你选的是 Lambda 还是 Kappa。你用什么手段调？得先理解事件时间和处理时间的区别。