架构师指南：开放式表格格式和对象存储_

比较 Apache Iceberg、Delta Lake 和 Apache Hudi，学习如何为您的数据湖仓选择合适的开放表格式。

译自The Architect’s Guide to Open Table Formats and Object Storage，作者 Brenna Buuck。

开放式表格式和对象存储正在重新定义组织构建其数据系统的方式，为可扩展、高效且面向未来的数据湖仓奠定了基础。通过利用对象存储的独特优势——其可扩展性、灵活性和成本效益——以及Apache Iceberg、Delta Lake和Apache Hudi等开放式表格式的高级元数据管理功能，组织可以创建满足现代数据工作负载需求的模块化架构。

这种架构转变的核心是计算和存储的分离。对象存储作为基础，提供结构化、半结构化和非结构化数据的无缝管理，而开放式表格式则充当元数据抽象层，支持数据库式功能，例如模式、分区和ACID（原子性、一致性、隔离性和持久性）事务。像Spark、Presto、Trino和Dremio这样的计算引擎与这些表格式交互，提供灵活地大规模处理和分析数据，而无需厂商锁定。

本指南将深入探讨开放式表格式和对象存储在构建现代数据湖仓中的作用。我将探讨它们的演变，比较领先的表格式，并重点介绍优化架构以适应高级分析和AI工作负载的性能注意事项。通过了解这些组件，您将能够设计出不仅高效且可扩展，而且能够适应数据驱动时代快速变化需求的数据系统。

开放式表格式的适用之处

现代数据湖仓架构建立在三个关键组件之上：存储层、开放式表格式和计算引擎。这种模块化设计旨在充分利用对象存储的可扩展性和成本效益，同时利用开放式表格式实现跨不同计算引擎的无缝元数据管理和互操作性。

其基础是对象存储的存储层，它为结构化、半结构化和非结构化数据提供可扩展且灵活的存储。在存储层中存在开放式表格式，例如Apache Iceberg、Delta Lake或Apache Hudi。这些开放式表格式充当元数据抽象层，提供类似数据库的功能，包括模式、分区和版本控制，以及ACID事务、模式演变和时间旅行等高级功能。最后，像Spark、Presto、Trino和Dremio这样的计算引擎与开放式表格式交互，以大规模处理和分析数据，为用户提供选择最适合其工作负载的工具的灵活性。

数据架构的演变

数据湖仓的兴起可以理解为数据架构更广泛演变的一部分。早期的系统，如联机事务处理 (OLTP) 数据库，优先考虑事务完整性，但缺乏分析能力。联机分析处理 (OLAP) 系统的出现引入了数据仓库，它针对查询结构化数据进行了优化，但代价是无法高效地处理半结构化和非结构化数据。

数据湖的出现是为了解决这些限制，它为各种数据类型提供可扩展的存储和基于读取的模式功能。然而，数据湖中缺乏事务保证促使了数据湖仓的发展，它将数据湖和数据仓库的优势集成到一个统一的架构中。

数据湖仓建立在开放式表格式和对象存储之上，并且是完全解耦的，这意味着它们是由模块化组件构建的。这种分散的架构同时提供了数据库的事务一致性和对象存储的可扩展性。

为什么开放式表格式非常适合对象存储

数据湖仓架构旨在利用对象存储系统（例如 Amazon Web Services (AWS) S3、GoogleCloud Storage 和AzureBlob Storage）的可扩展性和成本效益。这种集成使得能够在一个统一的平台上无缝管理各种数据类型——结构化、半结构化和非结构化数据。

基于对象存储的数据湖仓架构的关键特性包括：

统一存储层: 利用对象存储，数据湖仓可以以其原生格式存储海量数据，无需在存储之前进行复杂的数据转换。这种方法简化了数据摄取，并支持与各种数据源的兼容性。
可扩展性: 对象存储系统具有固有的可扩展性，允许数据湖仓适应不断增长的数据量，而无需进行重大的基础设施更改。这种可扩展性使组织能够有效地管理不断扩展的数据集和不断变化的分析需求。
灵活性: 最佳的对象存储可以在任何地方部署——本地、私有云、公有云、托管设施、数据中心和边缘。这种灵活性允许组织根据具体的运营和地理需求定制其数据基础设施。

通过集成这些元素，数据湖仓架构提供了一个全面的解决方案，它结合了数据湖和数据仓库的优势。这种设计促进了高效的数据存储、管理和分析，所有这些都建立在可扩展和灵活的对象存储系统基础之上。

定义开放式表格式

开放式表格式是一种标准化的开源框架，旨在有效地管理大规模分析数据集。它作为数据文件之上的元数据层运行，方便跨各种处理引擎进行无缝数据管理和访问。以下是三种开放式表格式Iceberg、Delta Lake和Hudi的概述：

Apache Iceberg

Apache Iceberg是一种为海量数据集设计的高性能表格式。其架构优先考虑高效的读取操作和可扩展性，使其成为现代分析工作负载的基石。其定义特性之一是元数据与数据的分离，允许高效的基于快照的隔离和规划。这种设计消除了代价高昂的元数据操作，从而能够跨大型数据集进行并行查询规划。

Iceberg 生态系统中的最新进展突显了其在业界日益增长的采用率。S3 Tables 通过使查询引擎能够直接访问存储在与 S3 兼容的系统中的表元数据和数据文件来简化数据管理，从而减少延迟并提高互操作性。同时，Databricks 收购 Tabular 的举动强调了 Iceberg 在开放式湖仓平台中的主要作用，并突出了其对性能和治理的关注。此外，Snowflake 将 Polaris 开源的决定也证明了业界对开放性和互操作性的承诺，进一步巩固了 Iceberg 作为领先的表格式的地位。

Delta Lake

Delta Lake 最初由 Databricks 开发，与 Apache Spark 密切相关。它完全兼容 Spark API 并与 Spark 的结构化流集成，允许进行批处理和流处理操作。

Delta Lake 的一个关键特性是它使用事务日志来记录对数据所做的所有更改，从而确保一致的视图和写入隔离。这种设计支持并发数据操作，使其适用于高吞吐量环境。

Apache Hudi

Apache Hudi 旨在解决实时数据摄取和分析的挑战，尤其是在需要频繁更新的环境中。其架构支持写入优化存储 (WOS) 以实现高效的数据摄取和读取优化存储 (ROS) 以进行查询，从而实现数据集的最新视图。

通过增量处理数据流中的更改，Hudi 促进了大规模实时分析。诸如布隆过滤器和全局索引之类的功能优化了 I/O 操作，从而提高了查询和写入性能。此外，Hudi 还包括用于集群、压缩和清理的工具，这些工具有助于维护表组织和性能。它能够处理记录级更新和删除，使其成为高速度数据流和需要合规性和严格数据治理的场景的实用选择。

比较开放式表格式

Apache Iceberg、Delta Lake 和 Apache Hudi 各自为数据湖仓架构带来了独特的优势。以下是基于关键功能对这些格式的比较概述：

ACID 事务: 所有三种格式都提供 ACID 兼容性，确保可靠的数据操作。Iceberg 使用快照隔离来保证事务完整性，Delta Lake 使用事务日志来保证一致的视图和写入隔离，Hudi 提供文件级并发控制以应对高并发场景。
模式演变: 每种格式都支持模式更改，允许添加、删除或修改列。Iceberg 提供灵活的模式演变，无需重写现有数据；Delta Lake 在运行时强制执行模式以维护数据质量；Hudi 提供预提交转换以提高灵活性。
分区演变: Iceberg 支持分区演变，能够在不重写现有数据的情况下无缝更新分区方案。Delta Lake 允许更改分区，但可能需要手动干预才能获得最佳性能，而 Hudi 提供细粒度集群作为传统分区的替代方案。
时间旅行: 所有三种格式都提供时间旅行功能，允许用户查询历史数据状态。此功能对于审计和调试目的非常宝贵。
广泛采用: Iceberg 是数据社区中采用最广泛的开放式表格式。从 Databricks 到 Snowflake 再到 AWS，许多大型平台都投资了 Iceberg。如果您已经是这些生态系统的一部分，或者正在考虑加入它们，Iceberg 可能会自然而然地脱颖而出。
索引: Hudi 提供多模式索引功能，包括布隆过滤器和记录级索引，可以提高查询性能。Delta Lake 和 Iceberg 依赖于元数据优化，但没有提供相同级别的索引灵活性。
并发和流式处理: Hudi 专为实时分析而设计，具有高级并发控制和内置工具（如 DeltaStreamer）用于增量摄取。Delta Lake 通过更改数据馈送支持流式处理，Iceberg 提供基本的增量读取功能。

这些区别突出了虽然所有三种格式都为现代数据架构提供了强大的基础，但最佳选择取决于具体的负载需求和组织需求。

性能预期

在数据湖仓架构中实现最佳性能对于充分利用开放式表格式的功能至关重要。此性能取决于存储层和计算层的效率。

存储层必须提供低延迟和高吞吐量以适应大规模分析的需求。对象存储解决方案应促进快速数据访问并支持高速传输，确保即使在高负载下也能平稳运行。此外，每秒高效的输入/输出操作 (IOPS) 对于处理大量并发数据请求至关重要，能够在没有瓶颈的情况下实现响应式数据交互。

同样重要的是计算层性能，它直接影响数据处理和查询执行速度。计算引擎必须具有可扩展性，才能在不影响性能的情况下管理不断增长的数据量和用户查询。采用优化的查询执行计划和资源管理策略可以进一步提高处理效率。此外，计算引擎需要与开放式表格式无缝集成，以充分利用 ACID 事务、模式演变和时间旅行等高级功能。

开放式表格式还包含旨在提高性能的功能。这些也需要正确配置并加以利用才能获得完全优化的堆栈。其中一项功能是高效的元数据处理，其中元数据与数据分开管理，这可以加快查询规划和执行速度。数据分区将数据组织成子集，通过减少操作期间扫描的数据量来提高查询性能。对模式演变的支持允许表格式适应数据结构的变化，而无需大量重写数据，从而确保灵活性并最大限度地减少处理开销。

通过关注存储层和计算层的这些性能方面，组织可以确保其数据湖仓环境高效、可扩展，并能够满足现代分析和 AI 工作负载的需求。这些考虑因素使开放式表格式能够充分发挥其潜力，提供实时洞察和决策所需的高性能。

开放式数据湖仓和互操作性

数据湖仓架构基于开放式表格式来提供一种统一的数据管理方法。但是，实现真正的开放不仅仅是采用开放式表格式。开放式数据湖仓必须集成模块化、互操作且开源的组件，例如存储引擎、目录和计算引擎，以实现跨不同平台的无缝操作。

开放式表格格式是开放标准，其设计本身就支持整个堆栈的互操作性和开放性。然而，仍然存在实际挑战，例如确保目录互操作性以及避免依赖于专有服务进行表格管理。最近引入的Apache XTable等工具证明了朝着普遍兼容性迈进的进展，为编写一次、随处查询的系统提供了一条途径。需要注意的是，XTable 并不允许您使用多种开放式表格格式进行写入，只允许读取。希望未来互操作性的创新将继续建立在这些项目以及围绕开放式表格格式的其他项目之上。

开放式表格格式的未来

随着数据湖仓的格局不断发展，某些趋势和进步可能会塑造其未来。一个重要的增长领域可能是将AI 和机器学习 (ML)工作负载直接集成到湖仓架构中。对于存储层，这可能看起来像是与Hugging Face和OpenAI等关键AI平台直接集成的平台。对于计算层，AI集成可能导致创建针对ML算法优化的专用计算引擎，从而提高湖仓生态系统中训练和推理过程的效率。

另一个重要的增长领域可能是开源社区。当Databricks、Snowflake和AWS等大型私营公司开始发挥其影响力时，很容易忘记开放式表格格式是真正的开放标准。Iceberg、Hudi和Delta Lake可供任何贡献者使用，并可与开源工具和平台进行协作或集成。换句话说，它们是充满活力且不断发展的开放标准数据生态系统的一部分。重要的是要记住，开源产生开源。我们将看到开源应用程序、附加组件、目录和此领域的创新将持续激增。

最后，随着企业为AI和其他高级用例构建大规模、高性能的数据湖仓，开放式表格格式的采用率将继续上升。一些业内人士将开放式表格格式的普及与21世纪初Hadoop的兴起和霸权地位相提并论。大数据已死；大数据万岁。