1. 实时数仓概述：传统数仓的痛点、实时数仓的演进、Lambda架构与Kappa架构对比、Iceberg在实时数仓中的定位
大家好，我是你们这门课的主讲。今天咱们聊聊实时数仓的来龙去脉。说实话，我做了快十年的数据架构，从传统数仓一路摸爬滚打过来，踩过的坑真不少。这一章算是整个课程的“地基”，把为什么需要实时数仓、架构怎么演变的、以及Iceberg到底扮演什么角色，一次性讲清楚。
1.1 传统数仓的痛点：为什么我们“忍”了这么久？
先说说传统数仓。很多公司现在还在用，但痛点其实很明显。
核心矛盾：业务要求“秒级响应”，传统数仓却只能做到“T+1”。
我归纳了四个最典型的痛点：
- 时效性差：数据从产生到可查询，通常要等24小时。你想想看，电商大促期间，运营盯着昨天的报表做决策，这不是刻舟求剑吗？
- ETL链路长：数据从业务库到ODS，再到DW、DM，层层加工。我曾经在项目里数过，一条核心链路跑了7个MapReduce任务，出问题排查要半天。
- 存储与计算耦合：传统数仓大多基于MPP架构，扩缩容非常痛苦。我记得有一次双十一前扩容，光数据重分布就花了三天。
- 难以支撑实时场景：风控、实时大屏、个性化推荐，这些场景传统数仓基本无能为力，只能靠旁路系统。
我的经验：2018年我在一家电商公司，业务方要求“下单后5分钟内看到订单在实时大屏上”。传统数仓根本做不到，我们只好用Kafka + Flink临时搭了一套，虽然能跑，但数据一致性经常出问题。那时候我就意识到，必须有一套统一的实时数仓方案。
1.2 实时数仓的演进：从“批处理”到“流批一体”
实时数仓不是凭空冒出来的。它经历了几个阶段：
- 阶段一：离线数仓 + 实时旁路 —— 离线照跑，实时用Storm/Flink单独拉一条链路。问题是两套数据口径经常对不上。
- 阶段二：Lambda架构 —— 批处理层 + 速度层 + 服务层。解决了口径问题，但维护两套代码，成本翻倍。
- 阶段三：Kappa架构 —— 统一用流处理，数据全量走Kafka。简化了架构，但对消息队列的存储和回溯能力要求极高。
- 阶段四：流批一体 + 湖仓一体 —— 这就是我们现在所处的阶段。用Iceberg这类开放表格式，让流和批共用同一份数据、同一套表结构。
说白了，演进的核心就是：从“两套系统、两套代码”走向“一套系统、一套代码”。
1.3 Lambda架构 vs Kappa架构：到底选哪个？
这个问题我几乎每次分享都会被问到。咱们直接上对比：
| 对比维度 | Lambda架构 | Kappa架构 |
|---|---|---|
| 核心思想 | 批处理层 + 速度层，服务层合并结果 | 全量数据走流处理，消息队列统一存储 |
| 数据一致性 | 批处理层保证最终一致，速度层保证实时 | 流处理保证Exactly-Once，依赖消息队列回溯 |
| 开发维护成本 | 高，需要维护两套代码（批+流） | 中，一套流代码，但消息队列运维复杂 |
| 数据回溯能力 | 强，批处理层天然支持历史重跑 | 弱，依赖Kafka等消息队列的保留时长 |
| 适用场景 | 对历史数据一致性要求极高，实时性要求中等 | 实时性要求高，历史数据回溯需求少 |
避坑指南：我曾经在一个金融项目中选了Kappa架构，结果业务方要求“回刷三个月前的数据修正口径”。Kafka根本存不了那么久，最后不得不临时补了一套批处理任务。所以，选型前一定要问清楚：你的历史数据回溯窗口是多久？
现在有了Iceberg，其实我们可以走第三条路：流批一体架构。流作业实时写入Iceberg，批作业直接读取Iceberg的快照。既不需要维护两套代码，又能利用Iceberg的Time Travel能力做历史回溯。嗯，这才是现代实时数仓该有的样子。
1.4 Iceberg在实时数仓中的定位：为什么是它？
Iceberg不是数据存储，也不是计算引擎。它是一个开放的表格式（Table Format）。你可以把它理解为：在数据湖（HDFS/S3）之上，加了一层“表结构管理”和“事务支持”的中间层。
它在实时数仓中的定位，我总结为三个关键词：
- 统一底座：流和批共用同一张Iceberg表。Flink实时写入，Spark/Presto离线分析，数据只有一份。
- 事务保障：支持ACID，读时无锁。实时写入不会阻塞离线查询。
- 快照隔离：每次写入生成一个快照，查询可以指定读取某个快照。这就解决了“实时数据还在写，查询读到一半”的问题。
下面这张图，是我自己画的一个Iceberg在实时数仓中的定位图，你看完就明白了：
你看，Iceberg处在中间层，向上对接各种计算引擎，向下统一管理数据文件。它不关心数据是怎么来的（流还是批），只负责把数据管好、查对。
我的建议：如果你正在从传统数仓向实时数仓迁移，不要一上来就搞Lambda或Kappa二选一。先引入Iceberg作为统一存储层，流和批都往Iceberg写。你会发现，很多架构上的纠结，其实是因为“存储层不够强大”。Iceberg补上了这一环。
小结
这一章我们聊了：
- 传统数仓的四个核心痛点：时效性差、ETL链路长、存算耦合、不支持实时。
- 实时数仓的四个演进阶段：从离线+旁路，到Lambda、Kappa，再到流批一体。
- Lambda与Kappa的对比：没有银弹，关键看你的回溯窗口和一致性要求。
- Iceberg的定位：统一存储底座，让流批共用一份数据，解决架构分裂问题。