湖仓架构的计算引擎如果存储是湖仓架构的核心，那么计算引擎就是执行所有计算活动的大脑。你需要一个高性能的计算引擎来摄取、处

如果存储是湖仓架构的核心，那么计算引擎就是执行所有计算活动的大脑。你需要一个高性能的计算引擎来摄取、处理和消费数据平台中的数据。计算引擎使数据工程师、数据分析师、数据科学家、业务用户等平台用户能够根据自己的需求访问和使用数据。

在本章中，我们将首先讨论实现湖仓架构时获得的各种数据计算优势。我们将探讨湖仓如何实现统一的批处理和实时处理、提高BI工作负载的性能，并提供选择任何处理引擎的自由。

我们还将讨论通过开源工具、云平台或其他第三方平台提供的各种计算引擎。每个云服务提供商（CSP）都提供数据和分析服务，提供计算资源。我们将讨论现代数据平台中数据工程师和分析师最常使用的一些服务，以及它们对开放表格式的不同支持水平。我们讨论的示例将帮助你理解云服务和开放表格式之间的集成挑战。

最后，我们将研究选择计算引擎时的关键考虑因素，以及在设计和实现平台的数据摄取、处理和消费过程时需要注意的事项。

湖仓架构的数据计算优势

正如我们在第1章中讨论的那样，湖仓架构基于解耦的存储和计算层。这种解耦为数据计算活动（如数据摄取、处理、转换和消费）提供了多种好处。

独立扩展

解耦的计算帮助独立扩展平台的计算能力，而无需依赖存储的扩展。在传统的Hadoop和数据仓库系统中，这种独立扩展计算能力是不可能的，因为要增加计算能力，你必须添加带有额外存储的新节点。湖仓架构允许你独立扩展存储和计算能力。

跨区域、跨账户访问

湖仓的解耦计算层使你能够跨云区域和跨账户使用计算引擎来访问数据。例如，你可以在AWS上实现湖仓，在特定区域的一个S3桶中存储数据（以保持数据主权），并使用任何其他区域的分析服务进行分析。

注意

数据主权指的是限制数据存储在特定国家或地区之外的合规政策。许多国家有数据保护法律和法规，限制其居民的数据被转移或复制到国外。收集、处理和存储数据的组织必须遵守这些法律法规，确保数据不会存储在特定国家之外的云服务器上。

统一的批处理和实时处理

在湖仓架构中，你可以统一批处理和实时处理。这种统一有助于维护代码库，并使你能够轻松地在一个地方进行更改。可以考虑使用实时方法构建代码，并控制执行频率，将其配置为每24小时（批处理）、每几小时（微批处理）甚至每几分钟（近实时）执行一次。这种统一的数据处理方法在湖仓中是可能的，因为只有一个存储层来持久化批处理和实时工作负载的数据。

增强的BI性能

在Hadoop生态系统中，SQL/BI在Hadoop上是执行BI工作负载的常见方法。数据分析师会在HDFS数据上执行Hive查询来探索和分析数据。这种方法最具挑战性的方面是性能。Hive（使用MapReduce引擎）非常慢，在生态系统内造成了主要的性能瓶颈。

BI性能将是任何计划实施湖仓架构的组织中一个高度讨论和争议的话题。主要关注点是运行在云对象存储（如S3、ADLS或GCS）上数据查询的计算性能。湖仓架构不使用像数据仓库那样的专用、专有存储。那么，它如何解决传统Hadoop架构面临的性能问题呢？

开放表格式和湖仓计算引擎采用以下技术来解决这些性能挑战：

维护统计数据 像Apache Parquet这样的文件格式在每个文件内维护最小值和最大列值等统计信息。当你查询Parquet文件上的数据时，计算引擎使用这些统计数据来跳过数据记录。然而，这个过程需要读取每个Parquet文件。开放表格式在一个中心位置（元数据层）维护这些统计数据，因此查询不需要扫描单个数据文件。这有助于数据跳过并提高整体查询响应时间。
文件压缩 MapReduce和Spark等框架使用分布式处理进行计算。当数据存储在较小文件大小（几KB/MB）时，这些框架的性能会受到影响。开放表格式提供将较小文件压缩为较大文件的功能，从而提高整体查询性能。减少文件数量意味着较少的数据扫描和更快的查询结果检索。
分区、聚类和Z顺序 你可以对存储在湖仓存储层中的数据进行分区。当你在查询中使用正确的谓词时，计算引擎会跳过不需要的分区，从而有助于提高查询性能。

一些开放表格式具有通过使用分区、聚类或Z顺序来提高性能的特定功能。以下是一些示例：

Iceberg支持隐藏分区和分区演化（如第3章所讨论的）。随着数据随时间增长，分区演化可以帮助更改分区而无需重写完整数据集。

Delta Lake提供了一项称为液体聚类的功能（在撰写本文时，Delta Lake 3.1.0中以实验支持模式提供），允许用户重新定义聚类列而无需重写现有数据。

一些开放表格式还支持Z顺序功能，即将数据共同定位在同一组文件中。Z顺序会重写数据文件，成本较高但有助于提高性能。

除了这些技术，以下是一些提供优化计算引擎以提高BI性能的商业产品示例：

Databricks提供了一个由C++开发的下一代Photon引擎，在基于Spark的Databricks Runtime（DBR）上具有改进的查询性能。
Dremio，另一个领先的湖仓平台，提供了一项称为Reflections的功能，使用各种优化技术加速查询性能。
Snowflake使用各种级别的缓存来提高查询结果性能。

选择不同引擎类型的自由

多种计算引擎支持Iceberg、Hudi和Delta Lake等开放表格式。各种开源引擎、云原生服务和第三方产品支持从这些开放表格式中写入和读取数据。你可以使用不同类型的处理引擎来处理存储在湖仓中的数据。

图5-1展示了具有不同类型计算引擎（如Spark、Apache Flink和Presto）的湖仓计算层。

考虑一个场景，数据工程师想在湖仓中摄取数据。他们可以使用Spark来执行PySpark代码，从源系统摄取数据。数据工程师通常更擅长编写Spark代码，并可以使用Spark引擎来处理类似ETL的工作负载。如果数据分析师想要访问这些相同的数据以进行进一步分析，他们可以使用基于SQL的引擎，如Presto或Trino，从湖仓中查询数据。这些引擎还可以根据开放表格式的兼容性更新或删除记录。我们将在本章的后续部分详细讨论这一点。

使用你首选的计算引擎的自由有助于减少对供应商的依赖。在你的平台的数据消费者使用不同供应商的产品的情况下，他们可以使用自己产品的计算引擎，并根据其计算能力和使用情况付费。你不需要为他们提供访问你的计算引擎的权限，也不需要承担他们数据消费的成本。

跨区分析

湖仓架构使你能够在湖仓存储内的各个存储区执行数据处理操作。

什么是存储区？

当你在云存储（如Amazon S3、ADLS或GCS）中存储湖仓数据时，通常会创建独立的存储区。这些存储区在物理上将湖仓内的数据分开，并指示数据使用的目的。

标准的湖仓架构至少包含三个数据存储区：

原始区 存储来自源系统的“原始”数据
清洗区 在执行数据质量检查和验证后存储的数据
整理区 存储根据业务流程建模的数据，以便于查询和分析

此外，还有一些其他存储区，有助于整体数据管理。我们将在第7章详细讨论这些存储区。

考虑一种组合架构，其中原始数据存储在数据湖中，整理后的数据存储在数据仓库中，用于执行BI工作负载。在这种架构中，你需要使用两种不同的计算引擎：

可以访问数据湖内数据的计算引擎
数据仓库提供的专有计算引擎，用于查询存储在仓库中的数据

在这种情况下，你无法使用任何开源引擎直接连接数据湖和数据仓库中的数据。你需要将数据湖的数据复制到数据仓库中，或依赖数据仓库提供的专有引擎，该引擎能够访问来自数据湖的数据。例如，Amazon Redshift Spectrum是一项服务，可以帮助你查询存在于S3数据湖和Redshift仓库中的数据。

由于湖仓架构仅使用一个存储层，你可以使用任何开源计算引擎来连接原始区和整理区的数据。你不必依赖任何专有服务来进行跨区分析。

湖仓平台的计算引擎选项

图5-2显示了你通常在数据平台上执行的两大类活动：数据工程和数据消费。

数据工程活动包括数据摄取、验证、清洗、处理、转换和整理，然后将数据存储在平台中。这些活动确保在平台内存储干净、有效、准确和完整的数据，使用户可以信任并轻松消费这些数据。数据工程师负责这些数据工程活动。他们编写代码连接多个源系统，以摄取并存储数据到数据平台中。

数据消费活动涉及各种用例，如交互式分析、BI、AI/ML以及与下游应用程序的共享。数据消费者利用平台中的数据进行交互式分析、洞察生成、预测、推荐，甚至数据共享或货币化。数据分析师、BI工程师、ML工程师、数据科学家和业务用户是消费平台中存储数据的不同角色。此外，还有一些下游应用程序可以从平台中消费数据。

湖仓架构提供了使用不同计算引擎的灵活性，使不同角色可以使用这些引擎来完成他们的工作。在本节中，我们将探讨各种开源工具、云服务和提供湖仓计算能力的第三方产品。

开源工具

有多种开源计算引擎可用于各种数据工程和数据消费活动。

数据工程工具

Spark是最受欢迎和广泛采用的大数据处理框架，用于数据工程活动。Flink是另一种选择。

Spark

Spark是一个分布式内存处理框架。它没有存储组件，而是使用分布式存储（如HDFS）或云对象存储（如S3、ADLS或GCS）来存储数据。

Spark的主要特性、优点和限制如下：

Spark在处理大规模数据时提供高可靠性和可扩展性。
与其前身MapReduce（将数据存储在磁盘上）不同，Spark支持内存处理。
Spark支持Python、Java、Scala和R语言。
Spark最适合处理大规模数据的ETL工作负载。
你可以使用Spark结构化流进行实时处理。
你还可以使用Spark SQL进行SQL查询，这使得拥有SQL技能的数据工程师可以用SQL编写转换逻辑并使用Spark引擎执行。
对于期望亚秒级延迟的流处理工作负载，延迟可能是一个问题。
在湖仓架构中，你可以使用Spark进行ETL工作负载，包括数据摄取、转换、验证、清洗和加载到湖仓中。你可以使用托管云服务（如Amazon EMR、Azure HDInsight或GCP Dataproc）运行Spark集群来处理数据，并使用合适的开放表格式进行写入。

Spark是开放表格式中功能最丰富的引擎之一。它支持Iceberg、Hudi和Delta Lake。在为你的平台最终确定技术堆栈之前，应考虑Spark最新版本与所选开放表格式的兼容性。

Flink

Spark可能不是低延迟流操作（需要毫秒级延迟）的最佳选择。在这种情况下，Flink是另一种开源框架，可用于实现流摄取和处理。

它提供以下特性：

它是一个分布式内存处理框架。
它支持低延迟、高吞吐量和实时处理。
它也有类似于Spark SQL的SQL支持，用于编写类SQL查询。
它支持Iceberg、Hudi和Delta Lake。
Flink是实现流用例的广泛采用的处理框架。在将其用于你的平台之前，请确保你了解其特性和与各种开放表格式的兼容性。

数据消费工具

正如许多数据工程师更擅长编写Spark程序来执行ETL操作，大多数数据分析师更喜欢使用传统的SQL命令来分析数据。SQL是业务用户和分析师访问和查询结构化数据最常用的语言之一。

Presto和Trino

Presto和Trino是广泛采用的开源分布式SQL引擎，用于在湖仓平台上运行快速分析查询。它们具有以下特点：

它们支持ANSI SQL方言来查询数据。
它们支持推送优化，通过将查询推送到源或目标数据库来增强查询性能。
它们利用解耦架构来独立扩展计算能力。
它们支持从异构数据源进行联合查询。

Presto和Trino是同一个引擎吗？

Meta（前Facebook）创建了Presto（前PrestoDB），用于在大型数据仓库上运行交互式查询。Presto后来成为一个开源工具。PrestoSQL从PrestoDB分叉，但在2020年底重新命名为Trino。

Presto和Trino具有相同的核心查询引擎和相似的架构。虽然它们有许多共同特性，但两个引擎都提供了一些独特的功能，你可以根据具体需求进一步探索。

还有一些托管服务可供选择，如基于Trino的Starburst和基于Presto的Ahana。

在选择Presto或Trino作为湖仓平台的计算引擎时，请确保检查这些引擎最新版本与Iceberg、Hudi和Delta Lake的兼容性。Presto和Trino对Delta Lake有原生支持，但其他表格式可能存在一些限制。这些是不断发展的技术，在使用它们之前，你应该始终研究最新版本的特性、支持的连接器和限制。

云平台（如AWS、Azure和GCP）也提供基于Spark或Presto/Trino引擎的托管服务，支持开放表格式，你可以在实现湖仓时考虑这些服务。我们将在下一节中讨论这些服务。

云服务

CSPs（云服务提供商）基于开源技术提供云原生和托管服务，用于与数据工程和消费相关的各种计算活动。在本节中，我们将讨论这些服务，它们的主要特性及其对开放表格式的支持。

AWS

AWS提供多种数据处理服务。图5-3展示了你可以用于处理和消费数据的一些主要AWS服务。请注意，本节仅涵盖大多数数据项目使用的少数关键服务。根据你的用例，还有许多其他专用的AWS服务可以考虑。

AWS Glue

AWS Glue 是一个基于 Spark 框架的无服务器数据集成服务。你可以使用它进行数据摄取、处理和转换活动。它提供了一个图形用户界面（GUI），采用低代码或无代码的方法来实现 ETL 作业。

Glue 3.0 及更高版本支持创建 Iceberg、Hudi 和 Delta Lake 开放表格式。你可以在创建 Glue ETL 作业的目标文件时选择这些格式中的一种。

Amazon EMR

Amazon EMR 提供了多种开源大数据处理框架，如 Spark、Hive、Presto、Flink 和 TensorFlow。通过 EMR，你可以在弹性计算云（EC2）机器或容器上部署集群，或运行无服务器 EMR 集群。

EMR 支持使用 Spark 等框架创建 Iceberg、Hudi 和 Delta Lake 开放表格式。与 Glue 相比，EMR 的一个关键优势在于你可以将 EMR 用作单一服务来处理数据工程（使用 Spark）、数据分析（使用 Presto）和机器学习（使用 TensorFlow）工作负载。

EMR 还提供了一个功能，可以将使用 Hive、Spark 和 Presto 创建的元数据同步到 Glue 数据目录，以便可以使用 Amazon Athena 等其他服务访问 Iceberg、Hudi 或 Delta Lake 表。这是湖仓实现的重要功能——你可以灵活地跨不同计算引擎查询表。

Amazon Athena

Amazon Athena 是一个无服务器查询服务，用于交互式分析。你可以在 Athena 中使用标准 SQL 分析存储在 S3 中的数据。

Athena 的最新版本（版本 3）提供了两种不同的数据处理引擎：

一个支持笔记本的 Spark 引擎，用于使用 Spark 集群执行代码
一个开源 Presto/Trino 引擎，用于执行 SQL 查询

这两个引擎现在都支持 Iceberg、Hudi 和 Delta Lake 格式。

Athena 供数据分析师和业务用户用于数据消费工作负载，如交互式分析，或作为 BI 工作负载的计算引擎。一些数据分析师可能精通 Spark，并且更喜欢编写 Spark 代码进行分析。他们可以使用 Athena Spark 笔记本进行数据处理活动。Athena 可以作为执行 Spark 或 SQL 代码的单一服务，具体取决于用户的偏好。

提示

如果你正在使用 AWS 云平台实现湖仓，考虑使用 Athena（作为计算引擎）和 Iceberg（作为开放表格式）。Athena 版本 3 提供了比其他表格式更好的 Iceberg 集成。它支持使用 SQL 引擎进行更新和删除操作，因此分析师可以执行读写操作。在撰写本书时，Athena SQL 引擎不支持 Hudi 和 Delta Lake 开放表格式的更新和删除操作。Iceberg 提供了一些独特的功能，如隐藏分区，可以通过减少扫描的数据量来优化 Athena 查询，从而获取所需结果。

你可以参考 AWS 的博客文章《Choosing an open table format for your transactional data lake on AWS》了解不同 AWS 分析服务对 Iceberg、Hudi 和 Delta Lake 的读写支持。

其他 AWS 服务

Amazon Redshift 是 AWS 内的云数据仓库服务，并提供了一个名为 Amazon Redshift Spectrum 的功能。你可以使用它读取存储在 S3 中的、使用 Iceberg 等开放表格式的数据。AWS 还提供了一项服务，称为 Amazon QuickSight，用于创建 BI 报告和仪表板，以及 Amazon SageMaker 用于实施你可以用于湖仓平台的机器学习模型。

Azure

Azure 提供多种数据计算服务，如图 5-4 所示。

Azure Data Factory (ADF)

Azure Data Factory (ADF) 是一个完全托管的无服务器数据集成服务，你可以使用它将多个源系统中的数据摄取到 Azure 云存储中。它为数据工程师提供基于 GUI 的低代码和无代码编程，通过拖放方式构建 ETL 作业。ADF 支持 Delta Lake 格式，既可作为源读取 Delta 文件，也可作为目标创建 Delta 文件。在撰写本书时，ADF 不直接支持其他开放表格式。

Azure HDInsight

Azure HDInsight 提供使用 Hadoop、Hive、Spark、Kafka 及其他大数据处理框架的服务。它是使用这些开源框架最简单的方法，无需花费精力来配置和管理硬件和软件更新。

数据工程师可以使用 HDInsight 的 Spark 框架来创建 Iceberg、Hudi 和 Delta Lake 文件。其他 Azure 服务如 ADF 和 Synapse Analytics 仅支持 Delta Lake 文件。

Azure Synapse Analytics

Azure Synapse Analytics 提供了一个完整的数据分析解决方案平台。它提供了两个不同的计算引擎来处理存储在 ADLS 中的数据。

数据工程师可以使用 Synapse 笔记本编写 Spark 代码来执行数据工程活动。为了执行代码，可以在 Synapse 中创建 Spark 池并将其附加到笔记本。Synapse Spark 池支持以 Parquet-Delta 格式写入文件并创建 delta 表。如第4章所讨论的，这些笔记本的元数据存储在湖数据库中。

数据分析师可以使用 Synapse 无服务器 SQL 池来编写和执行 SQL 查询。你可以编写标准的 T-SQL 命令并在无服务器 SQL 池上执行查询。你可以浏览 SQL 数据库以探索 delta 表元数据，并在查询中使用它。Synapse 无服务器 SQL 还支持查询 Delta Lake 文件。Synapse 无服务器 SQL 基于一个称为 Polaris 的引擎，与 Presto/Trino 和 Spark 引擎不同。

Synapse Analytics 原生支持 Delta Lake 格式，Delta Lake 库是 Synapse Spark 环境的一部分。对于其他开放表格式，如 Iceberg 或 Hudi，你需要额外配置，例如在 Spark 环境中导入所需的 jar 文件并配置 Spark SQL 扩展。

提示

Synapse 还提供另一种基于专用 SQL 池的计算引擎。然而，它只适用于你加载到专用 SQL 池（数据仓库）专用存储中的数据。如果你实现湖仓架构，应避免将数据加载到专用 SQL 池存储中。相反，应有一个单一的存储层（在本例中为 ADLS），可以使用任何兼容的计算引擎进行访问。使用无服务器 SQL 池来提供一个 SQL 引擎，以查询 ADLS 中的数据。

ADF 和 Synapse 是 Azure 中最广泛采用的湖仓实现服务。你还可以考虑使用 HDInsight 上的开源引擎，如 Spark 或 Presto，以获得这些开源框架的托管服务。微软最近推出了 Microsoft Fabric，它提供了一个 SaaS 平台，用于实现数据和分析用例。我们将在第9章中更多地讨论 Microsoft Fabric。

除了这些 Azure 服务外，你还可以使用 Power BI 来实现 BI 工作负载，并使用 Azure 机器学习服务来大规模构建 ML 模型。

GCP

与其他云平台一样，GCP 提供用于数据摄取、处理和消费的服务，如图 5-5 所示。

Dataproc

Dataproc 是一个完全托管的服务，用于在 GCP 中运行 Spark、Hadoop、Presto 和 Flink 等大数据框架。它与其他 GCP 服务（如 BigQuery、Dataplex 和 Vertex AI）无缝集成。

Dataproc 1.5.x 的 Spark 集群支持 Iceberg、Hudi 和 Delta Lake 表格式。你需要导入所需的 jar 文件并配置 SQL 扩展，以完成必要的配置和与数据目录的集成。请确保查看文档以了解 Dataproc 支持哪些开放表格式版本。

BigQuery

BigQuery 是一个无服务器查询服务，用于执行存储在 BigQuery 或 GCS 中的数据的复杂分析查询。对于将数据存储在 GCS 中的湖仓实现，你可以使用 BigQuery 作为数据计算活动的计算引擎。

BigQuery 支持 Iceberg 表格式。你可以使用 BigQuery 存储过程（用于 Spark）来创建 Iceberg BigLake 表（如第4章所述）。BigLake 表可以使用 BigQuery SQL 引擎进行访问，以执行分析查询。

GCP 还有其他服务，如 Looker 和 Vertex AI，分别可供探索用于 BI 和 AI/ML 需求。

第三方平台

第三方平台提供了基础设施抽象和多云支持等优势，减少了数据平台设置和管理的复杂性。许多组织更喜欢第三方产品而不是原生云服务，原因包括：(1) 这些组织没有云专家来管理他们的云基础设施；(2) 他们需要能够支持其多云策略的平台。

这些平台中的大多数现在支持开放表格式，以实现湖仓架构。一些平台，如 Databricks 和 Snowflake，被广泛采用，而其他一些则相对较新。

Databricks

Databricks 是实现湖仓架构的领先平台之一。它也是 Spark 和 Delta Lake 的创建者——这两项技术对实现湖仓架构具有重要影响。Databricks 拥有用于数据工程和分析工作负载的独立计算引擎（基于 Spark）。图 5-6 展示了一些用于数据工程和消费活动的 Databricks 服务。

Databricks 为数据工程师和科学家提供了一个基于笔记本的界面，用于编写和执行 Spark 代码。计算集群使用基于 Spark 的 Databricks Runtime (DBR)，并进行了多项更新以提高 Spark 的性能。

Databricks 还内置支持 Delta Lake（其专有的 Delta Lake，而不是开源版本的 Delta Lake）。与一些云提供商的托管服务不同，你不需要在 Databricks 内进行任何配置或设置 Delta Lake 的工作。

数据分析师可以使用 Databricks SQL 进行交互式分析或运行交互式查询。Databricks 提供了一种名为 SQL Warehouse 的计算引擎，用于运行 SQL 命令。你可以配置所需的容量或使用无服务器选项，并使用兼容的 BI 工具（如 Power BI、Looker 或 Tableau）连接到 Databricks warehouse 以执行 BI 工作负载。Databricks 还提供了本机仪表板，用于创建可视化和报告。

Databricks 还有一个改进的计算引擎，称为 Photon，我们之前已介绍过。Photon 可以在各种工作负载上提供极快的查询性能。它兼容 Spark API，你无需进行任何代码更改即可使用 Photon 运行 Spark 工作负载。

还有其他 Databricks 服务，如具有声明性 ETL 特性的 Delta Live Tables (DLT)，你可以根据你的用例进行探索。DLT 提供增量处理、数据质量和错误处理、集群管理、管道可观察性和编排等功能——这一切都在一个界面中完成。

Snowflake

Snowflake 云平台因其革命性的架构、性能和易用性在实现云数据仓库方面广为人知。许多组织已经采用它来满足其 BI 需求。它是一个 SaaS 平台，不需要任何基础设施配置和维护的工作。尽管组织主要使用 Snowflake 实现数据仓库架构，你也可以将其用作湖仓平台中的计算引擎。

图 5-7 显示了如何使用 Snowflake 创建本地 Iceberg 表（由 Snowflake 管理），数据存储在客户提供的云存储上。

Snowflake 具有一个称为外部表的功能，使你能够直接从云对象存储中读取数据，而无需将其加载到专有格式中。在这种情况下，你可以使用其计算引擎读取数据，但无法更新或删除云存储中的数据。

Snowflake 现在有一个新功能（在撰写本文时仍在预览中），可以创建类似于 Snowflake 管理表的本地 Iceberg 表。使用此功能，你可以将数据存储在客户提供的云存储（如 S3）中，并在 Snowflake 中创建 Iceberg 表。这将带来增强的性能、强大的治理以及支持更新和删除操作等好处。你还可以配置其他引擎（如 Spark）从云对象存储中访问和查询这些数据。Iceberg 的支持意味着 Snowflake 强大的查询处理器是你的湖仓的一个出色计算选项。

除了 Databricks 和 Snowflake 之外，其他平台如 Dremio、Ahana 和 Starburst 也提供计算能力，用于在湖仓架构内执行各种数据计算活动。尽管这些平台都能满足基本的计算需求，每个产品和平台都有独特的功能、附加特性和性能优化，在为湖仓选择计算引擎时应加以考虑。

关键设计考量

如前一节所述，你可以在湖仓平台中使用多种计算引擎。但如何决定使用哪一种呢？

计算引擎的选择在很大程度上取决于你的整体数据生态系统。然而，另一个关键因素是使用计算引擎的数据角色。你的平台应该具备灵活性，使不同用户能够根据他们的技能和偏好使用不同类型的引擎。

数据架构师在选择湖仓计算引擎时应回答的一些重要问题包括：

计算引擎是否支持我所选择的开放表格式及我需要的功能？
它是否支持所需版本的开放表格式？
这些计算服务是否能够很好地与我的云生态系统中的其他服务集成？
计算资源是否适合使用我们平台的所有数据角色？
云原生引擎是否提供可接受的BI性能，还是我需要其他第三方产品？
它们是否支持各种数据消费工作负载，如BI报告和机器学习？

考虑一个场景，你正在评估支持Delta Lake开放表格式的AWS云平台中的计算选项。图5-8展示了一个简单的评估过程，你可能会根据关键考量、可用服务及其限制（如果有的话）来评估不同的AWS计算选项。在本分析中，我考虑了AWS的分析服务，如Glue、EMR和Athena。这些观察基于撰写本文时各种AWS服务的最新版本。

从这个评估过程中得出的关键观察如下：

Glue 4.0 支持 Delta Lake，但不是最新版本。 我们还需要创建 Glue 爬虫来将元数据摄取到 Glue 数据目录中。你可以主要使用 Glue 进行数据工程工作负载。
EMR 7.x 支持 Delta Lake 3.0。 它与 Glue 数据目录集成，并可以利用其提供的各种开源框架，用于数据工程和数据分析工作负载。
Athena v3 引擎支持 Delta Lake 2.0.2。 Athena SQL 提供对 Delta Lake 的读取能力。你可以使用 Athena Spark 编写 Spark 代码。

你也可以单独或组合使用这些计算选项。例如，可以考虑使用 EMR 进行数据工程和 Athena SQL 进行数据分析。你应该根据自己的云生态系统进行类似的评估，并仔细评估各种计算选项。

让我们讨论选择湖仓平台计算资源的一些关键考量。

开放表格式支持

选择计算引擎时最重要的设计考量是它对用于实现湖仓的开放表格式的支持。如前几节所示，有多种开源、云和第三方计算引擎可供考虑。然而，并非所有这些引擎都深度支持 Iceberg、Hudi 和 Delta Lake 表格式。

例如，考虑在 Azure 云平台上实现湖仓。大多数 Azure 服务（如 Synapse Analytics）原生支持 Delta Lake，但不支持其他开放表格式。对于其他格式（如 Iceberg 或 Hudi），你需要在 Synapse Spark 环境中进行额外配置。你还可以考虑使用 HDInsight 和 Spark 创建 Iceberg 湖仓，但无法原生支持从 Synapse 无服务器 SQL 池查询数据的其他表格式。你将不得不使用其他开源引擎（如 HDInsight 中的 Presto）查询 Iceberg 表。这可能会增加架构的复杂性，并限制你使用一些原生云服务及其功能。

支持的版本和功能

在检查计算引擎对特定表格式的支持后，你还应检查它是否支持最新版本的开放表格式。并非每个计算引擎或云服务都支持开放表格式的最新版本。在这种情况下，研究支持的（较低）版本中不可用的功能。如果缺少的功能对你不重要，那么你可以使用该计算引擎。如果缺少的功能对你很重要，那么请探索支持最新版本的其他计算选项或云服务。

例如，最新的 Azure Synapse 运行时支持 Spark 3.4 和 Delta Lake 2.4.0。在这种情况下，你将失去最新的 Delta Lake（撰写本文时为 v3.1）功能。你可以等待 Synapse Analytics 中支持最新 Delta Lake 的 Spark 版本可用，或者可以探索其他选项，如托管自管理的开源 Spark 集群，安装最新的 Spark 和 Delta Lake 版本。你可以在 Delta Lake 网站上查看最新的 Delta Lake 版本和与 Spark 的兼容性。

提示

Azure Synapse Analytics 提供 Spark 池、无服务器 SQL 池、元数据管理功能以及与其他 Azure 服务的轻松集成。使用 Synapse Analytics 实现基于 Delta Lake 的湖仓平台比使用 HDInsight 或在虚拟机或容器上运行自管理的 Spark 集群要容易得多。

在某些情况下，最新的 Azure Synapse 运行时可能不支持最新的 Delta Lake 版本。在这种情况下，你可能会失去一些最新的 Delta Lake 功能，例如从 Delta Lake 3.1.0 开始提供的液体聚类。如果你对这些最新功能的依赖性不高，等待 Synapse Analytics 中最新的 Spark 或 Delta Lake 版本可用可能是值得的。毕竟，Synapse Analytics 减少了设置、维护和管理 Spark 集群的手动工作，同时也减少了与其他 Azure 服务集成的复杂性。

始终参考最新的产品或服务文档，了解其支持的版本，并相应地设计你的系统。你还可以与产品供应商联系，了解这些开源技术最新版本在其产品中的可用日期（基于产品路线图）。

生态系统支持

大多数情况下，你选择的计算引擎将取决于用于数据平台的云生态系统。你必须检查这些计算引擎与其他服务的集成情况。

例如，考虑在 AWS 上基于 Delta Lake 格式实现湖仓平台的场景。你有两个数据摄取和处理选项：

Glue ETL 作业
EMR

Glue ETL（基于 GUI）不会自动为 Delta Lake 格式在 Glue 数据目录中创建元数据（在撰写本文时）。你需要执行一个额外步骤，通过 Glue 爬虫在 Glue 数据目录中创建元数据表。如果使用 EMR，你可以直接将 Spark 元数据同步到 Glue 数据目录中，这样 Delta 表会立即可用，无需创建和执行爬虫。

另一个关键点是检查同一云平台中两个服务支持的开放表格式版本。这些版本可能不同，可能会导致兼容性问题。

例如：Glue 4.0 支持 Delta Lake 2.1，而撰写本文时最新版本的 EMR（emr-7.x）支持 Delta Lake 3.0。同样，在使用 Azure 生态系统时，检查 ADF 和 Synapse Analytics Spark 池创建的 Delta 文件的 Delta Lake 版本，并研究任何兼容性问题。Delta Lake 功能始终向后兼容（较低版本 Delta Lake 写入的表可以被较高版本 Delta Lake 读取和写入），但某些功能可能会破坏前向兼容性。

在使用开放表格式时，确保检查支持的开放表格式版本，并始终使用云服务的最新版本。由于这些是不断发展的技术，每个新版本的云服务可能会添加许多新功能。

基于角色的偏好

如前所述，你选择的计算引擎还取决于使用该引擎的数据角色。图 5-9 显示了数据工程师和其他角色的首选引擎。

为了执行数据处理活动，数据从业者根据他们的技能、专业知识和偏好使用不同的云计算服务。数据工程师更喜欢使用 Spark 笔记本，而数据分析师更喜欢使用 SQL 编辑器。

由于湖仓架构使用单一存储层，并且可以支持多种引擎，你可以使用不同的计算引擎。数据架构师应确保设计一个灵活的平台，可以提供各种计算引擎（以及共享数据目录），以便不同角色能够使用他们首选的计算引擎并进行协作。

一个好的经验法则是为数据工程师提供基于 Spark 的笔记本服务，为数据分析师提供 SQL 引擎。

托管开源服务与云原生服务与第三方产品

大多数云平台都提供托管开源服务和他们自己的云原生专用服务来进行数据计算活动。也有一些第三方产品为湖仓平台提供优化的计算引擎。

表 5-1 总结了使用托管开源和云原生服务实现湖仓平台的优缺点。

表 5-1. 托管开源服务与云原生服务

	托管开源服务	云原生服务
优点	支持使用笔记本编写自定义 Spark 代码（如使用 Jupyter 笔记本的 EMR）	更容易集成其他云服务，如目录
	更好地控制计算集群及其扩展选项	内置支持开放表格式，无需额外配置
	支持不同版本的开源框架	不需要为集群配置或初始设置做任何努力
	灵活添加库和配置 Spark SQL 扩展	与平台内的其他服务（如身份验证和日志记录）深度集成
	代码可以轻松迁移到使用相同开源服务的其他云平台
缺点	需要初始配置集群的努力	使用专有平台服务，难以迁移到其他云平台
	可能需要自定义配置以集成其他平台服务	相比托管开源服务更昂贵
	最新的开源更新可能较慢，可能需要几天或几个月才能提供
示例	Amazon EMR, Azure HDInsight	AWS Glue, ADF

基于前几节讨论的关键设计考量和表 5-1 中提到的要点，仔细评估并选择符合你需求的服务。

第三方平台

第三方平台如 Databricks、Snowflake 和 Dremio 提供了云服务的极佳替代方案。它们提供了一些独特的功能来实现你的数据处理工作负载。由于性能在选择计算资源中起着重要作用，如果云服务未提供预期的性能，可以考虑这些第三方平台。表 5-2 列出了一些领先第三方平台的优点。

表 5-2. 第三方平台的优点

第三方平台	优点
Databricks	提供优化的 Spark 引擎，可用于笔记本和 SQL 查询执行
	是 Azure Synapse Analytics 或 Amazon EMR 的良好替代方案；提供更深的 Spark-Delta Lake 集成
	在数据工程和消费服务中提供最新和一致的 Delta Lake 版本
Snowflake	使用 Snowflake 构建的数据平台可以通过存储为本地 Iceberg 表（预览功能）与非 Snowflake 消费者共享数据；消费者可以使用首选的计算引擎查询存储在云存储中的 Iceberg 文件数据
Dremio	Dremio 湖仓平台提供名为 Dremio Sonar 的 SQL 引擎，在湖仓上提供数据仓库级性能

你还可以考虑其他选项，如使用自管理的虚拟机或容器来安装和管理计算引擎。这种方法提供了最高水平的灵活性和自定义，但需要更多的努力和专业知识来实现。

数据消费工作负载

多种数据消费工作负载使用计算引擎来满足其数据计算需求。这些工作负载范围从创建仪表板到运行用于预测或预测的 ML 模型。你为这些工作负载选择的计算引擎在很大程度上取决于你的云平台。

BI 工作负载

像 Tableau、Power BI 和 Looker 这样的流行工具可以根据业务需求创建报告、可视化和仪表板。选择使用哪个工具主要由你使用的云平台或组织层面的战略决定来采用一个或多个工具驱动。

在选择这些工具的计算引擎时，请查找可用的连接器和支持的功能。使用来自相同云生态系统的工具将减少与其他服务（如身份验证、目录和安全性）的集成工作。

例如，Power BI 可以使用 Synapse 无服务器 SQL 池连接到 Delta Lake 表并查询数据。Power BI 还可以在没有运行任何 Spark 或 Synapse 集群的情况下原生读取 Delta Lake 表。你可以研究 Power BI—Delta Lake 连接器，了解支持哪些功能。

Amazon QuickSight 帮助在 AWS 内创建现代交互式报告和仪表板。你可以使用 QuickSight 与 Athena 引擎执行查询，并通过使用 AWS Lake Formation 服务实现细粒度访问控制来从湖仓获取数据。

AI/ML 工作负载

湖仓架构为你的所有数据和 AI/ML 用例提供了一个统一的平台。你可以使用 AI/ML 云服务或第三方产品来实现这些用例。这些服务大多数使用 Spark 作为处理引擎，并且可以从 Spark 和开放表格式集成中受益。

Amazon SageMaker 是 AWS 内的一项服务，用于构建、支持和训练 ML 模型。它支持 Iceberg 创建特征表，并在 Glue 数据目录中注册元数据。SageMaker 还支持使用 Delta-Spark 库（基于 Python API 的 PyPI 包）读写 Delta Lake 文件。

Databricks ML 提供与 Delta Lake 的开箱即用集成，使数据科学家可以轻松进行实验。你可以考虑使用 Databricks 集群进行需要 MLflow-Delta Lake 集成的 ML 工作负载。

在选择湖仓的 ML 服务时，请务必检查可用的连接器、支持的表格式和可用的功能。

开放表格式提供了统一数据工程、数据分析和数据科学工作负载的功能。你应该选择能够利用这些功能并使所有类型角色高效执行其活动的计算资源。可能没有单一的计算引擎能够提供你所需的所有功能。

湖仓架构的最佳部分是你不必只选择一个计算服务。你可以自由使用云生态系统中的任何计算服务。使用以下问题来评估和选择计算引擎：

是否有支持首选开放表格式和所需版本的云原生服务？
如果我需要更多自定义，有没有应该考虑的托管开源服务？
有没有第三方产品或平台可以提供更显著的好处？
如果都不合适，我是否愿意使用虚拟机或容器手动安装所需的计算引擎和其他兼容技术？

关键要点

湖仓架构让你自由选择计算引擎。你不必局限于单一引擎或单一云服务。这为在湖仓中提供多个引擎开辟了许多机会，使不同的数据角色能够执行他们的数据计算活动。

湖仓中有多种计算资源的选项。表 5-3 总结了开源工具、云服务和第三方平台的关键计算选项。

表 5-3. 计算选项总结

平台	计算引擎选项
开源（自管理）	Spark, Presto/Trino, Flink
AWS	Glue ETL, EMR, Athena
Azure	ADF, HDInsight, Synapse Analytics
GCP	Dataproc, BigQuery
第三方	Databricks, Snowflake, Dremio

在为湖仓提供计算引擎时，请记住以下关键点：

在选择任何计算引擎之前，请检查它对你为湖仓选择的开放表格式的支持。
阅读云服务文档，检查它们支持的 Spark 或 Trino/Presto 引擎的版本。还要检查它们支持的开放表格式的版本，以及它是否具有你所需的所有必要功能。
如果计算引擎不是基于开源技术，请检查引擎是否支持你首选的开放表格式。例如，Azure 无服务器 SQL 基于 Polaris 引擎。研究所有限制并实施解决方案以克服关键限制。
在实施使用相同计算引擎进行数据工程和分析的平台时，你将面临较少的集成挑战。例如，Databricks 中的数据工程使用 Spark，而数据分析使用 Spark SQL。
社区和商业供应商不断致力于为不同的计算引擎创建新的连接器，以支持开放表格式。密切关注这些连接器并在需要时在你的平台中利用它们。
有些专用的第三方产品提供优化的计算引擎，其功能可以提高查询的 BI 性能。在评估整体技术堆栈时考虑这些产品。

在本章中，我们讨论了湖仓平台内的不同计算选项以及选择它们时的关键考量。在下一章中，我们将讨论在湖仓平台内实施数据治理和安全流程的最佳实践和实际挑战。