本次 Iceberg Summit 2025[0] 上行业内众多公司做了分享，包括 Iceberg 核心技术、使用案例，优化方案，未来走向等等。其中国内的腾讯（两个 talk），小米，小红书均有分享，整体内容不错，这里做一个总结，更详细的请参考原视频。

Beyound Iceberg’s ongoing evolution

首先是 Iceberg 的 PMC member Ryan Blue 的 talk[1], 这个 talk 整体介绍了 Iceberg 的过去，现在以及将来的一些事情。Iceberg 现在已经成为湖仓的事实标准，在各大公司被官方使用，在湖仓一体/流批一体等方案中作为共享存储存在，提供了 ACID，time travel，branch，tag 等各种功能，支持了众多查询引擎，整体生态非常繁荣。

最近一年已经完成或者正在进行的一些重大特性包括

• Geo type 的支持，更好的支持地图数据
• Variant type 的支持，可以支持半结构化数据（这个另外一个 talk 单独有讲）
• 全表加密（data 和 metadata）
• deletion vector — 更好的 position deletes（有另外一个 talk 单独讲），在性能、文件数量以及维护成本做了一个均衡
• row lineage，主要方便增量消费以及数据的校验等

在 Iceberg 中增加新的数据类型可以带来：1）有标准，各引擎更方便交互；2）能够借用 Iceberg 的 Metadata/Index 等做查询优化。

另外在广泛使用过程中，大家也有提出来一些有关 metadata 的痛点，比如

• manifest 相关
  • 文件可能会比较多：先生成 manifest 然后是 manifest list；manifest 会重写最后删除
  • 现在对小表不太友好（实际中有很多小表）：scan 需要走 manifest list 然后顺序的访问每个 manifest 文件
  • manifest 文件太多：导致 metadata 需要周期性合并
• 故障恢复比较困难: file replication 不够恢复整张表；metadata 需要重写（主要是绝对路径）
• 列信息是二进制的：对扩展类型不优化（比如 geo/variant 等)
• plan 性能可以更好: 需要读取所有列信息（不在 filter 中的列信息也需要读取）
• Metadata skipping 需要分区信息：数据倾斜处理不好；无法和 geo 数据很好的结合；容易过度分区

针对这些问题，也有一些相应的规划，整体思路是 metadata 往 adaptive tree structure方向走，adaptive tree structure 加上 RestCatalog, 再加上 servcie 就更像 DB 了。

adaptive tree structure 大致如下

另外 Iceberg 也在如下一下方面有考虑

• Relative paths：主要是为了容灾、故障恢复考虑
• Columnar metadata: 更方便跳过不需要的 column stat；typed lower/upper bounds/alternative sort orders
• Adaptive metadata & Unified manifests: 更好的 manifest 结构，主要适配多模态数据，优化小表，manifest 的维护性等。

后文中会从如下几方面展开描述

• Manifest/Index：表元数据相关
• Catalog: Catalog 相关
• Compute&Management(Optimiztion&Service): 表查询和管理相关
• File format: file format 相关
• Streaming: 流式入湖
• Ecosystem(&usecase&migration): 生态以及迁移到 Iceberg

Matadata(manifest/Index)

Iceberg 的 metadata 是核心组件，包括了支持各种功能以及查询优化所必需的信息，这里介绍一些和 metadata 相关的演讲内容。更详细的可以查看原视频（下同）。

本次 Summit 中有介绍 Iceberg （正在）支持多种类型：geo 类型[2]，variant 类型[3]，支持了 deletion vector[4] — 更好的 position delete。

也有尝试将 Iceberg 的 metadata 暴露成常规的 Iceberg 表方便分析的[5]，演讲中有介绍使用 PG 来承载 metadata 的分析，发现量大之后会遇到性能瓶颈，因此希望 Iceberg 原生支持将 metadata 暴露为标准表。

其中增加新类型主要是定义标准以及优化查询，geo 主要是地图相关的数据（点、线，区域等），而 variant 则主要是支持半结构化的数据 — 比如 json。variant 在 log/event 等数据类型中大量使用，IoT/Telemetry 数据非常多，variant 的支持还有一个就是增加 shredding 过程，用于进一步加速。

在 position delete 的基础上演化出了 delete vector，出要出发点在于不管是 partition-level 还是 file-level 的 position delete 文件都有局限。因此演化成现在的 delete vector 方式，这样磁盘和内存中的数据结构统一，每条数据仅会被删除一次，文件数也大大减少。

也有一些分享提了类似[29] first-row/last-row 的 merge option 等需求。

Catalog

Catalog 主要负责表层面的元数据，包括最新的元数据，事物控制协调等。现在 Iceberg 提供了多种类型的 Catalog 供用户选择。

本次 Summit 中有用户介绍使用 Catalog 的具体情况[6]，也有介绍 RestCatalog 的相关事情[7][8][9]。

其中 Bloomberg 对不同的 catalog 有一些总结如下

• Hive
  • Easiest to utilize, as we were already using the ApacheHive Metastore
  • Scale and performance challenges
• AWS Glue
  • managed service
  • vendor lock-in
  • access control limited through AWS primitives
• JDBC
  • Easy and familiar to manage and connect to a database
  • access control limited through AWS or DB primitives
• Rest
  • Gave use the most flexibility to support the Iceberg Spec and additional custom features
  • Flexible integration with different query engines
  • Backed by a PostgreSQL database
  • Provided the most flexibility on access control and multi-tenancy

[7][8]分享了 RestCatalog 的由来。RestCatalog 从最初解决 HiveCatalog 的问题出发（锁粒度，以及事物控制等），分析了一个 Catalog 需要满足的条件：可靠性，低延迟提交；事物/冲突管理；客户端的兼容性；数据的权限等。Iceberg 的 RestCatalog 将部分客户端的职责移到 server 端，这样客户端更轻量级；更好的事物控制（DML/DDL 的协调，合并和实时写入的协调），多表事物控制；客户端更好实现（更轻量级，更方便多语言实现）。以及 Apache Polaris 的一些实际使用情况。

[9] 分享了 Pinterest 使用 Gravtino 解决 Iceberg 过程中的一些实际问题，包括：partition list 很慢；性能分析；已经引擎相关的性能问题等。

Compute&Management

数据存储后会被查询使用，为了查询效率高也需要对数据进行管理优化。

[10] 主要分享了不同参数下 Iceberg 表的性能情况。主要在 file format 层面的调优，包括 write.target-file-size-bytes 和 write.parquet.row-group-size-bytes 的调优实践。一些具体的测试数据如下：

并测试了不同引擎下的查询效率

• unsorted 情况下 2MB vs 128MB row group size 性能可以提升 15%
• sorted 的情况下 2MB vs 128MB row group size 性能可以提升 177%

[11] 分享了 Impala 优化 Iceberg MOR 的流程，主要思路是避免无限重复读取 delete 文件，单独一个算子读取 delete 文件，然后使用 broadcast join 来进行数据的删除。

[12] 分享了如果给 Iceberg 查询做 I/O 优化进行加速，主要思路是尽可能的进行 filter pushdown — filter pushdown is the gold standard of I/O optimizations

由于不是所有的 filter 都能够 pushdown，可以可能需要 rewrite SQL。现在 Iceberg 中 filter pushdown 会有如下约束

• Filters are only useful if they eliminate entire partitions or data files
• Limited set of statistics to evaluate with
  • Lower and upper bounds
  • Null, NAN, Value Counts
  • Partition Values
  • Not as useful for non-numberic cols
• Complex filters contain compute functions
  • Iceberg transforms are only a subset

然后给出了一些 rewrite 的具体例子

对于无法全部下推的，可以考虑部分下推，如下所示

在最后对 Iceberg Metadata 提出一些需求，希望未来有更多可用于 file pruning 的 metadata 信息。

[13] 分享了 partition stats 的背景，当前情况等。主要是为了更好优化查询(CBO 过程)。

现在 Iceberg 有 FileLevel/Manifest Level/Snapshot Level 的指标，希望有 partition level 的指标。由于实际场景中大部分是分区表，因此 partition level 指标在现实世界中有很多使用场景。

• 避免读取所有的 manifest（有些表的 manifest 非常多）
• 在 plan 的时候可以 autoscaling（根据 partition level 指标动态调整并发）
• 动态调整 query plan（join reordering，IO operator）
• 仅在最新 snapshot 中 partition 会影响查询时进行合并
• 根据 partition 指标刷新数据写入链路（Two sigma 无法 expire snapshot 的例子）

[14] 分享了 Iceberg 的跨集群复制以及灾难恢复，主要思路是基于 snapshot 的增量复制。

[15] 腾讯(TEG) 分享了处理超宽表的一些线上生产经验，主要在 ML/DL 等场景下，会有上千列的情况。主要问题有：

• 表太宽，单表上 P
  • 单表上千万的文件数量，上千数量的 manifest 文件
  • plan 性能瓶颈
  • batch 写入消耗内存多，容易导致 OOM
• 列管理困难
  • 不是所有列的价值都一样
  • 列的频繁增删

整体的思路包括：减少不必要的元数据（比如指标）；通过 column stats 知道列的使用频率，然后进行调整；将 datafile 合并到 manifest file 中，减少文件数量；另外在合并的时候通过直接操作 parquet 来加速等一系列优化方案。更详细的可以查看对应视频。

[16][17][18] 有讲表管理、优化相关的事情（和 Amoro 定位类似，Linkdin 开源了他们的 OpenHouse），这里面有比较多实际生产经验可以借鉴，包括合并策略、资源优化、扩展性、观测性（用户侧，服务侧）、告警等

[22] 分享了腾讯云基于 Amoro 做的流批一体的湖仓系统，包括 MixedIceberg 承接实时数据，以及支持 partial update 等需求。

File format

为了满足不同的场景（尤其是 ML&AI），有不同的 file format 出来(lance, vertox 等)，如何在 Iceberg 中结合新型 file format 的能力是一个社区正在做的事情。

[19]分享了 fileformat 出现的一些原因，以及 Iceberg 正在做的事情 — 抽象 FileReader/Writer 的接口等。

• ML workload 的特点
  • wide columns
  • both scan & search
  • grow horizontally(wide schema)
• 新硬件的特点
  • not just(or even primarily) run on CPUS
  • Accelerators like GPU & FPGA are embarrassingly parallel
  • Common bottlenecks: CPU, Copying to device memory
  • IDEA: Load compressed data, decompress on-device

新的 file-format 要求和特点如下所示

• 要求
  • Decompression via GPU SIMT
  • Decompression via CPU SIMD
  • Random access on compressed data
• 特点
  • workload diversity
  • flexibility & interop
  • accelerated computing

[15] 中腾讯的分享是在 parquet 中做的一些工作。

Streaming

随着大家对实时入湖的需求，以及 Iceberg 在实时入湖上的现状，大家在寻找时效性，湖仓治理的一个平衡点。

不同公司也在尝试实时入湖的事情，如何做到时效性、管理成本等的平衡是一个难点。

[20] 分享了 Snowflake 在 Iceberg 上做增量计算的一些事情，这个分享包括了增量计算的定义，以及在 snowflake 中实现的一些思路，思路大概是通过 row_id 来记录数据的演进（row_id 也可以当成 watermark），然后通过代数变换讲 join 等算子变换为增量计算的算子减少计算量。比较麻烦的是多表事物的处理 — 需要有一个全局的时间。

[21] 分享了实时入湖效率，以及后续湖仓内数据治理的一些实测数据，希望达到一个全局的最优，主要思路是在不影响 compaction 的情况下增大入湖效率（增大写入并发），然后通过类似 RestCatalog 的角色来协调 commit。另外会对一些错误配置等提前预判并通知。

[26] 分享了如何实时入湖相关的事情，并给出了从 Snowflake 迁移到 Iceberg 的一些情况，并且基于实际情况提出了 Flink Dynamic Schama 的需求，在最新的 Sink 中有相关的工作正在进行中。

Ecosystem(&usecase &migration)

[6] 有分享迁移到 Iceberg 前后的收益

[17][25][27]分享了 Hive 迁移到 Iceberg 的一些事情，描述了 Hive 的一些限制：partition 支持不好；ACID 支持不好，性能，扩展性，多引擎支持等等，以及从 Hive 迁移到 Iceberg 的详细流程和 checklist，包括前期分析，迁移计划，具体执行，以及最后验证等，对于 Hive 迁移 Iceberg 的可以参考下。从 Hive 迁移到 Iceberg 后，整体减少了 70% 的资源，查询峰值时间降低了 95%，对于 streaming 入湖也更简单了。

[9] 使用 Iceberg 做流批一体存储，链路大致如下 [upstream] -> kafka -> flink -> Iceberg -> [Flink/Spark]，使用了两张表来承接实时数据：其中一张表保留全量数据，一张表保留增量数据，增量数据周期性写入全量表（Amoro 中的 mixed-iceberg 思路类似）。

[23] 分享了使用 Trino 做可扩展的湖仓，主要解决如下问题：扩展性；管理难度；查询性能慢；vendor lock-in 等。

在扩展性方面遇到：metadata 增长；不同的 workload；查询性能的稳定；数据倾斜的处理以及限速等。

基于生产经验总结了一些最佳实践：

• 读方面：使用 NDV Status，filter pushdown， metadata/data cache，materialized view(trino），合适的线程池大小等
• 写方面（主要是 trino 相关）：限制写入并发；数据合理分区，专用 plan/delete 的线程池等

[23] 分享了使用 Iceberg 做统一存储后，避免在各系统之间进行数据的传输，计算等，减少了整体的计算和存储量。

[24] 分享了构建基于 Iceberg(+StarRocks/BigQuery) 的大规模分析系统，并且在生产中实现了 blue/green 的常规流程。 使用 Iceberg 前后的对比如下所示（之前是 PG 和 BigQuery）

[28] 则分享了 PG 支持 Iceberg 外表的一些情况，这样可以结合 PG 和 Iceberg 的能力。

[30] 分享了 Redpanda 的 iceberg table，听起来和Automq 的 iceberg table 以及 fluss 有相似之处，可以将 MQ 的数据直接 compaction 到 datalake 中，这块或许一个完整的是，有轻量级 MQ + service 能力负责 offload 和 compaction，以及现在的 datalake。

[31] 则分享了生产中实际情况，比如使用 storage partitioned join 来避免大量 shuffle 的场景。

另外类似 Trino/StarRocks/BigQuery 等引擎均在大会上分享介绍如何结合 Iceberg 的，在语言方面，除了 Java 之外，现在 Python/Rust/C++ 等语言也在积极推动中。

Ref

[0] https://www.icebergsummit2025.com/agenda/
[1] V3 and Beyond Iceberg’s ongoing evolution
[2] Decoupling Metadata: Leveraging Queryable Iceberg Tables for Scalable, Cross-Engine Innovation
[3] Understanding Deletion Vectors in Apache Iceberg
[4] Iceberg Geo Type: Transforming Geospatial Data Management at Scale
[5] Decoupling Metadata: Leveraging Queryable Iceberg Tables for Scalable, Cross-Engine Innovation
[6] Building Bloomberg’s First Incremental Alternative Data Product Using Apache Iceberg
[7] Pioneering the Next Frontier: The REST Revolution in Apache Iceberg Metadata
[8] Scalable Lakehouse Architecture with Iceberg & Polaris: A Battle-tested Playbook
[9] Scaling Iceberg Adoption at Pinterest with Gravtino
[10] Deep Dive into Iceberg Optimizations and Best Practices for a Scalable and Performant Lakehouse
[11] Extending the One Trillion Row Challenge to Iceberg V2 Tables
[12] Iceberg I/O Optimizations in Compute Engines
[13] Supercharging Apache Iceberg Strategies for Harnessing Partition Stats
[14] Iceberg Resilience: Building a DR Strategy for the Data Lake
[15] Efficiently Managing Table With Thousands of Columns Using Iceberg In Tencent
[16] Learning from running large-scale Apache Iceberg Table Management Service
[17] Airbnb Icehouse: The Journey to Iceberg
[18] Optimizing Iceberg Table Layouts at Scale: A Multi-Objective Approach
[19] Turbocharge Queries on Iceberg with Next-Gen File Formats
[20] CDC Implementations on Apache Iceberg and where are we headed
[21] Unleashing the power of Iceberg ingestion 100GB/s and beyond
[22] Building a Batch-Stream-Unified Lakehouse on Apache Iceberg in Tencent Cloud
[23] Eliminating redundancies in ETL with Iceberg tables on Snowflake
[24] From zero to one: Building a petabyte-scale data analytics platform with Apache Iceberg
[25] Hive Tables to Apache Iceberg: A Step by step Migration Blueprint
[26] Iceberg with Flink at DoorDash
[27] Implement Iceberg for Improved Data Management at Autodesk
[28] Postgres meets Iceberg
[29] Supercharging wise data lake with apache iceberg
[30] The ‘Streamhouse’: Extending Redpanda into a fully managed, Iceberg-backed realtime data lakehouse
[31] Adopting Apache Iceberg at Slack: Challenges, Lessons, and Best Practices