1. OLAP 基础与实时数仓概述
大家好，我是这次课程的主讲。做了十几年大数据架构，从传统数仓一路折腾到实时 OLAP，踩过的坑确实不少。今天咱们先打好地基，聊聊 OLAP 到底是什么，实时数仓又是怎么一步步演变成今天这个样子的。
说白了，OLAP 就是帮企业做「快速分析决策」的那套东西。我刚开始接触这行时，总觉得 OLAP 和 OLTP 差不多，都是查数据库嘛。后来被一个报表需求折磨了三天三夜，才真正明白这两者的区别有多大。
1.1 OLAP 概念与核心特征
OLAP（On-Line Analytical Processing，联机分析处理），核心是「分析」。它的设计目标很明确：让用户能从多个维度、多个层次快速查询和理解数据。
举个例子，一家连锁零售企业想分析「华东区上个月各品类销售额的同比变化」。这个查询涉及时间维度（上个月 vs 去年同期）、地理维度（华东区）、产品维度（品类），还要做聚合计算（销售额同比）。用 OLTP 系统跑这种查询？嗯，我试过，跑了一个多小时还没出结果，业务方直接打电话来骂人了。
OLAP 的核心特征，我总结为四点：
- 多维分析：支持按时间、地区、产品等多个维度自由组合查询
- 快速响应：秒级甚至毫秒级返回聚合结果
- 数据集成：整合来自多个源系统的数据
- 历史趋势：保留大量历史数据，支持时间序列分析
关键认知：OLAP 不是一种技术，而是一种分析模式。它关注的是「从数据中发现价值」，而不是「记录一笔交易」。
1.2 OLAP vs OLTP：两个世界的碰撞
很多新手容易把 OLAP 和 OLTP 搞混。我见过一个团队用 MySQL 直接跑百亿级数据的聚合查询，结果可想而知——数据库直接挂了。咱们用一张表把它们的核心差异说清楚：
| 对比维度 | OLTP（联机事务处理） | OLAP（联机分析处理） |
|---|---|---|
| 核心目标 | 高并发、低延迟的事务处理 | 复杂查询、多维分析 |
| 典型操作 | 增删改查（CRUD） | 聚合、分组、排序、窗口函数 |
| 数据模型 | 实体关系模型（3NF） | 星型模型、雪花模型 |
| 数据量级 | GB ~ TB 级别 | TB ~ PB 级别 |
| 响应时间 | 毫秒级 | 秒级到分钟级（可接受） |
| 典型系统 | MySQL、PostgreSQL、Oracle | ClickHouse、Doris、StarRocks |
你想想看，OLTP 就像超市收银台，每笔交易都要快速处理；OLAP 就像总部的年度经营分析会，需要从海量数据中提炼洞察。两者没有谁优谁劣，只是分工不同。
避坑指南：我曾经见过一个项目，直接在 OLTP 库上跑复杂的聚合报表，结果导致线上交易系统响应超时，损失了几十万的订单。记住：OLTP 负责「干活」，OLAP 负责「看路」，别让看路的干扰了干活的。
1.3 实时数仓的演进之路
数仓架构的演进，说白了就是业务对「数据新鲜度」的要求越来越苛刻。我入行时还在做 T+1 的离线数仓，每天凌晨跑批处理，第二天早上看报表。后来业务方说：「能不能看实时的？」于是就有了 Lambda 架构。再后来又说：「Lambda 维护两套代码太累了。」于是 Kappa 架构应运而生。
咱们用一张图来展示这个演进过程：
1.4 Lambda 架构详解
Lambda 架构是 Nathan Marz 提出的经典方案。它的核心思想是「批流分离」：
- 批处理层（Batch Layer）：处理全量历史数据，保证数据准确性
- 流处理层（Speed Layer）：处理实时增量数据，保证低延迟
- 服务层（Serving Layer）：合并批和流的结果，对外提供统一查询
我在 2018 年参与过一个电商实时大屏项目，用的就是 Lambda 架构。批处理层用 Spark 跑 T+1 的全量聚合，流处理层用 Flink 处理秒级的实时订单数据。当时觉得这个架构很完美，直到后来发现一个问题：同样的业务逻辑要在批和流里各写一遍，而且经常出现两边计算结果对不上的情况。
个人经验：Lambda 架构的「批流结果不一致」是个老大难问题。我建议在实现时，把核心业务逻辑抽象成公共函数库，批和流都调用同一份代码，能减少很多对账的麻烦。
1.5 Kappa 架构详解
Kappa 架构是 Jay Kreps（Kafka 的作者）提出的。它的理念很激进：只用一套流处理引擎，搞定所有事情。
核心思路是：
- 所有数据都进入消息队列（如 Kafka），作为统一的日志存储
- 流处理引擎（如 Flink）从 Kafka 消费数据，实时计算
- 如果需要重新处理历史数据，只需重置消费偏移量，重新跑一遍流作业
说白了，Kappa 就是把批处理也当成一种特殊的流处理——只不过这个「流」的数据量特别大，但处理逻辑是一样的。
关键区别：Lambda 是「两条腿走路」，Kappa 是「一条腿走到黑」。Kappa 的优点是架构简单、代码统一；缺点是对消息队列的存储能力和流引擎的容错能力要求极高。
1.6 Lambda vs Kappa：如何选择？
很多同学问我：「老师，现在是不是都用 Kappa 了？Lambda 是不是过时了？」
我的回答是：没有银弹。咱们用一张表对比一下：
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 架构复杂度 | 较高，需维护两套链路 | 较低，一套链路搞定 |
| 代码维护 | 批和流逻辑可能不一致 | 统一逻辑，易于维护 |
| 历史数据重算 | 批处理层天然支持 | 需重置偏移量重新消费 |
| 实时性 | 流处理层保证秒级 | 秒级（取决于流引擎） |
| 数据准确性 | 批处理层保证最终一致 | 依赖流引擎的 exactly-once 语义 |
| 适用场景 | 对历史数据准确性要求极高 | 实时性优先，可接受最终一致 |
我个人习惯这样选型：
- 如果业务对历史数据的准确性有强要求（比如金融对账），我会选 Lambda，用批处理层兜底
- 如果业务更看重实时性，且能接受最终一致性（比如实时大屏、推荐系统），Kappa 更合适
- 如果团队规模小、维护能力有限，优先考虑 Kappa，减少运维负担
我曾经踩过的坑：在一个实时风控项目中，我们选了 Kappa 架构，结果 Kafka 集群挂了半小时，导致大量实时数据丢失。后来我们加了 Kafka MirrorMaker 做跨机房备份，才解决了这个问题。选 Kappa 之前，一定要评估好消息队列的可靠性。
1.7 本章小结
这一章我们聊了 OLAP 的核心概念，对比了 OLAP 和 OLTP 的本质区别，梳理了实时数仓从离线到 Lambda 再到 Kappa 的演进脉络。这些都是后续章节的基础，尤其是后面要讲的 ClickHouse、Doris、StarRocks 等实时 OLAP 引擎，都是在这些架构思想下诞生的。
记住一句话：架构没有好坏，只有合不合适。理解每种架构的优缺点和适用场景，比盲目追求新技术更重要。