恭喜你！

你已经读完了本书的最后一章。我希望你现在对湖仓架构、其核心概念以及实施湖仓的不同技术选项有了深入的理解。

在上一章中，我们讨论了如何在现实世界中构建湖仓。在本章中，我将讨论一些构建湖仓的替代、非常规和未来的方法。我精选了一些技术、产品和设计方法，认为它们将塑造湖仓设计的未来，并促进数据社区的采用。虽然其中一些已经成为主流，但有些仍处于实验阶段。

在本章中，我们将探讨：

数据网格（Data Mesh）、混合事务/分析处理（HTAP）和零ETL等不同方法，与湖仓架构结合来实现数据平台
互操作性特性和即将推出的文件和表格式
可以简化公共和私有云中湖仓实施的托管平台
人工智能在湖仓中的应用

由于数据世界的快速变化，这些设计模式和方法论中的一些可能会成为实施数据平台的标准方法，而另一些可能不会吸引很多人。不管怎样，我认为以探索技术进步所能提供的无尽未来可能性来结束本书是个好主意。

从数据仓库到湖仓：下一步是什么？

正如现代技术会随时间演进，现代架构也在不断发展。在本书的前几章中，我们讨论了湖仓是如何从数据仓库和数据湖演变而来的。然而，湖仓肯定不是最后的架构模式。在未来，新方法将利用湖仓的能力，并将其与其他架构设计结合，构建创新的数据平台。大型组织已经开始采用数据网格（Data Mesh）方法，并使用湖仓架构。让我们讨论数据网格和其他可能的方法（如HTAP和零ETL）来实现湖仓。

数据网格

传统的数据和分析平台采用了集中式方法来存储和管理数据。然后，在她的书《数据网格》（O'Reilly）中，作者Zhamak Dehghani介绍了一种去中心化的数据组织方法，称为数据网格。在数据网格方法中，数据的所有权和责任归属于各个领域团队。它们负责维护和与其他领域团队共享它们的数据。图9-1显示了这种去中心化的数据管理方法。

数据网格的四大支柱是：

数据的去中心化所有权应该归属于生成数据的领域团队。
数据应被视为产品，并与其他领域共享。
应有一个共享的基础设施（数据平台），领域团队可以利用（自助服务）来构建他们的数据产品。
应该有每个领域都遵循并实施的中央治理政策，用于他们的数据产品。

在构建数据产品时，组织在踏上数据网格之旅时可以考虑湖仓架构。湖仓为数据网格提供的一些主要好处是：

能够存储结构化、半结构化和非结构化数据，以创建最终的数据产品。
支持从BI到AI的所有类型的工作负载。
不同领域团队可以灵活地使用他们选择的计算引擎。
能够在领域团队之间共享数据产品。
通过统一的数据目录实现对数据和AI资产的联邦治理。

结合湖仓架构的数据网格已经成为一种流行的做法，并被大组织所采用。

HTAP

传统上，我们一直在构建独立的系统来支持事务性（OLTP）和分析性（OLAP）工作负载。为了支持各种BI和分析用例，需要一个额外的ETL过程将数据从OLTP系统移动到OLAP系统。这种执行ETL的额外步骤增加了运营成本并导致处理延迟。

过去，组织尝试了不同的方法来减少这些成本和延迟，以便使用户能够尽快访问最新的分析数据。其中一种流行的方法是混合事务/分析处理（HTAP）。

HTAP在单一系统中结合了OLTP和OLAP。图9-2显示了一个使用HTAP方法实现的数据平台，它统一了事务和分析工作负载。

HTAP 方法的主要好处如下：

它使您能够实现一个支持事务和分析工作负载的单一生态系统。
它消除了在 OLTP 和 OLAP 系统之间移动数据的 ETL 过程。
由于数据实时可供分析，因此有助于执行流分析。
它有助于实现一个易于管理和维护的简单架构。

鉴于这些好处，各种供应商推出了具有 HTAP 功能的产品。例如，Snowflake 推出了一种基于混合表的功能，称为 Unistore。当用户在混合表中插入数据时，Snowflake 将其存储为行存储，创建另一个副本，并使用列存储方法存储该副本。行存储用于 OLTP 用例，列存储数据用于 OLAP 用例。SingleStore 是另一个提供 HTAP 功能的平台，用于实现数据平台。

您可能会问：HTAP 方法如何影响湖仓实现？

在本书中，我们讨论了湖仓架构如何统一分析工作负载。HTAP 支持事务和分析工作负载的统一。未来，我们可能会看到组织使用 Snowflake Iceberg 表（如第 5 章所述）实现湖仓架构，并使用混合表来结合事务数据------所有这些都在单一平台内。我们还可能会看到混合表使用 Iceberg 等开放表格式来存储数据的列式副本。当然，这是推测，构建这样的功能可能会有许多限制。但随着 HTAP 和湖仓的结合，可能会有多种创新的可能性和机会。

Zero ETL

虽然 HTAP 是统一事务和分析系统的优秀方法，但在需要解耦或隔离这些系统时，可能会存在特定的设计约束。在这种情况下，您可以考虑 Zero ETL 方法。Zero ETL 是指消除或最小化构建 ETL 管道以将数据从 OLTP 移动到 OLAP 平台所需的工作。

图 9-3 和图 9-4 显示了采用 Zero ETL 方法的数据复制和数据联邦两种选项。

如图 9-3 和 9-4 所示，您可以选择将数据从事务系统实时复制到分析系统（无需转换），或者从分析平台直接查询事务系统（数据联邦）。主要的云服务提供商（CSP）现在提供支持 Zero ETL 的服务和功能。例如，Azure 提供 Synapse Link 以集成 Azure SQL DB 和 Synapse Analytics。AWS 提供 Aurora Zero-ETL 与 Redshift 的集成。

数据从业者已经开始在实施湖仓时采用 Zero ETL 方法。这种方法可以帮助在湖仓平台上直接查询源系统中的数据。例如，Databricks Unity Catalog 支持运行联邦查询以查询源数据。Microsoft Fabric 的快捷方式可以帮助您访问 S3 数据。我们将在本章后面详细讨论 Fabric。

HTAP 和 Zero ETL 方法都可以成为在事务系统和湖仓系统之间移动数据的复杂数据管道的优秀替代方案。凭借它们的能力，您不仅可以统一分析（数据和 AI/ML）工作负载，还可以统一事务工作负载。这些方法还可以简化实施数据网格的组织的技术布局，其中每个域都负责维护和管理事务和分析数据。

互操作性和新格式

在第3章中，我们探讨了不同开放表格式所提供的独特功能。我们还讨论了根据您的需求、生态系统和其他因素选择合适格式的关键考虑因素。然而，我们没有讨论通过互操作性功能在三种开放表格式之间交换数据的可能性。让我们探讨如何实现和利用这些表格式之间的互操作性。

在项目开始时选择其中一种格式是一个艰难的决定。在这个阶段，您可能对项目没有完全的清晰认识，最终可能会选择一种并不完全适合您需求的表格式。您还需要投入大量时间和精力来研究功能、评估性能并进行评估以最终确定一种格式。此外，始终存在丧失其他格式所提供的一些优秀功能的限制。

为了解决这些挑战，您可以考虑提供各种格式之间互操作性的解决方案。

图9-5展示了开放表格式及其元数据层。

如图 9-5 所示，这些格式在元数据层面上有所不同。然而，它们确实以标准、一致的格式（如 Parquet）存储数据。您可以通过转换元数据层在不同表格式之间进行操作。目前，有两个工具可用于执行此转换：

Delta Lake 的 Universal Format (UniForm)
Apache XTable（前称 OneTable）

Universal Format (UniForm)

Delta Lake 的 Universal Format (UniForm) 使计算引擎能够将 Delta 表读取为 Iceberg 表。UniForm 将 Delta 表的元数据转换为 Iceberg 兼容的元数据，以便支持 Iceberg 的引擎可以理解并读取它。底层数据文件保持不变，并且不会被复制。UniForm 可用于 Delta Lake 3.0 及更高版本。图 9-6 显示了将 Delta Lake 元数据转换为 Iceberg 兼容元数据的过程。

您可以为您的表启用 UniForm 支持，以应对将来需要 Iceberg 兼容性的工作负载或下游应用程序。然而，在以 Iceberg 表的形式使用数据时，必须了解 UniForm 的当前限制。

注意

UniForm 是单向的，这意味着您只能将 Delta 表读取为 Iceberg 表，不能反过来读取。UniForm 还支持 Hudi 表。在撰写本书时，该功能处于预览阶段。

Apache XTable

Apache XTable 是另一个旨在提供开放表格式之间互操作性的项目（前称 OneTable，由 Onehouse.ai 创建）。XTable 与 UniForm 的主要区别在于，XTable 提供 Iceberg、Hudi 和 Delta Lake 格式之间的全向互操作性。您可以使用 XTable 在三种开放表格式之间转换元数据。图 9-7 显示了元数据转换过程。

如图 9-7 所示，XTable 将一种格式识别为主格式，并为其他次要格式创建元数据。与 UniForm 类似，XTable 仅转换元数据，因此无需复制数据。

目前，XTable 作为 Apache Software Foundation (ASF) 的一部分正处于孵化阶段，为供应商提供了一个中立的空间，以协作并致力于实现真正开放的湖仓架构。未来，您不必局限于一种表格式，可以根据用例利用不同的表格式设计湖仓。这还允许您使用您偏好的平台（如 Databricks 或 Azure Synapse），这些平台可能有原生的 Delta 支持，但仍可以通过互操作性功能与 Iceberg 和 Hudi 客户端集成。

即将推出的文件和表格式

在第3章中，我们还讨论了 Parquet、ORC 和 Avro 等开放文件格式。虽然这些格式自 Hadoop 时代以来一直在使用，但目前正在进行创建新格式的尝试。Iceberg 社区推出的 Puffin 格式便是其中之一。

在讨论 Puffin 之前，让我们回顾一下 Iceberg-Parquet 格式中的数据跳过（data skipping）是如何工作的。每个 Parquet 数据文件在其尾部包含其数据的列级统计信息。计算引擎在访问数据时读取每个文件的尾部，并可以跳过行以加快处理速度。Iceberg 等开放表格式将这些列级统计信息存储在清单文件中，跳过不需要的数据文件，只读取所需文件，从而优化查询性能。

Iceberg 创建了 Puffin 来存储不能存储在 Iceberg 清单文件中的信息------如底层数据文件的统计信息和索引。

Puffin 可以帮助提高 Iceberg 管理表的查询性能。Puffin 收集的统计信息和索引可以帮助用户快速执行计算（例如估计不同值的数量）。Puffin 还处于早期阶段，值得关注其进展，看看未来如何与 Iceberg 一起使用以实现湖仓。

现代技术使得组织可以轻松实现一些曾经极具挑战性的用例。其中一个用例是流分析，这正在成为主流，并且是每个组织的愿望清单的一部分。对流数据执行分析非常复杂，如果需要极低延迟的流分析，难度会更大。

许多组织一直在使用 Apache Flink 来解决低延迟流处理用例。正如第5章所讨论的，Flink 可以提供亚秒级延迟，并支持统一的批处理和流处理用例。Flink 的创建者 Ververica 创建了 Apache Paimon，以帮助实现 streamhouse，即在湖仓中进行流分析。Paimon 是一个开放表格式，仍处于 ASF 的孵化阶段。

Paimon 的一些关键功能包括：

支持高速数据摄取、变更数据跟踪和实时分析。
与 Apache Flink 有很强的集成。
支持统一的批处理和流处理。

Hudi 也支持流处理用例，是在湖仓中实现这些用例的首选之一。您可以探索和评估 Paimon 作为 Hudi 的替代方案。如果您计划实现流处理用例，值得关注这一领域，并探索存储和计算选项在流处理用例中的进展和优化。

随着数据社区和产品供应商创建新文件和表格式以应对特定挑战，像 UniForm 和 XTable 这样的项目可以帮助实现一个简单、开放的湖仓架构。探索这些项目，并在设计湖仓时加以考虑，使其具有未来适应性并不依赖于任何一种格式。

托管的公共云和私有云平台

在前面的章节中，我们讨论了湖仓平台的不同组件及其实现技术选项。如果你回顾关键考虑因素，会发现有多个点与这些组件与开放表格式的集成、版本兼容性检查和底层云生态系统依赖性相关。

当使用云原生服务实施湖仓架构时，首先需要配置基础设施并进行多次配置，以确保系统的安全性、性能和成本优化。这需要相当多的管理和维护工作。通过使用不同产品供应商提供的托管湖仓平台设置数据基础设施，可以最小化这些工作量。图9-8展示了托管湖仓平台的组件。

托管湖仓平台的一些标准特征是：

抽象云基础设施资源配置的复杂性：你只需要专注于代码开发。
灵活选择开放表格式：或者基于特定表格式提供专业化产品。
提供高性能的计算引擎（或运行时环境）、目录、数据安全、数据生命周期和其他功能：这些功能可以帮助你更快、更轻松地实现湖仓。
通常是云平台无关的：可以在AWS、Azure和GCP基础设施上运行。
简化湖仓实施过程。

考虑到这些优势，托管平台可能成为组织实施湖仓的默认方法。在本节中，我们将探讨一些现代托管湖仓平台。

Microsoft Fabric 及其他平台

在本书中，我们通过引用Databricks和Snowflake等托管平台的例子讨论了各种湖仓场景。考虑到对统一分析平台需求的增加，微软于2023年推出了Microsoft Fabric，作为一体化的SaaS分析解决方案。对于已经采用Azure作为其云平台的组织来说，Fabric正在成为实施湖仓平台的主要竞争者。

Fabric支持多个用例，包括数据工程、数据仓库、数据科学、实时分析和BI------所有这些都来自一个中央平台。这些工作负载在Fabric中被称为"体验"。图9-9展示了Fabric架构的简单表示。

所有体验都可以从中央数据湖OneLake存储和检索数据。OneLake类似于湖仓存储------你可以使用ADLS服务将所有数据存储在Delta-Parquet格式中。数据工程师可以使用Synapse数据工程体验编写Spark代码以创建delta表，而数据分析师可以使用Synapse数据仓库体验编写SQL代码以查询这些delta表。

Fabric平台的主要功能和优势是：

易于使用：作为SaaS解决方案，它抽象了基础设施的复杂性，使开发人员专注于编写代码以解决业务问题。
在单一平台统一所有工作负载：无需在Fabric平台之外进行移动。
基于Delta-Parquet的单一存储：你可以享受湖仓架构的所有优势。
创建个人或部门特定的工作区：工作区类似于容器，你可以用来与他人协作，并根据用户角色管理访问权限。
提供快捷方式功能：这些快捷方式可以引用存储在其他位置的数据，例如其他工作区或外部源（如S3）。
所有数据存储在OneLake中：所有数据角色可以根据其技能和计算引擎偏好访问数据。对于希望使用简单、基于SaaS的平台的组织来说，Fabric可以成为自助配置云资源创建自定义湖仓的一个不错的替代方案。

在撰写本文时，Databricks、Snowflake和Fabric之间的一些关键区别是：

Fabric是基于Azure云平台的SaaS产品：无法在其他云平台上运行，并且仅支持Delta Lake。
Snowflake是云无关的：但仅支持Iceberg作为实现开放湖仓的本地表。
Databricks也是云无关的：提供出色的Spark运行时，但仅支持Delta-Parquet格式。
Databricks和Snowflake已经在这个领域运营了几年，而Fabric则是一个新进入者。随着湖仓架构的兴起，还有其他专业的湖仓平台，如Dremio和Onehouse，可以简化你的实施。

正如之前章节所述，在这些托管平台之间进行选择取决于你的用例、首选和批准的技术堆栈、整体生态系统以及所需的开放表格式功能。考虑到不断变化的技术环境增加了数据基础设施的复杂性，我预测数据从业者和组织将在未来更倾向于使用托管平台来实施湖仓。

私有云平台上的托管湖仓

到目前为止，我们主要关注的是使用AWS、Azure和GCP等公共云平台构建湖仓。这些CSP提供的对象存储服务是湖仓架构的基本构建块之一。然而，一些组织可能会有约束或内部合规性，限制他们迁移到公共云。在这种情况下，他们需要寻找在私有云环境中实施湖仓的解决方案。这时，他们可以考虑像MinIO这样的平台。

MinIO是一个用于实现数据湖或湖仓架构的统一存储解决方案。它是一个对象存储（类似于S3），可以在任何公共云或本地基础设施上运行。它是开源的，可以被认为是S3的替代品。

MinIO的主要特性是：

高性能：在对象存储中进行读写操作。
具备云对象存储的所有关键功能：如对象锁定、版本控制、分层存储、加密、生命周期管理和复制。
支持所有主要的Kubernetes发行版：在公共和私有云上。
支持公共和私有云以及边缘设备。

注：

存储分层是指使用不同的层来存储数据。云对象存储服务通常提供热层和冷层。你可以随时访问存储在热层中的数据，但如果你想从冷层访问数据，通常需要等待几分钟到几小时。分层存储的主要好处是成本效益------你为冷层支付的费用比热层少。你可以将归档数据存储在像S3 Glacier Deep Archive这样的冷层中，以降低存储成本。

图9-10展示了使用MinIO的简单湖仓架构。

使用MinIO实现湖仓架构的主要优势如下：

支持所有三种开放表格式：Iceberg、Hudi和Delta Lake，用于实现湖仓架构。
兼容所有主要的S3查询引擎：包括开源引擎（Spark、Presto/Trino、Flink）、云原生引擎（Amazon Redshift、Google BigQuery）和第三方引擎（Snowflake、Dremio）。
支持实现计算与存储解耦的架构：这使你能够灵活地独立扩展湖仓存储，并使用任何你选择的计算引擎。
迁移便捷：使用MinIO，你可以实现一个湖仓平台，易于迁移到其他云平台上。它也是执行湖仓概念验证（如开放表格式评估、查询引擎兼容性检查和性能基准测试）的良好替代方案，不需要在云服务上花费太多。

湖仓中的人工智能（AI）

如今，几乎每个现代数据驱动的组织都希望利用AI来改进决策过程。几乎每个产品供应商都希望将AI集成到他们的产品中，以便用户可以更有效地利用数据。几乎每个数据从业者都希望了解AI，并明白它如何影响他们的角色。AI无处不在。

随着生成性AI和大语言模型（LLM）能力的成熟，这些技术将使您的湖仓平台用户能够快速轻松地发现数据、提出问题并获得答案。这些AI能力将使您的湖仓平台为未来做好准备。

注意

在湖仓中利用AI功能与支持AI用例有所不同。在前面的章节中，我们讨论了湖仓如何支持您的数据和AI用例。本节讨论如何利用各种AI功能，使您的湖仓平台对其用户最有效。

几乎每个数据角色都可以从湖仓中的AI功能中受益：

技术用户 可以受益于AI助手，因为它们可以根据用户提示��成样板代码、Spark笔记本和SQL查询。
非技术用户 可以用自然语言提出问题并快速获得答案。
分析师 可以从AI支持的预测查询优化中受益。
AI可以帮助 识别和匿名化数据平台中的敏感数据。
业务领导者 可以轻松发现各类资产中的数据，并学习如何提出不同类型的问题以获得更多见解。

如果您正在构建湖仓平台，请考虑利用以下AI功能（无论是使用现成的产品功能还是构建自定义功能）使其为未来做好准备：

AI助手

现代产品现在大多提供具有智能功能的AI助手，可以用于数据发现和数据分析。助手可以用普通英语接受用户输入，并通过扫描整个生态系统提供结果。
目录中的数据质量

数据可观察性工具和目录工具之间的集成可以使用户在目录本身中识别任何数据质量问题。基于AI的目录可以在用户浏览数据时突出显示可能的异常、敏感性和趋势。
基于元数据的查询

您应该能够根据存储在目录中的表的元数据自动生成查询。AI可以通过扫描底层元数据属性来建议特定领域和行业的查询。例如，对于一个教育技术客户，根据与学生和招生相关的表，您应该被提示如下查询：
- 上个季度有多少学生报名了新课程？
- 哪些课程的录取率为100%？
自然语言处理（NLP）查询

这可能是最常见的AI用例之一。您应该为用户提供使用自然语言（英语）进行查询的功能。您的平台应该能够将这些普通查询转换为上下文感知的SQL查询，并显示结果以及用户可以进一步调整的实际查询。随着深度学习能力的成熟，未来您应该能够使用本地语言提出问题。
敏感数据识别

您的平台应该能够根据属性名称和领域识别敏感数据。使用AI/ML技术分析元数据、模型、特征表和内部文档，以识别可能包含敏感数据的属性。
自动化文档

利用AI生成代码、元数据、ML模型和其他资产的自动文档。不同的产品供应商在这一方向上进行了各种努力。例如，Databricks Unity Catalog 具有建议AI生成的评论（由LLM提供支持）来描述表或列的能力。

作为您湖仓平台的一部分，请确保提供AI功能，以帮助用户更高效地执行日常活动。虽然湖仓可以简化数据架构，但适当使用AI肯定可以让所有数据角色的生活更加轻松。

关键要点

未来，实施湖仓的可能性是无穷的。新格式、创新方法和智能产品可以简化湖仓的实施，并帮助用户高效地完成工作。表9-1总结了本章讨论的各种主题。

表9-1. 湖仓实施的未来选项和替代方案摘要

未来选项和替代方案	简要摘要
新的架构模式和方法	您可以将湖仓架构与不同的设计方法结合使用，如数据网格、HTAP或零ETL。您可以使用各种工具、产品或平台来实施这些模式并支持您的用例。随着技术进步和架构模式的成熟，我们将在未来看到许多创新的湖仓实施。
新格式和互操作性	未来将创建新的文件和表格式。Puffin和Paimon只是两个例子。您应该寻找互操作性功能，以确保您的平台可以支持从任何格式访问数据，并帮助实施真正开放的湖仓。探索UniForm和Apache XTable进行湖仓实施。
管理的湖仓平台	管理的湖仓平台可能会在未来得到更多采用。现代数据世界需要简单的解决方案，Databricks、Snowflake和Microsoft Fabric等管理的湖仓平台满足了这一需求。对于私有云和本地实施，您可以探索MinIO等解决方案。
AI在湖仓中的应用	在现代数据世界中，AI无处不在。湖仓也不例外。使用各种AI功能，使您的平台能够快速执行任务，并使用户能够轻松发现数据、提出问题和找到答案。

湖仓的未来