一、实时数仓概述：传统数仓痛点、实时数仓演进、CDC技术简介、Iceberg核心特性

1.1 传统数仓：那些年我们踩过的坑

先聊聊传统数仓。我入行那会儿，公司用的是 Teradata + Informatica 那套组合拳。每天凌晨跑批，早上 8 点出报表。听起来挺稳？其实问题一堆。

传统数仓最大的痛，说白了就是 「慢」 和 「僵」。

• T+1 延迟：今天的数据，明天才能看。业务说「我要看实时库存」，你只能回一句「明天早上给您」。
• ETL 链路脆弱：一个字段类型变了，整个管道崩掉。我记得有一次上游改了订单状态码，我们凌晨 3 点被电话叫醒。
• 存储与计算耦合：扩存储必须扩计算，扩计算必须扩存储。成本高得离谱。
• Schema 变更困难：加一列要改十几张表，改完还要重跑历史数据。你想想看，这谁受得了？

1.2 实时数仓的演进之路

实时数仓不是一天建成的。我把它分成三个阶段，大家看看自己团队现在在哪个阶段。

阶段	技术栈	延迟	典型问题
1.0 Lambda 架构	Kafka + Storm/Spark Streaming + HBase	分钟级	批流两套代码，维护成本翻倍
2.0 Kappa 架构	Kafka + Flink + 消息队列	秒级	历史回溯能力弱，存储成本高
3.0 流批一体	CDC + Flink + Iceberg	秒级 + 可回溯	—— 这是我们正在做的

Lambda 架构我做过，那叫一个痛苦。实时链路用 Storm，离线链路用 Hive，同一个指标两套逻辑。对不上数的时候，业务方来质问，你只能硬着头皮说「口径不一致」。

Kappa 架构好一些，统一了计算引擎。但问题在于：消息队列里的数据是有保留期限的。你想回溯三个月前的数据？对不起，Kafka 已经清掉了。

所以到了 3.0 阶段，我们引入了 Iceberg。它让流和批共用同一份数据，既能实时写入，又能做历史分析。嗯，这才是我们想要的。

1.3 CDC 技术简介：数据捕获的「听诊器」

CDC，全称 Change Data Capture，中文叫变更数据捕获。说白了，就是监听数据库的变更日志，把增删改操作实时同步出来。

我最早接触 CDC 是在做 MySQL 到 HBase 的实时同步。那时候用的还是 Canal，每天处理几亿条 binlog。有一次 MySQL 主库切换，Canal 的 offset 丢了，我们重跑了三天数据……

为什么 CDC 对实时数仓这么重要？

• 零侵入：不需要业务方改代码，不需要在表上加时间戳字段。
• 全量+增量：先做一次全量快照，然后持续监听增量变更。
• Exactly-Once 语义：配合 Flink 的 checkpoint，数据不丢不重。

我个人习惯用 Debezium 来做 CDC。它原生支持 MySQL、PostgreSQL、MongoDB、SQL Server 等多种数据源，输出格式是统一的 JSON 或 Avro。配合 Kafka Connect，部署起来非常方便。

1.4 Iceberg 核心特性：为什么选它？

Iceberg 是一个表格式（Table Format），不是存储引擎。它管理的是数据文件的元数据，让上层引擎（Flink、Spark、Trino）能像操作普通表一样操作数据湖。

我选 Iceberg 而不是 Hive 或 Delta Lake，主要看中这几点：

特性	说明	我的实战感受
ACID 事务	支持并发写入和读取，读写不互斥	以前用 Hive，写的时候读不了，读的时候写不了。Iceberg 解决了这个问题。
Schema 演进	支持加列、删列、改列名、改类型	有一次业务方临时要加一个字段，Iceberg 直接 ALTER TABLE 就搞定了，不用重刷历史数据。
分区演进	分区策略可以随时改，历史数据自动兼容	这个太实用了。之前用 Hive，改分区要重建表，数据还得重新导入。
Time Travel	可以查询任意时间点的数据快照	排查数据问题时，直接查昨天的快照，不用找 DBA 恢复备份。
隐藏分区	用户不需要关心分区字段，Iceberg 自动管理	对业务查询透明，写 SQL 的时候不用手动指定分区条件。

1.5 本章知识体系总览

下面这张图，是我梳理的实时数仓知识体系。你可以把它当作整个课程的「地图」。

这张图展示了整个课程的核心脉络。我们从传统数仓的痛点出发，经过实时数仓的演进，引入 CDC 技术，最后用 Iceberg 作为统一存储底座。后面的章节，我会带着大家一步步把这个架构落地。