我已经简要介绍了数据湖仓库作为数据湖和数据仓库概念的融合。数据湖仓库的理念是通过仅使用数据湖来存储所有数据，而不是还有单独的关系型数据仓库来简化事务。为了实现这一点，数据湖需要更多功能来替代关系型数据仓库的特性。这就是Databricks的Delta Lake发挥作用的地方。
Delta Lake是一个事务性存储软件层，运行在现有的数据湖之上，并添加了类似关系型数据仓库的功能，提高了数据湖的可靠性、安全性和性能。Delta Lake本身并不是存储系统。在大多数情况下，将数据湖转变为Delta Lake非常简单；你只需在将数据存储到数据湖时指定将其保存为Delta Lake格式（而不是其他格式，如CSV或JSON）即可。
在幕后，当使用Delta Lake格式存储文件时，它以其独特的方式存储，其中包括Parquet文件和一个事务日志，用于跟踪对数据所做的所有更改。虽然实际数据以类似于您习惯的方式存储在数据湖中，但添加的事务日志将其转变为Delta Lake，增强了其功能。但这意味着任何与Delta Lake交互的内容都需要支持Delta Lake格式；由于它变得非常流行，大多数产品都支持。
Delta Lake并不是为数据湖提供额外功能的唯一选择；另外两个流行的选择是Apache Iceberg和Apache Hudi，它们具有非常相似的特性。然而，在本章中我将重点介绍Delta Lake。
到目前为止，您已经了解了关系型数据仓库（第4章）、数据湖（第5章）、现代数据仓库（第10章）和数据织构（第11章）。本章将添加数据湖仓库。图12-1显示了这些架构在历史时间线上的演变。
Delta Lake的特性
Delta Lake为数据湖添加了几个类似关系型数据仓库（RDW）的功能。本节将介绍其中的一些功能。
也许公司使用Delta Lake的最大原因是它支持数据操作语言（DML）命令，如INSERT、DELETE、UPDATE和MERGE。这些命令简化了复杂的数据管理任务，使得在Delta Lake中处理数据更加灵活可靠。数据湖不提供对这些操作的本地支持，因为数据湖针对批处理和存储大量数据进行了优化，而不是针对实时更新。
在数据湖中更新数据通常涉及读取整个文件，进行必要的更新，然后将整个更新后的文件写回数据湖，这可能需要很长时间，特别是对于大文件而言。相比之下，当Delta Lake最初使用一个表（本质上是一个按行和列组织的数据的文件）时，它将该表分解为几个较小的数字文件，以便更容易地进行管理。结果是一个Delta Table。然后，Delta Lake使用事务日志来跟踪更改，这使得DML命令的工作速度更快，因为它使用了优化存储（列式存储格式）、内存处理以及针对批处理的优化。例如，对于UPDATE语句，Delta Lake会查找并选择包含与谓词匹配的数据的所有文件，因此需要更新这些文件。然后，它将每个匹配的文件读入内存，更新相关行，并将结果写入新的数据文件。这样可以高效地更新数据，而无需重写整个Delta Table。事务日志记录了对数据的更改历史，并确保数据始终处于一致的状态，即使出现故障或系统崩溃的情况下也是如此。
在处理数据库时，您会经常听到一个常见的缩写，即ACID，它代表原子性、一致性、隔离性和持久性。这是确保数据库事务的可靠性和完整性的四个属性。它们保证事务可以作为一个单一的、可靠的操作完成，其中的数据更改要么完全提交，要么完全回滚。虽然可以说Delta Lake支持ACID事务，但这种说法需要限定条件。与在关系型数据库（如SQL Server）中处理ACID事务不同，Delta Lake的ACID支持仅限于单个Delta Table。在Delta Lake中执行超过一个Delta Table的DML将不会保证ACID完整性。对于关系型数据库，跨多个表的DML事务可以确保ACID完整性。
Delta Lake还提供了"时间旅行"功能，允许您查询存储在Delta Tables中的数据，就像它在特定时间点存在一样。更改数据的历史记录保存在Delta事务日志中，以及元数据，例如每个更改的时间和由哪个用户进行的更改。用户可以查看和访问数据的先前版本，甚至在必要时将其恢复到以前的版本。这对于审核、调试或在意外数据更改或其他问题（如回滚）的情况下恢复数据非常有用。
在数据湖中，一个常见的问题是"小文件"问题，即大量的小文件会减慢读写操作的速度并增加存储成本。Delta Lake通过使用优化的压缩算法将小文件有效合并为大文件来解决这个问题。合并过程在后台自动执行，并可以根据计划运行或手动触发。
使用Delta Lake，用户可以在一个Delta Table中对相同的数据执行批处理和实时流处理，无需维护用于批处理和流处理的单独数据管道和系统。这种统一的解决方案使得管理和维护管道变得更加容易，并简化了数据处理架构。这也意味着Delta Lake支持Lambda架构。
模式强制是Delta Table的一个特性，它允许您为Delta Table中的数据指定预期的模式，并强制执行诸如可空约束、数据类型约束和唯一约束等规则。这确保写入Delta Table的数据符合指定的模式，有助于防止数据损坏。如果传入数据与模式不匹配，Delta Lake将拒绝写操作并引发错误。
性能改进
使用 Delta Lake 可以在多个方面改善数据湖的性能，包括：
- 数据跳跃（Data Skipping） ： Delta Lake 可以在从 Delta 表读取数据时跳过不相关的数据，这可以极大地提高查询性能。
- 缓存（Caching） ： Delta Lake 支持在 Spark 中对数据进行缓存，这可以显著提高重复查询的性能。
- 快速索引（Fast Indexing） ： Delta Lake 使用了优化的索引结构来快速定位数据，从而减少执行查询所需的时间。
- 查询优化（Query Optimization） ： Delta Lake 与 Spark SQL 集成，并利用 Spark 的查询优化功能，从而实现更快、更高效的查询。
- 谓词下推（Predicate Pushdown） ： Delta Lake 支持谓词下推，这意味着过滤条件被推送到存储层，减少了需要处理的数据量。
- 列修剪（Column Pruning） ： 通过列修剪，仅读取特定查询所需的列，从而减少了需要处理的数据量。
- 矢量化执行（Vectorized Execution） ： 在矢量化执行中，多个数据点在单个 CPU 指令中处理，从而提高了性能。
- 并行处理（Parallel Processing） ： Delta Lake 支持并行处理，意味着可以并行执行多个任务，从而提高了性能。
- Z-order： Z-order，也称为 Morton order，是 Delta Lake 架构中使用的一种数据索引技术，用于组织数据以实现快速、高效的访问和查询。
数据湖仓架构
在数据湖仓架中，数据经历了与MDW和数据织物架构相同的五个阶段，正如图12-2所示。这些阶段包括：（1）摄取、（2）存储、（3）转换、（4）建模和（5）可视化。
如图12-2所示，使用数据湖仓架架构时，您的数据只有一个存储库（即使用Delta Lake的数据湖），而不是两个（数据湖和RDW）。这解决了MDW和数据织物架构中常见的六个问题：
可靠性
保持数据湖和RDW的一致性可能会成为问题，特别是如果需要经常将大量数据从数据湖复制到RDW。如果复制数据的作业失败，未能准确复制数据，或者将数据放在数据湖的错误位置，这可能会导致可靠性问题。例如，针对RDW运行报告可能会返回与针对数据湖中相同数据运行报告不同的结果。使用数据湖仓架，由于没有RDW可供复制数据，这不是问题。
数据陈旧性
RDW中的数据将比数据湖中相应的数据旧。数据的年龄取决于从数据湖复制数据到RDW的频率，为了避免影响查询和报告性能，不希望运行这些作业太频繁。与上述可靠性问题类似，这可能导致针对RDW和数据湖运行的报告返回不同的结果。使用数据湖仓架，由于没有RDW可供复制数据，这不是问题。
对高级分析的有限支持
很少有人工智能/机器学习系统和工具能在RDW上良好运行，因为数据科学家通常更喜欢使用数据湖中的文件进行工作。使用数据湖仓架架构可以解决这个问题。
总体拥有成本
尽管存储成本相对较低，但需要用于将数据复制到RDW的计算存在额外成本。此外，结果是数据的两份副本，增加了额外的存储成本。相比之下，在数据湖仓架中，只有一份数据副本。此外，用于RDW中的查询和报告的计算通常比使用数据湖的计算成本高得多。此外，管理数据湖和管理RDW是不同的技能集，雇佣两者可能会产生额外的成本。
数据治理
在两个不同的存储环境中有两份数据副本，可能具有两种不同类型的安全性，增加了某人看到他们不应该看到的数据的风险。还很难确保这两个系统遵循相同的数据质量和数据转换规则。使用数据湖仓架及其一份数据副本，这些问题就不存在了。
复杂性
管理数据湖和RDW可能会很复杂，需要专业技能和资源。由于数据湖仓架中没有RDW，因此需要的专业技能较少。
如果您跳过关系型数据仓库会怎样呢？
这里涉及一个棘手的问题。不久以前，我会告诉您在架构中跳过关系型数据仓库是一个非常糟糕的主意。现在，随着Delta Lake不断将类似关系型数据仓库的功能添加到数据湖中，我开始看到越来越多的用例认为数据湖仓库是最佳架构。在使用较小数据集的情况下，使用数据湖仓库的理由尤其令人信服。因为大多数云供应商都提供无服务器计算资源，您可以针对Delta Lake支付每次查询的成本。不需要将数据复制到关系型存储中，这样可以节省成本，因为关系型存储成本更高，使用的关系型计算成本也更高。如果您使用的是专用计算资源而不是无服务器计算资源，即使不使用该计算资源，您也需要支付费用。与任何架构一样，存在权衡和问题，如果您选择不在架构中使用关系型数据仓库，了解这些问题非常重要。
第一个权衡是，相对于针对Delta Lake的查询，关系数据库查询速度更快，特别是当您的关系型数据仓库使用MPP技术时（参见第7章）。关系型数据仓库具有改善查询性能的功能，这些功能在Delta Lake中不可用，包括：
- 高级索引（例如聚集列存储索引和全文索引）
- 高级统计信息
- 缓存（除非您使用Spark）
- 高级查询计划优化
- 材料化视图
- 高级连接优化 Delta Lake的一些性能特性，例如Z-order，可以缓解其中一些缺失的功能。
Delta Lake还缺乏关系型数据仓库安全的一些常见特性，例如行级安全性、列级安全性、数据静态加密、列级加密、透明数据加密（TDE）和动态数据遮罩（自动替换或模糊数据的部分，以便未经授权的用户看到数据的遮罩版本而不是实际的敏感信息）。它也不提供SQL视图；引用完整性；工作负载管理；以及高级审计和合规特性，例如审计追踪、数据保留政策和合规认证。与Delta Lake相比，关系型数据仓库支持更高的并发性，因为它们提供了高级功能，例如高级锁定、隔离级别和事务管理。
复杂性也是一个问题。使用关系型数据仓库时，您必须创建一个强制性的元数据层------您必须创建一个数据库、模式和一个包含描述数据类型的字段的表，然后加载数据（写时模式）。这意味着您始终有元数据位于实际数据之上。这需要预先工作，但最大的好处是元数据和数据始终绑定在一起，因此很容易使用元数据找到数据。您永远不会"丢失"元数据，并且它将始终准确描述数据。这与Delta Lake大相径庭，后者是基于文件和文件夹的世界。这是让已经习惯关系型数据仓库的最终用户感到困惑的主要原因。
在Delta Lake中，元数据不需要与数据一起存在。您可能会在包含数据的文件中的一个或多个单独文件中找到它，也可能在同一个文件夹中，也可能在一个单独的文件夹中，或者根本找不到。更不用说，由于它与数据的一对一关系与关系型数据仓库不同，元数据可能极不准确。您可以想象到这对最终用户会有多么困惑，他们可能会很难找到元数据，错误地认为没有元数据，甚至使用错误的元数据。最后，当在Delta Lake之外进行更改时，元数据可能会与数据不同步。
使用Delta Lake架构的某些功能可能会将您锁定在必须使用Spark的位置。此外，如果从使用Spark SQL之外的SQL版本的产品迁移，准备重写存储过程、视图、报表、仪表板等。
如果确实需要使用Spark SQL，那可能意味着需要对已经习惯与关系型数据仓库交互并熟悉相关工具的最终用户进行重新培训。他们可能正在使用符合ANSI标准的SQL或与Microsoft产品一起使用的T-SQL（用于Microsoft产品）。他们习惯于关系模型，并且知道如何快速查询和报告。转向文件夹-文件世界可能会迫使他们学习使用新工具；习惯于读时模式；并学会处理速度、安全性、缺失功能、复杂性和前面描述的SQL更改的问题。这需要大量的培训。
现有技术可以缓解其中一些问题，并最终使它们变得不相关。但在发生这种情况之前，您需要认真考虑它们与您的需求之间的关系，以确定是否使用数据湖仓库架构。例如，如果在数据湖仓库架构中对数据湖的查询平均需要五秒钟，这是否是一个问题？如果最终用户对此表示满意，您可以忽略此问题，但是如果他们使用仪表板并需要毫秒级的查询响应时间，那么您需要将用于仪表板的数据复制到关系型数据仓库中（这意味着您最终会使用关系型数据仓库架构）。您还可以使用报表产品，允许您将数据导入其内存以获得毫秒级的查询响应时间，但是数据不会像在Delta Lake中那样更新，并且您需要在特定间隔内刷新报表工具内存中的数据。
再次强调，我们在讨论权衡。如果您是一名架构师，那么您的主要工作之一将是识别可用于每种架构的产品，并确定并分析它们的权衡，以选择最适合您特定用例的架构和产品。
以上任何问题本身都不一定是一个阻碍因素，但是结合起来，它们可能足以成为使用关系型数据仓库的足够理由。许多公司会开始进行一些概念验证，以确定跳过关系型数据仓库的权衡是否会引起问题。如果没有问题，他们会继续使用数据湖仓库。
关系型服务层
由于Delta Lake采用的是基于读取的模式（参见第2章），所以模式是在读取数据时应用的，而不是事先应用的。Delta Lake是一个文件夹系统，因此它不提供数据的上下文信息。（与RDW的元数据呈现层形成对比，该层位于数据之上并直接与数据相关联。）Delta Lake中不存在定义的关系。每个文件都处于自己的孤立岛屿中，因此您需要在Delta Lake中的数据上创建一个"服务层"，以将元数据直接与数据关联起来。为了帮助最终用户理解数据，您可能希望将其呈现为关系数据模型，因此您构建的是一个"关系服务层"。有了该层，如果需要将多个文件连接在一起，您可以定义它们之间的关系。关系服务层可以采用多种形式：SQL视图、报告工具中的数据集、Apache Hive表，或者在自定义SQL查询中。如果操作正确，最终用户将不会意识到他们实际上是从Delta Lake中获取数据，他们会认为数据来自RDW。
许多公司在Delta Lake文件上创建SQL视图，然后使用报告工具调用这些视图。这样可以使最终用户轻松创建报告和仪表板。
即使有了关系服务层，Delta Lake仍然存在一些挑战。例如，关系服务层可能会错误地呈现数据，或者您可能会得到两个指向相同数据但具有不同元数据的层。元数据与数据未关联是Delta Lake的固有问题。RDW通过具有所有人都可以使用的通用数据模型来避免这个问题。
总结
本章探讨了数据湖仓的概念，重点关注了Delta Lake作为事务性存储层，显著增强了现有数据湖的可靠性、安全性和性能。
您了解了跳过传统RDW可能带来的潜在缺点，重点关注了与速度、安全性和并发性相关的挑战。只要意识到了权衡取舍，如果没有即时的重大问题，那么就使用数据湖仓直到无法继续为止。如果其中一个权衡因素对于特定数据集来说难以克服，那么可以将该数据复制到RDW（无需复制所有数据）。随着Delta Lake、类似技术如Apache Iceberg和Apache Hudi，以及存储和计算技术的持续改进，维护RDW的理由将越来越少。大多数新的数据架构将是数据湖仓。
您了解到了Delta Lake独特的基于读取的模式，在此模式中，数据解释发生在读取时而不是事先。您还了解了其文件夹结构，它缺乏上下文，因此与RDW的结构化元数据呈现层明显不同。这需要建立一个"关系服务器层"，以建立与Delta Lake中数据的直接上下文关联。
快速的技术进步继续影响着数据架构策略。几年前，从架构中省略RDW将被视为重大失误，但当前的趋势表明，越来越多的用例中，数据湖仓正在成为最佳架构。
到目前为止，我所讨论的所有架构都是集中式解决方案，意味着源数据被复制到由IT拥有的中央位置。在下一章中，我们将讨论数据网格的分散解决方案，您将看到一个重大的区别。