架构师指南之开放表格式和对象存储篇

译者 | 陈峻

审校 | 重楼

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

本指南将从开放表格式和对象存储在构建现代化数据湖仓中的作用与演变出发，深入探讨各种顶级的表格式的特征比较，进而介绍在针对高级分析和 AI 工作负载架构进行性能优化时的注意事项。据此，你将能够设计出可扩展、高效、且能够适应数据驱动时代快速变化需求的数据系统。

开放表格式的适用范围

现代数据湖仓架构建立在三个关键组件之上，即：以对象存储为基础的存储层、位于中心的开放表格式、以及最终传递到可扩容的计算引擎。这种模块化设计经过优化，可以充分利用对象存储的可扩展性和成本效益，实现无缝的元数据管理，以及横跨不同计算引擎的互操作性。

如下图所示，此类架构转变的核心在于计算和存储的分解。作为基础，对象存储提供了对于结构化、半结构化、以及非结构化数据的无缝管理；而开放表格式充当着元数据的抽象层，支持类似数据库的功能，包括：模式（schema）演变、时间旅行、分区和 ACID（原子性、一致性、隔离性和持久性）事务等。而Spark、Presto、Trino 和 Dremio 等计算引擎通过与这些表格式的交互，提供了大规模处理和分析数据的灵活性，而不会受制于供应商。

数据架构的演变

如上图所示，数据湖仓的兴起可以被理解为数据架构一种更广泛的演变。过去，在线事务处理 （OTLP） 数据库等早期系统优先考虑的是事务的完整性，但缺乏分析功能。之后，在线分析处理（OLAP） 系统的出现引入了数据仓库，优化了结构化数据的查询，但是其代价是无法有效地处理半结构化与非结构化的数据。数据湖的出现解决了此类限制，为各种数据类型提供了可扩展的存储和读时模式 （Schema-on-Read） 功能。然而，数据湖缺乏事务的保证，这引发了数据湖仓的出现。它能够将数据湖和数据仓库的优势集成到一个统一的架构中。

说到数据湖仓，它是基于开放表格式和对象存储构建、且完全解耦的。这种分解式架构既提供了数据库的事务一致性，又提供了对象存储的可扩展性。

为何开放表格式是对象存储的理想选择

经过专门设计的数据湖仓架构，旨在充分利用诸如 Amazon Web Services （AWS） S3、Google Cloud Storage 和 Azure Blob Storage等对象存储系统的可扩展性和成本效益。也就是说，这种集成支持在一个统一的平台中，无缝地管理各种数据类型（如：结构化、半结构化和非结构化）。总体而言，对象存储上的数据湖仓架构的主要功能包括：

• 统一存储层：通过利用对象存储，数据湖仓可以其原生的格式存储大量数据，而无需在存储之前进行复杂的数据转换。这种方法不但简化了数据的摄取，而且实现了与各种数据源的兼容。
• 可扩展性：对象存储系统具有原生的可扩展性，使得数据湖仓能够容纳不断增长的数据量，而无需对基础设施进行重大更改。这种可扩展性使得组织能够有效地管理不断增多的数据集和不断变化的分析要求。
• 灵活性：一流的对象存储可以部署在包括：本地、私有云、公共云、主机托管设施、数据中心、以及边缘等任何地方。这种灵活性使组织能够根据特定的运营和地理需求，定制其数据基础设施。通过集成上述功能，数据湖仓架构结合了数据湖和数据仓库的优势，进而提供了一套全面的解决方案。由于所有这些设计都是建立在可扩展且灵活的对象存储系统之上，因此也就实现了高效的数据存储、管理和分析。

典型的开放表格式

开放表格式是一种标准化的开源框架，旨在高效管理大规模的分析性数据集。通常，它作为数据文件之上的元数据层来执行，可以促进横跨各种处理引擎的无缝数据管理和访问。以下是三种典型的开放表格式--Iceberg、Delta Lake 和 Hudi：

Apache Iceberg

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

Iceberg 生态系统的最新发展凸显了它在整个行业上的日益普及。其S3 表能够让查询引擎直接访问存储在 S3 兼容系统中的表元数据和数据文件，从而减少了延迟，提高了互操作性，并简化了数据管理。与此同时，Databricks 对 Tabular 的收购凸显了 Iceberg 在开放式湖仓平台中的首要作用，并强化了其对于性能和治理的关注。而Snowflake将 Polaris 开源化的决定，则表明了该行业对于开放性和互操作性的承诺，也进一步巩固了 Iceberg 作为领先表格式的地位。

Delta Lake

与 Apache Spark 密切相关的Delta Lake 最初由 Databricks 开发。它既能够与 Spark API 完全兼容，又可与 Spark 的结构化流式处理相集成，实现了批处理和流式处理操作。其中，Delta Lake 的一个关键性功能是：它使用事务日志来记录对于数据所做的所有更改，从而确保了一致性的视图和写入隔离。而且，该设计支持并发数据操作，能够适用于高吞吐量的环境。

Apache Hudi

Apache Hudi 旨在应对实时数据摄取和分析的挑战，尤其是在那些数据需要频繁更新的环境中。也就是说，其架构既支持用于高效数据摄取的写入优化存储（write-optimized storage，WOS） ，又可用于查询的读取优化存储（read-optimized storage，ROS），从而实现了数据集的最新视图。

通过逐步处理数据流中的更改，Hudi 实现了大规模的实时分析。bloom筛选条件和全局索引等功能可以优化 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 通过提供多模式索引功能，包括 Bloom 过滤器和记录级索引，来提高查询性能。Delta Lake 和 Iceberg 则依赖于元数据的优化，并不提供相同级别的索引灵活性。
• 并发和流式处理：Hudi 专为实时分析而设计，带有高级并发控制和内置工具（如 DeltaStreamer），可用于增量数据的摄取；Delta Lake 支持通过更改数据源，实现流式处理；而 Iceberg 提供了基本的增量读取功能。虽然上述三种格式都为现代化数据架构提供了强大的基础，但是由于各自的特点比较明显，因此具体该如何选择则取决于特定的工作负载要求和组织需求。

性能预期

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

• 存储层必须能够提供低延迟和高吞吐量，以满足大规模的数据分析需求。因此，选用的对象存储解决方案应有助于快速访问数据，并支持高速传输，而且即便是在高工作负载下也能确保平稳的运行。此外，高效的每秒输入/输出操作数 （input/output operations per second，IOPS） 对于处理大量并发的数据请求也非常重要，它能够实现无瓶颈的响应式数据交互。
• 计算层性能同样也会直接影响数据处理和查询的执行速度。计算引擎需要通过可扩展性，在不影响性能的情况下，管理不断增长的数据量和用户查询。采用优化的查询执行计划和资源管理策略，则可以进一步提高处理效率。此外，计算引擎需要通过与开放表格式的无缝集成，来充分利用 ACID 事务、架构演变和时间旅行等高级功能。
  通过正确配置和完全优化，开放表格式也能够将元数据与普通数据分开管理，从而实现更快的查询规划和执行。同时，数据分区会将数据分组成多个子集，通过减少操作期间扫描的数据量，来提高查询性能。而通过对架构演变的支持，表格式则能够适应数据结构的变化，而无需进行大量的数据重写，实现了在确保灵活性的同时，最大限度地减少了处理的开销。
  可见，通过关注存储和计算层的上述性能方面，组织可以确保其数据湖仓环境的高效与可扩展性，并能够满足现代化分析和 AI 工作负载的需求。当然，这些考虑因素也会使得开放表格式能够充分地发挥其潜力，并提供实时洞察和决策所需的高性能。

开放数据湖仓和互操作性

为了提供统一的数据管理方法，数据湖仓架构往往会基于开放表格式来构建。不过，实现真正的开放性，光靠采用开放的表格式是不够的。开放的数据湖仓必须集成各种模块化、以及存储引擎、目录和计算引擎等可互操作的开源组件，来实现横跨不同平台的无缝操作。

好在开放表格式是一套开放的标准，可以根据其设计，来支持整个技术栈的互操作性和开放性。不过，在实际使用中，挑战仍然存在。例如，需要确保目录互操作性，以及避免依赖专有服务进行数据表的管理。新近推出的 Apache XTable 等工具，便展示了其在通用兼容性方面的进展，并为“一次性写入、随处查询”的系统提供了新的途径。需要注意的是，XTable 并不允许用户以多种开放的表格式写入，而只允许读取。

开放表格式的未来

随着数据湖仓的不断发展，各种趋势和进步正在塑造其未来。其中，

• 一个重要增长领域便是将 AI 和机器学习 （ML） 工作负载直接集成到湖仓的架构中。对于存储层而言，它可能是与 Hugging Face 和 OpenAI 等关键 AI 平台直接集成的平台。而对于计算层，AI 集成可能会导致创建针对 ML 算法优化的专用计算引擎，从而提高湖仓生态系统中训练和推理过程的效率。
• 另一个显著增长的领域则可能是开源社区。当 Databricks、Snowflake 和 AWS 等大型私营公司大行其道时，人们很可能忘记了开放表格式其实是一个真正的开放标准。Iceberg、Hudi 和 Delta Lake 可供任何贡献者开展协作，或集成到开源的工具和平台中。换句话说，它们是充满活力且不断发展的开放式标准数据生态系统的一部分。我们可以预见到各种开源应用、插件、目录和创新在该领域的持续激增。
• 最后，随着企业为 AI 和其他高级用例构建更多大规模、高性能的数据湖仓，开放表格式的采用率也将继续上升。一些行业专业人士甚至将开放表格式的流行视同于 2000 年代初 Hadoop 的崛起和后续的霸主地位。

小结

通过将开放表格式与高性能对象存储相结合，架构师能够构建出开放、可互操作且能够满足 AI、ML 和高级分析需求的数据系统。而通过采用上述提到的各项技术，组织可以创建出可扩展且灵活的架构，从而在数据驱动时代推动业务的创新和提效。

译者介绍

陈峻（Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验。

原标题：The Architect’s Guide to Open Table Formats and Object Storage，作者：Brenna Buuck