📚 课程目录第1章课程导学与前置准备

1. 课程导学与前置准备：Iceberg是什么？为什么需要实时写入？Flink与Iceberg的生态关系

先说说我为什么想做这门课。

过去几年，我一直在跟数据湖打交道。从Hive到Hudi，再到Iceberg，踩了不少坑。尤其是实时写入这块，很多人以为把Flink连上Iceberg就能跑，结果一上线就出问题——小文件爆炸、数据不一致、查询延迟飙升。

这门课，说白了就是把我这些年积累的实战经验，系统性地梳理出来。从Iceberg的核心原理，到Flink如何与它深度集成，再到生产环境中的调优和运维，一条线讲透。

课程核心目标：

Apache Iceberg，一个开源的表格式（Table Format）。嗯，注意这个词——它不是存储引擎，也不是计算引擎。它定义的是「表」这个层面的元数据和组织方式。

你可以把它想象成一张「地图」。数据文件散落在HDFS或S3上，Iceberg就是这张地图，告诉你哪些文件属于哪个分区、哪个快照、哪个版本。

Iceberg的核心能力：

我在项目中遇到过最典型的场景：业务方要求「我要看昨天下午3点的数据状态」。用Hive的话，你得重新跑一次分区。用Iceberg，一行SQL就搞定——SELECT * FROM table FOR SYSTEM_TIME AS OF '2024-03-15 15:00:00'。

传统的数据湖，比如Hive，写入模式是批量的。每天凌晨跑一次ETL，把数据从业务库同步到Hive表。这种模式在几年前还行，但现在不行了。

为什么？

说白了，实时写入不是「锦上添花」，而是「刚需」。我见过一个电商客户，之前用Hive做离线报表，每天凌晨4点跑完，早上8点业务才能看到昨天的数据。后来换成Flink+Iceberg的实时链路，延迟从12小时降到30秒。嗯，这就是差距。

避坑指南： 我曾经以为实时写入就是「把批处理改成流处理」那么简单。结果第一次上线，Iceberg表的小文件数量从几百个暴涨到几十万，查询直接卡死。后来才明白，实时写入需要合理配置提交频率、文件大小阈值和压缩策略。这些内容，后面章节会详细讲。

Flink和Iceberg，一个是流计算引擎，一个是表格式。它们的关系可以用一句话概括：Flink负责「怎么算」，Iceberg负责「怎么存」。

具体来说：

这个链路里，Iceberg扮演的是「存储层」和「元数据层」的双重角色。它不参与计算，但它决定了数据怎么组织、怎么被高效读取。

Flink + Iceberg 的典型架构：

这个问题经常有人问。我的回答是：看场景。

我个人习惯：如果业务要求秒级延迟，或者需要复杂事件处理（CEP），无脑选Flink。如果延迟容忍度在分钟级，且团队Spark技术栈更成熟，Spark Streaming也能用。但注意，Iceberg官方对Flink的支持更深入，比如动态表、流式读取这些特性，Spark那边还没完全跟上。

这门课不是零基础入门。你需要具备以下基础：

如果你对Flink完全陌生，建议先花一周时间跑一遍Flink官方文档的Quick Start。嗯，我当年就是这么过来的。

注意： 课程中的代码示例基于以下版本，请尽量保持一致，避免版本兼容性问题：

这一章我们聊了：