找到复杂问题的答案很难。但更具挑战性的任务是提出正确的问题。只有通过（1）提出正确的问题和（2）利用数据揭示答案，才能探索“可能性艺术”。尽管听起来简单，但一个组织需要一个完整的数据平台来使用户能够执行这些任务。该平台必须支持数据的摄取和存储，为用户提供工具来提出和发现新问题，进行高级分析，预测和预报结果，并生成洞察。数据平台是使用户能够利用数据获得业务利益的基础设施。
让我们从数据架构的基本原理开始。
数据平台是使用所选技术栈实现数据架构的最终结果。数据架构是定义你打算构建的系统的蓝图。它帮助你可视化目标系统的最终状态以及实现它的计划。数据架构定义了核心组件、这些组件之间的相互依赖关系、基本设计原则以及实施数据平台所需的过程。
要理解数据架构，可以考虑这个真实世界的类比：一个商业建筑工地，例如购物中心或大型住宅开发项目。
建造商业物业需要稳健的架构、创新的设计、经验丰富的建筑师和一大批建筑工人。架构在开发中起着最关键的作用——它确保建筑能在各种天气条件下生存，帮助人们轻松访问和导航各个楼层，并在紧急情况下快速疏散人群。这类架构基于某些指导原则，这些原则定义了建筑模块的核心设计和布局。无论你是在建造住宅物业、商业综合体还是体育场，架构的基础支柱和核心设计原则是相同的。然而，设计模式——内部装修、美学和其他满足用户需求的功能——则不同。
类似于建造商业物业，数据架构在开发稳健的数据平台时起着最关键的作用，该平台将支持各种用户和各种数据与分析用例。为了构建一个对所有用户来说都具有弹性、可扩展性和可访问性的平台，数据架构应基于核心指导原则。无论是哪个行业或领域，数据架构的基本原理都是相同的。
数据架构，类似于建筑工地的设计架构，在决定用户如何适应平台方面起着重要作用。本节将涵盖数据架构在实现数据平台的整体过程中所具有的重要性。
构建数据平台的架构可能是数据项目中最关键的阶段，通常会影响平台的用户采用、可扩展性、合规性和安全性等关键结果。数据架构帮助你定义以下需要开展的基础活动，以开始构建你的平台。
在定义平台的核心组件之后，你需要确定它们如何互动。数据架构定义了这些依赖关系，并帮助你可视化数据在生产者和消费者之间的流动方式。架构还帮助你确定并解决在这些组件之间移动数据时可能遇到的特定限制或集成挑战。
作为数据架构设计过程的一部分，你还需要定义实施数据平台的指导原则。这些原则帮助在使用平台的各个数据团队之间建立共享理解。它们确保每个人都遵循相同的设计方法、共同的标准和可重用的框架。定义共享的指导原则使你能够实施优化、高效和可靠的数据平台解决方案。指导原则可以应用于各种组件，并根据数据架构的能力和限制进行定义。例如，如果你的平台配置了多个商业智能（BI）工具，指导原则应指定根据数据消费模式或用例选择使用哪个BI工具。
架构蓝图还会告知平台核心组件的技术栈。在设计平台时，可能很难最终确定所有的底层技术——需要对其限制和优势进行详细研究，并进行概念验证（PoC）来最终确定。数据架构帮助定义做出这些技术选择的关键考虑因素，以及在进行任何PoC活动和最终确定技术栈时所需的成功因素。
最后，也是最关键的，数据架构帮助你实施与整体愿景和组织的数据战略对齐的数据平台，以实现其业务目标。例如，数据治理是任何组织数据战略的核心。数据架构定义了确保数据治理在每个过程核心中的组件。这些组件包括元数据仓库、数据目录、访问控制和数据共享原则。
数据治理是一个涵盖各种标准、规则和政策的总括性术语，确保所有数据过程遵循相同的正式指南。这些指南有助于确保符合地理或行业法规，并确保数据的可信度、高质量和价值。组织应在所有数据管理过程中遵循数据治理政策，以保持消费者对数据的信任并保持合规性。数据治理帮助组织更好地控制数据，轻松发现数据，并安全地与消费者共享数据。
现在你更好地理解了数据架构及其在实现数据平台中的重要性，接下来让我们讨论数据平台的核心组件。
在本节中，我们将探讨数据平台的核心组件及其功能如何为健全的数据生态系统做出贡献。图1-1展示了基于数据架构蓝图实现数据平台的核心组件。
内部和外部源系统
内部源是组织内生成数据的内部应用程序。这些包括内部的客户关系管理（CRM）系统、事务数据库和机器生成的日志。内部源通常由负责生成数据的内部领域团队拥有。
数据平台通常需要从外部系统获取数据，以增强其内部数据并获得竞争性洞察。例如，来自外部源系统的数据包括汇率、天气信息和市场研究数据。
批处理、近实时和流处理系统
结构化、半结构化和非结构化数据
数据摄取是从源系统提取数据并将其加载到数据平台的过程。如前所述，根据源系统生成和发送数据的能力，摄取框架必须实施批处理、近实时或流处理系统。
批处理摄取
每天一次发送的数据（无论是作为一天结束或一天开始的过程）可以作为批处理过程摄取到数据平台中。这是传统数据仓库架构中生成每日管理信息系统（MIS）或监管报告时最常用的摄取模式。
近实时
流处理
数据摄取后，必须存储以确保持久性、易发现性和进一步分析。数据存储组件使各种数据类型能够有效存储。这些组件持久化数据，使其能够在需要时检索，并应提供高可用性和高持久性。
根据用例，你可以将数据存储分类为两大类：通用存储和专用存储。
通用存储
所有数据类型都可以存储在对象存储中，如Hadoop分布式文件系统（HDFS）、AmazonS3、Azure数据湖存储（ADLS）或Google云存储（GCS）。这些对象存储支持持久化结构化、半结构化或非结构化数据。它们提供高可用性和持久性，同时成本效益高，使其成为长期存储数据的最佳选择之一。
专用存储
虽然对象存储适用于成本效益高的长期存储，但你可能需要一种专用存储系统，它能够展示快速访问、更快检索、基于键的搜索、列存储和高并发等功能。
有不同的技术和架构模式来实现这些专用存储系统：
数据存储组件是数据平台中使用最广泛的组件。从存储长期数据到快速提供数据，所有主要活动都通过这些组件在计算引擎的帮助下进行。
从源系统收集的原始数据必须根据业务需求进行验证、清洗、集成和转换。作为数据处理的一部分，以下步骤将原始数据转换为更可消费的最终产品。
数据验证和清洗
当数据从源系统摄取时，它是原始形式的，需要验证和清洗后才能提供给最终用户。这两个步骤都很重要，以确保数据在移动到湖仓生态系统的更高存储区时其准确性不受损害。数据存储区的层级——原始、清洗、策划和语义——将在第七章详细讨论。
摄取后的第一步是对输入数据进行验证。这些验证适用于结构化数据以及用于报告和洞察生成的某些半结构化数据。在此步骤中，数据通过各种验证镜头，包括以下技术和业务验证：
数据转换
将原始数据转换为有用信息的过程称为数据转换。它可以包含一系列转换，首先整合来自多个源系统的数据，然后将其转换为下游应用程序、业务用户和其他数据消费者可以根据其需求使用的可消费形式。
根据你的用例和需求，可以应用多种数据转换。常见的数据转换包括：
ETL和ELT是什么？
在实现数据仓库和数据湖时，有两种广泛采用的数据转换方法：
在数据处理的最后一步，数据根据业务流程和需求进行策划和服务。数据基于行业标准数据模型加载到策划存储区，使用维度建模等建模方法。这种使用行业特定数据模型安排数据的方法有助于更快、更容易地生成洞察和报告。策划的数据可以用于创建数据产品，供消费者直接使用以满足其业务需求。
数据产品是一个新术语，用于定义专门为消费者策划的可消费最终产品。数据产品通常由负责数据的领域团队创建。这些产品可以与其他领域团队和下游应用程序共享。数据产品可以是表格、视图、报告、仪表板，甚至是机器学习（ML）模型，可以被最终用户轻松发现和消费。
平台中的数据消费组件使用户能够访问、分析、查询和消费数据。这些可以是你的BI报告工具或用于预测和预测的ML模型。这些组件支持的各种工作负载包括：
所有这些组件——BI报告工具和ML模型——都支持数据消费和交付给消费者，并在提高平台用户采用方面发挥重要作用。这些组件还为用户提供了与平台内数据交互的界面，因此在设计平台时应考虑用户体验。
有些通用服务在数据平台中提供功能，并在使数据易于发现、可用和安全访问方面发挥重要作用。这些通用服务概括如下。
所有这些核心组件形成了数据平台，使其用户能够执行各种活动。数据架构提供了构建这些数据平台的蓝图和指导原则。通过对数据架构和数据平台及其重要性的基本理解，现在让我们讨论一种新架构模式——湖仓，这是本书的主要主题。
数据仓库和数据湖一直是实现数据平台的最受欢迎的架构。然而，近年来，一些组织努力通过利用不同的架构方法来实现数据平台。
它们寻找新方法而不是实施众所周知的传统数据架构的动机主要有两个：
组织一直在寻求克服传统架构的限制，并利用新技术来构建可扩展、安全和可靠的平台。组织、独立服务提供商（ISV）和系统集成商（SI）尝试了不同且创新的方法来实现更现代的数据平台。这些方法包括：
所有这些努力表明需要一种新的架构模式，该模式可以：
这就是湖仓架构在过去几年中出现的新模式。在下一节中我们将详细讨论这一点。
新的工具、产品和开源技术改变了组织实现数据生态系统的方式。这些新技术帮助简化了复杂的数据架构，从而构建出更加可靠、开放和灵活的数据平台，以支持各种数据和分析工作负载。
湖仓（在本书中称为湖仓或湖仓架构）是一种利用新技术构建简单开放数据平台的新架构模式。如图1-2所示，湖仓的核心是一个数据湖，外加一个事务层和一个高性能计算层。这个额外的事务层使其具有类似数据仓库的ACID属性和其他功能。
注意
使用湖仓架构构建的数据平台表现出数据仓库和数据湖的特性，因此得名湖仓。图1-3展示了湖仓架构的关键特性，这些特性结合了数据湖和数据仓库的最佳特性。数据湖和数据仓库的特性将在第2章中更详细地讨论，我将在那里解释这些传统架构、它们的特点及其优势。
像数据湖一样，湖仓使用云对象存储，如AmazonS3、ADLS或GCS，并以开放文件格式存储数据，如ApacheParquet、ApacheAvro或ApacheORC。这种云存储使湖仓具备数据湖的所有最佳特性，如高可用性、高持久性、成本效益、可扩展性、对所有数据类型（结构化、半结构化、非结构化）的支持，以及对AI和ML用例的支持。
与数据湖相比，湖仓有一个额外的组件：事务层，这是在文件格式之上的一个附加层。这个额外的层使湖仓与数据湖区分开来。它使湖仓能够获得数据仓库的功能，如ACID合规性、对更新和删除的支持、更好的BI性能和细粒度的访问控制。用于实现这一事务层的技术称为“开放表格式”，我们将在下一节中详细讨论。
湖仓架构在数据社区中引起了兴趣，许多组织已经开始采用它来构建支持多种用例的平台，如ETL处理、BI、ML、数据科学和流分析。除了主要的云服务提供商外，多个商业产品供应商提供SaaS或PaaS产品来支持基于湖仓架构的数据平台的实现。这些产品包括Databricks、Snowflake、Dremio和Onehouse的产品。
当Hadoop兴起时，组织使用类似于湖仓的概念实现数据平台。他们使用HDFS作为存储，并使用Hive作为开放表格式。平台使用Hive的元存储作为元数据层，并使用其引擎处理存储在HDFS上的数据。然而，最初Hive缺乏Parquet等文件格式所需的ACID特性。后来它才开始为ORC文件提供ACID支持。
2021年，Databricks的创始人在创新数据系统研究会议（CIDR）上发表了一篇题为《湖仓：统一数据仓库和高级分析的新一代开放平台》的论文。论文提出了一种新的架构模式，称为湖仓，可能在未来几年内取代数据仓库。从那时起，湖仓架构迅速发展，全球的数据从业者开始探索它。
让我们更深入地探讨湖仓架构及其使用的基础技术。
图1-4展示了湖仓架构的简单视图，包括存储层和计算层以及底层技术选项。这是本章前面看到的图1-2的详细视图。
正如我们讨论的，湖仓架构包括存储层和计算层。使用湖仓架构构建的数据平台允许数据和分析工作负载从存储层中读取数据，同时利用计算引擎。
存储层
首先，让我们了解存储层中的技术选项。这个层次由三个组件组成：云存储、开放文件格式和开放表格格式。
云存储
云存储是一种提供高可用性、耐久性和可扩展性服务的解决方案，用于实现数据湖和湖仓平台。主要的云服务提供商提供以下服务来实现湖仓平台：
组织也可以使用本地HDFS存储来实现湖仓。仅使用云对象存储来实现湖仓并不是必须的。然而，考虑到低成本、计算与存储的分离以及易于扩展等特点，建议使用云对象存储作为实现湖仓的基础设施。
本书将仅讨论使用云技术实现的现代平台。我们将在第2章中详细了解现代平台。
开放文件格式
数据平台可以将数据以不同的文件格式存储在云存储中。CSV、JSON和XML是最受欢迎的文件格式。对于分析平台，三种最广泛采用的文件格式是Parquet、ORC和Avro。
这些都是开放文件格式，即它们是开源生态系统的一部分。这些格式不是专有的；任何人都可以轻松使用它们来存储数据。任何兼容的处理引擎都可以与这些开放文件格式进行交互。许多其他特性使这三种格式适合分析工作负载。我们将在第3章中更详细地讨论这些文件格式。
开放表格格式
如前所述，开放表格格式为数据湖提供事务能力，使其成为湖仓。这些开放表格格式是湖仓的核心。数据社区中越来越流行的三种格式是：ApacheIceberg、ApacheHudi和Linux基金会的DeltaLake。
让我们快速了解这三种开放表格格式：
目前有两个不同版本的DeltaLake。商业版本随Databricks平台提供。开源版本可在Linux基金会网站上获得，您可以在其他非Databricks环境中使用它。尽管Databricks将所有DeltaLake特性都开源了，但最新的开源版本可能不会立即在像AmazonEMR或AzureSynapseAnalytics这样的托管ApacheSpark服务中提供。您需要等到这些托管云服务提供最新的Spark和DeltaLake版本，才能利用所有最新的DeltaLake特性。
所有这些开放表格格式将在第3章中详细讨论。
计算层
湖仓架构的主要优点之一是其开放性以及可以直接由任何兼容的处理引擎访问或查询的能力。它不需要特定的专有引擎来运行BI工作负载或交互式分析。这些计算引擎可以是开源的，也可以是专门为湖仓架构设计的商业查询引擎。
开源引擎
您可以使用开源引擎来访问湖仓中的数据。这些引擎不是特定于供应商的，您无需购买许可证即可使用它们。开源计算引擎的例子包括Spark、Presto、Trino和Hive。
商业引擎
这些是专门为在湖仓上运行工作负载而构建的查询引擎。商业引擎通常从头开始构建，考虑到底层开放数据格式以及如何有效地获得最佳性能。商业计算引擎供应商的例子包括Databricks、Dremio、Snowflake和Starburst。
存储层和计算层共同作用，为湖仓架构提供了数据湖和数据仓库的最佳特性。因此，湖仓架构解决了传统数据架构的局限性，并支持不同的工作负载，从BI到AI，以及利用数据平台的不同下游应用。
基于湖仓架构的数据平台展现了帮助解决传统架构局限性的关键特性。以下部分详细介绍了这些特性。
以下特征使湖仓架构与其他传统数据架构区别开来。
单一存储层，无需专用仓库
如前所述，湖仓的核心是基于云对象存储构建的数据湖，并具有额外的事务层。没有类似专用数据仓库的独立存储来支持BI工作负载。所有用户直接从数据湖中读取、访问或查询数据。相同的云对象存储支持所有用例，包括BI和AI/ML工作负载。
数据湖上的类似仓库性能
云存储不适合BI工作负载，缺乏云数据仓库专用存储所提供的性能。使用湖仓架构构建的数据平台通过在存储和计算层提供优化杠杆，为BI用例提供了出色的性能。通过使用适合湖仓架构的开放数据（文件和表）格式和计算引擎的正确组合，您可以获得卓越的性能。
解耦架构，存储和计算独立扩展
湖仓架构基于解耦的方法，拥有独立的存储和计算引擎。以前的数据平台使用集成存储和处理层的架构。例如，数据库、传统的本地仓库和Hadoop生态系统。这样的集成架构无法实现存储或计算能力的独立扩展。
解耦的湖仓架构有助于单独扩展存储和计算能力。您可以轻松增加存储而无需增加计算能力，反之亦然。图1-5展示了实现湖仓架构的解耦存储和计算平台。
开放架构
湖仓架构采用“开放”方法来实现数据平台。这意味着您可以自由地使用开源数据格式和开源计算引擎来构建数据平台。与必须使用仓库软件中捆绑的本地处理引擎的专有仓库不同，湖仓允许您使用与底层存储格式兼容的任何分布式处理引擎。这种开放架构使数据用户可以直接从云存储中访问数据，而无需依赖供应商特定的软件。
对不同数据类型的支持
传统上，本地仓库架构仅支持结构化数据。它们不能存储、管理或维护半结构化和非结构化数据。现代一些云数据仓库现在可以支持半结构化数据，如JSON和XML文件。
使用湖仓方法构建的数据平台可以在单一存储层中支持所有数据格式——结构化、半结构化以及非结构化的数据，如图像、音频和视频数据。
对多样化工作负载的支持
由于湖仓能够处理所有数据格式，因此它可以支持所有类型的工作负载，包括BI、AI/ML、ETL和流处理。您无需实现独立的存储层或专用存储来支持这些工作负载。湖仓架构可以在单一存储层中支持所有这些工作负载。
接下来，让我们讨论湖仓架构的关键好处以及它如何帮助构建一个简单、统一和开放的数据平台。
采用Lakehouse方法实现的数据平台在当今需要构建既可扩展、灵活又安全可靠的数据平台的世界中，具有许多显著的优势。
以下是基于Lakehouse架构实现数据平台所带来的诸多好处。
在Lakehouse架构中，所有数据都存储在一个单一的存储层中。由于不再需要单独的数据仓库，也不需要将数据从数据湖移动到数据仓库的额外ETL管道，因此数据架构得以简化。Lakehouse架构还避免了将数据湖和数据仓库集成时可能出现的延迟、失败或数据质量问题。
这种单一存储层的架构有以下几个好处：
如今生产的大量数据是非结构化的。Lakehouse支持非结构化数据以及结构化和半结构化数据。这为实现AI和ML用例提供了无限可能，可以利用大量的非结构化数据进行预测、预测、推荐和从数据中获取新见解。
如前所述，Lakehouse使用开放格式来实现数据平台。开放格式使消费者能够使用任何与底层存储格式良好集成的兼容处理引擎来查询和处理数据。Lakehouse不使用需要特定供应商处理引擎的专有存储格式。这使得下游应用程序可以直接访问数据进行消费。
例如，如果您实现了一个包含数据湖和专用数据仓库的双层数据平台，则必须首先将数据加载到数据仓库中才能执行任何BI工作负载。要查询或访问这些数据，必须使用相同数据仓库供应商的专有计算引擎。您必须使用供应商提供的处理能力并支付相应的费用。这导致了供应商锁定，迁移到其他引擎需要相当大的努力。
注意：并非所有开放表格式都与所有开源或商业查询引擎兼容。这是一个不断发展的领域，多个独立软件供应商（ISV）正在开发与各种数据格式交互的连接器。在决定技术堆栈时，应考虑引擎与底层开放表格式的兼容性。
由于Lakehouse使用开放数据格式，与下游消费者共享数据变得更加容易。不需要在您的平台上接入消费者或与他们共享文件提取物。消费者可以根据数据共享访问权限直接从云存储中访问数据。
数据共享的一个例子是DeltaSharing协议，这是DeltaLake引入的一种用于安全数据共享的开放标准。图1-6显示了DeltaSharing协议的简化版本。请注意，实际实现将包含额外的组件，以管理权限并优化性能以仅提供所需的数据。
这是一个不断发展的领域，未来可能会有多个供应商和社区引入新的连接器，以直接访问存储在Lakehouse中的数据。
Lakehouse使用云存储，具有可扩展性且比传统数据仓库便宜得多。Lakehouse的存储成本由云存储提供商设定。您还可以利用生命周期管理策略以及云供应商提供的冷存储或归档层来优化长期存储成本。
许多组织在数据湖中存储了大量数据，但大多数情况下由于缺乏数据可见性而无法有效利用这些数据。
在没有适当的元数据管理、治理、数据溯源跟踪和访问控制的情况下，发现这些大量数据是困难的。没有这些功能，数据湖会变成数据沼泽，利用这些数据变得具有挑战性。Lakehouse通过提供统一的元数据管理（跨数据和AI资产）、数据溯源跟踪等功能，使平台的消费者可以轻松发现数据。
注意：数据沼泽是指存储了大量数据但没有适当组织或结构的数据湖。存储在这种数据湖中的数据治理不足，元数据没有组织成目录形式，使得数据发现极具挑战性，降低了消费者对数据的整体可见性。简而言之，由于缺乏强大的元数据和治理流程，数据沼泽中的数据无法用于业务需求。
Lakehouse架构中使用的技术支持强制模式验证，以避免存储数据时的模式不匹配。这些技术还支持模式演变，使用不同的方法来帮助接受源模式的变化。这些功能使系统更灵活，具有更好的数据质量和完整性。我们简要讨论一下这两个功能的好处。
模式强制确保存储在Lakehouse中的数据遵循该表的元数据定义的模式。ETL过程会拒绝任何额外的属性或不匹配的数据类型。这些验证有助于存储正确的数据，从而提高整体数据质量。例如，如果字符串值出现在模式中定义为整数的属性中，它将被拒绝。
虽然模式强制通过实施严格的验证提高了数据质量，但模式演变通过在存储数据时提供更多灵活性来支持放宽这些验证。任何未在表元数据中定义的额外属性都可以通过模式演变存储。根据开放表格式，存在各种方法来存储额外属性。此功能有助于保留新属性或数据类型不匹配，而不会拒绝它们。这种方法的主要好处是您不会丢失任何数据，并且可以即时适应变化。
虽然模式强制通过对特定属性实施严格规则来提高数据质量，但模式演变提供了灵活性，以适应源系统中的元数据变化。您可以在实现Lakehouse时同时使用这两者，以保持数据质量并适应任何源元数据变化。
如前所述，Lakehouse架构使您能够实现一个统一的数据平台，以支持多种工作负载。让我们详细讨论这些工作负载以及使用Lakehouse实现它们的好处。
为了实现ETL工作负载，您可以使用Spark等流行的处理引擎在将数据存储到Lakehouse存储层的较高级别区域之前执行转换。您还可以实施ELT工作负载，使用任何计算引擎通过SQL查询执行转换。更熟悉SQL的数据从业者更喜欢执行基于SQL的ELT操作来转换数据。
由于性能与数据仓库相当，您可以使用Lakehouse实现BI工作负载。由于Lakehouse为数据湖提供了事务层，更新和删除等操作比在数据湖中执行更快。
由于Lakehouse支持结构化数据、半结构化数据和非结构化数据，您可以通过直接访问Lakehouse中的数据来执行AI/ML用例。
统一的Lakehouse架构支持多种工作负载，包括实时处理。在过去几年中，由于物联网设备、可穿戴设备和点击流生成的实时数据的增加，组织试图实现支持实时工作负载的平台。早期的数据架构，如Lambda架构，使用不同的处理流支持实时工作负载。Lakehouse使用统一架构支持实时工作负载，支持使用相同代码库执行批处理或实时作业。
考虑一种情况，其中product_id为71的第三行已更新，将类别从“computeraccessory”更改为“mobileaccessory”。表1-2显示了更新后的表。
现在，如果您查询产品表，您将能够看到更新后的数据，但更新记录的旧product_category值将不可见。
您可以使用版本号检索记录的旧状态：
这些优势使得所有数据用户能够比早期数据架构更快、更有效地访问、管理、控制、分析和利用数据。
鉴于这些优势，Lakehouse架构很快可能成为实现数据平台的默认选择，并可能像数据仓库和数据湖一样被广泛采用。先进技术、不断增长的社区以及多个ISV正在开发基于Lakehouse的产品，表明对Lakehouse架构的需求和普及程度在不断上升。
如果您是第一次了解Lakehouse架构，我理解这些信息在第一次阅读时可能难以消化。我将总结本章讨论的关键点，以帮助您在阅读本书后续章节时记住最重要的概念。
在继续阅读本书时，您将深入了解更多高级主题，以理解如何设计和实现实际的Lakehouse架构，并看到它们相对于传统架构（如数据仓库和数据湖或组合的双层系统）的优势。但对于新接触数据领域的读者，我们首先需要更好地了解这些传统架构、它们的优点和局限性，以便更好地理解Lakehouse架构的优势。我将在下一章中讨论这些内容。