实用湖仓架构——数仓架构导论所有数据从业者，无论他们的工作职位如何，都会进行两个共同且基础的活动——提出问题和寻找答案！

所有数据从业者，无论他们的工作职位如何，都会进行两个共同且基础的活动——提出问题和寻找答案！任何数据人员，无论是数据工程师、数据架构师、数据分析师、数据科学家，还是像首席信息官（CIO）或首席数据官（CDO）这样的数据领导者，都必须保持好奇心并提出问题。

找到复杂问题的答案很难。但更具挑战性的任务是提出正确的问题。只有通过（1）提出正确的问题和（2）利用数据揭示答案，才能探索“可能性艺术”。尽管听起来简单，但一个组织需要一个完整的数据平台来使用户能够执行这些任务。该平台必须支持数据的摄取和存储，为用户提供工具来提出和发现新问题，进行高级分析，预测和预报结果，并生成洞察。数据平台是使用户能够利用数据获得业务利益的基础设施。

要实施这样的数据平台，你需要一个强大的数据架构——一个能够帮助你定义数据平台核心组件并建立实施设计原则的架构。传统上，组织使用数据仓库或数据湖架构来实施他们的数据平台。这两种架构方法在各行业中被广泛采用。这些架构也在不断发展，以利用不断改进的现代技术和模式。湖仓架构就是近年来发展起来的一种现代架构模式，已成为设计数据平台的数据架构师的热门选择。

在本章中，我将向你介绍与数据架构、数据平台及其核心组件相关的基本概念，以及数据架构如何帮助构建数据平台。然后，我将解释为什么需要像湖仓这样的新架构模式。你将学习湖仓架构的基础、特征，以及使用湖仓架构实施数据平台的好处。我将以重要的要点总结本章内容，帮助你在阅读本书后续章节时记住关键点。

让我们从数据架构的基本原理开始。

理解数据架构

数据平台是使用所选技术栈实现数据架构的最终结果。数据架构是定义你打算构建的系统的蓝图。它帮助你可视化目标系统的最终状态以及实现它的计划。数据架构定义了核心组件、这些组件之间的相互依赖关系、基本设计原则以及实施数据平台所需的过程。

什么是数据架构？

要理解数据架构，可以考虑这个真实世界的类比：一个商业建筑工地，例如购物中心或大型住宅开发项目。

建造商业物业需要稳健的架构、创新的设计、经验丰富的建筑师和一大批建筑工人。架构在开发中起着最关键的作用——它确保建筑能在各种天气条件下生存，帮助人们轻松访问和导航各个楼层，并在紧急情况下快速疏散人群。这类架构基于某些指导原则，这些原则定义了建筑模块的核心设计和布局。无论你是在建造住宅物业、商业综合体还是体育场，架构的基础支柱和核心设计原则是相同的。然而，设计模式——内部装修、美学和其他满足用户需求的功能——则不同。

类似于建造商业物业，数据架构在开发稳健的数据平台时起着最关键的作用，该平台将支持各种用户和各种数据与分析用例。为了构建一个对所有用户来说都具有弹性、可扩展性和可访问性的平台，数据架构应基于核心指导原则。无论是哪个行业或领域，数据架构的基本原理都是相同的。

数据架构，类似于建筑工地的设计架构，在决定用户如何适应平台方面起着重要作用。本节将涵盖数据架构在实现数据平台的整体过程中所具有的重要性。

数据架构如何帮助构建数据平台？

构建数据平台的架构可能是数据项目中最关键的阶段，通常会影响平台的用户采用、可扩展性、合规性和安全性等关键结果。数据架构帮助你定义以下需要开展的基础活动，以开始构建你的平台。

定义核心组件

数据平台的核心组件帮助执行日常活动，如数据摄取、存储、转换、消费，以及与管理、操作、治理和安全相关的其他常见服务。数据架构帮助你定义数据平台的这些核心组件。这些核心组件将在下一节中详细讨论。

定义组件之间的相互依赖关系和数据流

在定义平台的核心组件之后，你需要确定它们如何互动。数据架构定义了这些依赖关系，并帮助你可视化数据在生产者和消费者之间的流动方式。架构还帮助你确定并解决在这些组件之间移动数据时可能遇到的特定限制或集成挑战。

定义指导原则

作为数据架构设计过程的一部分，你还需要定义实施数据平台的指导原则。这些原则帮助在使用平台的各个数据团队之间建立共享理解。它们确保每个人都遵循相同的设计方法、共同的标准和可重用的框架。定义共享的指导原则使你能够实施优化、高效和可靠的数据平台解决方案。指导原则可以应用于各种组件，并根据数据架构的能力和限制进行定义。例如，如果你的平台配置了多个商业智能（BI）工具，指导原则应指定根据数据消费模式或用例选择使用哪个BI工具。

定义技术栈

架构蓝图还会告知平台核心组件的技术栈。在设计平台时，可能很难最终确定所有的底层技术——需要对其限制和优势进行详细研究，并进行概念验证（PoC）来最终确定。数据架构帮助定义做出这些技术选择的关键考虑因素，以及在进行任何PoC活动和最终确定技术栈时所需的成功因素。

与整体愿景和数据战略对齐

最后，也是最关键的，数据架构帮助你实施与整体愿景和组织的数据战略对齐的数据平台，以实现其业务目标。例如，数据治理是任何组织数据战略的核心。数据架构定义了确保数据治理在每个过程核心中的组件。这些组件包括元数据仓库、数据目录、访问控制和数据共享原则。

注意

数据治理是一个涵盖各种标准、规则和政策的总括性术语，确保所有数据过程遵循相同的正式指南。这些指南有助于确保符合地理或行业法规，并确保数据的可信度、高质量和价值。组织应在所有数据管理过程中遵循数据治理政策，以保持消费者对数据的信任并保持合规性。数据治理帮助组织更好地控制数据，轻松发现数据，并安全地与消费者共享数据。

现在你更好地理解了数据架构及其在实现数据平台中的重要性，接下来让我们讨论数据平台的核心组件。

数据平台的核心组件

在本节中，我们将探讨数据平台的核心组件及其功能如何为健全的数据生态系统做出贡献。图1-1展示了基于数据架构蓝图实现数据平台的核心组件。

核心组件和相关过程

源系统

源系统为数据平台提供用于分析、商业智能（BI）和机器学习（ML）的数据。这些来源包括传统系统、后端在线事务处理（OLTP）系统、物联网设备、点击流和社交媒体。源系统可以根据多个因素分类。

内部和外部源系统

内部源是组织内生成数据的内部应用程序。这些包括内部的客户关系管理（CRM）系统、事务数据库和机器生成的日志。内部源通常由负责生成数据的内部领域团队拥有。

数据平台通常需要从外部系统获取数据，以增强其内部数据并获得竞争性洞察。例如，来自外部源系统的数据包括汇率、天气信息和市场研究数据。

批处理、近实时和流处理系统

直到几十年前，大多数源系统只能发送批处理数据，即通常在一天结束时作为每日批处理过程发送数据。随着对更近实时洞察和分析需求的增加，源系统开始以近实时的方式发送数据。这些系统现在可以在固定间隔内以多个较小的微批次共享数据，间隔可以短至几分钟。物联网设备、社交媒体馈送和点击流等来源会连续不断地发送数据，需要实时摄取和处理以获得最大价值。

结构化、半结构化和非结构化数据

源系统传统上只生成表格或固定结构文件中的结构化数据。随着数据交换格式的进步，半结构化数据（如XML和JSON文件）的生产增加。而且，随着组织开始实施大数据解决方案，它们开始生成大量非结构化数据，如图像、视频和机器日志。你的数据平台应该支持所有类型的源系统，在不同时间间隔发送不同类型的数据。

数据摄取

数据摄取是从源系统提取数据并将其加载到数据平台的过程。如前所述，根据源系统生成和发送数据的能力，摄取框架必须实施批处理、近实时或流处理系统。

批处理摄取

每天一次发送的数据（无论是作为一天结束或一天开始的过程）可以作为批处理过程摄取到数据平台中。这是传统数据仓库架构中生成每日管理信息系统（MIS）或监管报告时最常用的摄取模式。

近实时

对于时间敏感性更高的数据，可以作为微批次或近实时进行摄取。微批次的摄取间隔可以在几小时到几分钟之间，而近实时数据的摄取间隔可以在几分钟到几秒之间。数据摄取工具应根据业务需求满足所需的服务水平协议（SLA）。

流处理

流处理分析用例对时间非常敏感，需要一种支持实时数据摄取的架构，即在数据生成后的几毫秒内摄取。由于这些数据对时间至关重要，如果不立即摄取和处理，它们的价值会迅速降低。你的数据平台的摄取组件应该能够支持低延迟要求，以便在源系统生成数据时立即使其可用。

数据存储

数据摄取后，必须存储以确保持久性、易发现性和进一步分析。数据存储组件使各种数据类型能够有效存储。这些组件持久化数据，使其能够在需要时检索，并应提供高可用性和高持久性。

根据用例，你可以将数据存储分类为两大类：通用存储和专用存储。

通用存储

所有数据类型都可以存储在对象存储中，如Hadoop分布式文件系统（HDFS）、Amazon S3、Azure数据湖存储（ADLS）或Google云存储（GCS）。这些对象存储支持持久化结构化、半结构化或非结构化数据。它们提供高可用性和持久性，同时成本效益高，使其成为长期存储数据的最佳选择之一。

专用存储

虽然对象存储适用于成本效益高的长期存储，但你可能需要一种专用存储系统，它能够展示快速访问、更快检索、基于键的搜索、列存储和高并发等功能。

有不同的技术和架构模式来实现这些专用存储系统：

数据仓库：支持在线分析处理（OLAP）工作负载
关系数据库管理系统（RDBMS） ：支持应用程序后端的在线事务处理（OLTP）系统
内存数据库：提供更快的数据检索
图数据库：存储连接和关系

数据存储组件是数据平台中使用最广泛的组件。从存储长期数据到快速提供数据，所有主要活动都通过这些组件在计算引擎的帮助下进行。

数据处理和转换

从源系统收集的原始数据必须根据业务需求进行验证、清洗、集成和转换。作为数据处理的一部分，以下步骤将原始数据转换为更可消费的最终产品。

数据验证和清洗

当数据从源系统摄取时，它是原始形式的，需要验证和清洗后才能提供给最终用户。这两个步骤都很重要，以确保数据在移动到湖仓生态系统的更高存储区时其准确性不受损害。数据存储区的层级——原始、清洗、策划和语义——将在第七章详细讨论。

摄取后的第一步是对输入数据进行验证。这些验证适用于结构化数据以及用于报告和洞察生成的某些半结构化数据。在此步骤中，数据通过各种验证镜头，包括以下技术和业务验证：

技术验证：主要与数据类型、数据格式和其他技术性质的检查有关，可以跨任何领域或行业应用
业务验证：与特定值、准确性或完整性相关的特定领域或功能验证
模式验证：输入数据馈送应遵循的约定模式，定义在规格或数据合同中

数据转换

将原始数据转换为有用信息的过程称为数据转换。它可以包含一系列转换，首先整合来自多个源系统的数据，然后将其转换为下游应用程序、业务用户和其他数据消费者可以根据其需求使用的可消费形式。

根据你的用例和需求，可以应用多种数据转换。常见的数据转换包括：

数据整合：随着数据从多个源系统摄取，你必须将其合并以获得综合视图。例如，整合来自外部源系统、内部系统或营销应用程序的客户档案数据。不同的源系统可以以不同格式提供数据，因此我们需要将其带入一个通用的标准格式供下游应用程序消费。例如，“出生日期”属性在不同的源系统中可能有不同的格式（如MM/DD/YYYY或DD-MM-YY）。在存储到中央数据平台之前，重要的是将所有记录转换为标准格式（如DD/MM/YYYY）。作为转换过程的一部分，这种整合在存储数据之前完成。
数据增强：为了使数据更有意义，必须使用外部数据进行增强。例如：
- 使用来自第三方应用程序的外部汇率增强内部数据，以计算全球每日销售额
- 使用来自信用评级机构的外部数据增强内部数据，以计算客户的信用评分
数据聚合：根据业务需求对数据进行汇总，以加快查询和检索速度。例如，根据日期、产品和位置汇总数据以获得销售的摘要视图。

ETL和ELT是什么？

在实现数据仓库和数据湖时，有两种广泛采用的数据转换方法：

ETL（提取、转换和加载） ：ETL是从源系统提取数据、执行所需转换，最后将数据加载到数据仓库的过程。这种方法广泛用于基于数据仓库方法构建的架构中。
ELT（提取、加载和转换） ：ELT是从源系统提取数据，将其加载到仓库中，然后使用仓库平台提供的计算能力执行转换。近年来，随着高效和高性能仓库的兴起，ELT方法变得非常流行。

数据策划和服务

在数据处理的最后一步，数据根据业务流程和需求进行策划和服务。数据基于行业标准数据模型加载到策划存储区，使用维度建模等建模方法。这种使用行业特定数据模型安排数据的方法有助于更快、更容易地生成洞察和报告。策划的数据可以用于创建数据产品，供消费者直接使用以满足其业务需求。

数据产品是一个新术语，用于定义专门为消费者策划的可消费最终产品。数据产品通常由负责数据的领域团队创建。这些产品可以与其他领域团队和下游应用程序共享。数据产品可以是表格、视图、报告、仪表板，甚至是机器学习（ML）模型，可以被最终用户轻松发现和消费。

数据消费和交付

平台中的数据消费组件使用户能够访问、分析、查询和消费数据。这些可以是你的BI报告工具或用于预测和预测的ML模型。这些组件支持的各种工作负载包括：

BI工作负载：BI工具帮助创建用于MIS、监管报告和销售分析或每日趋势等用例的报告和仪表板。BI是传统技术（如RDBMS）和基于数据仓库方法构建的架构支持的最早用例之一。
临时/交互式分析：业务用户、数据分析师和数据领导者经常需要进行分析以支持临时需求或回答会议期间出现的即兴问题。使这种交互式、临时分析成为可能的组件提供了简单的SQL接口。
下游应用程序和API：下游应用程序需要一种通用方式与数据平台交互。API提供了灵活性，可以被下游系统用来轻松获取数据。
AI和ML工作负载：AI和ML可以帮助支持多种用例，如预测、预测和推荐。如果你的组织中存在这类用例，那么你的数据平台应该能够提供用于ML生命周期的工具，包括训练、部署和推理模型。

所有这些组件——BI报告工具和ML模型——都支持数据消费和交付给消费者，并在提高平台用户采用方面发挥重要作用。这些组件还为用户提供了与平台内数据交互的界面，因此在设计平台时应考虑用户体验。

通用服务

有些通用服务在数据平台中提供功能，并在使数据易于发现、可用和安全访问方面发挥重要作用。这些通用服务概括如下。

元数据管理：这些工具和技术帮助你摄取、管理和维护生态系统内的元数据。元数据有助于用户轻松发现和访问数据。你可以创建数据目录，以详细组织各种表格、属性、数据类型、长度、键和其他信息。数据目录帮助用户更快、更有效地发现和利用数据。
数据治理和数据安全：实施强有力的数据治理和数据安全政策对于：
- 确保良好的数据质量，以建立消费者对数据的信任
- 满足所有相关法规合规要求
- 查看数据沿袭，以跟踪数据在系统中的流动
- 为所有平台用户实施正确级别的访问控制
- 与内部和外部数据消费者共享数据
- 通过抽象非授权用户来管理敏感数据
- 在数据存储或在数据平台内外移动时保护数据
数据操作：这些服务帮助管理数据生命周期各阶段的各种操作。数据操作使以下活动成为可能：
- 编排数据管道并定义运行过程的时间表
- 自动化测试、集成和部署数据管道
- 管理和观察整个数据生态系统的健康状况
- 现代数据平台采用数据可观测性功能来监控数据的整体健康状况。

数据可观测性是一个新术语，用于理解生态系统内数据的健康状况。这是一个主动识别与数据质量、准确性、新鲜度和完整性相关问题的过程，以避免任何数据停机时间。现代数据平台应该提供数据可观测性功能，主要考虑到大数据量和快速数据摄取和处理，其中任何停机时间都可能严重影响系统。

所有这些核心组件形成了数据平台，使其用户能够执行各种活动。数据架构提供了构建这些数据平台的蓝图和指导原则。通过对数据架构和数据平台及其重要性的基本理解，现在让我们讨论一种新架构模式——湖仓，这是本书的主要主题。

为什么我们需要新的数据架构？

数据仓库和数据湖一直是实现数据平台的最受欢迎的架构。然而，近年来，一些组织努力通过利用不同的架构方法来实现数据平台。

它们寻找新方法而不是实施众所周知的传统数据架构的动机主要有两个：

传统架构作为独立系统实现时存在若干限制。我将在第2章中讨论这些传统架构及其限制。
过去几年技术取得了多项进步。云计算领域的创新和开源技术的成熟是这些进步的主要驱动力。

组织一直在寻求克服传统架构的限制，并利用新技术来构建可扩展、安全和可靠的平台。组织、独立服务提供商（ISV）和系统集成商（SI）尝试了不同且创新的方法来实现更现代的数据平台。这些方法包括：

结合数据湖和数据仓库的两层架构，以支持BI、数据分析和ML用例
利用混合事务/分析处理（HTAP）技术，使用单一存储层统一事务（OLTP）和分析（OLAP）工作负载
构建能够处理非结构化数据以及结构化和半结构化数据的现代云数据仓库
在云对象存储上实施专有存储格式，可以提供类似数据仓库的性能
构建直接在数据湖上执行BI的计算引擎

所有这些努力表明需要一种新的架构模式，该模式可以：

支持实现一个简单、统一的平台，能够处理所有数据格式和多样化的用例，帮助用户轻松消费数据
提供数据仓库的ACID支持、出色的BI性能和访问控制机制
提供数据湖的可扩展性、成本效益和灵活性

这就是湖仓架构在过去几年中出现的新模式。在下一节中我们将详细讨论这一点。

湖仓架构：一种新模式

新的工具、产品和开源技术改变了组织实现数据生态系统的方式。这些新技术帮助简化了复杂的数据架构，从而构建出更加可靠、开放和灵活的数据平台，以支持各种数据和分析工作负载。

湖仓（在本书中称为湖仓或湖仓架构）是一种利用新技术构建简单开放数据平台的新架构模式。如图1-2所示，湖仓的核心是一个数据湖，外加一个事务层和一个高性能计算层。这个额外的事务层使其具有类似数据仓库的ACID属性和其他功能。

注意

这个额外的事务层有时被称为“元数据层”，因为它提供了与事务相关的元数据。为了保持一致性，在整个书中我们将其称为事务层。

湖仓：两全其美

使用湖仓架构构建的数据平台表现出数据仓库和数据湖的特性，因此得名湖仓。图1-3展示了湖仓架构的关键特性，这些特性结合了数据湖和数据仓库的最佳特性。数据湖和数据仓库的特性将在第2章中更详细地讨论，我将在那里解释这些传统架构、它们的特点及其优势。

湖仓如何获得数据湖特性？

像数据湖一样，湖仓使用云对象存储，如Amazon S3、ADLS或GCS，并以开放文件格式存储数据，如Apache Parquet、Apache Avro或Apache ORC。这种云存储使湖仓具备数据湖的所有最佳特性，如高可用性、高持久性、成本效益、可扩展性、对所有数据类型（结构化、半结构化、非结构化）的支持，以及对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的详细视图。

正如我们讨论的，湖仓架构包括存储层和计算层。使用湖仓架构构建的数据平台允许数据和分析工作负载从存储层中读取数据，同时利用计算引擎。

存储层

首先，让我们了解存储层中的技术选项。这个层次由三个组件组成：云存储、开放文件格式和开放表格格式。

云存储

云存储是一种提供高可用性、耐久性和可扩展性服务的解决方案，用于实现数据湖和湖仓平台。主要的云服务提供商提供以下服务来实现湖仓平台：

Amazon Web Services (AWS) 的 Amazon S3
Microsoft Azure 的 ADLS
Google Cloud Platform (GCP) 的 GCS

注意

组织也可以使用本地 HDFS 存储来实现湖仓。仅使用云对象存储来实现湖仓并不是必须的。然而，考虑到低成本、计算与存储的分离以及易于扩展等特点，建议使用云对象存储作为实现湖仓的基础设施。

本书将仅讨论使用云技术实现的现代平台。我们将在第2章中详细了解现代平台。

开放文件格式

数据平台可以将数据以不同的文件格式存储在云存储中。CSV、JSON 和 XML 是最受欢迎的文件格式。对于分析平台，三种最广泛采用的文件格式是 Parquet、ORC 和 Avro。

这些都是开放文件格式，即它们是开源生态系统的一部分。这些格式不是专有的；任何人都可以轻松使用它们来存储数据。任何兼容的处理引擎都可以与这些开放文件格式进行交互。许多其他特性使这三种格式适合分析工作负载。我们将在第3章中更详细地讨论这些文件格式。

开放表格格式

如前所述，开放表格格式为数据湖提供事务能力，使其成为湖仓。这些开放表格格式是湖仓的核心。数据社区中越来越流行的三种格式是：Apache Iceberg、Apache Hudi 和 Linux 基金会的 Delta Lake。

让我们快速了解这三种开放表格格式：

Apache Iceberg
Apache Iceberg 是一种开放表格格式，可与云对象存储和 Parquet、Avro 和 ORC 等开放文件格式配合使用，用于实现湖仓架构。它支持时间旅行、模式演变和 SQL 支持等特性，使湖仓的实现更加快速和简便。
Apache Hudi
Apache Hudi 有助于实现事务性数据湖，并可用于为数据湖引入数据仓库式的功能。它提供 ACID 事务保障、增量处理、时间旅行能力、模式演变和执行特性。
Linux 基金会的 Delta Lake
Delta Lake 最初由 Databricks 作为内部项目启动，现已成为构建湖仓架构的开源存储框架。Delta Lake 提供元数据层和 ACID 能力，还提供时间旅行、模式约束和演变以及审计日志等特性。

注意

目前有两个不同版本的 Delta Lake。商业版本随 Databricks 平台提供。开源版本可在 Linux 基金会网站上获得，您可以在其他非 Databricks 环境中使用它。尽管 Databricks 将所有 Delta Lake 特性都开源了，但最新的开源版本可能不会立即在像 Amazon EMR 或 Azure Synapse Analytics 这样的托管 Apache Spark 服务中提供。您需要等到这些托管云服务提供最新的 Spark 和 Delta Lake 版本，才能利用所有最新的 Delta Lake 特性。

所有这些开放表格格式将在第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 架构实现数据平台所带来的诸多好处。

简化的架构

在 Lakehouse 架构中，所有数据都存储在一个单一的存储层中。由于不再需要单独的数据仓库，也不需要将数据从数据湖移动到数据仓库的额外 ETL 管道，因此数据架构得以简化。Lakehouse 架构还避免了将数据湖和数据仓库集成时可能出现的延迟、失败或数据质量问题。

这种单一存储层的架构有以下几个好处：

不需要额外的努力来同步数据湖和数据仓库之间的数据。同步两种不同存储类型的数据始终是一个挑战。
不需要担心数据湖和数据仓库之间的数据类型变化。这两者的架构常常不匹配，因为数据类型可能不同。
数据治理在 Lakehouse 中变得更容易，因为只需在一个地方实施访问控制。在双层存储系统中，需要维护分别用于访问数据湖和数据仓库的独立访问控制机制，并确保它们始终保持同步。
机器学习工作负载可以直接从 Lakehouse 中读取底层的 Parquet、Avro 或 ORC 存储文件。这消除了在需要机器学习工作负载时从数据仓库复制任何聚合数据的需求。

支持非结构化数据和机器学习用例

如今生产的大量数据是非结构化的。Lakehouse 支持非结构化数据以及结构化和半结构化数据。这为实现 AI 和 ML 用例提供了无限可能，可以利用大量的非结构化数据进行预测、预测、推荐和从数据中获取新见解。

无供应商锁定

如前所述，Lakehouse 使用开放格式来实现数据平台。开放格式使消费者能够使用任何与底层存储格式良好集成的兼容处理引擎来查询和处理数据。Lakehouse 不使用需要特定供应商处理引擎的专有存储格式。这使得下游应用程序可以直接访问数据进行消费。

例如，如果您实现了一个包含数据湖和专用数据仓库的双层数据平台，则必须首先将数据加载到数据仓库中才能执行任何 BI 工作负载。要查询或访问这些数据，必须使用相同数据仓库供应商的专有计算引擎。您必须使用供应商提供的处理能力并支付相应的费用。这导致了供应商锁定，迁移到其他引擎需要相当大的努力。

注意：并非所有开放表格式都与所有开源或商业查询引擎兼容。这是一个不断发展的领域，多个独立软件供应商（ISV）正在开发与各种数据格式交互的连接器。在决定技术堆栈时，应考虑引擎与底层开放表格式的兼容性。

数据共享

由于 Lakehouse 使用开放数据格式，与下游消费者共享数据变得更加容易。不需要在您的平台上接入消费者或与他们共享文件提取物。消费者可以根据数据共享访问权限直接从云存储中访问数据。

数据共享的一个例子是 Delta Sharing 协议，这是 Delta Lake 引入的一种用于安全数据共享的开放标准。图 1-6 显示了 Delta Sharing 协议的简化版本。请注意，实际实现将包含额外的组件，以管理权限并优化性能以仅提供所需的数据。

开放数据共享的关键优势在于数据消费者可以自由使用任何开源处理引擎或商业产品来查询和分析数据。消费者无需使用与数据生产者相同的产品来访问共享数据。另一方面，数据生产者只需分享数据，无需担心消费者将使用哪些处理引擎来访问数据。这一特性为安全数据共享以及协作共享和交换数据的市场实现了多种可能性。

这是一个不断发展的领域，未来可能会有多个供应商和社区引入新的连接器，以直接访问存储在 Lakehouse 中的数据。

可扩展且成本高效

Lakehouse 使用云存储，具有可扩展性且比传统数据仓库便宜得多。Lakehouse 的存储成本由云存储提供商设定。您还可以利用生命周期管理策略以及云供应商提供的冷存储或归档层来优化长期存储成本。

无数据沼泽

许多组织在数据湖中存储了大量数据，但大多数情况下由于缺乏数据可见性而无法有效利用这些数据。

在没有适当的元数据管理、治理、数据溯源跟踪和访问控制的情况下，发现这些大量数据是困难的。没有这些功能，数据湖会变成数据沼泽，利用这些数据变得具有挑战性。Lakehouse 通过提供统一的元数据管理（跨数据和 AI 资产）、数据溯源跟踪等功能，使平台的消费者可以轻松发现数据。

注意：数据沼泽是指存储了大量数据但没有适当组织或结构的数据湖。存储在这种数据湖中的数据治理不足，元数据没有组织成目录形式，使得数据发现极具挑战性，降低了消费者对数据的整体可见性。简而言之，由于缺乏强大的元数据和治理流程，数据沼泽中的数据无法用于业务需求。

模式强制和演变

Lakehouse 架构中使用的技术支持强制模式验证，以避免存储数据时的模式不匹配。这些技术还支持模式演变，使用不同的方法来帮助接受源模式的变化。这些功能使系统更灵活，具有更好的数据质量和完整性。我们简要讨论一下这两个功能的好处。

模式强制

模式强制确保存储在 Lakehouse 中的数据遵循该表的元数据定义的模式。ETL 过程会拒绝任何额外的属性或不匹配的数据类型。这些验证有助于存储正确的数据，从而提高整体数据质量。例如，如果字符串值出现在模式中定义为整数的属性中，它将被拒绝。

模式演变

虽然模式强制通过实施严格的验证提高了数据质量，但模式演变通过在存储数据时提供更多灵活性来支持放宽这些验证。任何未在表元数据中定义的额外属性都可以通过模式演变存储。根据开放表格式，存在各种方法来存储额外属性。此功能有助于保留新属性或数据类型不匹配，而不会拒绝它们。这种方法的主要好处是您不会丢失任何数据，并且可以即时适应变化。

虽然模式强制通过对特定属性实施严格规则来提高数据质量，但模式演变提供了灵活性，以适应源系统中的元数据变化。您可以在实现 Lakehouse 时同时使用这两者，以保持数据质量并适应任何源元数据变化。

统一的平台，用于 ETL/ELT、BI、AI/ML 和实时工作负载

如前所述，Lakehouse 架构使您能够实现一个统一的数据平台，以支持多种工作负载。让我们详细讨论这些工作负载以及使用 Lakehouse 实现它们的好处。

ETL/ELT 工作负载

为了实现 ETL 工作负载，您可以使用 Spark 等流行的处理引擎在将数据存储到 Lakehouse 存储层的较高级别区域之前执行转换。您还可以实施 ELT 工作负载，使用任何计算引擎通过 SQL 查询执行转换。更熟悉 SQL 的数据从业者更喜欢执行基于 SQL 的 ELT 操作来转换数据。

BI 工作负载

由于性能与数据仓库相当，您可以使用 Lakehouse 实现 BI 工作负载。由于 Lakehouse 为数据湖提供了事务层，更新和删除等操作比在数据湖中执行更快。

AI/ML 工作负载

由于 Lakehouse 支持结构化数据、半结构化数据和非结构化数据，您可以通过直接访问 Lakehouse 中的数据来执行 AI/ML 用例。

实时工作负载

统一的 Lakehouse 架构支持多种工作负载，包括实时处理。在过去几年中，由于物联网设备、可穿戴设备和点击流生成的实时数据的增加，组织试图实现支持实时工作负载的平台。早期的数据架构，如 Lambda 架构，使用不同的处理流支持实时工作负载。Lakehouse 使用统一架构支持实时工作负载，支持使用相同代码库执行批处理或实时作业。

注意：Lambda 架构是一种传统方法，用于处理以不同频率摄取的大量数据。Lambda 架构有两个不同的层，用于处理批处理数据和流数据。这些层的批处理和流数据组件也是独立的，基于延迟和相关 SLA 等因素。这导致了复杂的数据架构，需要额外的努力来维护不同层的不同代码库。

时间旅行

Lakehouse 中的事务层使其能够维护各种数据版本。这有助于它执行时间旅行，以查询和获取已更新或删除的旧数据。让我们通过一个例子来了解时间旅行功能。表 1-1 显示了一个包含三列的产品表。

product_id	product_name	product_category
22	keyboard	computer accessory
12	mouse	computer accessory
71	headphone	computer accessory
11	mobile case	mobile accessory

考虑一种情况，其中 product_id 为 71 的第三行已更新，将类别从“computer accessory”更改为“mobile accessory”。表 1-2 显示了更新后的表。

product_id	product_name	product_category
22	keyboard	computer accessory
12	mouse	computer accessory
71	headphone	mobile accessory
11	mobile case	mobile accessory

现在，如果您查询产品表，您将能够看到更新后的数据，但更新记录的旧 product_category 值将不可见。

如果您使用 Iceberg、Hudi 或 Delta Lake 等开放表格式，只需使用较早的版本号或旧时间戳查询表，即可看到以前的记录。

基于版本检索旧数据

您可以使用版本号检索记录的旧状态：

SELECT * FROM product AS OF VERSION <older version number>

基于时间戳检索旧数据

您可以使用较早的时间戳检索记录的旧状态：

SELECT * FROM product AS OF <older timestamp>

注意：确切的 SQL 命令将根据用于实现 Lakehouse 的开放表格式和计算引擎而有所不同。

这种时间旅行操作在传统的数据仓库或数据湖中是不可行的。一些 NoSQL 数据库（如 HBase）和现代云仓库存储所有版本的数据，但传统仓库缺乏此功能。

这些优势使得所有数据用户能够比早期数据架构更快、更有效地访问、管理、控制、分析和利用数据。

鉴于这些优势，Lakehouse 架构很快可能成为实现数据平台的默认选择，并可能像数据仓库和数据湖一样被广泛采用。先进技术、不断增长的社区以及多个 ISV 正在开发基于 Lakehouse 的产品，表明对 Lakehouse 架构的需求和普及程度在不断上升。

关键要点

如果您是第一次了解 Lakehouse 架构，我理解这些信息在第一次阅读时可能难以消化。我将总结本章讨论的关键点，以帮助您在阅读本书后续章节时记住最重要的概念。

理解数据架构

数据架构是任何数据平台的基础。它定义了核心组件及其相互依赖关系。它提供了构建数据平台的蓝图，并帮助建立设计系统的指导原则。
数据平台的核心组件包括源系统、数据摄取、数据存储、数据处理和转换、数据消费和交付，以及元数据管理、数据治理和数据安全、数据操作等公共服务。
设计数据架构是建立数据基础设施的最关键步骤之一。您应尽一切努力设计一个可扩展、灵活、可靠且最重要的是简单的平台。这将加快用户的采用速度。

Lakehouse 架构特征

Lakehouse 架构是过去几年出现的一种新的架构模式。它结合了数据仓库和数据湖的最佳特性。
Lakehouse 架构将数据存储在云存储中，并添加了事务层，使其具备类似数据仓库的能力。
您可以获得数据湖的可扩展性、灵活性和成本效益，以及数据仓库的性能、ACID 合规性和更好的数据治理。
Lakehouse 架构只有一个存储层，没有单独的仓库存储。它采用解耦架构，计算和存储层是独立的，并且可以独立扩展。
它支持存储和管理所有数据类型，包括结构化数据、半结构化数据和非结构化数据。它还支持多种工作负载，如 ETL、流处理、BI 和 AI/ML。

Lakehouse 架构的优势

Lakehouse 架构帮助您实现一个简单、统一的数据平台，以实现多种数据和分析用例。
Lakehouse 使用开放技术进行存储；您无需担心供应商锁定问题。您可以使用任何兼容的计算引擎通过直接访问云对象存储中的数据来查询数据。
无论技术或产品如何，与数据消费者共享数据变得更容易，无需复制数据或发送文件提取物。
Lakehouse 通过模式强制、模式演变、时间旅行等功能，帮助您更高效地管理和控制数据。

在继续阅读本书时，您将深入了解更多高级主题，以理解如何设计和实现实际的 Lakehouse 架构，并看到它们相对于传统架构（如数据仓库和数据湖或组合的双层系统）的优势。但对于新接触数据领域的读者，我们首先需要更好地了解这些传统架构、它们的优点和局限性，以便更好地理解 Lakehouse 架构的优势。我将在下一章中讨论这些内容。