📚 课程目录第3章 Iceberg表结构详解

Iceberg 表结构详解：Schema、分区、分桶与排序键

好，咱们今天来聊聊 Iceberg 表的骨架——表结构。说白了，就是你的数据在 Iceberg 里长什么样，怎么存、怎么找、怎么读得快。

我记得刚接触 Iceberg 时，第一反应是：这不就是个表吗？跟 Hive 表有啥区别？后来踩了几个坑才明白，Iceberg 的表结构设计，藏着不少巧思。咱们一个一个拆开看。

Schema 定义：列的类型与演进

Schema 就是表的列定义。Iceberg 的 Schema 跟传统表最大的不同在于——它支持原地演进。加列、删列、重命名、甚至调整类型，都不需要重写数据文件。

核心特性：Iceberg 使用 Schema ID 来追踪每一次 Schema 变更。每个数据文件都记录了它写入时的 Schema ID，读取时自动匹配。

来看一个简单的建表语句：

CREATE TABLE orders (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10,2),
    status STRING,
    created_at TIMESTAMP
) USING iceberg;

嗯，这里要注意：Iceberg 的字段类型比 Hive 更严格。比如 DECIMAL 必须指定精度，TIMESTAMP 默认不带时区。我建议你建表时就明确类型，避免后续演进出问题。

我在项目中遇到过这样一个场景：业务方突然要加一个 discount 字段，老数据没有这个值。在 Hive 里你得重建表，或者用 ALTER TABLE ADD COLUMNS 但历史分区读出来是 null。Iceberg 呢？一行命令搞定：

ALTER TABLE orders ADD COLUMN discount DECIMAL(5,2);

新数据写入时带 discount，老数据读取时自动补 null。文件不动，元数据更新一下就行。这就是 Schema 演进的威力。

个人习惯：我一般把 created_at 和 updated_at 作为每个表的标配字段，方便后续做增量读取和回溯。

分区（Partition）：物理隔离的艺术

分区是数仓的老概念了。但 Iceberg 的分区跟 Hive 分区有本质区别——Iceberg 是隐藏分区。

什么意思？Hive 分区是目录结构，比如 /orders/dt=2024-01-01/，你写 SQL 时必须手动指定分区条件。Iceberg 呢？分区信息存在元数据里，对用户透明。

看个例子：

CREATE TABLE orders (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10,2),
    created_at TIMESTAMP
) USING iceberg
PARTITIONED BY (days(created_at));

这里 days(created_at) 就是 Iceberg 的分区转换函数。数据写入时，Iceberg 自动根据 created_at 的值计算分区，你完全不用管分区目录长什么样。

我刚开始用的时候，总觉得不踏实——分区目录在哪？后来查了 Iceberg 的元数据表才放心。Iceberg 把分区信息存在 metadata.json 里，查询时自动剪枝。

避坑指南：我曾经犯过一个错——用 PARTITIONED BY (created_at) 直接按时间戳分区。结果每个文件一个分区，小文件爆炸。正确的做法是用 days()、months() 等转换函数，控制分区粒度。

Iceberg 支持的分区转换包括：

转换函数	说明	适用场景
`years(ts)`	按年分区	历史归档表
`months(ts)`	按月分区	月度报表
`days(ts)`	按天分区	实时数仓常用
`hours(ts)`	按小时分区	高频实时场景
`bucket(N, col)`	哈希分桶	均匀分布数据
`truncate(L, col)`	截断字符串	按前缀分组

分桶（Bucket）：数据局部性的利器

分桶，说白了就是把数据打散成固定数量的桶。Iceberg 的分桶基于哈希，跟 Hive 的分桶类似，但 Iceberg 的分桶信息也写在元数据里。

为什么要分桶？举个例子：你的订单表按天分区，但每天有几亿条数据。查询某个用户的所有订单时，需要扫描整个分区。如果按 user_id 分桶，查询就能直接定位到对应的桶文件。

CREATE TABLE orders (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10,2),
    created_at TIMESTAMP
) USING iceberg
PARTITIONED BY (days(created_at), bucket(16, user_id));

这里 bucket(16, user_id) 表示按 user_id 哈希到 16 个桶。每个分区下最多 16 个数据文件。

我的经验：桶数不要设太大。16 或 32 通常够用。桶数太多会导致小文件，影响读取性能。我一般按数据量估算——每个桶 100MB 到 1GB 比较合适。

分桶还有个好处：支持高效的更新和删除。Iceberg 的 Merge-on-Read 策略会利用分桶信息，只处理相关桶的文件，而不是全表扫描。

排序键（Sort Order）：数据布局的优化

排序键是 Iceberg 比较独特的功能。它决定了数据文件内部的数据排列顺序。注意，这不是全局排序，而是每个文件内部有序。

为什么要排序？你想想看，如果查询经常按 created_at 范围过滤，数据按时间排序后，Iceberg 就能利用 min/max 统计信息快速跳过不相关的文件。

CREATE TABLE orders (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10,2),
    created_at TIMESTAMP
) USING iceberg
PARTITIONED BY (days(created_at))
ORDER BY (created_at, user_id);

这里 ORDER BY (created_at, user_id) 表示每个文件内的数据先按 created_at 排序，再按 user_id 排序。

关键点：排序键不影响分区结构，只影响文件内部的数据布局。它跟分区是正交的——分区决定文件放哪个目录，排序决定文件里数据怎么排。

我在项目中遇到过这样一个优化场景：有一个用户行为表，经常按 event_time 范围查询。加了排序键后，查询扫描的文件数减少了 70%。

排序键的语法支持多列、升降序：

ORDER BY (created_at DESC, user_id ASC NULLS LAST)

隐藏分区（Hidden Partitioning）：Iceberg 的杀手锏

隐藏分区是 Iceberg 最让我惊艳的特性。它把分区逻辑完全封装在元数据层，用户写 SQL 时根本不需要知道分区字段。

传统 Hive 表，你要查某天的数据：

SELECT * FROM orders WHERE dt = '2024-01-01';

Iceberg 隐藏分区下，你直接查时间字段：

SELECT * FROM orders WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02';

Iceberg 自动识别 created_at 的分区转换，帮你做分区剪枝。用户完全感知不到分区的存在。

这意味着什么？

迁移成本低：从非分区表迁移到 Iceberg，SQL 不用改
分区策略可调整：今天按天分区，明天想按月分区？改元数据就行，数据不用动
查询更简洁：业务 SQL 里不用写分区条件，减少出错

注意：隐藏分区虽然对用户透明，但分区策略的选择仍然影响性能。我建议根据查询模式选择分区粒度——如果大部分查询是最近 7 天，按天分区就够；如果经常查整月数据，按月分区更合适。

下面这张图展示了 Iceberg 表结构的整体关系：

总结一下：Schema 定义数据的形状，分区决定数据的物理位置，分桶控制数据的分布，排序键优化数据的排列。这四个维度组合起来，构成了 Iceberg 表结构的完整体系。

我个人习惯在建表时先确定查询模式，再反推分区和排序键。比如实时数仓里，大部分查询按时间范围 + 用户维度，那就按天分区 + 按用户分桶 + 按时间排序。这样既能快速剪枝，又能高效定位。