Iceberg 互操作是神话？行级删除让 Write Once 失效

“开放表格式”的承诺，到底承诺了什么？

行业里有句口头禅：“Apache Iceberg is open, so any Iceberg engine can read an Iceberg table.”听起来合理，但作者评价很直接：“It sounds reasonable but it is incomplete.” 来源：OLake。这话不是抬杠，是拿生产环境当试金石换来的判断。

Iceberg 给引擎的是一份共享规范，用来描述一张表。作者把它比喻成 “a menu of capabilities”，一份能力菜单。可菜单只证明后厨有这些菜，不证明每个客人都点了、也都吃到了。规范是开放了，不同系统可以照同一套规则实现，不用依赖谁的私有存储布局。这是真承诺。常见错误是把这句话撑得太远。

作者把 “open” 拆成四层：data files、Iceberg table metadata、catalog、query engine。只有这四层都对齐，互操作才算真正成立。反直觉的地方在这里：“The table is valid. The reader is valid. The combination is incompatible.”一个有效的表，配一个有效的读引擎，组合起来照样失败 来源：OLake。

这个观点在 Hacker News 上刚挂出来，1 point、0 comments，没引发什么讨论 来源：HN。讨论热度低不代表问题不存在，它戳的恰恰是生产环境里最隐蔽的那种坑。

行级删除是怎么让两个引擎翻脸的？

先把对象存储想象成一个装满密封箱的仓库。每个箱子是一份 Parquet 数据文件。Parquet 只编码行，却不告诉你：哪些箱子属于这张表、当前快照是谁、表怎么分区、schema 怎么变过、哪些行后来被更新或删除了 来源：OLake。

Iceberg 补上这套表级说明书。它的元数据树把 snapshots、manifest lists、manifests、data files 和 delete files 串起来 来源：OLake。因为规范开放，不同系统可以不靠私有布局实现同一套规则。到这一步，一切都好。

裂缝从行级删除开始。典型产物是 equality delete files。一个 writer 可以创建完全有效的 Iceberg 表，里面带着这些文件。Apache Spark 理解它们，能返回当前行。另一个引擎可能压根不支持 equality deletes。它能到 catalog，能加载 metadata，能读 Parquet，但就是产不出正确结果 来源：OLake。

作者追踪了一张 “one small customer table”，从第一次写入，一路跟到两个引擎对“能不能读它”产生分歧，用真实路径展示不兼容发生在哪一环 来源：OLake。所以作者提醒，别等生产查询帮你发现不匹配，先评估 Iceberg 兼容性。

交叉验证：规范、引擎实现与生产现实

把 Apache Iceberg 官方规范翻出来，格式层面确实明确列出了 equality delete files 和 position delete files 来源：Iceberg 规范。这是表格式的规则，写在纸面上，不偏不倚。

但规范只管格式。OLake 的质疑点在于：同一份规范下，引擎对 equality delete 的支持程度可能完全不同。支持分两种，一种是在代码里认得出这个文件类型，另一种是能返回正确结果。认得出，和算得对，中间隔着不少距离 来源：OLake。

Spark SQL 文档里提供了 MERGE / UPDATE / DELETE 这类行级操作语法入口，说明 Spark 侧确实有引擎级实现 来源：Spark 文档。把它和官方规范、OLake 案例并排放一起，能看出 “write once, read anywhere” 依赖的不是规范本身，而是每个引擎对规范菜单的实现覆盖。

作者给的评估办法不玄乎：用那四层框架，data files、metadata、catalog、query engine，逐层确认再上线 来源：OLake。我不确定这是不是唯一办法，但拿它当清单去检查一张真实表，比信口头禅靠谱。

原文：

The Iceberg Interoperability Myth: Write Once, Read Anywhere? · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月28日