1. 课程导学与实时数仓概述
大家好，我是你们这门课的老朋友。做大数据这行十几年了，从离线数仓一路摸爬滚打到实时数仓，踩过的坑比走过的路还多。今天咱们先不急着敲代码，把实时数仓这个概念彻底聊透。
你可能会问：为什么非要搞实时？离线跑个 T+1 报表不也挺好？嗯，我刚开始也这么想。直到有一次在电商大促现场，老板盯着大屏问「现在实时 GMV 多少」，我支支吾吾说「等明天早上跑完 Hive 任务」——那个场面，别提多尴尬了。
核心认知：实时数仓不是离线数仓的替代品，而是互补品。它解决的是「数据产生后多久能被分析」这个核心问题。
1.1 实时数仓到底是个啥
说白了，实时数仓就是一套能处理「秒级到分钟级」数据延迟的架构体系。它跟离线数仓最大的区别在于：数据从产生到进入分析系统，中间几乎不等待。
我习惯把实时数仓拆成三个层次来看：
- 实时接入层：负责把各种数据源（MySQL 的 binlog、App 埋点日志、物联网设备消息）实时采集进来。Kafka 是这层的主力。
- 实时计算层：对流入的数据做清洗、关联、聚合。Flink 在这层扮演核心角色。
- 实时存储层：把计算结果存到支持高并发查询的存储里，比如 ClickHouse、Doris、HBase。
举个例子。你在淘宝下单，订单数据通过 Canal 同步到 Kafka，Flink 消费 Kafka 消息后实时更新订单宽表，再写入 ClickHouse。整个过程不超过 5 秒。这就是实时数仓的典型场景。
1.2 Lambda 架构 vs Kappa 架构
聊实时数仓，绕不开这两个架构。我当年刚接触实时数仓时，也被这两个概念绕晕过。咱们用一张图把它们说清楚。
这张图把两个架构的差异讲得很清楚了。我补充几个实战中的体会：
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 代码维护 | 两套代码（Storm/Flink + Spark/Hive） | 一套代码（Flink 流处理） |
| 数据一致性 | 实时与离线结果需合并，易出现偏差 | 天然一致，通过重放保证 |
| 历史修正 | 重跑离线任务即可 | 需要 Kafka 保留足够长的数据 |
| 适用场景 | 对历史数据准确性要求极高的金融、审计 | 互联网、电商、物联网等快速迭代场景 |
| 学习成本 | 需要掌握多种技术栈 | 聚焦 Flink + Kafka 即可 |
我的建议：如果你从零开始搭建实时数仓，直接选 Kappa 架构。我在两家公司都推过 Kappa，只要 Kafka 集群够稳定、数据保留策略合理，这套架构能省掉至少 40% 的维护工作量。
1.3 为什么选 Kafka + Flink 这个组合
市面上实时计算框架不少，Storm、Spark Streaming、Flink 各有拥趸。但我个人认为，Kafka + Flink 是目前最成熟的实时数仓技术栈。
原因有三：
- Kafka 的「日志即存储」理念：数据写入 Kafka 后，天然就具备了「可重放」能力。这在 Kappa 架构里是命脉——数据出错了？把 offset 往前调，重新消费一遍就行。
- Flink 的「精准一次」语义：做实时数仓最怕什么？数据重复或丢失。Flink 的 Checkpoint 机制配合 Kafka 的幂等生产者，能保证端到端的 exactly-once。我在一次金融交易场景中验证过，百万级 QPS 下数据零丢失。
- 生态无缝衔接：Flink 官方提供了 Kafka Connector，Source 和 Sink 都是开箱即用。你不需要写额外的适配代码。
注意：Kafka + Flink 不是银弹。如果你的数据量很小（每天百万级以下），用 RabbitMQ + 定时任务反而更简单。别为了技术而技术。
1.4 课程目标与前置知识
这门课的目标很明确：让你能独立搭建一套生产级的实时数仓。具体来说，学完后你应该能做到：
- 独立部署和调优 Kafka 集群
- 用 Flink 消费 Kafka 数据做实时 ETL
- 设计实时数仓的分层模型（ODS、DWD、DWS、ADS）
- 处理乱序数据、延迟数据、数据倾斜等生产难题
- 将结果写入 ClickHouse/Doris 等实时存储
前置知识方面，我希望你具备：
- Java 或 Scala 基础（能看懂代码就行）
- SQL 基础（Flink SQL 会大量用到）
- Linux 基本操作（部署集群时需要）
不需要你已经是大数据专家。我当年也是从零开始，一步步踩坑过来的。这门课会把那些「书上没写、面试不问、但生产必遇」的坑都告诉你。
一句话总结：实时数仓的核心就三件事——数据怎么进（Kafka）、数据怎么算（Flink）、数据怎么用（实时存储）。这门课就是带你把这三点打通。