1. 课程导入
欢迎进入《Flink与Iceberg实时湖仓工程实战》。在动手写第一行流式入湖作业之前，我们需要先建立一张清晰的“技术地图”：实时湖仓到底解决什么问题，Flink 与 Iceberg 各自站在什么位置，它们如何协作，以及本课程将沿着怎样的路线带你从概念走到生产可用。本章不涉及复杂代码，但它是后续 29 章所有工程决策的坐标系。
一、为什么需要实时湖仓：从离线数仓到流批一体的演进
传统数据架构通常分为两条链路：一条是面向分析的离线数仓，数据以 T+1 方式批量写入 Hive 或对象存储；另一条是面向监控与告警的实时链路，数据经消息队列进入流处理引擎，结果写入 Kafka、Redis 或 ClickHouse。两条链路各自维护一套元数据、一套存储格式和一套计算逻辑，导致口径不一致、数据重复、运维成本高。
实时湖仓的核心诉求，是让“湖存储”同时具备数据湖的低成本、开放格式与数据仓库的事务能力、Schema 管理能力，并让流式写入成为一等公民。它要解决四个关键矛盾：
- 时效性矛盾：离线链路无法满足分钟级甚至秒级可见性。
- 一致性矛盾：流批两条链路计算结果难以对齐。
- 成本矛盾：实时链路通常使用昂贵存储，历史数据保留成本高。
- 可维护性矛盾：多套系统意味着多套元数据、权限与血缘。
实时湖仓并不是简单地把 Kafka 数据落到 HDFS，而是要求存储层支持 ACID 事务、快照隔离、Schema 演进、分区演进与时间旅行。这正是 Iceberg 的价值所在；而 Flink 则承担“持续、低延迟、Exactly-Once 地把变化数据写入湖表”的计算职责。
二、Flink与Iceberg的技术定位：计算引擎与表格式的分工
理解二者关系，最有效的方式是区分“计算”与“存储语义”两个层面。Flink 是分布式流批一体计算引擎，负责数据读取、转换、状态管理、Checkpoint 与故障恢复；Iceberg 是面向数据湖的表格式规范，负责定义表结构、分区、快照、清单文件与元数据，并依赖底层文件系统（HDFS、S3、OSS 等）存储实际数据文件。
换句话说，Flink 决定“数据怎么流动、何时提交”，Iceberg 决定“数据以什么语义被组织和暴露”。二者通过 Flink Iceberg Connector 衔接：Flink 作业在 Checkpoint 完成时提交 Iceberg 事务，使写入具备原子性与一致性。
关键认知：Iceberg 不是存储引擎，也不是计算引擎。它是一层“表语义”，让对象存储上的文件集合表现得像一张可事务访问的表。Flink 也不是湖存储，它不负责长期保存数据。把二者混为一谈，是初学者最常见的定位错误。
三、课程整体知识框架与实战路线
本课程共 30 章，按“认知—环境—入湖—进阶—治理—生产”六个阶段推进。每一阶段都围绕可运行的最小闭环设计，避免只讲概念不落地。
| 阶段 | 核心内容 | 产出目标 |
|---|---|---|
| 认知建立 | 实时湖仓概念、Flink 与 Iceberg 定位、整体路线 | 能画出技术分层图并解释协作关系 |
| 环境准备 | Flink 集群、Iceberg Catalog、Hive Metastore、对象存储 | 本地或测试环境可提交流式入湖作业 |
| 实时入湖 | Kafka 源、Checkpoint 调优、写入模式、分区策略 | 实现分钟级可见的 Iceberg 表 |
| 进阶能力 | Upsert、CDC、Schema 演进、小文件合并 | 支持变更数据捕获与表结构在线演进 |
| 湖仓治理 | 快照管理、过期清理、元数据维护、权限与血缘 | 形成可运维、可审计的湖表资产 |
| 生产实战 | 监控告警、故障恢复、性能压测、成本优化 | 具备上线与排障能力 |
实战路线遵循“先跑通、再调优、后治理”的原则。第 2 至第 6 章完成环境与基础写入；第 7 至第 15 章深入 Flink 写入 Iceberg 的各类模式与参数；第 16 至第 24 章覆盖 CDC、Schema 演进、小文件与快照治理；第 25 至第 30 章聚焦生产监控、故障复盘与综合项目。
四、典型场景与常见误区
实时湖仓的典型场景包括：用户行为日志的秒级入湖与分钟级分析、数据库 CDC 的准实时同步、IoT 设备数据的低成本长期留存、以及流批统一口径的指标计算。这些场景的共同点是：数据持续到达、需要事务可见性、需要历史回溯、且存储成本敏感。
误区一：把 Iceberg 当成数据库。Iceberg 不提供行级更新服务，也不适合高并发点查。它的优势在于大批量写入、扫描与事务快照。
误区二：认为 Flink 写入 Iceberg 就是简单 Sink。实际上提交频率、Checkpoint 间隔、分区策略、文件大小都会直接影响湖表健康度。
误区三：忽略小文件问题。高频 Checkpoint 会产生大量小文件，若不配合合并策略，元数据和查询性能会迅速恶化。
一个常见的复盘案例是：某团队将 Checkpoint 间隔设为 10 秒，Kafka 每秒百万条数据直接写入 Iceberg，结果一周后单表产生数十万小文件，查询延迟从秒级升至分钟级。根因不是 Flink 或 Iceberg 本身，而是写入频率与文件大小未做权衡。后续章节会给出具体的参数组合与合并方案。
学习建议：本章结束后，请用自己的话回答三个问题——实时湖仓解决了什么矛盾？Flink 与 Iceberg 各自负责什么？本课程六个阶段分别产出什么？能清晰回答，说明你已经具备继续实战的认知基础。
接下来，我们将从环境搭建开始，把这张技术地图逐步变成可运行的工程系统。