1、课程导学：为什么需要Iceberg + Kafka？实时数仓的痛点与架构演进

大家好，我是这次课程的主讲。做了十几年数据架构，我见过太多实时数仓的“翻车现场”。今天这第一节课，咱们不急着写代码，先聊聊一个核心问题：为什么非要把 Iceberg 和 Kafka 凑在一起？

说白了，这俩东西单独拿出来都很能打。Kafka 是流式数据的“高速公路”，Iceberg 是湖上数据的“超级仓库”。但现实中的业务，往往需要一条从“路”到“仓”的稳定管道。我见过不少团队，路修好了，仓盖好了，结果中间对接那块儿天天出幺蛾子。

1.1 传统实时数仓的三大痛点

先说说我以前踩过的坑。2018年我帮一家电商公司搭实时数仓，当时选型是 Kafka + Hive。嗯，现在回想起来，那叫一个痛苦。

• 痛点一：数据延迟与一致性难保证
  Kafka 里的消息到了 Hive，经常出现“丢数”或“重复”。为什么？因为 Hive 的 ACID 支持太弱了。有一次大促，实时大屏上的 GMV 数字跳来跳去，运营总监直接冲进机房……那场面，我至今记忆犹新。
• 痛点二：小文件爆炸
  实时写入 Hive，每几分钟就生成一堆小文件。我记得有一次，一个分区里躺了 3 万多个小文件，查询性能直接崩了。DBA 兄弟每天的工作就是跑脚本合并文件，苦不堪言。
• 痛点三：流批分离，架构割裂
  实时用 Flink 写 Kafka，离线用 Spark 读 Hive。两套代码、两套运维、两套元数据。你想想看，一个字段类型改了，两边都得改，漏一个就出数据质量问题。

1.2 架构演进：从 Lambda 到 Kappa，再到 Iceberg + Kafka

为了解决这些痛点，业界走过不少弯路。我简单梳理一下这条演进路线：

架构阶段	核心思路	典型问题
Lambda 架构	实时层 + 离线层，各自计算后合并	两套代码、口径不一致、运维复杂
Kappa 架构	统一用流处理，数据全存在 Kafka	Kafka 存储成本高、回溯能力弱、不支持高效分析
Iceberg + Kafka	流数据入湖，湖上提供 ACID 和快照	解决了前两者的核心矛盾

我个人习惯把 Iceberg + Kafka 称为“流湖一体”架构。它既保留了 Kafka 的实时性，又借助 Iceberg 的 ACID 和快照能力，让湖上的数据可以像数据库一样被可靠查询和回溯。

1.3 Iceberg + Kafka 的核心价值

那这对组合到底能带来什么？我总结了四点：

1. Exactly-Once 语义
   Iceberg 的 ACID 事务 + Kafka 的幂等生产者，可以保证数据不丢不重。我曾经在金融项目中靠这个特性，把对账差异率从 0.5% 降到了 0。
2. 流批一体
   同一份 Iceberg 表，Flink 可以实时写入，Spark 可以批量读取，Presto 可以即席查询。元数据统一，口径自然统一。
3. 小文件自动合并
   Iceberg 有专门的 compaction 机制。我不用再写脚本合并小文件了，Iceberg 自己就能搞定。嗯，这功能救了不少 DBA 的头发。
4. 时间旅行与回溯
   Iceberg 的每个快照都是不可变的。你可以随时查询“昨天下午 3 点的数据长什么样”。这在数据审计和故障恢复时，简直是救命稻草。

1.4 本章知识体系总览

下面这张图，是我对整门课程知识体系的一个梳理。你可以把它当作一张“地图”，后面每节课都会对应到其中的一个模块。

1.5 这门课你会学到什么？

我不喜欢讲空话。这门课一共 30 章，我会带着你从零搭建一套完整的 Iceberg + Kafka 实时数仓。具体来说：

• 基础篇（第 1-5 章）：搞懂 Iceberg 的表格式、Kafka 的 Exactly-Once 原理，以及它们如何配合。
• 实战篇（第 6-20 章）：手写 Flink CDC 入湖、Kafka Connect 配置、小文件合并策略、时间旅行查询。每一行代码我都会跑给你看。
• 进阶篇（第 21-28 章）：性能调优、数据治理、跨集群同步、监控告警。这些是我在多个项目中积累的“压箱底”经验。
• 总结篇（第 29-30 章）：一个完整的电商实时数仓案例，从需求分析到上线运维，全流程复盘。