课程导入：学习目标、课程结构、三剑客概览与选型背景
1.1 为什么需要关注数据湖表格式
当数据湖从“能存数据”走向“能管数据”时，一个关键问题浮出水面：如何让存储在廉价对象存储上的海量文件，具备数据库表那样的事务性、一致性和高效更新能力？ 传统 Hive 表面对“小文件泛滥”“覆盖写无快照”“并发写冲突”等问题时束手无策。Delta Lake、Apache Iceberg 与 Apache Hudi 正是为解决这些问题而生的数据湖表格式（Table Format）——它们不是存储引擎，而是定义在文件系统之上的一层“元数据与事务管理层”。
本课程将围绕这三套开源方案，从原理、操作到选型，帮助你建立完整的知识图谱。无论你是数据平台工程师、数据架构师，还是正在设计湖仓一体方案的开发者，这门课都能为你提供清晰的决策依据。
- 说出三种表格式的核心定位与解决的核心痛点；
- 从元数据组织、事务机制、更新方式三个维度区分 Delta Lake、Iceberg、Hudi；
- 根据业务场景（如 CDC 入湖、数据湖上的 ACID、大规模扫描）初步判断选型方向；
- 理解课程后续章节的编排逻辑，建立系统化学习路径。
1.2 课程结构：从原理到实战的六阶段
本课程共 30 章，分为六个递进阶段，避免“只讲 API 不讲原理”或“只谈概念不落代码”的偏科问题。下表展示了整体结构：
| 阶段 | 章节范围 | 核心主题 | 产出能力 |
|---|---|---|---|
| 一、基础认知 | 第1-3章 | 表格式概念、三剑客概览、与 Hive 表的差异 | 能解释“为什么需要表格式” |
| 二、原理深潜 | 第4-10章 | 事务日志、时间旅行、元数据组织、文件布局 | 能画出各框架的读写流程图 |
| 三、操作实战 | 第11-18章 | Spark/Flink 集成、建表、更新、合并、SQL 操作 | 能独立完成基础数据管护任务 |
| 四、性能调优 | 第19-23章 | 小文件治理、分区裁剪、Compaction、查询优化 | 能定位并解决性能瓶颈 |
| 五、生态集成 | 第24-27章 | 与 Hive Metastore、Presto/Trino、数据湖服务集成 | 能设计跨引擎访问方案 |
| 六、选型与案例 | 第28-30章 | 对比决策矩阵、生产案例复盘、迁移路径 | 能输出技术选型报告 |
每个阶段都配有可运行的代码示例与故障排查清单。建议按顺序学习，但如果你已有 Spark 基础，可以直接跳到第二阶段开始精读。
1.3 三剑客概览：各自的核心设计哲学
虽然三者都解决“文件级事务”问题，但设计出发点差异显著。下图从元数据组织、事务实现、更新语义三个维度对比了它们的核心机制：
从上图可以提炼出关键差异：Delta Lake 以“事务日志 + Checkpoint”为核心，与 Spark 深度绑定；Iceberg 将元数据抽象为多层清单，强调引擎中立与快照隔离；Hudi 则从“增量处理”出发，内置索引与 MOR 机制，更贴近流式更新场景。 这些差异直接决定了后续章节中建表语法、写入路径与调优手段的不同。
1.4 选型背景：没有银弹，只有权衡
选型不是“哪个最好”，而是“哪个最匹配你的约束条件”。以下是三个典型决策场景：
- 场景 A：已有 Databricks 或 AWS 托管 Spark 环境 —— Delta Lake 集成最顺滑，事务日志与 Spark 优化器配合成熟，适合快速落地湖仓一体。
- 场景 B：查询引擎多样（Flink、Trino、Spark 混用）且要求云原生存储无关 —— Iceberg 的 REST Catalog 与多引擎支持更友好，且其 Manifest 统计信息能显著加速谓词下推。
- 场景 C：核心诉求是数据库 CDC 入湖，且需要分钟级数据可见 —— Hudi 的 MOR + 索引机制专为此设计，Clustering 与 Compaction 可灵活调度。
1.5 本章小结与学习路径建议
本章建立了三个核心认知：第一，表格式是数据湖从“文件集合”走向“可管理数据集”的关键中间层；第二，Delta Lake、Iceberg、Hudi 分别以事务日志、清单层、时间线+索引为技术支点，形成差异化设计；第三，选型必须结合自身场景的写入模型、查询模式与团队技术栈。
在进入下一章前，建议你完成以下自测：
- 用自己的话解释“为什么 Hive 表无法支持 ACID 而 Iceberg 可以”？
- 如果业务需要每秒 5000 次 UPSERT，你会优先考虑哪种表格式？为什么？
- 尝试在 Spark Shell 中分别打印三种表格式的版本信息，确认环境就绪。