1. 课程导入：学习目标、核心概念、整体框架
1.1 为什么需要关注 Iceberg 隐藏分区
在数据湖架构中，分区策略直接决定了查询扫描的数据量。传统 Hive 表要求用户在建表时显式声明分区字段，并在写入时手动维护分区目录，一旦业务字段调整或写入逻辑遗漏，就会产生分区目录与数据内容不一致的问题。Apache Iceberg 引入的隐藏分区（Hidden Partitioning）机制，将“物理分区目录”与“逻辑分区规则”解耦，让分区对写入端完全透明，同时显著提升查询裁剪效率。
以一个实际场景为例：订单表按 order_time 字段进行小时级分区。在 Hive 中，如果业务方忘记在写入 SQL 中指定 hour 分区列，数据会落入错误目录；而 Iceberg 隐藏分区会在写入时自动根据 order_time 的值计算分区归属，无需用户关心目录结构。更重要的是，Iceberg 在元数据层记录了每个分区文件与数据字段的映射关系，使得查询引擎能够利用 分区裁剪（Partition Pruning） 跳过无关文件。
1.2 核心概念速览
在深入细节之前，我们先建立四个关键术语的清晰认知，它们是理解后续所有内容的基础。
| 概念 | 定义 | 与 Hive 分区的区别 |
|---|---|---|
| 隐藏分区 | Iceberg 根据表定义的分区变换（Transform）自动计算每条数据所属分区，写入时无需用户指定分区列 | Hive 需要显式声明分区列并手动维护目录 |
| 分区变换 | 将源字段值转换为分区值的函数，如 day(order_time)、bucket(user_id, 16)、truncate(price, 10) | Hive 仅支持按字段值直接分区，无变换能力 |
| 分区裁剪 | 查询引擎利用元数据中的分区统计信息，跳过与过滤条件无关的数据文件 | Hive 依赖目录结构推断，Iceberg 基于元数据精确裁剪 |
| 元数据层 | Iceberg 的 .metadata 目录中存储的 Manifest 文件，记录数据文件与分区值的映射 | Hive 无独立元数据层，分区信息散落在文件系统目录名中 |
1.3 隐藏分区的核心原理
Iceberg 隐藏分区的本质是“分区规则与存储路径的分离”。表结构定义中通过 PARTITIONED BY 子句声明分区变换，但实际数据文件可以存放在任意路径下，Iceberg 的 Manifest 文件会精确记录每个文件对应的分区元组。这种设计带来三个直接收益：
- 写入简化：Spark、Flink 等引擎写入时只需提供数据本身，Iceberg 自动完成分区值计算和文件归属。
- 演进灵活：分区规则可以随业务变化而修改，无需重写历史数据（通过元数据刷新实现）。
- 裁剪精准：查询时引擎读取 Manifest 中的分区统计信息，结合过滤条件下推，实现文件级跳过。
下图展示了隐藏分区与分区裁剪的整体协作流程，从写入端到查询端完整呈现了 Iceberg 如何通过元数据层实现分区透明化与高效裁剪：
1.4 整体课程框架
本课程共分为五个模块，从基础概念到高级调优层层递进，每个模块均配有真实案例与排障演练：
- 基础篇（第1-6章）：隐藏分区原理、分区变换类型（
identity、day、hour、bucket、truncate）、建表与迁移实践。 - 进阶篇（第7-14章）：分区裁剪的引擎集成（Spark/Flink/Trino）、元数据过滤机制、Manifest 合并与优化、分区统计信息的利用。
- 调优篇（第15-22章）：分区粒度选择策略、bucket 与 sort 组合优化、小文件治理、分区演进与重写（
RewritePartitions）。 - 实战篇（第23-27章）：基于真实业务场景（订单、日志、用户行为）设计分区方案，对比不同策略的查询性能。
- 排障篇（第28-30章）：分区裁剪失效的常见原因（如
transform与过滤条件不匹配）、元数据膨胀问题、跨引擎兼容性坑点。
1.5 常见误区与学习建议
学习本课程时，建议你始终带着两个问题思考：“我的查询过滤条件是什么？” 以及 “这种分区变换能否让引擎精准跳过无关文件？”。同时，建议在测试环境使用 EXPLAIN 语句观察实际扫描的文件数，验证分区裁剪是否生效。