一、为什么需要表格式？Hive 数仓的三道老伤

在传统 Hive 数仓里，数据就是"对象存储/HDFS 上的一堆文件 + MetaStore 里记的表结构"。这种模式撑起了离线数仓，但越用越痛：

1. 没有真正的 ACID：一次写入被打断，就留下半截脏文件；两个任务同时往一张表写，结果互相覆盖。
2. Schema 漂移、分区脆弱：改个列常常要 ALTER 还要重写数据；分区就是目录名，查询必须手写 WHERE dt='2026-11-04'，分区策略一变旧数据全废。
3. 看不见"谁动了我的表"：想知道表在哪一刻是什么样子？做不到。更别提回滚、增量读、时间旅行。

于是"数据湖 + 表格式"登场：数据仍廉价地存在对象存储（S3/OSS/HDFS），但再盖一层元数据管理——让这堆文件对外表现得像一张正经的表。Iceberg、Hudi、Delta Lake 都是这个思路，本文聚焦 Apache Iceberg。

二、Iceberg 是什么：把文件变成"表"的抽象层

Iceberg 的核心贡献，是定义了一套表格式（Table Format）：它不存数据，只管"数据文件在哪、schema 是什么、哪个快照有效、怎么原子提交"。

一句话：Iceberg 让"对象存储上的文件"获得了数据仓库级别的可管理性，却保留了数据湖的低成本与开放格式。

三、核心文件结构：三层元数据

Iceberg 表的目录里，数据文件和元数据文件分开存放。元数据是一棵可回溯的树：

表根目录/
├── data/                         # 真正的数据文件（parquet/orc/avro）
│   └── ...00000-0.parquet
└── metadata/
    ├── v3.metadata.json          # 当前元数据，指向最新 snapshot
    ├── snap-xxx.avro             # manifest list（快照清单）
    ├── *.avro                    # manifest（数据文件清单 + 统计信息）
    └── version-hint.text         # 提示从哪个版本号开始找

关键收益在第三层：每个 manifest 带列级统计，查询时 Iceberg 能跳过明显不含目标数据的文件（min/max 剪枝），这就是它"不扫全表也能快"的底层原因之一。

四、快照隔离与时间旅行

每次写操作（append/overwrite/merge）都会生成一个新的 snapshot，并原子地更新 metadata.json 指向它。读请求默认读"当前快照"，因此：

• 快照隔离：写入过程中，正在读旧快照的查询完全不受影响，读写互不阻塞。
• 时间旅行（Time Travel）：用历史 snapshot id 或时间戳，读到任意历史时刻的视图。
• 回滚 / 增量读：出错了 CALL catalog.system.rollback_to_snapshot 回滚；增量消费用 snapshot_id 之间差异即可。

-- 看表的所有快照
SELECT * FROM prod.db.table.snapshots;

-- 时间旅行：读到指定快照
SELECT * FROM prod.db.table FOR SYSTEM_VERSION AS OF 1234567890000;

-- 回滚到上一个快照
CALL catalog.system.rollback_to_snapshot('prod.db.table', 1234567890000);

对比 Hive：Hive 想回滚只能靠手工备份分区目录，Iceberg 把"版本"做成了表的一等公民。

五、隐藏分区与分区演进

Hive 的分区是"目录即分区"，dt=/year=/month= 写死在路径里，查询必须手写 WHERE dt='...'，而且分区策略一旦定下就几乎不可改。

Iceberg 的隐藏分区（Hidden Partitioning）把"分区列"和"物理布局"解耦：

• 你定义分区规则（如 days(ts)、bucket(16, user_id)），Iceberg 自动维护映射；
• 查询不必在 SQL 里写分区过滤，Iceberg 自己知道哪些文件对得上；
• 分区演进（Partition Evolution）：想从 days(ts) 改成 hours(ts)？直接 evolve，新数据走新规则、旧数据保留旧规则，查询透明合并，零重写历史数据。

-- 建表时声明隐藏分区
CREATE TABLE prod.db.events (
  id BIGINT, user_id BIGINT, ts TIMESTAMP, payload STRING
) PARTITIONED BY (days(ts), bucket(16, user_id));

-- 查询时无需手写分区过滤，引擎自动剪枝
SELECT * FROM prod.db.events WHERE ts BETWEEN ... AND ...;

-- 分区演进：换成小时粒度，旧数据不动
ALTER TABLE prod.db.events CREATE PARTITION FIELD hours(ts);

六、Schema 演进：列 ID 追踪，零重写

Hive 改列经常要 ALTER TABLE ... CHANGE COLUMN 再担心历史数据对不上。Iceberg 给每一列分配稳定列 ID，后续 rename/add/drop/reorder 都只改元数据：

ALTER TABLE prod.db.users ADD COLUMN age INT;
ALTER TABLE prod.db.users RENAME COLUMN name TO full_name;

因为靠 ID 而非位置/名字定位列，改名不会丢历史、字段顺序变化也不影响旧文件解析——这对"线上表要长期演进"的场景极其友好。

七、并发写、ACID 与行级更新

Iceberg 的提交走乐观锁：提交时比较"我的 base snapshot"和"当前最新 snapshot"，若期间没人动过就原子切换；若被别人抢先，则按冲突策略重试或失败——这保证了多 writer 不互相覆盖。

早期 Iceberg 以 append / overwrite 为主，行级更新通过两种策略实现：

-- 行级删除（COW/MOR 由表属性决定）
DELETE FROM prod.db.orders WHERE status = 'expired';
UPDATE prod.db.orders SET amount = amount * 0.9 WHERE vip = true;

与 Hudi 的差异一句话带过：Hudi 把"记录级主键索引"做进格式、偏流更新；Iceberg 偏"通用表格式 + 强元数据"，两者都能做 CDC 入湖，选型看团队栈。

八、与计算引擎集成：Spark / Flink / Trino

Iceberg 的最大卖点之一是开放格式、多引擎共用同一张表。

-- Spark：建表 + 读写
CREATE TABLE lake.ods.user_log USING iceberg PARTITIONED BY (days(ts)) ...;
INSERT INTO lake.ods.user_log SELECT * FROM staging.src;

-- Flink：实时 CDC 入湖（upsert 语义）
CREATE TABLE user_log_sink (
  id BIGINT, ts TIMESTAMP(3), payload STRING,
  PRIMARY KEY (id) NOT ENFORCED
) WITH ('connector'='iceberg', 'catalog-name'='lake', 'table'='lake.ods.user_log');

-- Trino / Presto：直接交互式查询同一张表
SELECT user_id, COUNT(*) FROM lake.ods.user_log GROUP BY 1;

Flink + Iceberg 把 Kafka 里的变更流实时落湖，配合 Trino 即时分析，构成经典的"流批一体入湖"链路——这块与 flink-core、kafka-core 的能力无缝衔接。

九、湖仓一体：Iceberg 在哪一层，和 Doris/ClickHouse 怎么分工

"湖仓一体（Lakehouse）"不是说消灭数仓，而是用一套数据底座同时服务多种负载：

                对象存储（S3/OSS/HDFS）
                        │
        ┌───────────────┼─────────────────┐
    ODS / DWD 层        DWS 层            ADS 层
   （Iceberg 表，       （Iceberg 轻度        （Doris / ClickHouse
    可更新、低成本、     聚合，开放格式）      服务化高并发查询）
    支持时间旅行）              │                    │
        │                     │                    │
   Spark/Flink 写入      Trino 即席分析      BI / 接口直接查

分工建议（已在 hive-core、doris-realtime-datawarehouse、clickhouse-olap-practice 详述各自内部原理）：

• Iceberg 做"贴源 + 明细"底座：ODS/DWD 层落地、保留历史、支持更新与时间旅行，成本远低于把全量明细塞进 OLAP；
• Doris / ClickHouse 做"服务化"出口：把 Iceberg 的结果同步/物化到 Doris 做高并发点查、到 ClickHouse 做实时 OLAP，对外提供 ADS 服务。

这样一份数据在湖里，上层引擎按场景取用，告别"湖一份、仓一份"的双倍存储与同步链路。

十、Iceberg vs Hudi vs Delta Lake 对比

十一、生产避坑清单（10 条）

1. 小文件是头号杀手：高频 append 会堆出海量小文件，务必配 rewrite_data_files / compact 定期合并。
2. 快照要清理：快照只增不删会撑爆元数据，定时 expire_snapshots 并设保留期。
3. manifest 也要压缩：长期运行后 rewrite_manifests 减少清单数量，提升计划阶段速度。
4. 写入并发控制：多 writer 用乐观锁，冲突重试需配合理退避，高争用表考虑单一 writer。
5. 分区别过细：bucket(2048, ...) 之类会产生巨量空分区，按数据量选 16–256 即可。
6. Schema 演进别滥用 DROP：被下游物化视图/外表引用的列删除前先评估血缘。
7. 统计信息要准：列级 min/max 剪枝依赖统计，写入时保留/刷新统计，否则退化成全扫。
8. 对象存储一致性：用 S3 等需确认其一致性模型，避免"写后读"短暂看不到新 snapshot。
9. 与 OLAP 分层：别把 Iceberg 当 OLAP 用；高并发点查和实时聚合交给 Doris/ClickHouse。
10. Catalog 选型：Hive Metastore、JDBC、REST 各有取舍，生产建议独立、高可用的 catalog 服务，别和算力混部。