你家里有一把用了多年的钥匙。某天门锁升级了，钥匙外形却没变，直到回家才发现打不开。数据格式也怕这种“看起来照旧，实际不兼容”的升级。Apache Parquet 社区正在讨论的办法很直接：凡是可能让旧软件读不懂的变化，就用新的大版本号明确标出来。
Parquet 是一种面向分析数据的开源列式文件格式。它把同一列的数据放在一起，查询时只读取需要的列，也便于压缩。数据工程团队常用它保存仓库或数据湖里的大表，再交给 Spark、Trino 等查询引擎读取。正因为使用者多、文件寿命长，一次格式变化的影响可能跨越许多软件和存档数据。
先把“不兼容”写在版本号上
据社区周报 Apache Data Lakehouse Weekly，Apache Parquet 已发起正式投票，拟对包含破坏性变更的发布采用版本化的大版本号管理。这里的“破坏性变更”，指旧软件不支持或无法正确处理的新格式变化。
大版本号相当于清楚地换一把锁，并在门上贴出说明。数据写入工具、读取引擎和表格式可以分别声明自己支持哪些版本，团队也能据此安排升级和迁移。它提供的是明确边界，并不会自动让旧系统获得新能力，也不会免去不同项目之间的协调。
需要特别区分：这次讨论的是规范或项目发布如何标记破坏性升级，不能直接等同于 Parquet 文件格式版本、writer version，或某个具体实现库的版本。
为什么湖仓和 AI 数据栈都该留意
这件事的重要性来自 Parquet 所处的位置。Lakehouse——让对象存储同时承担数据湖的低成本存储和数据仓库的表管理、查询能力——通常用 Parquet 保存底层数据文件，再由 Iceberg 等表格式管理文件的版本、结构和事务。底层格式若要增加新能力，上层表格式、写入工具和多个查询引擎都要一起面对兼容问题。
周报称，这套治理思路借鉴了 Apache Iceberg 多年完善的做法，目标是在开放格式继续演进的同时，避免破坏已经依赖它的大量表。周报还把这场讨论放在 AI 与机器学习工作负载推动格式调整的更大背景下。不过，现有材料没有说明 Parquet 此次准备引入哪些具体格式能力，也不足以确认向量类型是否已进入提案。
局限与未知
- 目前只是“发起正式投票”，材料没有显示提案已经通过或开始实施。
- 唯一信源是社区周报，未附邮件列表投票、提案文本或官方公告，无法交叉核验具体规则。
- “数百万张表”是周报对影响面的概括，没有给出统计依据；实际迁移方式、版本命名和支持周期也尚未披露。