正文
Iceberg 的 Geo 类型 Spec 吸收之前类似项目的经验，设计了新的 Geometry & Geography 数据类型，并推进其成为 Parquet 的一部分，Geo 数据类型的标准定义也是一个多方协作的复杂项目，包括 GeoLake、GeoParquet、Iceberg、Sedona、Snowflake、Databricks、Apple 等很多社区 / 公司的参与，非常不容易。
Iceberg 更新 / 删除可能是为数不多 Spec 持续在演进的特性，Iceberg V1 Spec 里定义了基本的 Table format，引擎可以通过 Copy-on-write 的方式来更新、删除数据。Iceberg V2 Spec 里支持了更轻量的 Merge-on-write 的实现方式，定义了 position-delete 和 equality delete 的规范，目前有部分计算引擎已经支持该特性。
Position-delete 目前默认采用 File scope 的 Delete file，也就是给每个涉及删除的文件，都建立一个 Delete file，好处是查询的时候能快速定位到文件的删除信息，但缺点是会产生大量小的 Delete file，而 Iceberg 很多用户缺少对数据的精细治理，大量小文件会引发各种稳定性、性能问题， Deletion Vectors 就是引入解决 position-delete 存在的不足，在 V3 Spec 里，老的 position-delete 会被废弃。
值得一提的是，Iceberg V3 Deletion Vectors 的存储格式跟 Delta Lake 是兼容的，这个选择跟该特性由 Databricks 主导有关，对用户来说是好的，要做湖格式转换成本更低，不用动数据，只需修改元数据；这样的理念可能在后续的迭代里会越来越常见，因为用户需要且仅需要一个 Open lake format，作为企业数据的 Singe source of truth。
Iceberg V3 引入 Row Lineage 特性支持行级别的变更追踪，引擎在写入数据文件时，必须维护表级别的 next-row-id 字段，和行级别的 _row_id 和 _last_updated_sequence_number 字段。
其中 _row_id 是表中每一行的唯一长整型标识符，当一行首次被添加到表中时，通过继承机制分配该值；_last_updated_sequence_number 是最后一次更新的提交序列号，当一行首次被添加或修改时，通过继承分配该值。
Row Lineage 不会追踪通过等值删除（Equality Deletes）更新的行的血统，因为使用等值删除的引擎在写入更改之前会避免读取现有数据，因此无法为新行提供原始行 ID。
Iceberg Catalog Service 保证一个表多并发写入同时提交时，只能有一个成功；Table Spec 则保证了多个写入成功提交后，会形成一个 Serializable 的历史。而对于多表操作的行为，Iceberg 没有明确的定义，多表的元数据如何存储组织，多表的元数据同时更新，完全依赖于 Catalog 的内部实现，本质上，Iceberg 对于整个 Lakehouse 层面元数据如何组织是没有任何要求的，更谈不上支持 Multi-table Transaction 的能力。
Jack YE（前 AWS Tech Lead，现在在 LanceDB）分享了个人兴趣驱动的开源项目 Olympia Format，旨在定义一个 Lakehouse Metadata Format，这样根据对象存储上自描述的数据和元数据，就能构建出一个 Storage only 的完整 Lakehouse。
Olympia Format 让构建一个 RESTful Catalog 变得更容易，Engine 能进一步基于 RESTful Catalog 实现更复杂的特性，例如 Multi-table Transaction。
Iceberg 支持多种不同的文件格式，例如 Avro、Parquet、ORC，随着 Iceberg V3 Spec 的引入，许多新功能被添加到 Iceberg。其中一些功能，如新数据类型，默认值等特性需要在文件格式级别进行修改才能支持，并非所有功能都适用于每种支持的文件格式。
另外 Parquet、ORC 等格式主要针对数据分析场景，AI、ML 场景下，对数据大对象、数据随机访问、检索的能力提出了更高的要求，出现了 Lance、Vortex 等新兴的文件格式，这些文件格式目前还无法跟 Iceberg 很好的结合。
File format API 是希望对 Iceberg 底层的文件格式的访问统一的 API 抽象，比如 Iceberg 某个特性需要某些 API 的支持，底层 File format 只要实现这些 API 即可，而无需关注上层的特性细节，这样就能更好的将 Table format 与 File format 的迭代解耦。
社区用户的支持是 Iceberg 蓬勃发展的核心动力之一，很多科技大厂从三四年前就可以深度使用 Iceberg，并参与 Iceberg 建设。用户选择用 Iceberg 一般有几种场景，第一种是原来用 Hive，升级到 Iceberg，这类用户主要从 Iceberg 的特性收益，ACID 减少了 Hive 常见的数据正确性的问题，降低了 Hive 平台的维护开销，Schema Evolution 简化表结构变更管理，update/delete 减少数据全量更新的代价等。
第二种是采用 Lakehouse 来替代 Cloud Data Warehouse 例如 Snowflake、Redshift，这类用户的收益主要在于降成本，替换更优秀的计算引擎带来计算成本降低，数据无需冗余存储带来存储成本降低、无需 ETL Pipeline 带来维护成本的降低。
第一种场景很直观，Iceberg 本来就是解决 Hive 遇到的痛点问题孵化出来的项目，第二种场景则影响数据架构的演进，当前有大量的 Workload 在 Cloud Data Warehouse 里，Lakehouse 能更低成本的解决 Data warehousing 的问题，这一类场景增量空间很大，从 Iceberg Summit 2025 的分享看，这样的 Use case 在持续增加，比如 Apple、DoorDash、TRM Labs、RedNotes 等都有这样的场景。
Apple 大规模使用 Iceberg，是 Iceberg 最有影响力的客户。Apple 积极参与 Iceberg 社区贡献，很多重要特性，例如 COW 和 MOR 更新机制的实现，以及 rewrite_data_files、rewrite_table_path 等 procedures 的支持，都有 Apple 的参与，成长出多位 Iceberg PMC。
因为重度使用 Iceberg，Apple 构建了 Iceberg 的容灾机制以服务重要的业务场景，将 Primary Iceberg 的数据复制到 Secondary Iceberg，在灾难发生时 Secondary 能接管服务。Iceberg 的数据直接复制是不可行的，换了环境各种文件路径都变化了，元数据也就失效了。
Apple 的做法是持续将 Primary 上的增量 Commit，通过 RewriteTablePath procedure 修改元数据文件，然后将 Data file、Manifest、Snapshot 元数据复制到 Secondary，并在 Secondary Catalog 上提交，这样就达到 Commit 复制到 Secondary 的目的，从而实现 Disaster recovery。
