当数据量从TB级迈向PB级，企业发现真正卡住脖子的往往不是算力，而是数据湖里那层薄薄的元数据。过去两年，以Iceberg、Delta Lake、Hudi为代表的开放数据湖表格式快速成熟，把数据库的事务能力带进对象存储，也让湖仓一体从概念口号走向生产环境。

表格式补上了数据湖的短板

传统数据湖用目录和文件组织数据，优点是便宜、灵活，缺点是缺少事务、缺少版本、缺少统计信息。一旦多个任务并发写入，读取方就可能看到半截数据；想回溯昨天某个时刻的快照，只能靠人工备份。

表格式在数据文件之上引入一层元数据：用清单文件记录每个数据文件的位置、分区和统计信息，用快照记录某个时刻的完整状态。由此带来三项关键能力：

三种主流路线各有侧重

Iceberg最初由Netflix开源，强调引擎中立，Spark、Flink、Trino、StarRocks等都能作为读写端，近年来社区活跃度最高；Delta Lake由Databricks主导，与Spark生态耦合紧密，在流批一体场景中体验成熟；Hudi则更早聚焦增量更新与近实时摄入，适合需要频繁做Upsert的场景。

近期的明显变化是，标准之争正在让位于互通。围绕REST Catalog一类的接口规范，多家厂商开始支持跨引擎、跨平台的元数据访问，数据湖的元数据层有了成为开放标准的可能。

企业为什么开始关心开放

最直接的原因是避免锁定。表格式把元数据和计算引擎解耦后，同一份数据可以被不同引擎读取，企业更换查询引擎时不必重写数据、重跑链路。其次是成本：配合对象存储的分层能力，冷数据可以沉到低频层，而表格式记录的统计信息能让查询引擎跳过大量无关文件，扫描量往往成倍下降。

第三是治理。文件级统计信息天然是数据质量与血缘的抓手，配合快照可以回答“这批脏数据是什么时候写进来的”“又影响了哪些下游表”这类过去难以追溯的问题。

落地仍需跨过的坎

表格式并非银弹。小文件问题是绕不开的：高频写入会产生大量小文件，需要定期做压缩与重写；元数据本身也会膨胀，快照过期策略、清单文件合并都要纳入日常运维。此外，Catalog的统一、细粒度权限控制、跨团队命名规范，往往比选型本身更耗时。

实践中的经验是：先在一个中等规模、读写并发可控的场景试点，把压缩、快照清理、监控告警做成自动化任务，再逐步迁移核心链路，避免一次性全量切换带来的风险。

结语

数据湖表格式的成熟，标志着湖仓一体从“把仓库能力搬到湖上”的权宜之计，转向以开放元数据为核心的长期架构。对企业而言，选哪一款表格式或许不是最重要的，重要的是尽早把元数据当作一等公民来管理——它决定了数据资产能否被稳定地发现、复用和审计。