Apache Iceberg 已经赢在未来——2025 年会怎样？

注释：这里将英文标题中的“Won the Future”理解为“赢在未来”，并且结合中文的表达习惯，将“What’s Next for 2025?”翻译为“2025 年会怎样”，使标题更加通俗易懂和符合中文的口语表达习惯。

2024年的冰山生态系统

多年来，数据工程社区一直在争论开放表格式的未来发展方向。Delta Lake与Databricks的紧密集成是否会胜出？Apache Hudi在流处理领域的早期采用能否保持其优势？还是Apache Iceberg会悄悄地占据主导地位？

比较GitHub星。

到了2024年底，答案已经明朗：Apache Iceberg 赢了。

我们是如何走到这一步的？Databricks 收购了由 Iceberg 的原始创建者创立的 Tabular 公司，这表明了对 Iceberg 潜力的重要认可。与此同时，Snowflake 推出了基于 Iceberg 的目录功能 Polaris。随着像 Starburst 和 Dremio 这样的知名查询引擎供应商支持 Polaris，整个行业围绕着一个共同的标准团结在一起。

2024年6月，Databricks买下了Tabular。

Apache Iceberg 现已成为事实上的开放表格式标准。但真正的故事才刚刚开始。展望未来，比如 2025 年，几项激动人心的发展将巩固 Iceberg 在现代数据工程中的核心作用。

让我们面对现实——在数据湖中管理权限一直很混乱。没有统一的方法，用户只能依赖临时的方法，例如在S3桶级别上设置权限或使用特定查询引擎的访问控制功能。这种碎片化不仅效率低下，还带来了安全隐患。

有了标准格式的分发凭证，开发人员可以轻松地将RBAC系统无缝集成到Iceberg目录中。

冰山社区正在通过一个新的OpenAPI规范（PR #10722）来解决这个问题。该规范标准化了提供的凭证结构，使之允许开发人员可以直接在Iceberg目录中构建基于角色的访问控制（RBAC）系统。

例如，管理员可以在目录级别定义详细的访问控制策略，独立于底层存储和查询引擎。这些功能类似于企业级产品中提供的功能，例如 Databricks 的 Unity Catalog，但具有 Iceberg 提供的灵活性和开放性。

之前人们常说冰山不适合用于实时流处理。公平地说，冰山缺乏强大的CDC（变更数据捕获）能力。虽然它的架构确实支持版本化的表快照（Spark CDC过程），但它不太适合高频数据变更或实时分析。

随着Iceberg Spec V3的推出，情况正在改变，它引入了一个关键特性：行谱系。

行系已经在多个主流的数据系统中得到实现。

行血统特性使得Iceberg能够跟踪行在更新、删除或插入时的具体变化。这使得可以直接在Iceberg表上高效实现CDC管道，这对流处理场景来说是一大进步。这将使物化视图维护和系统间的数据同步更加顺畅。

查看规格提案以获取更多详细信息。一旦Spec V3完全实现后，Iceberg在实时数据处理方面将能与Kafka和Hudi等传统的流处理系统一较高下。

数据湖中存放着原始的、历史性的数据，通常称为“青铜”数据。这些表非常庞大，但真正有价值的是通过这些原始数据计算出的各种派生数据集。想想聚合、转换和预计算的指标等。

到现在为止，Iceberg 没有内置的 materialized views（即物化视图）支持，导致用户需要依赖外部系统或自定义方法来管理衍生数据。这带来了两个主要问题：

• 跟踪基础表和派生表之间的依赖关系非常繁琐。
• 对基础表的任何更新都需要重新生成所有派生出来的数据。

提议的物化视图功能（PR #11041）改变了这一点。物化视图将预计算的结果存储为表，从而，并且 Iceberg 自动管理这些表所需的元数据，以便追踪依赖关系。这意味着更快的查询速度，并且当基础表发生变化时，Iceberg 会自动更新依赖数据。这为专注于物化视图的系统，如 RisingWave，提供了显著的好处。这将使用户在从动态数据中提取见解时体验到显著的改善。

随着冰山的发展壮大，冰山生态系统也在不断发展。以下是2025年值得关注的几个方面：

• 新数据类型：支持带有时区的纳秒级精度的时区时间戳，这将使Iceberg更适合金融和电信等行业的使用，这些行业对高精度数据有严格要求。
• 二进制删除向量：Spec V3 引入了一种可扩展高效的删除处理方案，这对于监管要求严格的环境或GDPR合规尤其有用。

冰山生态系统比以往任何时候都要强大。今天，你可以通过 Kafka 或者通过 RisingWave 的 PostgreSQL 协议将数据输入到 Iceberg 中，并可以使用现代查询引擎如 Trino、Snowflake、Databricks 和 RisingWave 等来查询这些数据。2025 年将会有更多令人激动的发展，RisingWave（https://risingwave.com/）。

冰山的生态系统已经很成熟了。你可以使用Kafka或Postgres协议（通过RisingWave）来导入数据，并使用多种引擎查询数据。但有一个明显的不足：轻量级压缩。

今天，Iceberg 数据合并仍然高度依赖于 Apache Spark。更多详情请参阅 https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/best-practices-compaction.html。

今天，数据压缩通常依赖于重型的Spark任务，这可能对较小的团队或工作负载来说过于庞大。这使得希望以更简单、更经济的方式来压缩Iceberg表的使用SQL和Python的用户感到困扰。

好消息来了，社区已经意识到这个问题，并且对构建一个轻量级、与引擎无关的 compaction 框架（压缩框架）的兴趣日益增长。希望在 2025 年能看到使所有用户都能更轻松地使用 Iceberg 的解决方案。

凭借诸如 RBAC 目录、流处理能力、物化视图（Materialized Views）以及对新数据类型的支持等创新功能，Apache Iceberg 正逐渐成为数据工程领域的通用表格格式。

2024年证明了Iceberg能够在格式之争中获胜。到了2025年，焦点将转向让它更高效、更便捷、更快捷、更易用，无论是初创公司还是全球企业，Iceberg都能满足你的需求。不论是构建实时数据分析管道、管理PB级历史数据量，还是探索数据湖屋架构的前沿技术，Iceberg都能提供帮助。

数据工程的未来来了，就是 Iceberg。