几十年来，数据仓库一直是企业构建数据平台的主要体系结构方法。然而，随着云、大数据和Hadoop等技术的出现，现代数据平台的发展速度加快，导致了数据湖和数据湖屋等各种选择的出现。
根据领先的云提供商发表的文章，数据湖屋代表了新一代的数据平台。但每个数据平台架构师都应该问自己的问题是：数据湖屋是我特定用例的理想架构吗？还是应该选择数据湖或数据仓库？
在这篇文章中，我将探讨这些架构之间的差异，并分析哪些架构在哪些场景中最有效。
数据仓库
数据仓库体系结构（DW，DWH），也称为企业数据仓库（EDW），几十年来一直是一种占主导地位的体系结构方法。数据仓库是结构化业务数据的中央存储库，使组织能够获得有价值的见解。在将数据写入仓库之前，定义模式非常重要。通常，数据仓库是通过批处理填充的，并由BI工具和特殊查询使用。数据仓库的设计是专门为处理BI查询而优化的，尽管它不能处理非结构化数据。它由表、约束、键和索引组成，支持数据一致性并提高分析查询的性能。这些表通常分为维度表和事实表，以进一步提高性能和实用性。
数据仓库的通用设计包含一个暂存区，使用Informatica PowerCenter、SSIS、data Stage、Talend等ETL工具从各种来源提取原始数据。然后，使用ETL工具或SQL语句将提取的数据转换为数据仓库中的数据模型。有几种体系结构方法可以设计数据仓库，包括Inmon、Kimball和data Vault方法。
数据仓库设计模式
现在，让我们研究一些不同的数据仓库实现模式。有几种体系结构方法可以设计数据仓库。在这篇文章中，我们将简要概述这些体系结构。
在企业数据仓库的环境中，多个部门有不同的报告需求，因此有必要实现数据集市。根据定义，数据集市是一种专门为满足特定业务领域或部门的独特需求而优化的数据模型。例如，市场营销部门的报告需求与会计部门的报告需要有很大不同。
数据平台的另一个重要组成部分是操作数据存储，专门用于存储事务系统的最新数据。它与数据仓库（DWH）的主要区别在于缺少历史数据。操作数据存储旨在促进更频繁地从源系统导入数据。
现代数据仓库
在现代数据平台中，我们需要传统的数据仓库吗？答案是：这取决于情况。
如果我们正在为银行或保险公司开发一个平台，其中BI工具的监管报告或利用至关重要，那么数据仓库仍然是最佳方法。它确保数据的结构、准备和优化适用于这些特定目的。
Azure Synapse、Redshift、BigQuery和Snowflake等技术能够创建可用作数据仓库的标准数据模型。与流行的BI工具（如Power BI、Tableau或Qlik）集成，可以生成所需的报告或将数据提取为XLSX、XML或JSON文件等格式。为了消除对大量ETL工具的需求，可以建立ELT（提取、加载、转换）过程来使用直接从源系统提取的数据。此外，上述所有数据库引擎都支持外部表，这有助于将数据从数据湖导入数据仓库。创建双层体系结构。
在本文的后面部分，我将更多地关注它，但简单地说，这种方法允许使用BigQuery、Redshift或Snowflake等平台创建数据仓库，利用熟悉的SQL和DBT（数据构建工具）和GCP Dataform框架等工具来建立满足组织报告要求的ETL流程。
然而，需要注意的是，TensorFlow、PyTorch、XGBoost和scikit-learn等流行的机器学习系统并不能与数据仓库无缝集成。此外，通常需要分析可能无法在现有数据模型中实现的数据。
双层数据仓库：优点和缺点
优点：
- 对数据进行结构化、建模、清理和准备。
- 轻松访问数据。
- 针对报告目的进行了优化。
- 列和行级别的安全性，数据屏蔽。
- ACID事务支持。
缺点：
- 数据模型和ETL过程中的实现更改的复杂性和耗时性。
- 必须定义架构。
- 平台的成本（取决于数据库提供程序和类型）。
- 数据库供应商依赖性（例如，从Oracle到SQL Server的迁移非常复杂）。
Data Lake历史
随着新一代人的出现，收集原始数据的做法已经出现。例如，它用于数据湖模型。
这些数据湖利用低成本的存储和文件API，建立在Apache Hadoop（2006）及其Hadoop分布式文件系统（HDFS）上。数据以各种格式存储，包括Avro和Parquet等开放文件格式，以其高效的压缩比和查询性能而闻名。数据湖通过其读模式方法提供了灵活性。
Hadoop和MapReduce新技术的引入为分析大量数据提供了一种经济高效的解决方案。然而，一种替代方案仍然存在，允许将数据子集加载到数据仓库中，以便使用BI工具进行分析。
开源格式的使用使包括机器学习和人工智能在内的各种分析工具都可以访问数据湖。尽管如此，这也带来了新的挑战，如数据质量、数据治理以及数据分析师MapReduce工作的复杂性。为了应对这些挑战，引入了ApacheHive（2010），提供了对数据的SQL访问。大数据平台和数据湖的开源性质促进了许多工具的开发。虽然该平台提供了灵活性，但由于使用的工具种类繁多，它也带来了复杂性。结果，一个题为“是口袋妖怪还是必应的数据？”可以在这里找到，允许用户测试他们对该平台的了解。
数据湖开发的下一个阶段是引入云环境和数据存储，如S3、ADLS和GCS，逐渐取代HDFS。这些新的数据存储是无服务器的，并提供了成本效益，以及归档等附加功能。云提供商引入了新型数据仓库，包括Redshift（2012）、Azure数据仓库、BigQuery（2011）和Snowflake（2014）。这促进了双层架构的实现，将数据湖和数据仓库相结合。另一个重要的进步是ApacheSpark，它实现了大规模的数据处理，并支持流行的编程语言，如Python、SQL和Scala。
数据湖架构
Medalion
我遇到过几个数据湖设计，目前最受欢迎的是Medallion建筑。然而，根据具体的用例，可能会遇到其他模式。
在Medallion架构中，青铜层负责从源中获取原始数据，并将其转换为银层，在银层中以常见的数据格式存储，如Parquet。最后，数据被聚合并存储在黄金层中。
- Bronze/Raw区域以其原始格式（如JSON、CSV、XML等）存储数据。我们在从源系统获取数据时保留数据。这些数据是不可变的，这里的文件是只读的。此处的文件应按每个源系统组织在一个文件夹中。我们应该阻止用户访问该层。
- Silver/Cleansed区域存储的数据可以被丰富、清理，并转换为常见格式，如Parquet、Avro和Delta（这些格式提供了良好的压缩比和读取性能）。我们可以在这里验证数据，进行标准化和协调。我们还定义了一个数据类型和一个模式。数据科学家和其他用户可以访问该层。
- 黄金/Curated区域这是消费层，针对分析而非数据摄入或数据处理进行了优化。这里的数据可以在维度数据模型中进行聚合或组织。您可以使用Spark查询此数据或数据虚拟化。在这种情况下，性能可能是个问题。您还可以将数据导入BI工具，以改善仪表板的用户体验。
数据湖的演变与数据仓库融合为两层架构
Medalion的一个替代方案可以是双层数据仓库，我在上面提到过，在这里我将进一步探索它。在这种方法中，我们在数据湖中有青铜和白银，然后我们将数据加载到数据仓库中进行分析。要加载数据，我们可以使用批量加载命令或外部表。BigQuery、Redshift、Snowflake和Synapse具有此功能，可以从数据湖文件中读取数据，并通过ELT过程进行转换。这种工作方式改进了集成，尤其是当我们使用具有定义的模式并且具有良好读取性能的镶木地板文件时。
我们还可以创建一个归档层，例如在一个单独的存储桶中，以降低数据存储的成本（我们可以更改存储类型以降低成本）。
此外，我们还可以创建一个产品区，支持数据工程师和分析师构建自己的结构和计算，用于分析和ML/AI目的。
- 存档区区域可用于存档较旧的数据以供将来分析，从而降低存储成本。云提供商提供不同类型的存储，这些存储具有不同的访问时间和成本。这是优化数据归档成本的好方法。
- 产品/劳动力区这是进行探索和实验的层。在这里，数据科学家、工程师和分析师可以自由地进行原型和创新，将自己的数据集与生产数据集混合在一起。此区域不能替代测试或开发环境。
- 敏感区是我们需要处理敏感数据的数据湖的另一种设计。通常，只有特定的用户才能访问该层，并且访问比访问数据湖的其他部分更受限制。
Data Lake中的文件夹组织
为了防止数据沼泽的发生，在数据湖中建立一个简单且自我描述的文件夹结构是至关重要的。应该实现适当的层次结构，确保文件夹是可读的、易于理解的和不言自明的。在启动数据湖开发过程之前，定义命名约定至关重要。这些措施将促进数据湖的适当利用，并有助于访问管理。此外，了解如何构建文件夹结构以增强查询引擎对数据的理解也很重要。建议的方法是以青铜层和银层内呈现的方式组织数据。
-Source
-Entity
-year-month-date
-files实现这种分层结构将有效地管理查询引擎的分区数据。通过在结构化层次结构中组织数据，查询引擎可以有效地导航和访问特定分区，从而优化性能并增强数据检索能力。
-SAS
-CTAS
-2023–07–07
ctas.parquet
-Source
-Entity
-files当对特定的表采用全负载策略时，可以在不分区的情况下创建文件夹结构。在这种情况下，如果整个表都是完整加载的，则可能不需要分区，因为数据不是基于特定标准进行分割的。相反，可以建立一个简单的文件夹结构来组织和存储完整的数据集。
-Salesforce
-accounts
accounts.parquet当考虑到金层时，建立面向畴的结构是有益的。这种方法不仅便于访问管理，而且提高了数据湖的利用率。通过在特定于领域的类别（如客户、产品或销售）中组织数据，用户可以轻松地导航和利用相关数据来满足其特定的业务需求。
-Sales
-accounts
-accounts.parquet
-Finance
-time_registraion
-time.parquet朝着Lakehouses的方向所做的努力
当我最初遇到“Lakehouse”这个词时，我发现自己在质疑与传统数据湖方法的区别。当时，AWS引入了Athena和Redshift外部表等功能，Glue目录促进了各种AWS服务之间的无缝元数据共享。这一开发实现了在黄金层中创建数据模型，允许类似于数据仓库中的查询功能。主要提供商实现的Spark SQL、Presto、Hive和External Tables等SQL引擎的可用性促进了数据湖的查询。然而，在数据管理、事务ACID支持以及通过索引实现高效性能等领域仍然存在挑战。
Data Lakehouse
由Databricks实现的Data Lakehouse架构代表了第二代数据湖，通过结合Data Lake和Data Warehouse的优势，为设计数据平台提供了一种独特的方法。它是一个单一的统一平台，用于容纳数据仓库和数据湖。Data Lakehouse体系结构不仅像传统的数据仓库一样支持ACID事务，而且还提供了数据湖中存储的成本效益和可扩展性。该体系结构允许直接访问数据湖的所有层，并包括对有效数据治理的模式支持。此外，Data Lakehouse还引入了索引、数据缓存和时间旅行等功能，以增强性能和功能。它继续支持结构化和非结构化数据类型，数据以文件格式存储。
为了实现Lakehouse架构，Databricks开发了一种称为Delta的新型文件格式（关于文件格式的更多细节将在本文稍后描述）。然而，作为德尔塔的替代品，可以使用其他文件格式，如Iceberg和ApacheHudi，提供类似的功能。这些新的文件格式使Spark能够利用新的数据操作命令来改进数据加载策略。在Data Lakehouse中，可以对表中的行进行更新，而无需将整个数据集重新加载到表中。
Data Lakehouse架构
Data Lakehouse主要使用奖章结构来组织数据。正如我所提到的，我们有三层数据湖屋青铜、白银和黄金。Lakehouse数据的主要区别在于文件格式。我们使用德尔塔格式来存储数据。或者，如果我们使用Databricks以外的其他工具，我们可以使用Iceberg或Hundi作为主要数据格式。我们可以通过以下几种方式来组织lakehouse中的数据。
我们用来“照原样”从来源获取数据的青铜。数据在存储中是源系统对齐和组织的。如果我们从源导入数据，我们将以德尔塔格式保存它。如果数据不支持增量，或者源系统将数据直接转储到存储器中，则数据可以由摄取工具摄取并以其本地格式保存。
Silver保存的数据经过了清理、统一、验证，并用参考数据或主数据进行了丰富。优选的格式是德尔塔。表仍然对应于源系统。该层可用于数据科学、特别报告、高级分析和ML。
黄金层承载一个数据模型，业务用户、BI工具和报告将使用该模型。我们使用德尔塔格式。该层保留了包括计算和丰富的业务逻辑。我们只能从Silver获得一组特定的数据，或者只能获得聚合数据。在这一层中，表格的结构是面向主题的。
带Lakehouse的Data Vault
组织Lakehouse的另一种方法是使用Data Vault方法。这种方法特别适用于处理大量数据、多个数据源和频繁集成更改的组织。Data Vault模式类似，但它涉及数据建模和组织方面的重要更改。