摘要：2024 年 6 月，Databricks 宣布收购由 Iceberg PMC ChAIr Ryan Blue 创办的 Tabular 公司，一时间，Iceberg 未来走向何方，众说纷纭，很多人担忧 Iceberg 项目会因为商业原因被毁掉，甚至 Icebe
作者 | 张友东
一年以后，面对 Iceberg Summit 2025 座无虚席的会场，Ryan Blue 将会回想起与同事讨论 Iceberg 原型的那个遥远的下午。
2024 年 6 月，Databricks 宣布收购由 Iceberg PMC ChAIr Ryan Blue 创办的 Tabular 公司，一时间，Iceberg 未来走向何方，众说纷纭，很多人担忧 Iceberg 项目会因为商业原因被毁掉，甚至 Iceberg 社区有 "Call for Ryan Blue to Step Down as Iceberg PMC Chair" 的讨论。
事实证明，担忧是多余的，Iceberg 的发展反而变得更快了， 主要有几个原因，一是 Databricks 与 Snowflake 都加大了在 Iceberg 上的投入，湖仓标准是必争之地，倘若 Databricks 不尽心支持 Iceberg 的发展， Snowflake 会立即扛起大旗；二是 Ryan Blue 不再担任 Tabular CEO，不用为公司生计操心，有更多的精力来推动 Iceberg 社区的发展。
Iceberg 在 2024 年一路开挂，Snowflake 和 Databricks 先后开源 Iceberg RESTful Catalog、AWS Reinvent 发布 Iceberg Format 的 S3 Table Bucket ... 一整年时间里，Iceberg 持续占据 Data Infra 的热点，毫无争议的成为开放表格式的事实标准。
2025 年 4 月 Iceberg Summit 首次在旧金山线下举办，赞助厂商、社区明星用户、大数据领域专家云集，吸引了超过 500 人线下参会，看着 Iceberg 一步步发展壮大，回想起过去坚持理念孤独前行的漫长岁月，Ryan Blue 感慨万千，满怀激情的给社区分享了 Iceberg V3 的发展情况作为大会的开场。
表格式标准之争
Apache Iceberg、Apache Hudi、Delta Lake 是过去几年里被应用最广泛的 Open table format，他们都是在 2016-2017 年孵化出来的项目。Hudi 是 Uber 在 2016 年创建，为了解决大规模数据集上的实时数据写入和更新问题，全称是 Hadoop Upsert Delete Insert，名字就能很好的体现她能解决的问题。
Iceberg 由 Netflix 在 2017 年开发，在对象存储上构建一个通用的 Table layer，解决 Hive 在大规模数据集场景下遇到的正确性、扩展性、维护困难等问题。Hudi、Iceberg 是用户在使用 Hadoop 的过程中遇到的痛点问题孵化而来，而 Delta Lake 则是由数据平台厂商 Databricks 研发，其代表的是未来数据平台往 Open lake + Compute Engine 构建 Lakehouse 发展方向的构想。
三大开放表格式在演进的过程中，Iceberg 在性能、功能等很多方面都不是最突出的，但似乎从一开始就注定，只有 Iceberg 具备成为标准的潜质。
Delta Lake 虽然也是 Open format，但使用 Delta Lake 的用户基本都是 Databricks 的客户，Delta Lake 可以看作是 Databricks 的内表。Hudi 早期在功能、性能层面比较领先的，迭代也比较快，尤其实时方面比较突出，但从标准的角度，Hudi 的顶层设计相比 Iceberg 有很多不足，而且其早期跟 Spark 引擎深度耦合，也影响了 Hudi 的发展。
从定位上，Iceberg 成为标准可能性最大，但要真正被业界广为认可，理论设计支撑是远远不够的。
首先，打铁要靠自身硬，Iceberg 一直以 Table format layer 作为定位，在设计的时候考虑到不同引擎的需求，定义了可扩展的 Table format、分区演进、time travel 等 Spec，为了保证引擎行为的统一性，每次发布都包含 reference implementation，所有的引擎适配以这个为参考标准，保证最终引擎在 table 上的操作行为表现是一致的。
其次，在严格遵循 Spec 的基础上，众多的引擎开始适配 Iceberg，比如 Spark、Flink、StarRocks、Trino 等，引擎的广泛支持让用户的落地实践变得更简单，吸引了社区大客户开始使用 Iceberg 并参与社区贡献，像 Apple、Netflix、Linkedln、Pinterest 都是 Iceberg 社区活跃的知名客户，不光使用，还参与社区贡献，推动 Iceberg Spec 向前迭代。
最后，厂商的深度参与，也是推动 Iceberg 走上神坛的重要力量，三大云厂商尤其是 AWS 都在支持 Iceberg 的发展，Snowflake 与 Databricks 因为竞争的原因，也不遗余力的推动 Iceberg 发展。总的来说，Iceberg 最终获得了开发者、客户、厂商的广泛认可，推动其成为开放表格式的标准。
Iceberg V3 Spec
Iceberg V3 的 Spec 已经基本确定，包括 Variant、Geo 数据类型，基于 Deletion vector 实现的数据更新 / 删除能力，以及用于追踪数据变化的 Row Lineage 等特性，V3 的落地极大的补充其相比其他表格式的不足之处。
Iceberg 社区已经开始有一些未来 V4 Spec 的想法，比如解决元数据多跳访问的问题、索引增强、物化视图以及 AI 场景的能力增强等，但这些还非常早期，未来一年最重要的事情还是推动 V3 Spec 变成能实际在真实业务场景使用的特性，让 Spec V3 在真实业务里发挥价值。
Variant
Variant 数据类型用于高效地存储和处理动态半结构化数据，Variant 类似于 JSON 类型，但其相比 JSON，编码效率更高，读写访问效率更高。 Snowflake 的 Aihua Xu 是 Variant 的核心贡献者，Snowflake 是业界最早实现了 Variant 类型支持的厂商，Variant 的实现也吸收了 Snowflake 的经验 。Variant 的编码规范定义在 Apache Parquet 项目里，是一个复杂的跨开源社区协作的项目，这也是 Iceberg 社区厉害的地方，社区的核心参与者能够沉下心，持续多年的迭代去推动标准落地。
Variant 类型要发挥作用，Shredding 策略关键，否则整体访问 Varint 对象，对于性能要求较高的 OLAP 场景，影响会很大。标准里定义了 Shredding 后数据应该如何存储，但实现 Shredding 依赖于引擎本身，需要主流引擎逐步适配，才能充分发挥 Variant 的威力。
Geometry & Geography
Geometry & Geography 是强场景关联的数据类型，对于有地理位置存储、分析需求的业务是非常有帮助的。Geo 类型在很多数据库里都支持，并不是一个新鲜东西，Geo 数据已经有很多公开的编码方式，像 WKT、WTB、GeoJSON，但 Iceberg 社区最终还是选择设计新的类型及编码方式，主要考虑性能、扩展性，毕竟原来这些格式都不是专门为数据分析场景设计的。
Iceberg 的 Geo 类型 Spec 吸收之前类似项目的经验，设计了新的 Geometry & Geography 数据类型，并推进其成为 Parquet 的一部分，Geo 数据类型的标准定义也是一个多方协作的复杂项目，包括 GeoLake、GeoParquet、Iceberg、Sedona、Snowflake、Databricks、Apple 等很多社区 / 公司的参与，非常不容易。
Delete Vectors
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。
Row Lineage
Iceberg V3 引入 Row Lineage 特性支持行级别的变更追踪，引擎在写入数据文件时，必须维护表级别的 next-row-id 字段，和行级别的 _row_id 和 _last_updated_sequence_number 字段。
其中 _row_id 是表中每一行的唯一长整型标识符，当一行首次被添加到表中时，通过继承机制分配该值；_last_updated_sequence_number 是最后一次更新的提交序列号，当一行首次被添加或修改时，通过继承分配该值。
Row Lineage 不会追踪通过等值删除（Equality Deletes）更新的行的血统，因为使用等值删除的引擎在写入更改之前会避免读取现有数据，因此无法为新行提供原始行 ID。
Multi-table Transaction
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。
File Format API
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
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。
Linkedln
Linkedln 将使用 Iceberg 过程中沉淀的经验产品化，发布了 OpenHouse，OpenHouse 是一个开源的 Lakehouse 的管理系统，作为一个 Lakehouse 的 Catalog Service，同时支持 Iceberg 数据合并、数据回收、数据共享、数据治理等，让 Lakehouse 的数据管理变得更简单。
其中 AutoComp 模块负责数据的自动合并，解决大量小文件的问题，AutoComp 的目标是最大程度减少文件数量，同时要最小化资源开销，所以 AutoComp 会有很多 Tradeoff；因为不同的表价值不一样，AutoComp 要能灵活的定义 Compaction 规则，而不是无脑全量 Compaction，同时 AutoComp 会自动跟踪每个表的使用情况、数据分布情况，综合考虑制定合并策略，来平衡文件数量和资源开销。
Airbnb
Airbnb 从 2021 年开始使用 Iceberg，数据架构经历从 Hive on HDFS 到 Hive on S3 到 Iceberg on S3 的演进，这是互联网大厂的典型演进路线，引入 Iceberg 的解决 Hive 上遇到的 HMS 元数据管理瓶颈、分区管理复杂等问题。
Airbnb 通过 login event 分析场景作为试点，这个场景里最新写入的数据会按小时分区，满足业务小时级 Data freshness 的要求，但会产生大量的分区，对 HMS 产生很大压力，于是后台将历史的分区合并成按天，按小时分区的数据短周期保留，按天分区的数据长周期保留，替换成 Iceberg 后，借助 Iceberg Schema Evolution 的特性，做到不动数据只修改元数据就能达到类似的效果，节省大量数据合并的计算资源，同时在数据查询延时上有大幅下降。
后续 Airbnb 在内部更多场景推广 Iceberg，并围绕 Iceberg 作为存储底座构建一整套 Lakehouse 数据迁移、治理、性能优化的管理系统 IceHouse，这个名字很受欢迎，跟 Iceberg 和 Warehouse 都能形成关联。
Pinterest 从 2022 年开始使用 Iceberg，业务发展经过试点验证，到新业务默认采用 Iceberg，到存量部分历史业务迁移降低 ROI 等几个阶段，很多公司推广 Iceberg 都是类似的灰度逻辑。
Pinterest 目前 Hive 的数据规模 650+PB，Iceberg 规模 130+ PB，Iceberg 占到 20%，其中 v1 版本的表占到 90% 以上，其余的是 v2 版本，只在小部分场景开始使用。
Pinterest 在使用 Iceberg 过程中，遇到 List partition 时间长，读写指标缺失等性能问题、数据缺乏统一治理、以及安全认证访问控制等问题。Pinterest 通过引入 Apache Gravitino 统一 Catalog Service 来解决这些问题。Gravitino 旨在提供企业级统一的元数据中心，可以认为是 Catalog of Catalogs，在 Iceberg 上，可以采用 Plugin 的模式对接后端各种常见的 Catalog Service，包括 Rest Catlog、JDBC Catloag、HMS 等，对用户提供 Iceberg RESTful API，这样就很容易跟企业现有的元数据管理系统打通。
在这个基础上，Gravitino 提供了基于事件的扩展接口、丰富的访问 Metrics、统一的认证、细粒度的权限控制等通用能力，比如基于事件接口，Pinterest 可以做一些 Table 数据治理的优化，以及额外存储 Partition 元数据解决访问延时的问题，基于丰富的 Metrics，收集并分析 Metrics，来优化集群的访问效率。
从当前 RESTful Catalog Use case 看，用上开源 Unity Catalog、Polaris 的基本没看到，Hive Catalog 和自研的 RESTful Catalog 占了大多数，新开源的 Catalog， 反而是 Gravitino 这种复用现有系统的模式对于存量 Iceberg 用户来说落地更快；但随着 Unity Catalog、Polaris 的逐步成熟，很多 Gravitino 的当前具备的能力会成为未来 Catalog Service 的标配，Catalog 的战争才刚刚开始。
TRM Labs
TRM Labs 是一家领先的区块链情报公司，致力于通过区块链数据分析帮助金融机构、加密货币企业和政府机构检测和调查与加密货币相关的金融犯罪和欺诈行为。TRM Labs 第一代平台基于 BIgQuery、PostgreSQL 构建，Customer-facing 场景下的点查、小的聚合在 PostgreSQL 集群上完成，复杂查询在处理大规模数据和多环境部署时遇到瓶颈。
结合 On-prem 部署需求、成本、扩展性等多个维度的考量，TRM Labs 选择往 Lakehouse 架构演进，其选择 Iceberg 作为底层的 Table format，引擎方面经过详细的对比评测，StarRocks 在点查询和复杂聚合查询中均优于 Trino 和 DuckDB，故最终选择 Iceberg x StarRocks 构建 Lakehouse，新一代的 Lakehouse 架构目前已经稳定支持 TRM Labs 面向客户的数据分析业务，相比第一代架构，P95 延时下降一倍，同时省去了复杂的 ETL 链路维护以及冗余的存储成本。
DoorDash
DoorDash 的实时分析场景，原来通过 Flink -> S3 -> SQS -> Snowpipe -> Snowflake 构建，随着业务规模的增长，Snowflake 部分的成本高，链路里借助 Snowpipe 实时写入 Snowflake， 引入 Snowpipe 本身的成本以及 Double write 的资源开销，导致链路无法扩展。新的链路里，直接 Flink -> Iceberg(S3)，然后采用 Snowflake unmanaged lceberg 来查询，链路更加简单易维护，同时资源成本更低，存储上 Iceberg 的存储相比 Snowflake 存储量降低了 25-49%，计算上，因为链路简单，计算资源下降 40-70%。
Tencent
腾讯内部大量使用 StarRocks 的 Lakehouse 方案支持各类数据分析场景，其中服务广告、机器学习两个场景有个共同的特点，就是纬度多，容易产生大宽表，到上千列的数量级，上千列大宽表会导致 Iceberg 产生大量的数据文件，以及元数据文件，腾讯通过设置更大的文件大小、Rewrite procedure 合并数据文件等一系列手段来减少数据文件等数量，通过减少不必要的列元数据来减少元数据量，在运行过程中，还会进一步追踪列的使用情况，完全没有价值的列会考虑直接删除来减少数据量，上述优化保证上千列大宽表场景的稳定运行。
RedNotes
小红书采用 Iceberg 统一 AI、BI 的场景，小红书 Iceberg 数据规模超过 100PB，每天新增 3PB，这些数据主要应用在 BI 分析与机器学习的场景。BI 场景下，小红书原来的方案是将 Iceberg 数据导入到 ClickHouse 服务 OLAP 查询，后面升级到 StarRocks 直接查询 Iceberg 的方案，结合 Iceberg 表 zorder 排序的优化，P90 的延时下降到 1/3，达到 10s 量级，同时省去了复杂的 ETL 链路以及冗余的存储成本。AI 场景下，为了便于模型高效的迭代，在 Iceberg 上实现了轻量级 MOR 的更新能力，结合 Iceberg branch 的特性，高效的实现模型的训练数据的增量更新与灰度验证。
商业化生态
Iceberg Summit 2025 参会的人员，基本都是大数据圈的专业技术同学，对于数据类厂商来说，是高质量的人群，第一次线上活动就吸引 20+ Iceberg 生态相关的厂商赞助。这些厂商包括云计算平台、Lakehouse 计算平台 / 引擎、流数据平台、对象存储、ETL 平台、BI 等厂商，已成星火燎原之势。
Cloud Platform
三大云厂商 AWS, Microsoft, Google Cloud 都是赞助商，从 Iceberg 生态的角度，云厂商可以提供对象存储底座，Iceberg 应用给云厂商带来巨大的对象存储用量增加；同时，云厂商还能够提供 Iceberg Catalog Service 的能力，给应用提供便捷的访问入口，将 AWS 其他产品与 Iceberg 连通；最后，云厂商还提供 Iceberg 分析处理的能力，增加计算的用量。
AWS 无疑是 Iceberg 方向上表现最突出的选手，在社区贡献上，很早就开始投入 Iceberg 社区，有两位 PMC 成员。在产品方面，2024 年 AWS Reinvent 上发布 S3 Table Bucket，简化了 Lakehouse 的构建与维护，堪称杀手级的产品，让 Lakehouse 变得跟 S3 对象存储一样唾手可得，在数据分析场景，Lakehouse is the new S3。
Azure 虽然在 Iceberg 方向上建树一般，但在 Lakehouse 商业化上布局是很早的，早在 2016 年，Azure 就跟 Databricks 展开合作，Azure 给 Databricks 带来了巨大的流量，这个合作也是影响 Databricks 公司发展最重要的决策之一。
AWS, Microsoft, Google Cloud 的数仓产品 Redshift、Synapse、BigQuery 都增加了 Iceberg Table 的支持，模式跟 Snowflake 的 Managed Iceberg Table 类似，可以通过数仓引擎直接分析外部构建好的 Iceberg Table，也可以服用数仓引擎的 Data Pipeline 构建 Iceberg Table，并提供对 Iceberg Table 的管理、维护与优化能力。
Lakehouse Platform
Databricks 与 Snowflake 两家数据科技巨头无需多介绍，是当前 Iceberg 社区发展的最核心的力量，2024 年 Databricks 收购 Tabular 后，成为拥有 Iceberg PMC 成员最多的公司，随后 Databricks 和 Snowflake 都不甘落下风，从其他公司挖了更多的 PMC Member，唯一的中国本土公司成长起来的 PMC Member 近期也加入了 Databricks。
从当前的情况看，Databricks 要更胜一筹，Lakehouse 概念是 Databricks 造出来，落地了众多 Delta Lake x Photon 引擎构建 Lakehouse 的场景，经验丰富，思考深远。
虽然 Databricks 在 Iceberg 上的能力建设才刚起步，但其已经建立了社区的领导地位，能力建设只是时间问题，从 Iceberg V3 Spec 也可以看出，Databricks 也在把一些 Delta Lake 上的经验推到 Iceberg，加速 Iceberg 的迭代。
CelerData 是基于开源 StarRocks 构建的企业级 Lakehouse 分析平台，借助 StarRocks 强劲的分析性能，可以在 Iceberg 等开放数据湖上直接分析满足 Customer-facing、Data warehousing 等场景 BI 场景需求，而无需维护复杂的 ETL Pipeline。
StarRocks 从 2022 年初就开始支持 Iceberg，已经实现了从查询分析到数据写入等常见能力等支持，也是最早支持 Iceberg RESTful Catalog 的引擎之一，Iceberg 的用户可以通过 StarRocks x Iceberg 构建 Lakehouse，替代原来基于 Data Warehouse 的解决方案，目前在全球有大量的行业头部客户大规模实践 StarRocks，比如 Pinterest、Airbnb、Expedia、Shopee、Grab、腾讯、小红书等。
Dremio 是一体化的 Lakehouse 数据分析平台，基于开源 Arrow、Calcite、Iceberg 等技术构建，Dremio 是最早以 Iceberg 作为存储底座等 Lakehouse 平台，比 Ryan Blue 创办 Tabular 还要早。
Dremio 的思路跟 Databricks 类似，提供数据集成、数据存储、数据分析、数据治理一体化 Lakehouse 平台，而 Tabular 的思路是组合式 Lakehouse，Tabular 提供 Iceberg 数据集成、元数据管理、性能优化等基础构建数据湖的能力，用户可以灵活的选择计算引擎，来分析处理 Iceberg 上的数据。Databricks 收购 Tabular 后，在 Iceberg 上的支持会不断增强，后面 Dremio 面临 Databricks 的竞争挑战会更大。
Starburst 是基于开源 Trino 构建的企业级 Lakehouse 平台。Trino 最早定位是一个联邦分析的引擎，支持非常丰富的数据源，最近几年，Trino 把重心放在跟 Open lake 的对接上，深度优化 Iceberg 上的查询、写入以及数据管理，推出了 Icehouse。Starburst 在 Kafka->Iceberg 数据入湖链路上做了深入的优化工作，正是由于 Lakehouse 架构的快速发展，使得 Starburst 有机会提升其产品 Scope，升级为 Lakehouse 平台，Trino 近期一直在讲 Iceberg 数据导入相关的工作，也是在向社区讲 Trino 不再只是一个查询引擎，而是一个完备的 Lakehouse SQL 引擎的故事。
Stream Data Platform
Confluent、Redpanda、StreamNative 是流数据处理领域最好的几家公司，商业模式也很相似，基于开源的 Kafka、Redpanda、Apache Pulsar 构建企业级流数据平台。三家公司在 Iceberg Summit 上讲的故事基本一样，在实时场景，Kafka/Redpanda/Pulsar 是数据流的入口，当前最多的应用 Case 就是连接 Operational Data 与 Analytical Data，大部分的数据下游是 Data Warehouse。
例如 Snowflake、Redshift、StarRocks、Clickhouse 等产品，服务数据分析的业务场景。近几年，随着 Lakehouse 快速演进，Iceberg、Delta lake 成为数据分析的新选择，从 Kafka 到 Iceberg，需要考虑 Schema 映射与演进、数据入湖存储、Catalog Service 等很多复杂的工作，流数据平台公司试图将这些工作简化，实现 Kafka 与 Iceberg 的无缝集成。
Confluent 公司已经成立 11 年，是行业的老大哥。Confluent 推出 TableFlow 来实现 Kafka 到 Iceberg 的集成。一个有意思的点是，Confluent 在过去做了一个流处理的产品 KsqlDB，在 Kafka 上通过 SQL 做流处理，这个产品一直不温不火，在流处理能力上也有不少限制，再加上 Flink 快速的发展态势，在前几年，Confluent 已经放弃 KsqlDB，All in Apache Flink，Confluent 完全可以选择借助 Apache Flink 跟 Iceberg 对接，但最终还是发布了独立的产品 TableFlow 来实现跟 Iceberg、Delta Lake 的集成，足以说明其对 Lakehouse 的重视，这是一个足以撬动行业格局变化的数据架构升级。Redpanda 是 C++ 版本的 Kafka，以性价比作为切入点与 Confluent 竞争，号称在性能上比 Kafka 快 10 倍，同时硬件需求仅为 Kafka 的六分之一。
Redpanda 在与 Iceberg 的集成上，引入了两个新概念，Iceberg Topic 和 StreamHouse，前者是一个很好的名字，写入 Iceberg Topic 的数据，会自动写入到 Iceberg 存储。StreamHouse 是底层基于 Iceberg 的 Realtime Lakehosue，是一个更大的故事，名字包含 House 也说明是想让 Iceberg 数据也在 Redpanda 平台管理。
2025 年 4 月 Redpanda 新融资 1 亿美金，估值约 10 亿美金，Redpanda 过去几年获得较好的增长，需要大故事来支撑未来，但大故事的弊端在于面临更大的竞争，当前对于流数据平台来说，我认为不是一个很好的选择，Iceberg 的核心在于开放，上下游各种系统可以组合起来，构建强大的 Lakehouse。
StreamNative 基于开源 Apache Pulsar 构建商业化产品，云原生存算分离是 Pulsar 早期的核心特性，官网宣称 TCO 比 Kafka 低 95%，后面为了更好的商业化发展，Pulsar 也兼容了 Kafka 协议，所以上面的三家公司本质都是泛 Kafka 生态的商业公司，StreamNative 基于 Ursa Engine 实现与 Iceberg、Delta Lake 等 Lakehouse 的融合。
梦开始的地方
2017 年的某天早晨，Ryan Blue 来到 Netflix 的办公室，开始平常的一天。他又一次接到业务团队的投诉，Hive 里有好多张表数据对不上。他和团队根据数据拓扑和运行日志做了一轮分析，发现中间有一个数据加工的任务没有处理好，所有依赖这个结果表的结果都不对，需要帮助业务重新跑所有的任务，从早上一直折腾到下午，所有的数据都重新处理完。
Ryan Blue 感到非常疲惫，对旁边的 Dan Weeks 说，我们需要做点事情来改变这个糟糕的状态。我们的系统需要支持事务、需要能做数据更新和删除，需要能快速的做 Schema 演进 ... 有了这些能力，我们的业务使用起来会更加得心应手，我们也不用再经常性的折腾数据，他们把这些痛点问题逐个记录下来，在公司的白板上画起了 Iceberg 第一个原型设计图。
作者简介
张友东，StarRocks TSC Member
今日好文推荐
传字节跳动内部开始禁用Cursor了
模型下载量12亿，核心团队却几近瓦解：算力分配不均、利润压垮创新？
印度国家级大模型上线两天仅 300 余次下载，投资人直呼“尴尬”：韩国大学生模型都有20万！
Java 三十周年重磅发声：James Gosling 怒斥 AI 是“一场骗局”，是科技高管“疯狂压榨”程序员的新工具
来源：InfoQ
