【数据湖与开放表格式】选型、迁移与运维

前面 19 篇讲清了文件格式、表格式、catalog、查询引擎、流式入湖的机制。这一篇把它们落到三个工程问题上：手里已有 Hive 表，怎么迁到开放表格式而不停服、不丢数？怎么给湖仓做一个不骗自己的 benchmark？上线之后会遇到哪些故障，怎么提前规避？

这是系列的收束篇，不再引入新机制，而是把前面的机制串成可执行的决策和清单。

环境说明：本机为 Arch Linux on WSL2、i9-12900K / 32 GB，未安装 Spark / Trino / Hive / JVM。本文的迁移命令、运维操作均为按官方文档可复现的步骤，不粘贴未执行输出，benchmark 部分只讲方法与口径、不给伪造数字。

一、从 Hive 表迁移

存量基本都是 Hive 表（目录式分区 + Hive Metastore）。迁到 Iceberg 有三条路径，区别在于要不要重写数据文件。

in-place migrate

Iceberg 提供 migrate 存储过程，把一张 Hive 表原地转成 Iceberg 表：读取 Hive 表的分区与文件清单，生成 Iceberg 元数据（manifest/snapshot）指向原有的数据文件，不复制数据。

-- Spark + Iceberg：原地迁移（备份原表为 db.events_BACKUP_）
CALL ice.system.migrate('db.events');

-- 想先试不动原表，用 snapshot 建一张独立的 Iceberg 表指向同一批文件
CALL ice.system.snapshot('db.events', 'db.events_iceberg');

snapshot 过程更安全：它新建一张 Iceberg 表，与原 Hive 表共享数据文件但元数据独立，可以先在新表上验证查询结果，确认无误再 migrate 真正接管。

add_files

已有外部 Parquet 文件、或要把某些分区增量纳入已有 Iceberg 表，用 add_files：

CALL ice.system.add_files(
  table => 'db.events',
  source_table => '`parquet`.`s3://bucket/landing/2026-06-30/`'
);

它只登记文件、不校验内容，所以源文件的 schema 必须和目标表对齐（列名、类型、可空性），否则查询时才报错。

迁移期的关键风险

1. 双写窗口：迁移不是瞬时的。in-place migrate 期间若还有写入打到原 Hive 表，会产生 Iceberg 元数据没追踪到的新文件。标准做法是迁移前停写、迁移后把写入切到 Iceberg 表。
2. 回滚预案：migrate 会把原表改名备份（_BACKUP_ 后缀）。回滚就是删掉 Iceberg 元数据、把备份表名改回来。迁移前确认备份策略，别迁完就删原表。
3. 统计信息缺失：迁移过来的表没有 Iceberg 收集的列统计，文件级裁剪（第 18 篇）会退化。迁移后跑一次统计收集或重写，让 manifest 带上 min/max。

二、Benchmark 的口径与陷阱

湖仓 benchmark 最容易自欺。同样一张表、同一个查询，换个口径数字能差几倍。写性能结论前，至少把下面这些钉死，否则数字没意义（写作规范第七节）。

1. 缓存状态：对象存储的本地缓存、引擎的 page cache、文件系统 cache 都会让第二次查询飞快。区分冷查询（清缓存）和热查询，分别报，别混。
2. 文件布局：一张刚 compaction 过、按查询列 z-order 排过序的表，和一张流式写入留下一堆小文件的表，扫描代价天差地别。benchmark 必须声明表的文件数、平均文件大小、是否排序。
3. 统计信息新鲜度：manifest 里的 min/max、NDV sketch 是否最新，直接决定 file pruning 效果。陈旧统计会让引擎多扫文件。
4. 并发与资源：单查询延迟和高并发吞吐是两个指标，别用单查询数字推断集群能扛多少 QPS。
5. 引擎版本与配置：Trino 的 dynamic-filtering、table-statistics-enabled，Spark 的 AQE，开不开结果不同；必须随数字标注。

可信的最小口径模板：

表: events, Iceberg V2, 1.2 亿行, 480 个 data file, 平均 256 MB, 按 (day, user_id) 排序
引擎: Trino 481, 8 worker, 各 16 vCPU/64 GB
查询: 单分区点查 + 全表聚合各一类
口径: 冷/热各 5 次取中位数, 报扫描文件数 + 扫描字节 + 墙钟时间
对照: 同一份数据, 仅改文件布局(compaction 前后)

外部 benchmark（厂商博客、会议 PPT）只能当引用数据，标清来源、版本、硬件，不能写成自测结论。

三、生产故障模式

湖仓的故障大多不是「查询报错」，而是「越来越慢」「空间越用越多」「偶发提交失败」。按根因分五类。

孤儿文件（orphan files）

失败的写入、被取消的 compaction、流式作业重启都会在对象存储上留下没有任何 snapshot 引用的数据文件。它们不影响正确性（读端只看 manifest 引用的文件），但白占空间、拉高 list 成本。

-- 先 dry-run 看会删哪些（务必先看再删）
CALL ice.system.remove_orphan_files(table => 'db.events', dry_run => true);

注意：remove_orphan_files 默认有时间阈值（只删足够旧的文件），是为了不误删正在写、还没提交的文件。把阈值调太小、又恰好有流式作业在写，会删掉在途文件导致作业失败。这是「清理误伤在途写入」的典型事故。

元数据膨胀

每次提交都生成新的 metadata.json、manifest list、manifest。高频流式提交一天上千次，元数据文件能堆到几万个，导致：表加载（读最新 metadata.json）变慢、manifest planning 变慢。

治理手段： - expire_snapshots 过期老快照，连带清理不再引用的 manifest 和 data file。 - rewrite_manifests 把碎片化的 manifest 合并成少量大 manifest。 - 限制保留的 metadata.json 数量（write.metadata.previous-versions-max）。

CALL ice.system.expire_snapshots(table => 'db.events', older_than => TIMESTAMP '2026-06-23 00:00:00');
CALL ice.system.rewrite_manifests('db.events');

提交冲突风暴

多个写者 + compaction 同时改一张表，乐观并发（第 11 篇）会冲突重试。正常情况下重试几次就成，但当写入太密、compaction 太重时，会陷入「提交—冲突—重做整批—再提交—再冲突」的活锁，表现为提交延迟飙升、CPU 空转。

缓解：错峰跑 compaction、给 compaction 限流、把写入按分区分散到不同作业减少同分区竞争。

快照过期误删

expire_snapshots 删掉的不只是快照指针，还有那些只被过期快照引用的 data file。如果有人正依赖时间旅行读历史快照（合规审计、回溯训练数据），过期窗口设太短就会把还在用的历史数据删掉。过期策略要和「最长需要回溯多久」对齐。

catalog 单点

catalog 是表名到当前元数据指针的唯一权威（第 15 篇），也是提交的原子点。catalog 挂了，整个湖的写入和元数据访问全停。基于单库的 JDBC catalog、单实例 Hive Metastore 都是单点。生产上 catalog 要做高可用（REST catalog 多副本 + 后端高可用数据库），并监控其延迟和可用性。

四、运维清单

把上面的故障预防整理成周期任务：

关键监控指标：每表的 data file 数与平均大小、活跃 snapshot 数与 manifest 数、提交成功率与冲突重试次数、catalog 提交延迟。这些指标的趋势比绝对值更重要——文件数持续上涨、提交成功率持续下降，都是该介入的信号。

五、选型回顾

把第 14 篇的对照落成一句话决策（不排名，看约束）：

• 引擎要中立、生态要广：Iceberg。它的规范最完整、引擎支持最齐、catalog 选择最多。
• 强 upsert、CDC 为主：Hudi 的 record index 在主键更新上路径最短；Iceberg 走 equality delete 也能做，但更依赖 compaction。
• Databricks/Spark 深度绑定：Delta 最顺，UniForm 还能顺带产出 Iceberg 元数据兼顾外部引擎。

无论选哪个，前面讲的运维负担（compaction、快照过期、孤儿清理、catalog 高可用）都跑不掉——开放表格式把「数据库内核做的事」摊到了你的运维作业里。这是 lakehouse 用存算分离、引擎中立换来的，必须算进总成本。

参考资料

1. Apache Iceberg Documentation, Spark Procedures（migrate、snapshot、add_files、expire_snapshots、rewrite_data_files、rewrite_manifests、remove_orphan_files）。A 级（官方文档）。
2. Apache Iceberg Documentation, Maintenance 与 Configuration（write.metadata.previous-versions-max、快照保留、孤儿文件时间阈值）。A 级。
3. Trino Documentation 481, Iceberg connector（statistics、optimize、dynamic filtering 对 benchmark 的影响）。A 级。
4. 写作规范 WRITING_GUIDE.md 第七节（benchmark 口径要求）。
5. 本系列：第 11 提交协议与并发控制、14 三者对照与互通、15 Catalog 之争、17 小文件与 Compaction、18 查询引擎如何读湖、19 流式写入与 CDC 入湖 篇。

返回 系列目录 · 上一篇 流式写入与 CDC 入湖 · 下一篇 湖上 AI 与向量