《Architecting Data and Machine Learning Platforms》第七章：湖仓一体

正如您现在所了解的，组织在设计其数据平台时有两种主要方法：遵循数据湖或数据仓库（DWH）范例。这两种方法都有其利弊，但问题是：是否可能使这两种技术共存，实现湖仓一体的架构？在本章中，我们将探讨这个主题，首先简要阐述这个想法的动机，然后分析湖仓一体架构的两个广泛变体------被称为湖屋架构------并帮助您决定如何在它们之间进行选择。

湖屋概念因其能够以更灵活和可扩展的方式存储和分析规模化的结构化、半结构化和非结构化数据而日益受到欢迎。湖屋可以以受管理的方式处理结构化和非结构化数据的整个生命周期，结合了前两章学到的数据湖和数据仓库方法的优点。在本章末尾，我们将描述如何演变朝着湖仓一体架构迈进。

需要一种独特的架构

数据湖和数据仓库（DWH）的出现是为了满足不同用户的需求。一个既有数据湖用户又有数据仓库用户的组织面临一个令人不悦的选择。

用户角色

正如您在前几章中所学到的，数据湖和数据仓库之间的一些关键差异与可以摄取的数据类型以及将未经处理（原始）数据落入共同位置的能力有关。因此，这两种范例的典型用户是不同的。 传统的数据仓库用户是更接近业务的BI分析师，专注于从数据中获取洞见。数据通常由ETL工具根据数据分析师的需求进行准备。这些用户通常使用数据来回答问题。他们往往精通SQL。

数据湖用户除了分析师外，还包括数据工程师和数据科学家。他们更接近原始数据，具有探索和挖掘数据的工具和能力。他们不仅将数据转换为可供业务访问的形式（即可传输到数据仓库的数据），而且还对其进行实验，并将其用于训练机器学习模型和进行人工智能处理。这些用户不仅在数据中找到答案，还找到了对业务相关的问题，并准备数据使其对其他用户有用。他们通常精通编程语言，如Python、Java或Scala。

反模式：断开的系统

由于这些不同的需求，我们经常看到不同的IT部门或团队管理数据仓库和数据湖。然而，这种分离的方法具有机会成本：组织将资源投入运营方面，而不是专注于业务洞见。因此，他们无法分配资源专注于关键的业务驱动因素或解决能够帮助他们获取竞争优势的挑战。

此外，维护两个有相同最终目标------从数据中提供可操作洞见的系统，可能会导致数据质量和一致性问题。将数据从一个系统转换为另一个系统以与其并用所需的额外努力可能会完全打消最终用户的积极性。这还可能导致企业中存在数据汇集，即存储在个人计算机上的数据集，既造成安全风险，又导致数据的低效使用。

反模式：重复数据

为什么不简单地通过平台团队同步数据将这两个系统连接起来呢？您可能最终会得到图7-1所示的架构，其中数据湖和数据仓库共存，以实现自助分析和机器学习环境。

请注意，在这种架构中，由平台集中管理的数据是存储在数据湖中的数据。所有其他数据（例如数据仓库、BI/报告工具、笔记本等）可以被视为原始数据的复制/转换版本，一方面有助于提高性能和促进分析（例如物化视图），但正如您在前几章中已经看到的，它会产生许多缺点，因为它导致了数据孤立。

让我们来看看数据旅程的主要构建块： 来自各种来源（批处理和/或流式处理）的数据被收集并进行转换/整理/准备（甚至实时进行），以存储在数据湖中，数据会经过所有不同的阶段（铜、银和金）。从一开始，数据就要经历安全性、数据质量和数据治理的检查。 现在可以通过与SQL客户端、批量报告和笔记本进行交互的分析引擎解决方案（例如Spark）处理数据。 数据还可以并行地转换并注入到数据仓库中的业务特定段中，即数据集市，以处理BI工作负载。维护数据集市是一项复杂且昂贵的活动，因为它需要大量的ETL工程，并且难以保持所有所需数据的最新状态。而且，这必须以永久的方式进行。此外，所有数据治理活动都必须在数据仓库中重复进行。 数据仓库为BI工具和SQL客户端提供支持，但有时无法提供最终用户所需的适当性能水平，因此人们倾向于下载数据、创建本地副本并使用它进行工作。 机器学习解决方案（例如scikit-learn、TensorFlow、Keras），通常通过笔记本处理，可以利用来自数据湖的数据，同时还可以与数据仓库和分析引擎连接。 这样的架构通常包含一系列缺点：

• 数据的蔓延 数据以各种形式存在，可能甚至超出平台的边界（即本地笔记本电脑），这可能导致安全和合规风险、数据新鲜度问题或数据版本问题。
• 上市时间减缓 组织可能需要花费最多两周的时间来实施对管理层报告的微小更改，因为他们必须首先要求数据工程师修改ETL，以便访问完成任务所需的数据。
• 数据规模的限制 用户可能无法访问进行分析所需的所有数据，因为例如，由于性能需求，数据仓库中的数据集市可能只包含所需信息的子集。
• 基础设施和运营成本 由于需要建立的ETL的复杂性，这些成本可能会增加。

有这样的重复/转换数据是不好的做法，您应该尽量将其最小化。理想情况下，您将消除重复项和自我管理的数据，目标是使所有数据以平台管理的方式可供所有参与者进行分析（即在图7-1中所示的架构图的右侧）。

在这一点上，您可能会问为什么组织要利用这种架构。这背后的原因非常简单：因为直到2018年，这是为满足各种用户需求提供所有所需解决方案的唯一方式。 技术不断发展，尤其是由于云的出现，新的解决方案已经被开发出来，以在数据处理方面提供更好的可能性。让我们看看如何改进这种综合架构。

融合架构

到这一点为止，很明显，数据湖和数据仓库之间的完全融合可以帮助最终用户充分发挥平台的潜力，从而充分利用他们的数据。但是，实现这样一个最终状态的架构是什么，以及达到那里的路径是什么？

两种形式

融合湖仓架构的关键因素在于数据仓库（DWH）和数据湖共享一个通用存储。两种不同的计算引擎------SQL引擎（用于数据仓库用例）和分布式编程引擎（用于数据湖用例）------读取和处理数据而无需移动数据。

这个通用存储可以采取以下两种形式之一：

1. 数据存储在云存储上的开源格式（Parquet、Avro等），您可以利用Spark进行处理。同时，您可以使用Spark SQL提供交互式查询功能（例如Databricks解决方案）。此外，数据仓库技术（例如BigQuery、Athena、DuckDB、Snowflake等）可以支持您在数据集上直接运行SQL，无需进行任何数据复制或移动。您可以使用开源格式结合Delta Lake或提高底层性能的Apache Iceberg等技术。
2. 或者，通用存储可以是高度优化的数据仓库格式（例如BigQuery、Snowflake等内置格式），在其中您当然可以原生地利用SQL。此外，这些数据仓库支持直接在原生数据上使用Spark等计算引擎。

这两者都是妥协。支持另一种类型的工作负载并不意味着它具有相等的性能。对于SQL工作负载而言，数据湖比数据仓库更慢/成本更高。而对于Spark和机器学习工作负载而言，数据仓库比数据湖更慢/成本更高。

根据用户技能选择

我们建议根据您的主要用户来在两种形式之间做出选择。在云存储上运行的SQL引擎（第一种选择）丧失了许多使数据仓库具有交互性和适用于即席查询的优化。而在数据湖上运行SQL（第二种选择）则失去了使数据湖如此灵活的无模式数据处理能力。因此，根据您想要很好支持哪种类型的用户和工作负载，以及哪种类型的用户和工作负载您愿意妥协支持，选择混合架构的形式。

在非常高的层次上，第一种选择对于精通编程的用户最为适合。如果大多数用户是经常在代码中进行大量数据整理的程序员，例如编写ETL管道和训练ML模型，那么使用数据湖（即云存储）作为存储来构建湖仓是最佳选择。数据湖的主要优势在于允许程序员进行灵活的数据处理。第二种选择对于希望与数据互动以获取洞见的用户最为适合。如果大多数用户是分析师而不是程序员，也就是说，他们可以编写SQL或使用仪表板工具（如Tableau、Power BI或Looker）生成SQL，则使用数据仓库（即DWH）作为存储来构建湖仓是最佳选择。数据仓库的主要优势在于允许业务用户进行自助、即席查询。

全面评估标准

到目前为止，我们所讨论的只是尝试初步确定适合您组织的正确方法。其他因素包括要摄取的数据量、是否需要流式处理、您的数据有多少是结构化或半结构化的，以及您是否在一个需要严格数据治理的受监管行业工作。

您应该列出在第5章和第6章中讨论的数据湖和数据仓库方法的所有特性，并制作一个评估矩阵，为每个元素分配一个从0到5的分数（0表示不太重要，5表示必需）。这将帮助您更全面地了解您的需求，并为湖仓方法做出正确选择。

现在您对用于实施湖仓的不同替代方案有了更好的理解，让我们更仔细地了解这两个选项，以更好地了解它们在幕后的运作方式。

云存储上的湖仓一体

将计算与存储分离为数据湖和数据仓库的融合提供了理想的环境。云服务提供商通过将计算引入存储来实现对交互式查询的分布式应用。这使得云服务提供商能够独立分配存储和计算资源给组织的作业，这在本地环境中很难做到，因为需要提前数月采购机器。用于分析数据的数据量和所需的计算资源可以从计算集群的热池中动态缩放。当存储与计算解耦时，您可以将其用于许多不同的用例。曾经用于结构化数据的基于文件的数据湖的同一存储现在可以作为数据仓库的存储和数据。这种关键的融合使您能够一次性存储数据，并使用视图为每个特定的用例准备数据。

让我们看看这种架构的基础元素，如何实现它，以及为什么这是可以为未来需求做好准备的东西。

参考架构

我们正在利用云存储（AWS S3、Google Cloud Storage或Azure Blob Storage）同时用于Spark集群使用的数据和用于BI报告的数据仓库。这使得数据湖团队花费多年完善的Spark代码可以在连接到始终可用的存储的短暂计算集群上运行。它允许计算移动到数据，而不是数据必须在本地磁盘之间传输（如使用HDFS时的情况）。云存储的高吞吐量提高了速度和性能。Databricks和超大规模云服务提供商都提供Spark集群作为托管服务，进一步抽象了对基础设施的管理。

数据湖和数据仓库的融合（参见图7-2）的目标是简化和统一数据的摄取和存储，并利用适用于特定问题的正确计算框架。对于结构化和半结构化数据，使用CDC工具将所有数据流式写入表，使用户能够使用简单的SQL转换数据，并构建逻辑视图以查询信息，符合业务用例的方式。由于在此模式中大量使用了视图，因此可以进行列消除、分区和逻辑操作，以优化查询速度，同时保持对流入表的数据的历史分类账。

相反，通过批处理管道摄取的数据可以使用类似的方法，其中所有数据都写入表，并使用SQL创建包含每条记录最新版本的视图。与流式数据一样，原始表中保留了历史分类账，使数据科学家能够使用所有数据构建和测试ML模型。在这种架构中，用户可以利用计划任务查询或基于事件的Lambda架构进行数据摄取。

与图7-1中有两个不同引擎（即分析引擎和内部DWH SQL引擎）的架构相比，图7-2中的参考架构具有一个可以访问数据湖和数据仓库数据的单一分析引擎。这很重要，因为它允许更简化和高效的数据分析过程。

像Dremio和Databricks这样的数据湖仓解决方案的主要目标是在数据湖存储上直接支持高性能数据处理、分析和BI。它们通常提供一个语义层，允许您抽象底层数据，并为分析引擎提供对数据的视图，实现快速查询处理，而无需实现数据集市。

项目的生产/金属层（参见第5章）可以是业务驱动的视图或经过管理和专门构建的物化表。底层逻辑和存储为最终用户和应用程序提供访问，使您能够将融合的数据平台用于Hadoop、Spark、分析和ML。

数据存储在数据仓库内还是在自由浮动的云存储桶中已经不再重要。在幕后，这是类似的分布式存储架构，但数据结构不同。例如，数据湖将数据从HDFS移动到集群外的相同对象存储中。这与云EDW将其存储系统的骨干使用相同。因此，数据很容易被数据湖和数据仓库架构在同一位置访问和管理。因此，组织现在可以在湖中存储的数据和DWH访问的相同数据周围应用治理规则。感谢这一点，您不仅可以通过将数据放入中央存储库来打破数据隔离，还可以通过使处理和查询引擎移动到数据所在的任何位置来实现，如图7-3所述。这导致了数据仓库和数据湖的融合，使它们可以使用相同的元数据存储和治理，并使数据工程师、数据科学家和数据分析师能够共同协作，而不是在隔离的系统中工作。

数据工程师、数据科学家，甚至业务用户都将能够在任何类型的数据上执行自服务查询，利用一个单一的访问点。甚至在开发方面，工作将变得更容易，因为只需与一个系统进行交互，而不是与众多不同的工具。这种方法的另一个优点是通过消除自我管理的数据副本来加强安全性和治理的集中化。

迁移

从图7-1的架构迁移到图7-2中的架构是一个迭代的过程，保留了数据湖但迁移了数据仓库。首先引入一个连接到数据湖存储的单一分析引擎，以处理所有数据处理，如图7-4所示。然后，通过各种子步骤迁移离开DWH SQL引擎，按照第4章中描述的过程进行。

由于这个过程可能需要多次迭代，因此首先识别一个能够展示新解决方案优势并在组织内形成共识的"快速成功"用例非常重要（如第4章所述）。从那里开始，就可以继续扩展新解决方案的足迹，直到它成为整个平台的"事实上"的分析引擎。一个非常好的起点通常是交互式查询的数据探索领域：用户可以使用新引擎与跨足数据湖和数据仓库的各种数据进行数据分析。他们可以直接使用新工具执行查询，或通过与BI和报告解决方案的集成进行查询。一旦变革的好处变得明显，就可以逐渐停用旧的DWH引擎以节省成本、降低复杂性，并限制离线处理的需求，因为现在用户根据组织的数据治理规则可以访问公司的所有数据。当然，全新的工作负载应该只使用新的分析引擎来实现。

未来保障

一旦完全部署，与主要位于数据湖和数据仓库中（仅为经过策划的数据）的数据集的交互将是双向的：这意味着分析引擎将能够直接在通常以Apache Parquet或Apache Avro等开放格式存储数据的底层存储系统上进行读写。这是一个巨大的好处，因为底层技术可以被视为不同类型存储系统之间的一致和共同的媒介。分析引擎将足够灵活，可以使用基于读取的架构方法（这是数据湖模式的典型特征）或更结构化的方法，例如基于SQL的数据系统。在采用湖仓架构时的另一个重要好处是轻松采用流处理。

正如您将在下一章中看到的，实时访问数据对于各种业务越来越重要，能够将流数据与标准存储的数据同等对待肯定是可以带来额外价值的。实际上，在这种架构中，流数据管道可以实时读写数据，知道底层技术（例如Apache Iceberg、Apache Hudi或Delta Lake，请参阅"使用Apache Iceberg、Apache Hudi和Delta Lake演进的数据湖"）可以确保完整的ACID事务，在系统内带来一致性，始终处理最新和最新的数据。您可以在EMR、Dataproc等上以专有（例如Databricks）或开源的方式使用这些技术。选择哪种对于您的组织来说是正确的决定由您决定。要考虑的关键因素包括灵活性、维护和支持。

SQL优先的湖仓一体

SQL优先的湖仓解决方案的主要目标是在直接在数据仓库存储上通过Spark支持灵活数据处理的同时，实现高性能的分析和BI。这种架构的优势在于业务用户可以进行编排和机器学习。

让我们来看看这种架构的基本要素，如何实现它，以及为什么它对您未来可能是有益的。

参考架构

当然，将数据仓库用作数据湖需要数据仓库解决方案不仅能够处理对表的标准SQL查询，还要能够与基于Spark的环境、机器学习功能和流处理功能进行本地集成。现代数据仓库，如BigQuery、Athena、Synapse和Snowflake，在各种程度上支持这些功能，无疑在您阅读此文时已经得到了改进。在图7-5中，您可以看到一个参考架构，其中数据仓库充当平台的中央分析引擎点。正如从图中可以看出的那样，数据从原始来源（以各种形式和速度出现）通过数据湖和本地数据仓库存储流动。从这里，您可以识别出四个主要的存储区域：

1. 与前一部分中所见相同的数据湖存储

2. 数据仓库存储在三个维度上分割：

   • Raw：以原样来自各种来源的数据（批处理或流处理）
   • Enriched：具有第一层转换的原始数据
   • Curated：经过丰富处理的准备好进行最终转换的数据

3. Spark（ETL）或SQL（ELT）可以执行所有的转换。

在构建湖仓的这种方法中，使用SQL是处理和转换数据的首选方法。SQL优先的方法利用数据仓库的高度优化的交互式查询功能，以降低成本，并将基于数据的决策引入到业务用户中。

当需要处理更高级的数据处理时，您可能可以利用类似Spark的结构化编程语言。特别是在使用ML算法时，无论是结构化数据（例如提升树回归/分类）还是非结构化数据（例如NLP），这是真实的。这是因为这些操作在SQL中不够灵活（不灵活，但不是不可能：在撰写本文时，BigQuery和Redshift SQL具有一些ML功能，其他数据仓库在不久的将来无疑也会支持它们）。利用Spark还可以避免重写可能已经在SQL中编写的传统数据处理作业。

现代数据仓库解决方案具有直接从其引擎执行Python、Spark甚至无服务器函数的能力，而且最重要的是，无需将数据移动或复制到其所在的数据存储之外。例如，BigQuery通过提供在Spark中编写的存储过程的能力，可以在特定的无服务器Spark环境中执行，可以在SQL语句中调用。Snowflake提供了Snowpark，这是一个内置的Python引擎，能够运行Spark（和其他编程语言）。Athena通过使用Parquet等标准格式文件运行，以便可以从管理的Hadoop环境（如EMR）中读取相同的数据。此外，数据湖技术，例如Databricks，通过优化的批量API（例如BigQuery Storage API）直接支持对本机仓库存储的读写。

数据湖仓范式的一个关键优势是它促使供应商（以及行业总体）开发越来越强大的数据仓库，以使多种复杂的解决方案对广泛的用户群体非常易于使用。这在ML方面尤其如此。业务用户可以利用标准的SQL代码训练和部署ML模型，并且他们可以利用像dbt这样的开源解决方案轻松自动化和产业化数据准备。如今很常见看到业务分析师，例如能够自主准确地预测客户需求，以建立有效的库存管理或根据历史数据预测最佳价格。

虽然SQL对ML的支持很好，但与ML技术相关的大多数任务都在数据工程师和数据科学家手中，他们倾向于利用更熟悉的Python框架。特别是在处理非结构化数据上的深度学习模型开发时，您需要使用开源语言处理大规模数据集，以训练必须提供给最终用户的模型。这就是本地集成在各种数据源之间发挥关键作用的原因：利用Spark支持的能力是这种范式赋予用户高度自由的关键特性。

随着ML模型开发的普及，平台还必须处理另一类运营：ML运营（MLOps）。在MLOps中，用户希望跟踪数据版本、数据血缘（对于审计目的尤其重要）以及模型更新，利用与软件开发相同的方法（即DevOps）。诸如Databricks MLflow、Google Vertex AI或Amazon SageMaker之类的解决方案与现代数据仓库进行了本地连接，为最终用户提供了在处理ML模型生命周期时统一的体验。

迁移

与云存储上的湖仓方法一样，迁移到SQL优先的湖仓是一个迭代的过程，需要多个步骤才能完全运行，如图7-6所示。第一步是实现数据直接进入数据仓库：数据源不仅必须与数据湖直接连接，尤其是与数据仓库的三种存储类型（即原始、丰富和策划）直接连接。一旦数据完全被摄入到中央数据存储库中，无论是批处理还是流处理模式，都是时候剔除外部分析引擎，将数据仓库的SQL引擎提升为主要引擎。在这里，关键是要注意如何将数据湖工作负载移至数据仓库，利用内置的编程语言模块（即Python或Spark引擎/连接器）直接在本地存储格式上运行。最后一次迭代过程中，最初仍在数据仓库外处理的ML工作负载将被内源化。

在迁移的各个阶段中，遵循SQL优先的方法，组织将发现需要用SQL编写大量的流水线。 在这种体系结构中，通过SQL实现数据处理更加高效（尽管使用Spark进行ETL仍然是可能的）。这通常需要组织内引入一种新类型的技能，被称为分析工程。您可能很容易在组织内找到具备分析工程技能的员工（参见"数据分析驱动的组织"），因为SQL是一种广泛使用的语言（比Spark或其他编程语言更为普遍），而且可以迅速学习。实际上，这是民主化的一个有利因素，因为采用这种范例将使大量员工更容易访问数据。

分析工程师将负责大部分数据的丰富和策划工作，并且他们只需具备SQL技能即可发挥他们的领域知识。不同类型的数据集（原始、丰富和策划）可能会被不同类型的用户使用。一般来说，大多数最终用户、分析团队和应用程序将使用策划数据，而数据工程师和数据科学家可能更喜欢访问原始/数据湖和丰富的数据。 在这种情况下，重要的是要注意流处理和ML功能包含在分析引擎中：这意味着它们对所有人都是本地可用的，即使对于不擅长使用TensorFlow、PyTorch、Keras或scikit-learn编写代码的人也是如此。这是在推动数据和工具访问在组织内民主化方面取得的重要成就，它将使越来越多的用户能够更好地利用他们的数据。

最后，需要注意的是数据治理是以分布式和横向的方式处理的，创建了一个统一和集中的位置来管理、监视和治理数据，使其对各种用户和工具都可访问。

未来保障

一旦迁移完成，组织按照图7-6中的架构进行了开发，大多数交互将基于SQL。可以利用其他编程语言处理SQL难以处理或存在现成库的用例，使非SQL选项更具吸引力。

SQL优先的湖仓架构的好处是巨大的，因为它提供了一个单一的存储位置，并通过一种标准且广泛使用的编程语言（SQL）民主化地访问数据，该语言受到业务用户使用的大量工具的支持。与基于云存储的数据湖仓相比，主要的好处就在于能够将更广泛的用户群体带到数据附近，并允许他们创建创新解决方案（例如ML）------拥有能够使用数据（以一种受控的方式）的人越多，您的组织将看到越多的创新。

融合的好处

如果你是初创公司或者有幸进行绿地开发，可以根据你的用例和技能集选择纯数据湖或纯DWH。对于其他情况，我们建议选择湖屋架构，无论是选择基于存储的湖屋还是SQL优先的湖屋，都能带来以下好处：

1. 上市时间： 你可以直接摄取和使用数据，无论是批量还是实时数据源。与使用复杂的ETL管道处理数据不同，数据被"分阶段"存储在消息总线或对象存储中，然后在汇聚的DWH/数据湖中进行转换，使用户能够在接收到数据时立即操作。
2. 降低风险： 你可以继续利用现有的工具和应用程序而无需重写它们。这减少了与变更相关的风险和成本。
3. 预测性分析： 从传统的数据仓库和数据挖掘的观点转向使用新鲜数据进行实时决策，增加了业务价值。这仅仅是因为对数据仓库的治理和严格程度降低，降低了进入门槛。
4. 数据共享： 汇聚的环境现在是所有类型用户（例如，数据分析师、数据工程师和数据科学家）的一站式商店。他们都可以访问相同的托管环境，在需要时获取不同阶段的数据。同时，不同角色可以通过不同的层次访问相同的数据，这由平台范围的访问权限进行管理。这不仅提高了数据治理，还简化了整个数据生态系统中的访问管理和审计。
5. ACID事务： 在典型的数据仓库中，数据的完整性得到了维护，多个读写数据的用户看到的是数据的一致副本。虽然ACID是大多数数据库的关键特性，但在传统基于HDFS的数据湖方案中提供相同的保证通常较为困难。有一些方案，比如Delta Lake和Apache Iceberg，试图维护ACID语义（请参阅"使用Apache Iceberg、Apache Hudi和Delta Lake进化的数据湖"）：它们存储一个事务日志，旨在跟踪对数据源的所有提交。
6. 多模态数据支持： 半结构化和结构化数据是DWH和数据湖的关键区别。半结构化数据具有一些组织属性，如语义标签或元数据，使其更容易组织，但数据仍不符合严格的模式。在融合的世界中，这通过扩展的半结构化数据支持得到了满足。另一方面，对于非结构化的用例，除了边缘用例外，仍然需要数据湖。
7. 统一环境： 传统上，不同的工具和环境通常由ETL进行编排，管理数据的捕获、摄取、存储、处理和服务。此外，处理框架，如Spark、Storm、Beam等，提供内置的ETL模板，使组织能够构建ETL管道。然而，借助强大的云EDW和集成的云工具，现在这个管道都由一个单一的环境处理。ELT在数据湖的不同阶段实现了大多数传统的ETL任务，如清理、去重、连接和丰富。这在DWH中实现的不同阶段使之成为可能。此外，通过核心DWH的支持，你可以通过一个统一的环境访问概念，如存储过程、脚本和物化视图。
8. 模式和治理： 实际上，业务需求和挑战会随时间演变。因此，随着数据的变化和积累，要么通过适应新数据要么通过引入新维度，这使得应用数据质量规则变得更具挑战性，需要模式强制执行和演变。此外，随着新的数据源的添加，PII数据治理变得更加重要。需要一个数据治理解决方案，使组织能够全面了解其数据环境。此外，对于不同的目的和角色，识别和屏蔽PII数据的能力至关重要。
9. 流处理分析： 实时分析能够实现即时响应，特定的用例可能需要运行一个极低延迟的异常检测应用程序。换句话说，业务需求可能要求在数据到达时立即采取行动。处理这种类型的数据或应用程序需要在仓库之外进行转换。

拥有一个单一系统来管理简化企业数据基础设施，并允许用户更有效地工作。

总结

在本章中，我们重点介绍了如何将数据湖和数据仓库技术混合在一种全新的混合架构中，称为湖屋。我们介绍了两种最常见的架构以及如何实现它们。以下是主要的要点：

1. 组织在设计其数据平台时有两种主要方法：数据湖或数据仓库范式。
2. 这两种方法都有优缺点，但还有一种新的选择：湖屋，它允许你兼得两者之利。
3. 选择湖屋时，有两种可能的方法。根据你的开发人员的主要技能集来选择其中一种方法。
4. 实现湖屋的一种方法是将数据湖和数据仓库汇聚在一起，使用云存储中的相同数据。Spark作业将从使用HDFS读取云的方式进行更改。使用基于Spark的SQL引擎。随着时间的推移，这将导致数据仓库引擎的停用。
5. 第二种湖屋选项是将数据湖工作负载移入数据仓库，并使用内置的Python引擎或Spark连接器直接在本机存储格式上运行。
6. 湖屋方法有几个好处：缩短上市时间、轻松实施预测性分析、打破数据隔离和ETL管道、模式和治理以及流处理分析只是其中的一部分。
7. 到目前为止，我们已经介绍了主干数据平台架构（数据湖、数据仓库和数据湖屋）。

在接下来的两章中，您将学习如何将流处理和边缘/混合要求纳入此架构中。