《Delta Lake Up & Running》第一章：数据架构的演进

作为一名数据工程师，您希望构建大规模的数据、机器学习、数据科学和人工智能解决方案，以提供最先进的性能。您通过摄取大量源数据，然后进行清洗、规范化和数据合并，最终通过易于使用的数据模型将这些数据呈现给下游应用程序。

随着您需要摄取和处理的数据量不断增加，您需要具备横向扩展存储的能力。此外，您需要动态扩展计算资源，以应对处理和消费的高峰。由于您将数据源合并到一个数据模型中，您不仅需要将数据追加到表中，还经常需要根据复杂的业务逻辑插入、更新或删除（即MERGE或UPSERT）记录。您希望能够在具有事务性保证的情况下执行这些操作，而无需不断重写大数据文件。

过去，上述一系列要求由两套不同的工具集解决。云端数据湖提供了水平可扩展性和存储与计算的解耦，而关系型数据仓库提供了事务性保证。然而，传统数据仓库将存储和计算紧密耦合到本地设备上，并不具备与数据湖相关的横向扩展性。

Delta Lake将具有事务性可靠性以及支持UPSERT和MERGE操作的功能引入了数据湖，同时保持了数据湖的动态水平可扩展性和存储与计算的分离。Delta Lake是构建数据湖仓库的解决方案之一，它是一种开放数据架构，结合了数据仓库和数据湖的优点。

在本介绍中，我们将简要了解关系型数据库以及它们是如何演变为数据仓库的。接下来，我们将研究数据湖出现背后的关键驱动因素。我们将讨论每种架构的优点和缺点，最后展示Delta Lake存储层如何结合每种架构的优点，从而实现数据湖仓库解决方案的创建。

关系数据库的简要历史

在他1970年的历史性论文中，E.F. Codd引入了将数据视为逻辑关系的概念，独立于物理数据存储。这种数据实体之间的逻辑关系被称为数据库模型或架构。Codd的著作导致了关系数据库的诞生。第一个关系数据库系统是在20世纪70年代中期由IBM和UBC引入的。

在20世纪80年代和90年代，关系数据库及其底层的SQL语言成为企业应用的标准存储技术。其中一个主要原因是关系数据库提供了一个称为"事务"的概念。数据库事务是对数据库执行的一系列操作，满足四个属性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），通常用它们的首字母缩写ACID表示。

原子性确保对数据库的所有更改作为单个操作执行。这意味着只有在所有更改都成功执行时，事务才会成功。例如，当在线银行系统用于从储蓄账户转账到支票账户时，原子性属性将保证操作仅在从储蓄账户中扣除资金并加入到支票账户时才会成功。整个操作要么成功，要么作为一个完整的单元失败。

一致性属性保证数据库在事务开始时从一个一致状态过渡到事务结束时的另一个一致状态。在我们之前的例子中，只有储蓄账户有足够的资金时，资金转移才会发生。否则，事务将失败，余额将保持在其原始一致状态。

隔离性确保数据库中同时进行的操作不会互相影响。这个属性确保当多个事务同时执行时，它们的操作不会相互干扰。

持久性指的是已提交事务的持久性。它保证一旦事务成功完成，即使在系统故障的情况下，也会产生永久状态。在我们的资金转移示例中，持久性将确保对我的储蓄和支票账户所做的更新是持久的，并可以在可能的系统故障情况下存活。

数据库系统在20世纪90年代继续成熟发展，而20世纪90年代中期互联网的出现导致数据爆炸性增长和数据存储的需求。企业应用程序非常有效地使用了关系数据库管理系统（RDBMS）技术。旗舰产品如SAP和Salesforce会收集和维护大量数据。

然而，这一发展也伴随着一些缺点。企业应用程序会以它们自己的专有格式存储数据，导致数据孤立的出现。这些数据孤立由一个部门或业务单位拥有和控制。随着时间的推移，组织认识到需要跨不同的数据孤立开发企业视图，从而导致数据仓库的兴起。

数据仓库

虽然每个企业应用程序都内置了某种类型的报告功能，但由于缺乏全面的组织视图，一些商机被忽视了。与此同时，组织们认识到分析长时间段内的数据的价值。此外，他们希望能够在多个交叉主题上对数据进行切分和分析，如客户、产品和其他业务实体等。

这导致了数据仓库的引入，它是来自多个数据源的集成历史数据的中央关系库，提供了企业的单一集成历史视图，使用统一的架构，覆盖了企业的各个方面。

数据仓库架构

典型数据仓库架构的简单示意图如图1-1所示。

当我们看图1-1中的图表时，我们从左侧的数据源层开始。组织需要从一组异构数据源中获取数据。虽然来自组织的企业资源规划（ERP）系统构成了组织模型的主干，但我们需要用日常运营的操作系统（如人力资源（HR）系统和工作流管理软件）的数据来补充这些数据。此外，组织可能希望利用其客户关系管理（CRM）和销售点（POS）系统涵盖的客户互动数据。除了这里列出的核心数据源外，还需要从各种外部数据源摄取数据，以各种格式，如电子表格、CSV文件等。

这些不同的源系统可能具有各自的数据格式。因此，数据仓库包含一个分级区域，用于将来自不同源的数据合并为一个通用格式。为了做到这一点，系统必须摄取来自原始数据源的数据。实际的摄取过程因数据源类型而异。一些系统允许直接访问数据库，而其他系统允许通过API摄取数据，而许多数据源仍依赖文件提取。

接下来，数据仓库需要将数据转换为标准化格式，以便下游流程轻松访问数据。最后，转换后的数据加载到分级区域。在关系型数据仓库中，这个分级区域通常是一组没有主键或外键或简单数据类型的扁平关系分级表。

这个从提取数据、转换成标准格式、加载到数据仓库的过程通常被称为ETL（提取、转换和加载）。ETL工具可以在最终加载数据到数据仓库之前对摄取的数据执行多项任务。这些任务包括消除重复记录。由于数据仓库将是唯一的真实数据源，我们不希望它包含相同数据的多个副本。此外，重复记录会阻止生成每个记录的唯一键。

ETL工具还允许我们将数据从多个数据源合并。例如，我们的客户的一个视图可能在CRM系统中捕获，而其他属性在ERP系统中找到。组织需要将这些不同方面合并成一个客户的全面视图。这是我们开始向数据仓库引入模式的地方。在我们的客户示例中，模式将定义客户表的不同列，每个列需要哪些列，每个列的数据类型和约束等等。

拥有规范化的列表示，如日期和时间，是重要的。ETL工具可以确保数据仓库中的所有时间列都使用相同的标准进行格式化。

最后，组织希望按照其数据管理标准对数据进行质量检查。这可能包括删除不符合最低标准的低质量数据行。

数据仓库在一个单块物理架构上进行物理实施，由一个单一的大节点组成，结合了内存、计算和存储。这种单块架构迫使组织在垂直方向上扩展其基础架构，导致昂贵的、通常超维度的基础架构，为峰值用户负载而配置，同时在其他时间接近空闲。

数据仓库通常包含以下分类的数据：

• 元数据：关于数据的上下文信息。这些数据通常存储在数据目录中。它使数据分析师能够描述、分类和轻松定位存储在数据仓库中的数据。
• 原始数据：以原始格式维护，没有经过任何处理。访问原始数据使数据仓库系统能够在负载失败的情况下重新处理数据。
• 摘要数据：由底层数据管理系统自动创建。随着新数据加载到数据仓库中，摘要数据将自动更新。它包含跨多个符合维度的聚合。摘要数据的主要目的是加速查询性能。

数据仓库中的数据在呈现层中被消耗。这是消费者可以与数据仓库中存储的数据互动的地方。我们可以广泛地识别出两大消费者群体：

• 人类消费者：这是组织内需要使用数据的人员。这些消费者可以是需要访问数据作为其工作的重要部分的知识工作者，也可以是通常使用高度摘要数据的高管，通常以仪表板和关键绩效指标（KPI）的形式使用数据。
• 内部或外部系统：数据仓库中的数据可以被各种内部或外部系统消耗。这可以包括机器学习和人工智能工具集，或需要使用仓库数据的内部应用程序。一些系统可以直接访问数据，而其他系统可以使用数据提取，还有一些系统可能以发布-订阅模式直接消耗数据。

人类消费者将利用各种分析工具和技术来从数据中获得可操作的见解，包括：

• 报告工具：这些工具使用户通过诸如表格报告和各种图形表示等可视化手段开发对数据的见解。
• 联机分析处理（OLAP）工具：消费者需要以各种方式切分和分析数据。OLAP工具以多维格式呈现数据，允许从多个角度查询数据。它们利用预存的聚合数据，通常存储在内存中，以提供高性能的数据。
• 数据挖掘：这些工具允许数据分析师通过数学相关性和分类来发现数据中的模式。它们协助分析师识别不同数据源之间以前隐藏的关系。从某种意义上说，数据挖掘工具可以看作是现代数据科学工具的前身。

维度建模

数据仓库引入了跨企业各个主题领域的综合数据模型的需求。用于创建这些模型的技术被称为维度建模。

在类似Bill Inmon和Ralph Kimball等先知的著作和思想的推动下，维度建模首次在Kimball的重要著作《数据仓库工具包：维度建模完全指南》中引入。Kimball定义了一种方法论，侧重于自下而上的方法，确保团队尽快为数据仓库提供真正的价值。

维度模型由星型模式（Star Schema）描述。星型模式将特定业务流程的数据（例如销售）组织成一种有利于进行轻松分析的结构。它由两种类型的表组成：

• 事实表，它是模式的主要或中心表。事实表捕获业务流程的主要测量、指标或"事实"。以销售业务流程为例，销售事实表将包括销售数量和销售金额。 事实表具有明确定义的粒度。粒度是由表中所表示的维度（列）的组合决定的。如果销售事实表只是销售的年度总结，那么它的粒度就很低；如果它包括日期、商店和客户标识的销售，那么它的粒度就很高。
• 与事实表相关的多维表。维度提供了所选业务流程周围的上下文。以销售场景为例，维度列表可以包括产品、客户、销售人员和商店。

维度表"包围"着事实表，这就是为什么这些类型的模式被称为"星型模式"的原因。星型模式由事实表组成，通过主键和外键关系与其关联的维度表相连。我们的销售主题领域的星型模式如图1-2所示。

数据仓库的益处和挑战

数据仓库具有固有的优势，为业务社区提供了良好的服务。它们以常见的格式提供来自不同数据源的高质量、清洁和标准化数据。由于来自不同部门的数据以常见格式呈现，因此每个部门都会按照其他部门的结果进行审查。拥有及时准确的数据是做出强有力的业务决策的基础。

由于它们存储大量的历史数据，它们允许历史洞察，使用户能够分析不同时期和趋势。

数据仓库往往非常可靠，基于底层的关系数据库技术，执行ACID事务。

数据仓库采用标准的星型模式建模技术，创建事实表和维度。越来越多的预建模板模型适用于各种主题领域，如销售和CRM，进一步加速了这些模型的发展。

数据仓库非常适用于商业智能和报告，基本上是在数据成熟度曲线上回答"发生了什么？"问题。数据仓库结合商业智能（BI）工具可以为营销、财务、运营和销售生成可行的见解。

互联网和社交媒体的快速崛起以及智能手机等多媒体设备的可用性打破了传统的数据景观，引发了"大数据"这一术语。大数据被定义为数据的体积不断增加，速度更快，格式更多样，准确性更高。这些被称为数据的四个"V"：

• 体积：全球创造、捕获、复制和消费的数据体积迅速增加。根据Statista的描述，未来两年，全球数据的创建预计将增长到超过200泽字节（1泽字节等于2的70次方字节）。
• 速度：在今天的现代商业环境中，及时决策至关重要。为了做出这些决策，组织需要信息能够快速流动，最好是尽可能接近实时。例如，股票交易应用程序需要访问接近实时的数据，以便高级交易算法可以做出毫秒级决策，并将这些决策传达给利益相关者。获得及时数据可以使组织获得竞争优势。
• 多样性：多样性指现在可用的不同"类型"数据的数量。传统的数据类型都是结构化的，通常以关系数据库或其提取形式提供。随着大数据的兴起，数据现在以新的非结构化类型到达。非结构化和半结构化的数据类型，如物联网（IoT）设备消息、文本、音频和视频，需要额外的预处理来提取业务意义。多样性还通过不同类型的摄取方式表达。一些数据源最适合批处理模式，而其他数据源适用于增量摄取，或实时的、基于事件的摄取，如IoT数据流。
• 准确性：准确性定义了数据的可信度。在这里，我们希望确保数据准确且质量高。数据可以从多个来源摄取；重要的是了解数据的责任链，确保我们拥有丰富的元数据，并了解数据采集的上下文。此外，我们希望确保我们对数据的视图是完整的，没有缺失的组成部分或迟到的事实。

传统数据仓库的架构难以解决这四个"V"。

传统数据仓库架构在处理指数增长的数据量方面面临困难。它们既存在存储问题，也存在可伸缩性问题。随着数据量达到了百千字节级别，要在不花费大量资金的情况下扩展存储能力变得具有挑战性。传统数据仓库架构不使用内存和并行处理技术，从而阻止它们在垂直方向上扩展数据仓库。 数据仓库架构也不适合处理大数据的速度。数据仓库不支持支持接近实时数据的所需流式架构类型。ETL数据加载窗口只能缩短到一定程度，直到基础架构开始崩溃。

虽然数据仓库非常擅长存储结构化数据，但不适合存储和查询半结构化或非结构化数据的多样性。 数据仓库没有内置支持跟踪数据的可信度。数据仓库元数据主要侧重于模式，而较少关注血统、数据质量和其他准确性变量。 此外，数据仓库基于封闭的专有格式，通常只支持基于SQL的查询工具。由于其专有格式，数据仓库不提供很好的支持数据科学和机器学习工具。 由于这些限制，建立数据仓库成本高昂。

因此，项目往往在上线之前就失败了，而那些上线的项目在跟上现代商业环境和四个"V"的不断变化要求方面面临困难。 传统数据仓库架构的限制催生了一种更现代的架构，基于数据湖（data lake）的概念。

介绍数据湖

数据湖是一个成本效益的中央存储库，用于以文件和二进制大对象（blobs）的形式存储任何规模的结构化、半结构化或非结构化数据。术语"数据湖"来自于与真实的河流或湖泊的类比，它保存着水，或在这种情况下是数据，具有几条支流，实时将水（也就是"数据"）流入湖中。一个典型数据湖的标准表示如图1-3所示。

最初的数据湖和大数据解决方案是建立在本地集群上的，基于Apache Hadoop开源框架。Hadoop用于高效地存储和处理各种大小的数据集，从几千兆字节到几百千字节不等。Hadoop不使用一台大型计算机来存储和处理数据，而是利用多个普通计算节点的集群，以更快的速度并行分析大量数据集。

Hadoop会利用MapReduce框架来并行化多个计算节点上的计算任务。Hadoop分布式文件系统（HDFS）是一种设计用于标准或低端硬件的文件系统。HDFS非常容忍故障，支持大型数据集。

从2015年开始，云数据湖（如Amazon Simple Storage Service（Amazon S3），Azure Data Lake Storage Gen 2（ADLS）和Google Cloud Storage（GCS））开始取代HDFS。这些基于云的存储系统具有卓越的服务级别协议（SLA）（通常大于10个九），提供地理复制，最重要的是提供极低的成本，以及利用更低成本的冷存储进行存档的选项。

在数据湖中，存储的最低级别是数据块。数据块天生是非结构化的，可以存储半结构化和非结构化数据，如大型音频和视频文件。在更高的层次上，云存储系统在数据块存储之上提供了文件语义和文件级安全性，从而可以存储高度结构化的数据。由于其高带宽的入口和出口通道，数据湖还可以支持流式使用案例，如持续摄取大量IoT数据或流媒体。

计算引擎使大量数据可以以类似ETL的方式进行处理，并交付给消费者，如传统数据仓库和机器学习和人工智能工具集。流式数据可以存储在实时数据库中，可以使用传统的BI和报告工具创建报告。

数据湖通过一系列组件实现：

• 存储：数据湖需要非常大、可扩展的存储系统，通常在云环境中提供。存储需要具有耐用性和可扩展性，并应该支持与各种第三方工具、库和驱动程序的互操作性。请注意，数据湖将存储和计算的概念分开，允许二者独立扩展。存储和计算的独立扩展允许按需、弹性地微调资源，使解决方案架构更加灵活。存储系统的入口和出口通道应支持高带宽，以便摄取或消耗大批量数据，或连续流入大量流媒体数据（如IoT和流媒体）。
• 计算：处理存储层中存储的大量数据需要大量计算能力。不同云平台上提供了几种计算引擎。数据湖的首选计算引擎是Apache Spark。Spark是一个开源的统一分析引擎，可以通过各种解决方案（如Databricks或其他云提供商开发的解决方案）部署。大数据计算引擎将利用计算集群。计算集群汇集计算节点以处理完整的数据收集和处理任务。
• 格式：数据在磁盘上的形状定义了格式。提供了各种存储格式。数据湖主要使用标准的开源格式，如Parquet、Avro JSON或CSV。
• 元数据：现代的基于云的存储系统维护元数据（即关于数据的上下文信息）。这包括描述数据何时被写入或访问的各种时间戳、数据模式以及包含有关数据的使用和所有者信息的各种标签。

数据湖具有一些非常强大的优势。数据湖架构使组织的数据资产能够整合到一个中央位置。数据湖是格式不可知的，依赖于Parquet和Avro等开源格式。这些格式被各种工具、驱动程序和库充分理解，从而实现平滑的互操作性。

数据湖部署在成熟的云存储子系统上，可以受益于这些系统的可扩展性、监控、部署便捷性和低存储成本。自动化的DevOps工具，如Terraform，具有成熟的驱动程序，实现了自动部署和维护。

与数据仓库不同，数据湖支持所有数据类型，包括半结构化和非结构化数据，从而实现了媒体处理等工作负载。由于其高吞吐量的入口通道，它非常适合流式使用案例，如摄取IoT传感器数据、媒体流和Web点击流。

然而，随着数据湖变得越来越流行和广泛使用，组织开始认识到传统数据湖存在一些挑战。虽然底层的云存储相对廉价，但构建和维护有效的数据湖需要专业技能，从而导致高端员工成本或增加的咨询服务成本。

虽然很容易摄取原始数据，但将数据转化为能够提供业务价值的形式可能非常昂贵。传统数据湖具有较差的查询性能，因此无法用于交互式查询。因此，组织的数据团队仍然需要将数据转化并加载到类似数据仓库的系统中，从而延长了价值实现的时间。这导致了数据湖+仓库架构。这种架构在相当长的一段时间内一直占主导地位（我们个人实施了几十种这类系统），但现在因为湖仓架构的崛起而有所下降。

数据湖通常使用"按读取时的模式"策略，其中数据可以以任何格式摄取，而不需要强制执行模式。只有在读取数据时才能应用某种类型的模式。这种模式强制执行的缺乏可能会导致数据质量问题，从而使原始的数据湖变成"数据沼泽"。

数据湖不提供任何形式的事务性保证。数据文件只能追加，这会导致以高昂的成本重写先前编写的数据以进行简单的更新。这会导致"小文件问题"，即为单个实体创建多个小文件。如果这个问题管理不当，这些小文件会减慢整个数据湖的读取性能，导致数据过时和存储浪费。数据湖管理员需要运行重复的操作，以将这些较小的文件合并到针对高效读取操作进行了优化的较大文件中。

现在我们已经讨论了数据仓库和数据湖的优势和劣势，接下来我们将介绍数据湖仓（Lakehouse），它结合了两种技术的优势并解决了它们的弱点。

数据湖仓

Armbrust、Ghodsi、Xin 和 Zaharia在2021年首次提出了数据湖仓（data lakehouse）的概念。这些作者将湖仓定义为"一种基于低成本和直接可访问存储的数据管理系统，还提供了像ACID事务、数据版本控制、审计、索引、缓存和查询优化等性能特征的分析数据库管理系统（DBMS）管理。"

当我们解读这个陈述时，我们可以将湖仓定义为一种系统，它将数据湖的灵活性、低成本和可扩展性与数据仓库的数据管理和ACID事务相结合，解决了两者的限制。与数据湖类似，湖仓架构利用低成本的云存储系统，同时具有这些系统固有的灵活性和水平可扩展性。湖仓的目标是使用现有的高性能数据格式，如Parquet，同时支持ACID事务（和其他功能）。为了添加这些功能，湖仓使用了一种开放表格格式，其中包括ACID事务、记录级操作、索引和关键元数据等功能，以增强现有数据格式。这使得存储在低成本存储系统上的数据资产具有了过去只有关系数据库管理系统（RDBMS）领域才具备的可靠性。Delta Lake是支持这些功能的开放表格格式的一个示例。

湖仓特别适用于大多数云环境，如果不是所有，都具有独立的计算和存储资源。不同的计算应用程序可以按需在完全独立的计算节点上运行，比如Spark集群，同时直接访问相同的存储数据。然而，理论上也可以在本地存储系统上实现湖仓，比如前面提到的HDFS。

数据湖仓的好处

湖仓架构的概览如图1-4所示。

有了湖仓架构，我们不再需要在数据湖和某种数据仓库存储中都保存一份数据副本。事实上，我们可以通过Delta Lake存储格式和协议从数据湖中获取数据，其性能可与传统数据仓库相媲美。

由于我们可以继续利用低成本的基于云的存储技术，而无需将数据从数据湖复制到数据仓库，因此我们可以实现大幅降低基础设施、员工和咨询开销的成本节省。

由于数据移动较少，ETL过程得以简化，数据质量问题的机会显著减少，最后，由于湖仓结合了存储大数据量和精细的维度模型的能力，开发周期缩短，价值实现时间大幅缩短。

从数据仓库到数据湖再到湖仓架构的演变如图1-5所示。

实施湖仓架构

正如我们前面提到的，湖仓架构利用低成本的对象存储，比如Amazon S3、ADLS或GCS，将数据存储在开源表格式中，比如Apache Parquet。然而，由于湖仓实施需要对这些数据运行ACID事务，我们需要在云存储之上构建一个事务性元数据层，定义哪些对象属于表版本。

这将允许湖仓实施功能，比如ACID事务和版本控制，在元数据层内，同时保持大部分数据存储在低成本的对象存储中。湖仓客户端可以继续使用他们已经熟悉的开源格式的数据。

接下来，我们需要解决系统性能的问题。正如我们前面提到的，湖仓实施需要实现出色的SQL性能才能有效。数据仓库非常擅长优化性能，因为它们使用封闭的存储格式和众所周知的模式。这使它们能够维护统计信息、构建聚簇索引、将热点数据移到快速的SSD设备上等。

在湖仓中，基于开源标准格式，我们没有这种奢侈，因为我们不能更改存储格式。然而，湖仓可以利用众多其他优化，而不改变数据文件。这包括缓存、辅助数据结构，如索引和统计信息，以及数据布局优化。

加速分析工作负载的最后一个工具是开发标准的DataFrame API。许多流行的机器学习工具，比如TensorFlow和Spark MLlib，都支持DataFrames。DataFrames最早由R和pandas引入，提供了对数据的简单表抽象，具有多种变换操作，大多数源自关系代数。

在Spark中，DataFrame API是声明性的，使用惰性评估来构建执行DAG（有向无环图）。在DataFrame消耗底层数据之前，可以优化此图。这为湖仓提供了许多新的优化特性，比如缓存和辅助数据。图1-6展示了这些要求如何适应湖仓系统设计的整体框架。

由于Delta Lake是本书的重点，我们将说明Delta Lake如何满足实施湖仓的要求。

Delta Lake

正如前一节中提到的，一个潜在的湖仓解决方案可以构建在Delta Lake之上。Delta Lake是一种开放表格式，将元数据、缓存和索引与数据湖存储格式相结合。这些功能共同提供了一种抽象级别，以提供ACID事务和其他管理功能。

Delta Lake的开放表格式和开源元数据层最终实现了湖仓的实施。Delta Lake提供ACID事务、可扩展的元数据处理、跨批处理和流式处理的统一过程模型、完整的审计历史记录以及对SQL数据操作语言（DML）语句的支持。它可以运行在现有的数据湖上，并与多个处理引擎完全兼容，包括Apache Spark。

Delta Lake是一个开源框架，其规范可以在delta.io上找到。Armbrust等人的工作详细描述了Delta Lake如何提供ACID事务。

Delta Lake提供以下功能：

• 事务性ACID保证

Delta Lake将确保所有使用Spark或任何其他处理引擎的数据湖事务都以原子方式提交以确保持久性，并对其他读取器公开。这是通过Delta事务日志实现的。在第2章中，我们将详细介绍事务日志。

• 完整的DML支持

传统的数据湖不支持对数据的事务性、原子更新。Delta Lake完全支持所有DML操作，包括删除和更新，以及复杂的数据合并或更新场景。这种支持大大简化了构建现代数据仓库（MDW）时维度和事实表的创建。

• 审计历史

Delta Lake事务日志记录了对数据所做的每一项更改，按照更改的顺序记录。因此，事务日志成为对数据所做的任何更改的完整审计跟踪。这使管理员和开发人员可以在意外删除和编辑后回滚到数据的早期版本。这个功能被称为时间旅行，将在第6章中详细介绍。

• 批处理和流处理的统一处理模型

Delta Lake可以处理批处理和流处理的接收或源。它可以对数据流执行MERGE操作，这是在将IoT数据与设备参考数据合并时的常见要求。它还支持从外部数据源接收CDC数据的用例。我们将在第8章中详细介绍流处理。

• 模式强制和演进

Delta Lake在从湖中写入或读取数据时强制执行模式。然而，当为数据实体明确启用时，它允许安全的模式演进，从而支持数据需要演进的用例。模式强制和演进将在第7章中介绍。

• 丰富的元数据支持和可伸缩性

拥有支持大容量数据的能力是很重要的，但如果元数据不能相应扩展，解决方案将会受到限制。Delta Lake通过利用Spark或其他计算引擎来扩展所有元数据处理操作，使其能够有效处理PB级数据的元数据。

湖仓架构由三个层组成，如图1-7所示。湖仓存储层建立在标准的云存储技术上，如ADLS、GCS或Amazon S3存储。这为湖仓提供了高度可扩展且低成本的存储层。

湖仓的事务层由Delta Lake提供。这为湖仓带来了ACID保证，使原始数据能够高效地转化为经过精心策划的可操作数据。除了ACID支持，Delta Lake还提供了一套丰富的附加功能，如DML支持、可扩展的元数据处理、流式支持以及丰富的审计日志。湖仓堆栈的顶层由高性能的查询和处理引擎组成，这些引擎利用底层的云计算资源。支持的查询引擎包括：

• Apache Spark
• Apache Hive
• Presto
• Trino 请查阅Delta Lake网站以获取支持的计算引擎的完整列表。

Medallion架构

图1-8提供了一个基于Delta Lake的Lakehouse架构的示例。这种具有Bronze、Silver和Gold层的架构模式通常被称为Medallion架构。尽管这只是众多Lakehouse架构模式之一，但它非常适合现代数据仓库、数据集市和其他分析解决方案。

在这个解决方案中，最高层次我们有三个组件。在左侧，我们有不同的数据源。数据源可以采用多种形式，这里提供了一些示例：

• 存储在外部数据湖上的一组CSV或TXT文件
• 本地数据库，如Oracle或SQL Server
• 流数据源，如Kafka或Azure Event Hubs
• 来自SAS服务的REST API，如Salesforce或ADP

中央组件实施了Medallion架构。Medallion架构是一种数据设计模式，用于通过Bronze、Silver和Gold层在Lakehouse中逻辑组织数据。Bronze层是我们从左侧的源系统中摄取的数据着陆的地方。Bronze区域的数据通常是按原样着陆的，但可以附加其他元数据，如加载日期和时间、处理标识等。

在Silver层，来自Bronze层的数据被清洗、规范化、合并和标准化。这是企业数据在不同主题领域之间逐渐汇集的地方。

Gold层中的数据是"可用于消费的"数据。这些数据可以采用经典的星型模式格式，包含维度和事实表，或者可以采用适合于使用案例的任何数据模型。

Medallion架构的目标是在数据通过架构的每个层次流动时，逐步提高数据的结构和质量，每个层次都具有固有的目的。这个数据设计模式将在第10章中更详细地介绍，但重要的是要理解Lakehouse与Delta Lake一起如何支持可靠的、高性能的数据设计模式或多跳架构。像Medallion架构这样的设计模式为统一Lakehouse中的数据流水线提供了一些架构基础，以支持多个用例（如批量数据、流数据和机器学习）。

Delta生态

正如我们在本章中所介绍的，Delta Lake使我们能够构建数据湖仓库架构，从而能够直接在数据湖上托管数据仓库和机器学习/人工智能应用。目前，Delta Lake是最广泛使用的湖仓库格式，已被超过7,000个组织使用，每天处理的数据达到艾克赫。

然而，数据仓库和机器学习应用程序并不是Delta Lake的唯一应用目标。除了其核心事务性ACID支持，为数据湖带来可靠性之外，Delta Lake还使我们能够无缝地摄取和消费流数据和批处理数据，所有这些都可以在一个解决方案架构中完成。

Delta Lake的另一个重要组件是Delta Sharing，它使公司能够以安全的方式共享数据集。Delta Lake 3.0现在支持独立的读取器和写入器，使任何客户端（如Python、Ruby或Rust）都可以直接将数据写入Delta Lake，而无需任何大数据引擎，如Spark或Flink。Delta Lake附带了一组扩展的开源连接器，包括Presto、Flink和Trino。Delta Lake存储层现在广泛用于许多平台，包括ADLS、Amazon S3和GCS。Delta Lake 2.0的所有组件都已由Databricks开源。

Delta Lake和湖仓库的成功催生了一个完全新的生态系统，围绕Delta技术构建。这个生态系统由各种独立组件组成，包括Delta Lake存储格式、Delta Sharing和Delta Connectors。

Delta Lake存储

Delta Lake存储格式是一个开源的存储层，运行在基于云的数据湖之上。它为数据湖文件和表添加了事务能力，将数据仓库类似的功能带到了标准的数据湖。Delta Lake存储是生态系统的核心组件，因为所有其他组件都依赖于这一层。

Delta Sharing

数据共享在业务中是一个常见的用例。例如，一家采矿公司可能希望将其大型采矿卡车引擎的IoT信息安全地与制造商共享，以进行预防性维护和诊断。恒温器制造商可能希望将暖通空调数据安全地与公用事业公司共享，以优化高负荷使用日的电网负载。然而，在过去，实施安全可靠的数据共享解决方案非常具有挑战性，需要昂贵的定制开发。

Delta Sharing是一个用于安全共享Delta Lake数据的开源协议。它允许用户安全地共享存储在Amazon S3、ADLS或GCS中的数据。使用Delta Sharing，用户可以直接连接到共享的数据，使用他们喜欢的工具集，如Spark、Rust、Power BI等，而无需部署任何其他组件。请注意，数据可以跨云提供商进行共享，无需进行任何自定义开发。

Delta Sharing可以支持以下用例：

• 存储在ADLS中的数据可以由AWS上的Spark引擎处理。
• 存储在Amazon S3中的数据可以由GCP上的Rust处理。

有关Delta Sharing的详细讨论，请参考第9章。

Delta Connectors

Delta Connectors的主要目标是将Delta Lake引入Apache Spark之外的其他大数据引擎。Delta Connectors是一组开源连接器，可以直接连接到Delta Lake。该框架包括Delta Standalone，这是一个允许直接读写Delta Lake表格的Java本地库，而无需Apache Spark集群。消费应用程序可以使用Delta Standalone直接连接到由其大数据基础架构编写的Delta表格，从而无需在数据被消耗之前将其复制到另一种格式中。

还有其他用于不同引擎的本地库，包括：

• Hive

Hive连接器可以直接从Apache Hive读取Delta表格。

• Flink

Flink/Delta连接器可以在Apache Flink应用程序中读取和编写Delta表格。该连接器包括一个用于将数据写入Delta表格的sink以及一个用于使用Flink读取Delta表格的source。

• sql-delta-import

此连接器允许从JDBC数据源直接导入数据到Delta表格。

• Power BI

Power BI连接器是一个自定义的Power Query函数，允许Power BI从Microsoft Power BI支持的任何基于文件的数据源中读取Delta表格。

Delta Connectors是一个快速增长的生态系统，定期推出更多连接器。实际上，在最近宣布的Delta Lake 3.0版本中包括Delta Kernel。Delta Kernel及其简化的库消除了理解Delta协议细节的需求，因此更容易构建和维护连接器。

总结

考虑到数据的数量、速度、多样性和准确性，数据仓库和数据湖的限制和挑战推动了一种新的数据架构范式。由Delta Lake等开放表格格式的进步提出的湖宅架构为现代数据架构提供了一种方法，汇集了其前身的最佳元素，为数据平台带来了统一的方法。

正如前言中提到的，本书不仅仅是触及表面；它将深入探讨本章中已经提及的Delta Lake的一些核心功能。您将了解如何最佳设置Delta Lake，识别不同功能的用例，了解最佳实践和需要考虑的不同事项等等。本书将不断为数据从业者提供背景信息和证据，说明这种开放表格格式如何支持湖宅架构的现代数据平台。通过阅读本书，您将自信地开始使用Delta Lake并构建现代数据湖宅架构。