ASF 项目聚焦：Apache Iceberg

原文链接：https://news.apache.org/foundation/entry/asf-project-spotlight-apache-iceberg

Dipankar Mazumdar 是 Cloudera 的开发者关系总监，负责领导涵盖湖仓一体架构和 AI 的全球开发者计划。他曾在 Dremio、Onehouse 和 Qlik 担任布道师和工程师角色，为 Apache Iceberg、Apache Hudi 和 Apache XTable（孵化中）等开源项目做出贡献，并建设社区。他的工作聚焦于数据工程与 AI 的交汇领域。他是《Engineering Lakehouses with Open Table Formats》一书的作者，也是《Apache Iceberg: The Definitive Guide》的贡献者。

Apache Iceberg 已迅速成为现代数据架构中的基础技术——但其影响远不止于性能和规模。本次与 Dipankar 的对话探讨了 Iceberg 如何重新定义数据湖，以及社区、教育和开放协作如何推动其被广泛采用。

什么是 Apache Iceberg 以及它为何存在

问：能否介绍一下 Apache Iceberg？
答： Apache Iceberg 是一种面向海量分析数据集的高性能开放表格式。它旨在为数据湖带来可靠性和简洁性，允许多个引擎在强保证下安全地读写同一数据集。通过在原始数据文件之上引入表抽象层，Iceberg 帮助组织以通常与数据仓库相关联的一致性来管理大规模数据，同时保留数据湖的灵活性。

问：在 Apache Iceberg 出现之前，数据生态系统是怎样的？你早期看到了哪些不足？
答：在 Iceberg 之前，大多数数据湖依赖于像 Apache Hive（一种数据仓库基础设施）这样的技术构建的表，并以 Apache Parquet（一种列式存储格式）作为底层存储格式。这些系统在 Hadoop 时代运行良好，但随着工作负载多样化以及组织迁移到云对象存储（如 Amazon S3），一系列结构性限制开始显现。更新不可靠，分区策略脆弱，模式演化难以管理。元数据处理成本也日益高昂，尤其是在文件数量庞大时，查询性能会随时间下降。

与此同时，数据仓库通过专有系统将这些复杂性完全抽象掉，因此许多工程师从未直接面对这些问题。然而，他们却面临着高昂的成本问题，并陷入了供应商锁定的环境。

数据湖和数据仓库中的这些限制/问题清楚地表明，需要一种新的方法，将表视为一等对象，而不仅仅是文件的集合。

从 Netflix 到 Apache：Iceberg 如何成型

问：Iceberg 是什么时候开始的，为什么？
答： Iceberg 最初由 Netflix 开发，旨在解决这些大规模数据挑战。团队需要一个能够可靠处理海量数据集，同时支持不断变化的数据需求的解决方案。认识到这些挑战是整个行业面临的，该项目后来被开源，并于 2018 年贡献给 The Apache Software Foundation（Apache 软件基金会），以促进更广泛的协作和采用。

问：Apache Iceberg 解决了哪些技术问题？
答： Iceberg 解决了传统数据湖中的几个根本性问题：

多个引擎处理同一数据时缺乏一致性
复杂且脆弱的分区策略
存储层的互操作性
模式和分区演化的挑战

通过重新思考表的定义和管理方式，Iceberg 实现了可扩展、可靠的数据操作，而无需传统方法带来的开销和脆弱性。

问：早期塑造 Iceberg 的最重要的设计决策有哪些？
答：几个关键原则指导了 Iceberg 的设计：

将元数据视为性能和可扩展性的首要关注点
将逻辑表结构与物理存储布局解耦
将模式演化作为核心功能，而非事后考虑
支持引擎无关的数据访问

这些决策使 Iceberg 避免了早期系统面临的许多限制。

实际应用与影响

问：Iceberg 以跨多个计算引擎工作而闻名。为什么这一点从一开始就如此重要？
答：互操作性至关重要，因为现代数据生态系统依赖多个处理引擎。Iceberg 被设计为共享的表层，使不同工具能够安全地访问同一数据，而无需紧密耦合。这种方法为组织提供了灵活性，并有助于防止供应商锁定。

问：你能分享一些用例吗？
答： Iceberg 在各行各业被用于：

大规模分析和报告
AI 流水线
流式处理和批处理数据处理

它使团队能够在单一、可靠的数据基础上统一不同的工作负载。

挑战：解释数据栈的新层次

问：早期推广 Iceberg 时，最大的挑战是什么？
答：挑战不仅在于 Iceberg 是新的——更在于它所解决的问题并未被清晰认识。

从外部看，大多数系统似乎都在正常工作。数据仓库处理结构化工作负载，数据湖处理大规模存储，团队已经围绕它们建立了流程。因此，当我们开始谈论开放表格式和正式规范时，感觉并不像是在解决一个紧迫的问题。

即使问题确实存在，人们也不会将其归因于表抽象本身。作业缓慢、分区限制、模式破坏或并发写入导致的数据损坏，都被视为孤立的操作问题。团队会通过脚本、约定或变通方法进行修补，而不是质疑底层设计。

这让对话变得更加困难。我们不仅仅是在引入一种新方法——我们还在指出，人们依赖的基础层存在他们尚未完全理解的局限性。

建立理解：倡导、教育与内容

问：围绕 Iceberg 的倡导工作是如何扩展到核心 PMC（项目管理委员会）和 Committers（提交者）之外的？
答：最初，大部分宣传推广工作来自构建该项目的工程师。当时并没有围绕故事讲述或社区建设的结构化努力。

这种情况开始改变，是因为出现了专注于 Iceberg 的专职开发者倡导角色。我很幸运能成为其中一员。在 2021-2022 年，对于如何推广一种开放表格式（open table format），并没有现成的剧本。这种方法基本上是实验性的，即公开学习、将技术概念转化为实用内容，并持续与社区互动。

随着时间的推移，这项工作变得更加有意识。如果抽象概念对大多数人来说不明显，我们就必须让它变得可理解。而在生态系统甚至缺乏恰当词汇的地方，我们必须自己构建这套术语。

问：你是在什么时候意识到社区和教育将发挥核心作用的？
答：很早就清楚了：仅靠功能认知是无法推动采用的。我们要求人们去思考一个他们历史上从未需要推理的层。大多数工程师关注的是管道、性能和可靠性。存储层被抽象掉了，他们遇到的问题——比如任务缓慢、分区问题、模式破坏——都被视为孤立的运维问题，而不是更深层局限性的症状。

因此，在讨论 Iceberg 之前，我们必须先确立为什么表抽象（table abstraction）本身很重要。这意味着要解释表在数据湖中实际代表什么，元数据如何控制行为，以及为什么像快照隔离（snapshot isolation）或分区演化（partition evolution）这样的东西不是功能，而是安全运行多个工作负载所必需的基元。

再说一次，这些都不是表面概念。它们需要从头构建心智模型。这就是社区和教育变得核心的原因！

问：你提到技术内容在 Iceberg 早期采用中发挥了巨大作用。能详细说说吗？
答：当然！长篇技术内容成为了我们倡导目标的基础。我们更感兴趣的是解释系统实际如何工作——底层发生了什么，读写是如何执行的，以及设计决策如何转化为实际行为。

同时，很明显，仅靠阅读对工程师来说是不够的。他们需要自己运行东西，理解 Iceberg 带来了什么。这导致了动手练习，人们可以尝试创建表、模式演化、分区和表优化等操作，直接观察行为。

深度解释与实际探索相结合，帮助弥合了理论与采用之间的差距。

社区在行动：从对话到势头

问：现场互动（演讲、办公时间等）如何塑造了 Iceberg 社区的演变？
答：网络研讨会、会议和现场会议为实时互动创造了空间。早期，很多这类会议都花在澄清基础知识上——Iceberg 是什么，不是什么。

但随着时间的推移，对话的性质发生了变化。工程师开始将自己的系统、工作负载和约束条件带入讨论。问题从概念性转向了更操作性——这很棒。这促使我们引入了专门的办公时间。这些不再是单向的会议，而是变成了开放论坛，人们可以讨论真实的生产场景。这些对话成为了最重要的反馈循环之一，塑造了我们解释 Iceberg 的方式，并突出了理解上的差距。

会议成为了生态系统汇聚的地方。对话从理解技术转向了讨论它在生产中的使用方式。人们开始比较方法、分享运维策略，并在最佳实践上达成一致。那时你可以看到转变：Iceberg 不再只是 Netflix 推出的一项技术——它正在成为多个组织共同构建的共享基础。

问：有没有某个时刻你意识到 Iceberg 正在获得真正的势头？
答：转折点出现在社区本身开始塑造叙事的时候。Iceberg 从未被定位为供应商拥有的格式，其规范也是在开放中演进的。

随着越来越多的贡献者、采用者和组织参与进来，讨论的范围超越了任何单一视角。集成方案、使用案例和改进来自不同方向，每个都基于真实的生产需求。那时，增长不再是被人为推动的，而是从开源社区本身涌现出来的。这对我们来说是一个巨大的成功！

问：您是如何为构建和发展 Apache Iceberg 社区做出贡献的？
答：早期 Iceberg 的许多活动都是分散的。有贡献者在构建系统，有用户在尝试使用，讨论在 Slack、邮件列表和会议中展开——但这些往往没有相互连接。我们非常刻意地将它们整合在一起。

这意味着要持续创造这些互动能够发生的场所。我们积极在 Slack 上帮助用户，举办网络研讨会，发布博客和书籍，设立办公时间，并确保实际构建和使用 Iceberg 的人能够参与到这些对话中。我们没有让讨论孤立进行，而是努力将它们拉入共享空间。

随着时间的推移，这种努力开始产生累积效应。我们将用户的问题转化为演讲主题。生产环境的使用案例会出现在网络研讨会或会议上。在一个地方发生的对话会被带到其他地方。这给社区带来了以前没有的连续性。

这也改变了讨论的层次。早期，大多数对话是关于理解 Iceberg 是什么。随着更多人参与进来，讨论转向了它在真实工作负载下的表现——规模、并发性和多引擎访问。这种转变来自于反复将实践者带入同一个循环，并让这些讨论相互叠加。

这正是我们产生最大影响的地方——创建这个循环并保持其活跃。

Apache 之道：治理与社区重于代码

问：迁移到 Apache 软件基金会（The ASF）对项目的增长和方向有何影响？
答：成为 ASF 的一部分强化了 Iceberg 对开放治理和供应商中立的承诺。它为长期可持续性奠定了基础，并鼓励了来自整个行业的更广泛参与。

问：ASF 的使命是提供造福公众的软件。您的项目在哪些方面体现了这一使命以及“社区重于代码”的精神？
答： Iceberg 是在开放环境中开发的，决策由多元化的社区而非单一组织塑造。这种协作方式确保技术服务于广泛的用户和使用场景。对共同所有权和透明度的强调反映了 ASF 的“社区重于代码”理念。

入门与参与

问：您对今天考虑采用 Iceberg 的团队有什么建议？
答：首先了解您当前的数据挑战，以及 Iceberg（以及开放湖仓一体生态系统）如何与您的需求相匹配。利用其互操作性，在您现有的生态系统和工具中进行实验，并与社区互动，学习他人的经验。

问：学习该项目并尝试使用的最佳方式是什么？
答：最佳入门方式是通过官方文档，并使用您偏好的数据处理引擎来实验 Iceberg。社区渠道（Slack）、开发者邮件列表和会议演讲也为新用户提供了宝贵的指导（参见下方链接）。还有其他专注于 Iceberg 教育的途径，例如 Cloudera 社区、开发者播放列表和 Iceberg 101 (Dremio)。

问：其他人如何为这个项目做出贡献（代码贡献只是其中一种方式）？
答：贡献有多种形式，包括改进文档、分享使用案例、参与讨论以及帮助他人采用该技术。在构建一个强大且可持续的项目方面，这些努力与代码同样重要。

Apache Iceberg 的未来

问：该项目未来有何规划？
答： Iceberg 未来发展的一个重要方向是支持更新的工作负载，尤其是 AI 驱动的工作负载。我们开始看到对更宽模式、半结构化数据以及超越传统分析访问模式的更多需求。为了支持这一点，人们对基于向量的索引和更灵活的数据表示等领域越来越感兴趣。

与此同时，系统效率的持续优化仍是重点方向。这包括元数据处理和提交性能的改进——随着表规模扩大，这些能力愈发重要。索引方面也有新进展：不再仅依赖文件级统计信息，新提案正在探索主索引、二级索引甚至基于向量的索引，尤其是在访问模式发生变化的背景下。

总体而言，未来方向是持续演进核心组件，使 Iceberg 在保持原有设计原则的同时，能够支持更广泛的工作负载。

Iceberg 资源

ASF（Apache 软件基金会）拥有近 9,000 名提交者，为超过 320 个活跃项目贡献代码，包括 Apache Airflow、Apache Camel、Apache Flink、Apache HTTP Server、Apache Kafka 和 Apache Superset。在志愿者、开发者、管理者以及 75 多家赞助商的支持下，ASF 项目创建的开源软件在全球范围内得到广泛应用。这些工作帮助我们实现为公众利益提供软件的使命。

在举办社区活动、开展协作、编写代码以及诸多其他事务中，我们常常忘记花点时间认可并充分展示 ASF 生态系统中正在完成的重要工作。本系列博客正是为此而生：聚焦那些让 ASF 社区充满活力、多元且持久的项目。我们希望分享 ASF 社区内外的故事、用例和资源，让 ASF 社区及其贡献者的辛勤工作不被忽视。

如果您是 ASF 项目的成员并希望被展示，请联系 markpub@apache.org。

与 ASF 保持联系

– 在社交媒体上关注 ASF：X、LinkedIn、Bluesky、Fosstodon 和 YouTube
– 托管项目
– 成为 ASF 赞助商
– 社区资源
– 参加 Community Over Code