湖仓一体概念提出已有数年,但真正决定其能否规模落地的,并非查询引擎的性能,而是底层表格式与元数据层的开放程度。2024年以来,围绕开放表格式的并购、开源与产品发布密集出现,行业格局明显收敛。

三足鼎立转向一处收敛

长期并存的三大开放表格式中,Apache Iceberg 的势头最为突出。Databricks 在2024年收购了由 Iceberg 创始团队创办的 Tabular,并随后推动 Delta Lake 与 Iceberg 之间的双向互操作;Snowflake 宣布原生支持 Iceberg 表并开源 Polaris Catalog;AWS 推出基于 Iceberg 的托管表服务 S3 Tables;Google、微软等也相继在数据仓库与数据湖产品中补齐 Iceberg 读写能力。与此同时,源自 Flink 社区的 Apache Paimon 在流式湖仓场景快速成长,成为实时链路的重要选项。

这一系列动作指向同一个判断:表格式正在从厂商自有走向事实标准。对企业而言,数据以何种格式落在对象存储上,直接决定了未来更换计算引擎的成本。

竞争焦点上移到元数据层

表格式趋同之后,新的争夺点转移到元数据与目录服务。谁能掌握统一的 Catalog,谁就掌握了跨引擎、跨云的数据入口。Iceberg 社区推动的 REST Catalog 规范,试图用一套标准接口屏蔽底层实现差异,目前已有多家厂商宣布兼容;各大云厂商则纷纷推出自己的目录产品,并在开源版本与商业版本之间做平衡。

落地仍有三道坎

第一是小文件与元数据膨胀。高频写入会产生大量小文件,若缺乏自动合并与清单优化,查询性能会迅速退化,元数据服务的压力也随之上升。第二是流批一体的时延。要在同一份存储上兼顾分钟级实时与大规模离线分析,仍需在写入频率、快照管理与成本之间反复权衡。第三是治理复杂度。多引擎接入后,权限模型、命名规范与数据质量规则若不能统一,湖仓反而会演变成新的数据孤岛。

企业该关注什么

对正在建设或改造数据平台的企业来说,当下有几件事值得优先推进:优先选择开放表格式作为默认落盘格式,保留未来更换引擎的余地;把元数据与权限体系当作独立工程对待,而不是依附于某个计算引擎;在实时场景中谨慎评估流式表格式的成熟度,先小范围验证再逐步推广;同时建立小文件治理与成本监控机制,避免开放性带来的隐性开销。

可以预见,湖仓一体的下一阶段竞争,不再是谁的引擎更快,而是谁的元数据更开放、治理更扎实。表格式的统一只是起点,数据入口的开放程度,将长期决定企业在多云与多引擎环境中的主动权。