实时分析场景概述：实时数仓的演进、Lambda架构与Kappa架构、物化视图在其中的定位

大家好，我是这次课程的主讲。今天我们来聊聊实时分析场景的底层逻辑。

很多人一上来就问我：「老师，实时数仓到底怎么搭？」其实，在动手之前，你得先搞清楚一个问题——你的业务到底需要多「实时」？

我见过不少团队，一听说要搞实时，直接上 Flink + Kafka，结果发现业务方要的只是「小时级」的报表。嗯，这就有点杀鸡用牛刀了。所以，我们先从实时数仓的演进说起，看看这条路是怎么走过来的。

实时数仓的演进：从离线到近实时

最早的时候，大家做数仓都是 T+1 的。每天凌晨跑批，第二天早上看报表。这模式很成熟，但有个硬伤——你没法在中午 12 点看到上午 11 点的数据。

后来，业务方开始喊：「我要看今天的实时销售额！」于是，我们开始尝试「近实时」方案。比如每 5 分钟拉一次增量数据，或者用 Spark Streaming 做微批次处理。这算是一个过渡阶段。

再往后，随着 Flink 这类纯流引擎成熟，真正的「实时数仓」才成为可能。我个人习惯把实时数仓的演进分成三个阶段：

阶段	典型技术	延迟	痛点
离线数仓	Hive、Spark SQL	T+1	无法支持实时决策
近实时数仓	Spark Streaming、微批次	分钟级	架构割裂，维护成本高
实时数仓	Flink、Kafka、物化视图	秒级	状态管理复杂，一致性难保证

你看，从离线到实时，本质上是在用「计算延迟」换「数据新鲜度」。但这里有个坑——你越想实时，架构就越复杂。

Lambda 架构：批流分离的「老大哥」

说到实时数仓，绕不开 Lambda 架构。这玩意儿是 Nathan Marz 提出来的，核心思想很简单：批处理层 + 流处理层 + 服务层。

批处理层负责全量数据，保证准确性；流处理层负责增量数据，保证低延迟；服务层把两边的结果合并，对外提供服务。

听起来很完美，对吧？但我在实际项目中踩过坑——维护两套代码，太痛苦了。

举个例子：你写了一个批处理逻辑，算用户 PV。然后流处理那边也得写一遍，逻辑还得一模一样。一旦业务规则变了，两边都得改。稍有不慎，批和流的结果就对不上了。

Lambda 架构的典型流程是这样的：

原始数据
    ├── 批处理层 (Hive/Spark) → 全量表
    │       └── 合并查询 → 最终结果
    └── 流处理层 (Flink/Storm) → 实时表

说白了，Lambda 架构是用「双倍开发成本」换「数据一致性」。对于大厂来说，人力充足，这方案还能跑。但对于中小团队，我建议你慎重。

Kappa 架构：流式一体的「新势力」

后来，Jay Kreps（Kafka 的作者）提出了 Kappa 架构。他的观点很激进：为什么非要批流两套？一套流引擎搞定所有不行吗？

Kappa 架构的核心思想是：所有数据都走流处理，批处理只是流处理的一个特例——把历史数据重新「回放」一遍就行了。

你想想看，这确实有道理。如果流引擎足够强，比如 Flink 支持 Exactly-Once 语义和长窗口，那批处理确实可以被替代。

Kappa 架构的流程更简洁：

原始数据 → Kafka (消息队列) → 流处理引擎 (Flink) → 实时结果表
                                    ↑
                            历史数据回放 (重新消费 Kafka)

但这里有个问题——Kafka 能存所有历史数据吗？ 我遇到过的情况是，Kafka 的默认保留期只有 7 天。你要回放一个月的数据，得先扩容 Topic 的 retention，而且存储成本会飙升。

对比维度	Lambda 架构	Kappa 架构
代码维护	两套代码（批+流）	一套代码（纯流）
数据一致性	批处理保证最终一致	依赖流引擎的 Exactly-Once
历史数据重算	直接跑批任务	需要 Kafka 保留全量数据
适用场景	批处理逻辑复杂且稳定	流处理为主，历史数据量可控

我个人更倾向于 Kappa 架构，前提是你的团队对流引擎足够熟悉。如果你团队里都是写 Hive SQL 的老手，硬上 Kappa 可能会翻车。

物化视图在其中的定位

好了，聊完架构，我们来说说今天的重点——物化视图。

你可能会问：「物化视图不是数据库里的老概念吗？跟实时数仓有什么关系？」

有关系，而且关系很大。

在 Lambda 架构中，批处理层和流处理层各自产出一份结果，服务层需要做「合并查询」。这个合并逻辑，其实就是一个物化视图——它把批量和实时的数据预计算好，对外暴露一个统一的查询接口。

在 Kappa 架构中，物化视图的作用更直接。流处理引擎不断消费 Kafka 数据，然后持续更新物化视图。下游应用直接查这个视图，不用关心底层是流还是批。

说白了，物化视图就是实时数仓的「缓存层」。它把复杂的实时计算逻辑封装起来，让查询变得简单。

为了让你更直观地理解，我画了一张图，展示物化视图在实时数仓中的位置：

你看，物化视图就像是一个「数据中枢」。它把实时和批量的计算结果统一管理起来，对外提供一致的查询体验。这其实就是Lambda 架构和 Kappa 架构的「粘合剂」。

我个人觉得，物化视图最大的价值在于解耦。上游的计算逻辑怎么变，下游的查询接口不用动。你只需要更新物化视图的定义，业务方完全感知不到。