开放表格式与开放数据湖仓的视角分析

如今，围绕 数据湖仓（Data Lakehouse）架构 的讨论异常火热。这种架构将两种主流的数据存储技术——数据仓库 和 数据湖 相结合，承诺以更少的成本实现更多的功能。同时，由于客户对灵活性和开放性的需求，所有主要的数据仓库厂商都已经开始支持 开放表元数据格式（Open Table Metadata Formats）。

在这一领域，Apache Hudi、Apache Iceberg 和 Delta Lake 这三个项目成为了焦点，也成为厂商在这一技术方向上博弈的关键。这些项目为构建开放且可适应的基础架构铺平了道路，使企业能够根据自身的特定工作负载选择合适的计算引擎，从而避免被专有存储格式所限制。然而，在这些项目中，“开放表格式（Open Table Format）” 和 “开放数据湖仓（Open Data Lakehouse）” 这两个术语被频繁交替使用，这引发了对其定义和理解的需求。

虽然采用这些表格式确实为开放性奠定了基础，但需要明确的是，构建一个真正的 开放数据架构（Open Data Architecture） 需要的不仅仅是开放表格式。它还需要在格式、目录（Catalogs）和开放计算服务之间实现全面的互操作性，同时使诸如分区整理（Clustering）、压缩（Compaction）和清理（Cleaning）等表管理服务也具有开放性。目前，许多倡导者认为，将专有的数据存储格式替换为开放表格式，可以使数据架构变得开放和具有互操作性。然而，实际上，客户往往根据某个厂商支持的特定开放表格式做出选择，但在其他关键需求（例如表管理服务）上，仍被绑定到专有的服务和工具。这种现状阻碍了企业实现真正开放的数据架构。

通过这篇博客，我们希望解答以下问题：

1. 开放表格式和开放数据湖仓平台之间有哪些区别？
2. 仅仅采用开放表格式是否足以实现真正的开放数据架构？
3. 当前我们能多大程度上实现不同平台之间的无缝迁移？

为了回答这些问题，我们将探讨数据架构的演变历程，分解数据湖仓架构的核心组件，并进行对比分析，以明确什么可以被定义为开放性，什么又不能。让我们从一些历史背景开始。

数据架构的演变

多年来，各组织在开发集中式、可靠且可扩展的数据架构方面投入了大量资源。其目标是为用户提供更多的数据访问权限，让更多的数据消费者能够利用数据，从而支持从商业智能（BI）到机器学习（ML）等多种分析工作负载。随着对这些工作负载需求的不断增长，数据架构也在持续演变，以适应现代数据处理和存储中复杂多样的需求。

在接下来的部分中，我们将解析数据架构从 OLTP（在线事务处理） 到现代 数据湖仓（Data Lakehouse） 的演变过程，并重点介绍每种系统中的关键技术组件及其结构。

OLTP（在线事务处理）

OLTP 系统是处理事务性数据的基础。这些系统专为高效处理单行或少量数据的操作而设计，支持插入（insert）、更新（update）和删除（delete）等操作，非常适合高事务量的环境。

传统意义上，数据库中并没有“表格式（table format）”这一术语的对应概念，它们通常指代底层的存储格式，这是一种对用户抽象的底层技术细节。然而，为了与本文的重点保持一致，我们将 OLTP 系统中使用的存储格式分解为文件格式（file format）和表格式（table format）。一个 OLTP 数据库可以提炼为六个技术组件：存储、文件格式、表格式、存储引擎、计算引擎 和 系统目录。这些组件被整合到一个单一的系统中，用于事务处理。

OLTP 系统针对点查询和实时事务性数据进行了优化（例如，其存储格式使用了行优化文件和索引）。然而，它们并不适合需要扫描大量聚合数据的复杂分析查询。

OLAP/数据仓库

在线分析处理（OLAP）系统是最早设计用于高效查询聚合数据的数据系统之一。通常被称为数据仓库，这些系统作为中央数据存储库，用于存储来自不同来源的数据，并针对查询大量信息进行了优化。传统上，这些系统构建在行存储关系型数据库（RDBMS）之上，结合专门为分析查询模式设计的优化器、计算引擎和存储机制。然而，随着列式存储的引入（数据按列而非按行组织和存储），OLAP 数据库得以利用高效的压缩技术，并加快在分析查询中对特定属性的访问速度。

OLAP 数据库在管理结构化数据方面表现出色，是执行复杂查询和分析的关键，这些功能对于商业智能（BI）工作负载至关重要。与 OLTP 类似，基于 OLAP 的系统将六个技术组件整合为一个单一的单元；需要注意的是，其文件格式现在是列式存储，而非行式存储，并且计算引擎针对不同的用途进行了优化。

OLAP 系统非常适合对结构化数据进行分析，但在处理半结构化和非结构化数据方面能力有限，而这些数据对于机器学习（ML）等更高级的应用至关重要。这一局限性凸显了构建更灵活数据架构的必要性。

数据湖（Data Lake）

数据湖起源于 Hadoop 时代，旨在解决数据仓库的局限性，尤其是在处理多种类型数据（结构化、半结构化和非结构化）时的低效问题，以及高昂的运营成本。从技术角度来看，数据湖利用分布式文件系统或对象存储，以支持可扩展、低成本的存储，并采用开放文件格式（如 Apache Parquet 和 Apache ORC）。数据湖架构避免了数据读写路径中长时间运行的组件，使计算资源能够弹性扩展，其读取/写入性能通常是数据仓库的 10 至 100 倍，而数据仓库通常依赖少量节点的集群。

与数据仓库不同，数据湖支持 Schema-on-Read 架构，可以以显著更低的成本存储数据。数据湖引入了计算与存储分离的概念，使组织能够独立扩展这些资源，从而提高灵活性并优化成本。

在数据湖架构中，组织通常采用两层方法：在云数据湖中使用诸如 Parquet 等开放文件格式，支持机器学习和高级分析工作负载，同时选择性地将数据导出到现有数据仓库中，以支持商业智能（BI）和临时查询需求。这种两层方法增加了复杂性和管理开销，往往导致数据陈旧以及额外的数据副本。

数据湖仓（Data Lakehouse）

尽管数据湖提供了可扩展且具有成本效益的存储解决方案，但它们缺乏许多数据库管理系统（DBMS）的关键功能。尤其是由于缺乏存储引擎和表格式，它们无法支持 ACID 事务保障。这导致了在写入和读取数据时的可靠性问题，特别是在并发写入的情况下。为了弥补这一关键缺陷，数据湖仓架构引入了一个事务性数据库层，同时保留了数据湖架构的优势，如无限存储能力和弹性计算。

数据湖仓中的事务能力通过将存储引擎组件与存储格式结合实现，现在这一存储格式更常被称为“表格式（table format）”，它在 Parquet 等文件格式之上作为一个开放元数据层运行。事务性数据库层在现有的数据湖存储之上，集成了 DBMS 的核心功能，包括 ACID 事务、索引、并发控制以及表维护服务（如分区整理、压缩和清理）。

最重要的是，数据湖仓架构将传统数据仓库中紧耦合的组件解构为一个更模块化的框架。在数据湖仓中，数据以开放的文件格式和表格式存储，允许不同的计算引擎在同一数据上协作处理。同时，事务性数据库层为各类工作负载提供了传统 DBMS 的强大特性，确保了数据完整性和事务一致性。

解读通用数据湖仓架构

在深入探讨这些组件之前，为了更好地理解本文的内容，有必要区分 数据湖仓架构（Lakehouse Architecture）和 数据湖仓平台（Lakehouse Platform）。我们建议如下定义：

数据湖仓架构

数据湖仓架构是一种参考蓝图或设计模式，用于展示系统的不同层级和组件如何交互，将数据仓库和数据湖的功能整合到一个统一的系统中。数据湖仓架构由多个层级组成，包括数据摄取、存储、元数据、事务性数据库，以及数据消费服务等，每个层级在数据的管理和处理过程中都有其特定的作用。可以将其视为一座建筑的设计蓝图，展示不同房间、公用设施和结构元素的安排与交互方式，以及如何建设这座建筑的计划。

数据湖仓平台

数据湖仓平台指的是数据湖仓架构的实际实现。数据湖仓平台是一个功能完整的系统，通过整合各种工具、技术组件和服务，实现架构蓝图所描绘的目标，用于管理、处理和分析数据。如果说架构是蓝图，那么平台就是按照蓝图使用具体材料和技术搭建而成的实际建筑物。

数据湖仓架构的组件

让我们深入探讨数据湖仓架构的每个层级/组件。

1. 湖存储（Lake Storage）

湖存储层由云对象存储组成（存储对象——文件及其相关元数据）。在通过 ETL/ELT 流程提取数据后，各种操作系统的数据文件被存储在这一层中。这一层的功能是将字节组合成文件，并将文件保存到文件系统中的指定路径。湖存储层支持存储任何数据类型，并能够根据需求进行扩展。

2. 文件格式（File Format）

文件格式存储物理存储层（对象存储）中的实际原始数据。这些格式决定了每个文件中数据的组织方式，无论是结构化、半结构化，还是松散结构化/非结构化数据。同时，文件格式定义了数据排列方式，例如基于行（row-based）或列式（columnar）的存储布局。

3. 存储/表格式（Storage/Table Format）

表格式或存储格式是覆盖在文件格式层之上的开放元数据层。它提供了一种抽象，将文件的逻辑表示与物理数据结构分离开来。表格式为不可变的数据文件定义了一个模式（schema），支持事务性功能，并为读写数据提供 API 接口，使用户可以方便地与数据交互。

4. 存储引擎（Storage Engine）

存储引擎层负责管理数据湖仓架构中的底层数据，确保所有文件和数据结构（例如索引）保持良好维护、优化并始终最新。存储引擎通过支持原子性、一致性、隔离性和持久性（ACID）来确保事务完整性，这是确保数据准确性和可靠性的关键，尤其是在并发事务的情况下。此外，存储引擎还与表格式结合，处理关键的表管理服务，例如分区整理（clustering）、压缩（compaction）、清理（cleaning）和索引（indexing），以优化数据布局，从而提高查询性能和操作效率。

5. 目录（Catalog）

目录层对于数据湖仓架构中高效的搜索和数据发现至关重要。它跟踪所有表及其元数据，并对表名、模式（schemas）以及与每个表格式相关的特定元数据进行编目管理。

6. 计算引擎（Compute Engine）

计算引擎层由负责数据处理的引擎组成，确保读取和写入操作高效执行。它利用表格式提供的基础功能和 API，与底层数据交互，管理实际的数据处理任务。

理解表格式

与某些人的想法相反，表格式（Table Formats） 并不是一个全新的概念。它们类似于数据库多年来称为存储格式（Storage Formats）的内容。表格式的起源可以追溯到关系型数据库的早期，源自埃德加·科德（Edgar Codd）在 Oracle 等系统中实现的关系模型。历史上，像 Oracle 和 Microsoft 这样的 OLTP 数据库厂商允许用户将数据集（文件）视为由数据库存储引擎管理的结构化表，而其原生计算引擎则与这些底层文件交互。这些表格式具有专有性质，因此是封闭的，也就是说，它们只能被原生的计算引擎访问。

在大数据领域，随着基于 Hadoop 的数据湖的兴起，最初只有 MapReduce 框架可以访问和处理存储在 Hadoop 文件系统（HDFS）中的数据文件。然而，访问 HDFS 中存储的数据需要编写特定于 MapReduce 的 Java 代码，这意味着只能由少数专业工程师完成这项任务。

因此，像 Apache Hive 这样的计算引擎被开发出来，使更多的人（如数据分析师）能够访问存储在数据湖中的数据。这需要定义数据集的架构（Schema），并将数据集视为一个表，从而使引擎可以与该架构交互。这种需求催生了 Apache Hive 表格式 的发展。该格式通过类似 SQL 的 Hive 查询语言（HiveQL）实现了数据的民主化，使更多人可以使用这些数据。Hive 表格式标志着一个新一代独立表格式的诞生。

在了解了历史背景后，我们可以更深入地探讨表格式的概念。在上一部分中，我们将其定义为：覆盖在文件格式层之上的一个开放元数据层——它是一种抽象，将文件的逻辑表示与物理数据结构分离开来。进一步阐释来说，表格式将数据集的文件组织起来，以单个表的形式呈现。这种抽象允许多个用户和工具同时与数据交互，无论是写入还是读取。

表格式包括一组读取和写入的 API，并且负责跟踪元数据信息。它通过这些功能，使用户能够以更高效、更灵活的方式管理和访问数据。以下是表格式元数据的典型组成部分：

架构信息（Schema Information）
描述表的结构，包括列名、数据类型，以及任何嵌套结构（例如数组或结构体）。

分区信息（Partition Information）
列出每个分区的具体值或值的范围，以便在查询执行过程中快速定位相关的分区。

统计信息（Statistical Information）
包括基于 Parquet 数据文件的行数、空值计数，以及每列的最小值/最大值等信息。这些统计信息有助于查询优化，通过提供细节来高效过滤数据。

提交历史（Commit History）
记录对表所做的所有更改，包括插入、更新、删除以及架构的更改。这支持时间旅行查询和版本回滚功能。

数据文件路径（Data File Path）
列出表中数据文件的路径，通常还包含这些文件所属分区的详细信息。

通过对表格式的全面了解，我们将重点转向数据湖仓架构中的表格式。Hudi、Iceberg 和 Delta Lake 是数据湖仓架构中广泛使用的三种开放表格式。这些元数据格式带来了以下能力：

支持基于 ACID 的事务
表格式结合存储引擎支持 ACID 事务，允许可靠地执行操作（如插入、更新和删除），并确保并发操作不会导致冲突或数据损坏。

架构演进（Schema Evolution）
这些格式支持架构演进，允许用户随时间更改表的架构，而不会破坏现有的查询。例如，用户可以添加、重命名或移除列，同时保持与数据先前版本的兼容性。

时间旅行与数据版本管理
数据湖仓表格式支持时间旅行查询，允许用户查询数据的历史版本。这意味着可以访问某一特定时间点的数据状态，这对于支持多种查询类型、审计和调试非常关键。

这些功能对于在数据湖仓架构中运行分析型工作负载至关重要。然而，现代表格式的关键特性在于其开放性。这种开放性确保了数据可以被任何与特定表格式兼容的计算引擎访问，这使其区别于供应商专有（封闭）的表格式，这些封闭格式通常用于特定数据库和数据仓库中。

现在我们已经深入探讨了表格式的细微差别，并区分了数据湖仓架构和平台，是时候回答我们最初提出的问题了：开放表格式和开放数据湖仓平台之间有哪些区别？
一个开放表格式只是开放数据湖仓架构中独立的单一组件（如图7所示），而开放数据湖仓架构还包括文件格式、存储引擎、计算引擎和目录等其他元素。作为一个元数据层，开放表格式位于实际数据文件之上，为各种计算引擎提供了一个独立且开放的数据层。

另一方面，开放数据湖仓平台将存储、文件格式、表格式、存储引擎、计算引擎和目录等各个组件集成到一个统一的系统中。由于这些组件是开放且模块化的，该平台提供了灵活性，能够根据特定的使用场景在各种选项之间切换。

开放数据架构的要求

我们之所以需要深入探讨开放表格式与开放数据湖仓平台之间的区别，是因为目前存在一种普遍观点，认为采用开放表格式即可自动实现数据架构的开放性和互操作性。尽管这些表格式确实为构建开放生态系统奠定了基础，但简单地认为这足以实现真正的开放数据架构是不正确的。要实现真正开放的数据架构，还需要考虑一些关键因素。以下是一些实际需要注意的事项：

1. 组件的开放标准

要实现真正开放的数据架构，技术组件本身必须是开放且具有互操作性的。采用开放标准并不一定意味着必须使用自我管理的开源解决方案。许多组织由于高昂的工程成本和维护需求，会选择供应商托管的计算和存储解决方案，这是合理的选择。然而，在选择供应商平台时，必须确保不会被平台锁定（platform lock-in），并且数据可以通过多个计算引擎访问。这种灵活性允许使用“最佳解决方案”的组合，并在需要时可以切换供应商。

2.表格式之间的互操作性

开放表格式为构建开放数据架构提供了灵活性，但由于每种格式的独特优势，选择合适的格式仍然是一个具有挑战性的决策。例如，Hudi 在更新频繁的环境中表现出色，并且能够很好地集成 Spark、Flink、Presto 和 Trino；Apache Iceberg 针对读取操作进行了优化；而 Delta Lake 主要在 Databricks 生态系统中与 Spark 一起使用。此外，随着数据湖仓系统逐渐演化以支持使用多种表格式的新工作负载，组织需要实现通用数据访问。这意味着数据必须遵循“写一次，随处查询”的原则，能够跨任何计算平台使用。这正是像 Apache XTable（孵化中） 这样的开源项目发挥作用的地方，通过轻量级的元数据翻译实现了多种表格式之间的互操作性。

3.数据目录之间的互操作性

尽管开放表格式拓宽了对数据的访问，但数据目录（Catalog）作为数据湖仓架构中的另一个重要组件，往往仍被供应商控制。如今，供应商平台要求使用其专有目录来完全支持这些开放表格式，从而形成了一种新的锁定形式。这种依赖限制了与其他查询引擎的互操作性，特别是那些不受特定平台支持的引擎，迫使组织必须将数据管理局限于单一供应商的生态系统中。

在某些情况下，同一组织内的不同团队可能会使用遵循相同规范（例如 Iceberg REST）和标准（如相同 API）的不同目录。然而，尽管在某些层面上实现了一致性，但在这些目录之间同步数据并非易事，通常需要根据元数据重新创建或迁移表。值得注意的是，例如 Apache Iceberg 中的 register_table 方法就警告不要在多个目录中注册同一个表，因为这样可能导致更新丢失、表损坏以及数据丢失。此外，尽管这一过程对于小型数据集可能是可管理的，但在规模化的情况下却不可行。

每个目录都有其独立的访问控制策略，这些策略无法应用于其他目录，这进一步阻碍了通用数据访问。这些问题突显了需要开放、可互操作的目录来连接不同平台的重要性。开放目录能够帮助组织在不同的系统之间桥接，从而实现更高的灵活性和兼容性。

4.开放平台与表服务

在数据湖仓架构中，诸如压缩（compaction）、分区整理（clustering）、**索引（indexing）和清理（cleaning）**等表管理服务对于优化数据布局以实现高效查询处理至关重要。与这些表管理服务相辅相成的还有平台服务，它们为数据工作流提供特定功能，并与数据的写入和读取工具交互，包括数据摄取、开放表的导入/导出以及目录同步等工具。

传统上，客户通常依赖封闭的专有平台来完成这些功能，但这种方式限制了灵活性。要真正利用开放数据架构的优势，就迫切需要使这些服务保持开放性和互操作性，从而让用户能够管理数据源并维护表的最佳性能，而无需依赖供应商特定的解决方案。这种开放性确保了数据架构的灵活性，使其能够适应不断变化的需求，同时避免被供应商锁定。

现在回到我们的问题——仅仅依靠开放表格式是否足以实现真正的开放数据架构？

总结来说，仅仅用像 Hudi、Iceberg 或 Delta Lake 这样的开放表格式替代封闭数据架构/平台中的专有表格式，并不能实现完全开放的数据架构。真正的开放数据架构需要确保所有组件（包括开放表格式、目录以及作为存储引擎一部分的表管理服务）都是开放的，更重要的是，它们之间必须具备互操作性。

完全开放的方法使组织能够在出现新需求时，无缝地在特定组件或整体平台之间切换——无论是供应商托管的解决方案还是自我管理的开源解决方案。这种灵活性避免了新的锁定形式，并支持通用的数据访问能力。

开放数据湖仓平台的参考实现

这篇博客进入最后部分。鉴于我们已经花费相当多的时间理解与数据湖仓架构相关的术语和概念，现在是时候将这些内容整合起来，看看一个开放且具有互操作性的数据湖仓平台应该是什么样子。我们将以 Hudi 的湖仓平台为例进行说明。然而，这一讨论并不仅限于开源解决方案。只要平台符合上述四个要求，供应商托管的湖仓平台或其他开源解决方案也可以适用。

尽管许多人将 Hudi 仅仅视为一个开放表格式，但这种观点是片面的。实际上，Hudi 也是一个全面的开放数据湖仓平台，它结合了独特的存储引擎功能，并在 Apache Parquet 等开放文件格式之上构建了强大的表格式。与单纯的表格式不同，Hudi 提供了原生功能，包括数据摄取、恢复、回滚以及合规性跟踪的工具和实用程序。这使得 Hudi 不仅仅是数据湖仓架构中的一个组件——不仅仅是一个表格式，而是一个支持广泛分析工作负载的强大平台。

以下是一张典型数据库管理系统的参考示意图，展示了 Hudi 如何构成针对数据湖环境优化的数据库底层部分。在 Hudi 之上，多个客户端被展示，体现了 Hudi 与各种分析工具的集成能力。

Hudi 的事务层类似于数据库内核，通过其表格式管理文件布局和架构，并通过时间线（Timeline）跟踪更改。这个时间线（属于日志管理器的一部分）充当关键的事件日志，按顺序记录所有表操作，支持时间旅行、版本回滚和增量处理等功能。

在性能优化方面，Hudi 利用多种索引（属于访问方法模块的一部分）来最小化 I/O 并提升查询速度。这些索引包括文件列表、布隆过滤器（Bloom Filters）和记录级索引（Record-level Indexes），它们共同实现了更快的写入和高效的查询规划。

Hudi 内置的开放表服务（属于复制与加载服务的一部分），例如分区整理（Clustering）、压缩（Compaction）和清理（Cleaning），旨在保持表存储布局的高性能。这些服务可以根据操作需求运行在内联模式、半异步模式或全异步模式下，以满足不同的需求。

为了处理多种并发工作负载，Hudi 使用了多种并发控制技术（属于锁管理器的一部分），例如针对写入器和表服务的非阻塞多版本并发控制（MVCC），以及表服务之间的并发控制。同时，针对多写入场景，Hudi 采用了乐观并发控制（OCC），并引入了非阻塞并发控制（NBCC），以支持多写入操作而不发生冲突，确保各操作互不干扰。

此外，目前正在进行的工作包括将多租户缓存层（属于缓冲区管理器的一部分）集成到 Hudi 的事务性存储中，以平衡快速数据写入和最佳查询性能。这一缓存层将支持查询引擎之间的共享缓存，从而减少存储访问成本并提升整体性能。

此外，Hudi 将平台服务集成到其开放技术栈中，用于管理数据摄取、目录同步、数据质量检查和表导出等任务。Hudi Streamer 是 Hudi 技术栈中原生可用且常用的数据摄取工具，它与 Kafka 流无缝集成，支持自动检查点管理、架构注册表集成以及数据去重功能。Hudi Streamer 还支持数据回填（backfills）、与 Spark/Flink 的连续模式操作以及增量导出。

此外，Hudi 提供了多种目录同步工具，可以将 Hudi 表与各种目录（如 Hive Metastore、AWS Glue 和 Google BigQuery）进行同步。

从数据摄取端开始，Hudi Streamer 将来自各种数据源（如 Kafka 流、数据库或文件系统）的数据摄取到 Hudi 中。在该架构中，Amazon S3 被用作数据湖存储，存储 Parquet 数据文件，这些文件中写入了记录。

这里选择 Apache Hudi 的表格式 作为主要的开放表格式，但该架构还引入了 XTable，以确保不同格式之间的互操作性。这种灵活性使用户能够在不同的表格式之间切换，并使用自己选择的计算引擎读取特定的表格式元数据。通过这种方式，用户不会被强制绑定到特定的表格式或计算引擎上。

Hudi 的存储引擎负责表管理服务，例如分区整理（clustering）、压缩（compaction）以及清理旧版本数据（cleaning older versions of data），同时有效控制存储成本。Hudi 的平台服务还包括目录同步工具（catalog sync tools），这些工具使数据能够在各种目录（如 AWS Glue 和 Hive）中保持可用，从而支持通过交互式引擎（如 Trino 和 Presto）进行查询。一旦数据可以被查询，它就可以被分析层中的各种工具消费，用于从商业智能（BI）到机器学习的各种分析工作负载。

回答：我们能多大程度上实现不同平台之间的无缝切换？参考架构的一个重要方面是，所有组件和服务都是开放的、模块化的，并且具有互操作性。这种灵活性确保了如果未来需要基于特定使用场景在平台之间切换或迁移，不会受到任何内在限制。在这种架构中，用户可以选择最符合需求的工具和服务，确保与其运营目标的最佳契合。通过承诺采用开放标准，并确保在关键组件（如数据文件格式、数据表格式和数据目录）之间的互操作性，这种方法为真正开放的数据架构奠定了坚实的基础。

回顾

回顾之前提出的问题，我们可以明确，仅仅采用开放表格式并不能保证整体的开放性。真正的开放性依赖于对开放标准、互操作性以及跨越表格式的综合平台服务的承诺。我们了解到，虽然开放表格式为构建开放架构提供了基础要素，但开放数据湖仓平台不仅限于元数据层，还包括数据摄取、计算引擎、存储引擎和目录等所有组件——所有这些都需要是开放的，才能让数据在多个环境中可访问，而不受限于单一供应商的平台。

能够在不同平台之间无缝切换的灵活性对于现代数据架构至关重要。这也是为什么数据湖仓架构中各个组件之间的互操作性发挥着关键作用的原因。