你可以把公司数据想成一批放在巨大仓库里的文件。仓库便宜，却不知道哪些文件组成一张表，也不会自动记录谁改过什么。Apache Iceberg 就像加在仓库上的账本：它为对象存储里的文件补上表结构、版本记录和可靠更新能力，让多个分析工具安全地共享同一批数据。
现在，这本“账本”的下一版规则——Iceberg v4——正在形成。它还没有发布，但部分内容已经通过社区投票。值得提前关注，是因为表格式相当于各类计算引擎共同遵守的读写契约；规则一变，兼容范围和升级方案也可能跟着变。
本文依据 Alex Merced 对 Apache Iceberg 开发邮件列表和公开投票的梳理。材料没有附上对应的官方投票帖、规范提交或发布页，因此以下状态均来自这一项二手信源。
先分清：方向明确，不等于产品可用
据 Merced 的文章，截至 2026 年 7 月，Iceberg v4 尚未发布，也没有一份可直接采用的正式 v4 规范。当前稳定版本仍是 2026 年 5 月发布的 Iceberg 1.11，属于 v3 阶段。对正在建设生产系统的团队，文章给出的实际建议仍是：以 v3 为目标，把 v4 当作需要持续观察的方向。
这里最容易混淆三种状态：内容已经获准进入 v4、草案进入规范流程，以及完整的 v4 已经发布。它们不是一回事。
开源项目通常会在开发邮件列表里公开讨论设计。一个想法先进入 DISCUSS 讨论，可能配有设计文档、GitHub issue 或改进提案；成熟后才进入 VOTE 投票。讨论热烈只能说明问题重要，不能说明功能已经确定。真正更有分量的是具体规范文本和投票结果。
已经定下来的有两块
按 Merced 的梳理，2026 年 5 月，社区投票通过把 relative path support 加入 v4。它指“相对路径支持”，即用相对于某个位置的路径来描述文件，而不是处处依赖完整路径。
同一时期，新的 Content Stats representation 也获准进入 v4。Content Stats 是“内容统计信息”的表示方式，例如围绕数据文件保存的列级统计。新方案将以类型明确、结构化的形式，替代旧有的 column statistics maps——按列保存统计信息的映射结构。
这两项是目前材料中状态最明确的 v4 内容：它们已经通过投票，而不只是设计设想。
位图进了一步，但仍只是草案
2026 年 6 月上旬，社区投票同意把一种新的 compact bitmap format 规范草案加入代码仓库。bitmap 即“位图”，用一串位置标记来紧凑表达某些状态。
关键在“草案”二字。这次投票意味着该方案正式进入规范流程，但不能写成“功能已经成为最终 v4 规范”，更不能据此说 v4 已经可用。
另有两项提案仍在工程设计阶段：adaptive metadata tree（自适应元数据树）和 single-file commits（单文件提交）。前者涉及 Iceberg 如何组织描述表内容的元数据层级；后者关注一次提交如何收拢到单个文件。材料只表明社区正在持续讨论和设计，没有显示它们已经通过正式投票。
为什么现在值得看
Iceberg 的版本不是普通的软件小升级。它规定数据文件、元数据、快照和变更怎样组织，也决定不同计算引擎能否共同读写同一张表。团队今天选择的存储路径、统计信息结构和提交方式，未来都可能受到格式演进影响。
本刊第 278 期曾提到 Grab 采用 Apache Iceberg，以改善大规模数据管理的完整性与效率。这次继续追踪 v4，重点不在催促团队抢先升级，而在建立一张更可靠的判断表：relative paths 和 Content Stats 已获批准；compact bitmap 进入了草案流程；adaptive metadata tree 与 single-file commits 仍未定案。
局限与未知
- 目前只有 Merced 的单一二手梳理，尚缺 Apache 官方规范、投票记录和发布记录的交叉核验。
- 材料在介绍现有 metadata tree 时截断，无法进一步解释各项提案会怎样改变具体文件结构。
- v4 的发布日期、完整功能边界和迁移方式均未披露。