译者

韩宗泽（棕泽），阿里云计算平台事业部技术专家，负责开源大数据生态企业团队的研发工作

前言

本文翻译自大数据技术公司 Databricks 针对数据湖 Delta Lake 系列技术文章。众所周知，Databricks 主导着开源大数据社区 Apache Spark、Delta Lake 以及 ML Flow 等众多热门技术，而 Delta Lake 作为数据湖核心存储引擎方案给企业带来诸多的优势。

此外，阿里云和 Apache Spark 及 Delta Lake 的原厂 Databricks 引擎团队合作，推出了基于阿里云的企业版全托管 Spark 产品——Databricks 数据洞察，该产品原生集成企业版 Delta Engine 引擎，无需额外配置，提供高性能计算能力。有兴趣的同学可以搜索` Databricks 数据洞察`或`阿里云 Databricks`进入官网，或者直接访问以下链接进行了解：

https://www.aliyun.com/product/bigdata/spark

本系列还包括其他内容，欢迎持续关注：

• 第一章：基础和性能

  01、Delta Lake基础：为什么可靠性和性能很重要？>>

  02、（本文）深入理解事务日志 / 如何使用Schema约束和演变

  03、Delta Lake DML语法 / 在Delta Lake中使用Data Skipping和Z-Ordering来快速处理PB级数据

• 第二章：特性

• 第三章：Lakehouse

• 第四章：Streaming

• 第五章：客户用例

Delta Lake技术系列 - 基础和性能

（Fundamentals and Performance）

——使用 Delta Lake 为机器学习和商业智能提供可靠的数据保障

Chapter-02 深入理解事务日志

（Transaction Log）

事务日志（Transaction Log）是理解 Delta Lake 的关键，因为它是许多最重要功能的基础，包括 ACID 事务、可伸缩的元数据处理、时间旅行等等。Delta Lake 事务日志是自 Delta Lake 表创建以来在其上执行的所有事务的有序记录。

Delta Lake 构建在 Apache Spark 之上，允许用户在特定的表上同时进行并发的读写操作。为了随时向用户显示正确的数据视图，事务日志（Transaction Log）充当了唯一的真实来源：跟踪用户对表所做的所有更改的中央存储。

当用户第一次读取 Delta Lake 表或对自上次读取以来已修改的表运行新查询时，Spark将检查事务日志（Transaction Log），以查看哪些新事务已发布到该表。然后，Spark 用这些新的更改来更新最终用户的表。这可以确保用户版本的表始终与主记录在最近一次查询时保持同步，并且用户不能对表进行有分歧的、有冲突的更改。

在本章中，我们将探讨 Delta Lake 事务日志（Transaction Log）如何为多个并发读写的问题提供一个优雅的解决方案。

实现原子性以保证操作的完全性

原子性是 ACID 事务的四个属性之一，它保证对数据湖执行的操作（如插入或更新数据）要么完全完成，要么根本不完成。如果没有这个属性，硬件故障或软件错误很容易导致数据只部分写入表，从而导致数据混乱或损坏。

事务日志（Transaction Log）是 Delta Lake 提供原子性保证的机制。不管怎么说，事务日志中不存在的记录，它就永远不会发生。Delta Lake 事务日志（Transaction Log）只记录完全执行的事务，并将该记录用作唯一的真实来源，因此用户可以在 PB 级的数据进行推理，并确保基本的数据可信度。

处理多个并发读写

但是Delta Lake如何处理多个并发读写呢？由于 Delta Lake 是由 Apache Spark 提供支持的，因此需要能够支持让多个用户同时修改一个表——这是所期待的的能力。为了处理这些情况，Delta Lake 采用了乐观锁并发控制。

乐观锁并发控制是一种处理并发事务的方法，它假定了不同用户对表所做的更改可以在不发生冲突的情况下完成。它的速度非常快，因为在处理数 PB 级别数据时，用户很可能同时处理着数据的不同部分，从而允许他们同时完成不冲突的事务。

当然，即使使用乐观并发控制，有时用户也会尝试同时修改数据的相同部分。幸运的是，Delta Lake 有一个协议，Delta Lake 通过实施互斥规则来处理这些 case，然后它试图乐观地解决任何冲突。

这个协议允许 Delta Lake 提供 ACID 隔离原则，这确保了在多个并发写操作之后，表的结果状态与这些写操作彼此隔离地连续发生时的状态相同。

由于在 Delta Lake 表上进行的所有事务都直接存储到磁盘上，因此这个过程满足 ACID 的耐用性属性，这意味着即使在系统发生故障的情况下，它也将持续存在。

时间旅行、数据沿袭和调试

（Time travel、Data Lineage、Debugging）

每个表都是 Delta Lake 事务日志（Transaction Log）中记录的所有提交的总和的结果——不多也不少。事务日志（Transaction Log）提供了一个分步指导，详细说明了如何从表的原始状态到当前状态。

因此，我们可以从原始表开始，在任何时间点重新创建表的状态，并且只处理在该时间点之后进行的提交。这种强大的能力被称为“时间旅行（Time travel）”，或数据版本控制，在很多情况下都可以成为救命稻草。

有关更多信息，请参阅文章

• 「为大规模数据湖引入 Delta 时间旅行」

  https://databricks.com/blog/2019/02/04/introducing-delta-time-travel-for-large-scale-data-lakes.html）

• 「利用 Delta Lake 和 MLflow 为数据科学做好数据准备」

  https://www.youtube.com/watch?v=hQaENo78za0&list=PLTPXxbhUt-YVPwG3OWNQ-1bJI_s_YRvqP&index=21&t=112s

Delta Lake 事务日志（Transaction Log）是对表所做的每一次更改的最终记录，它为用户提供了一个可验证的数据谱系，对于治理、审计和法规遵从性非常有用。它还可以用于跟踪管道中的意外更改或错误的根源，以找到导致错误的确切操作。用户可以运行 DESCRIBE HISTORY 命令来查看所做更改的相关元数据信息。

想进一步了解 Delta Lake 的事务日志吗？

• 您可以阅读我们的博客

  https://databricks.com/blog/2019/08/21/diving-into-delta-lake-unpacking-the-transaction-log.html

• 或者观看我们的技术讲座

  https://databricks.com/discover/diving-into-delta-lake-talks/unpacking-transaction-log

Chapter-03 如何使用Schema约束（Schema Enforcement）和演变（Evolution）

随着业务问题和需求的发展，数据的结构也在不断变化。在 Delta Lake 中，合并新的列或对象是很容易的，用户可以访问简单的语义来控制其表的 Schema。同时，重要的是要强调 Schema 约束的重要性，以防止用户在 Schema 演变过程中意外地用错误或垃圾数据污染他们的表，这使他们能够自动添加新的数据列。

Schema 约束（Schema Enforcement）拒绝任何不兼容表的新增和修改操作。通过设置和维护这些更高的标准，分析师和工程师可以相信他们的数据具有最高级别的完整性，从而可以清晰地进行推理，使他们能够做出更好的业务决策。

另一方面，Schem 演变（Schema Evolution）通过使预期的 Schema 更改易自动发生。毕竟，添加一个列应该不难。

Schema 约束（Schema Enforcement）和 Schema 演变（Schema Evolution）是互补的能力。当这些功能结合使用时，比以往任何时候都更容易得到好的效果。

理解表的 Schema

Apache Spark 中的每个 DataFrame 都包含一个 Schema——Schema 定义了数据的描述（如数据类型和列）和蓝图、以及元数据信息。在 Delta Lake 中，表的 Schema 以 JSON 格式保存在事务日志中。

什么是 Schema 约束

（Schema Enforcement）？

Schema 约束（Schema enforcement，或 Schema validation）是 Delta Lake 中的一种保护措施，它通过拒绝对与表的 Schema 不匹配的写入操作，来保证数据质量。

就像繁忙餐厅的前台经理只接受预订一样，它检查插入表中的每一列数据是否在其预期列的列表中（换句话说，每一列是否都有“预订”），并拒绝任何不在列表中的列的写入。

Schema 约束是如何工作的？

Delta Lake 使用写时 Schema 校验，这意味着在写入时检查对表的所有新写入是否与目标表的 Schema 兼容。如果 Schema 不兼容，Delta Lake 将完全取消事务，不写入任何数据，并抛出异常以让用户知道表结构不匹配。

为了确定对表的写入是否兼容，Delta Lake 使用以下规则。要写入的 DataFrame 不能包含：

• 目标表结构中不存在的任何其他列。相反，如果传入的数据不包含表中的列，则没有问题——这些列将被简单地分配 null 值。

• 与目标表中的列数据类型不同的列数据类型。如果目标表的列包含 StringType 数据，但 DataFrame 中的相应列包含 IntegerType 数据，则架构强制将引发异常并阻止执行写操作。

• 只有大小写不同的列名。这意味着不能在同一个表中定义名为“Foo”和“foo”的列。虽然 Spark 可以在区分大小写或不区分大小写（默认）Schema 下使用，但是 Delta Lake 保留大小写，但在存储 Schema 时不区分大小写。在存储和返回列信息时，Parquet 区分大小写。为了避免潜在的错误、数据损坏或丢失问题（这是我们在 Databricks 亲身经历的），我们决定添加这个限制。

Delta Lake 不是自动添加新的列，而是强制执行 Schema，并停止写入。为了帮助识别导致不匹配的列，Spark 打印出堆栈来跟踪两个 Schema 以进行比较。

Schema 约束起到什么作用呢？

因为这是一个非常严格的检查，所以 Schema 约束是一个很好的工具，可以用作一个干净的、完全转换的数据集的网关，该数据集可以用于生产或消费。通常在结果数据的表上强制执行：

• 机器学习算法

• BI 仪表盘

• 数据分析和可视化工具

• 任何需要高度结构化、强类型、语义 Schema 的生产系统

为了为这最后一个障碍准备数据，许多用户采用了一种简单的多跳架构，该架构可以逐步地向表中添加结构。

要了解更多信息，请查看「基于 Delta Lake 的机器学习」

• https://databricks.com/blog/2019/08/14/productionizing-machine-learning-with-delta-lake.html

什么是 Schema 演变？

Schema 演变是一种允许用户轻松更改表的当前 Schema 以适应随时间变化的数据的功能。最常见的是，在执行追加或覆盖操作时使用它来自动调整 Schema 以包含一个或多个新增列。

Schema 演变是如何工作的？

继上一节中的示例之后，开发人员可以轻松地使用 Schema 演变来添加以前由于 Schema 不匹配而被拒绝的新列。通过使用 Spark .write  或 . writeStream 命令的 .option（'mergeSchema'，'true'） ，可以触发 Schema 演变，如下例所示。

#Add the mergeSchema option
loans.write.format(“delta”) \
.option(“mergeSchema”, “true”) \
.mode(“append”) \
.save(DELTALAKE_SILVER_PATH)

通过在查询中包含 mergeSchema 选项，DataFrame 中存在但目标表中不存在的任何列都会作为写事务的一部分自动添加到 Schema 的末尾。也可以添加嵌套字段，这些字段也将添加到各自结构列的末尾。

数据工程师和科学家可以使用这个选项向他们现有的 ML 生产表中添加新的列（可能是一个新跟踪的指标，或者本月销售数据的一列），且不会破坏依赖于旧列的现有模型。

在表追加或覆盖期间，以下类型的架构更改符合 Schema 演变的条件：

• 添加新列（这是最常见的场景）

• 从 NullType->any other type 更改数据类型，或从 ByteType->ShortType->IntegerType 升级数据类型

其他不符合 Schema 演变条件的更改要求通过添加 .option（“overwriteSchema”，“true”） 覆盖 Schema 和数据。这些变化包括：

• 删除列

• 更改现有列的数据类型（就地）

• 重命名仅区分大小写的列名（例如，“Foo”和“foo”）

最后，随着 Spark 3.0 的发布，完全支持显式 DDL（使用ALTER TABLE），允许用户对表 Schema 执行以下操作：

• 添加列

• 更改列注释

• 设置定义表行为的表属性，例如设置事务日志的保留期限

Schema 演变起到什么作用呢？

无论何时，只要您打算更改表的 Schema，就可以使用 Schema 演变（而不是意外地将不应该存在的列添加到 DataFrame 中）。这是迁移 Schema 的最简单方法，因为它自动添加正确的列名和数据类型，而不必显式声明。

总结

Schema 约束拒绝与表不兼容的任何新列或其他 Schema 更改，通过设置和维护这些高标准，分析师和工程师可以相信他们的数据具有最高级别的完整性，并且可以清晰地进行推理，从而使他们能够做出更好的业务决策。

另一方面，Schema 演变通过使预期的 Schema 更改轻松自动化。毕竟，添加一个列应该不难。

Schema 约束（Schema Enforcement）和 Schema 演变（Schema Evolution）是互补的能力。当这些功能结合使用时，比以往任何时候都更容易得到好的效果。

后续

本系列还包括其他内容，欢迎持续关注：

• 第一章：基础和性能

  01、Delta Lake基础：为什么可靠性和性能很重要？>>

  02、（本文）深入理解事务日志 / 如何使用Schema约束和演变

  03、Delta Lake DML语法 / 在Delta Lake中使用Data Skipping和Z-Ordering来快速处理PB级数据

• 第二章：特性

• 第三章：Lakehouse

• 第四章：Streaming

• 第五章：客户用例

也可点击文章下方阅读原文，查看所有本系列文章~

---

获取更详细的 Databricks 数据洞察 相关信息，可至产品详情页查看：

https://www.aliyun.com/product/bigdata/spark

阿里巴巴开源大数据技术团队成立 Apache Spark 中国技术社区，定期推送精彩案例，技术专家直播，只为营造纯粹的 Spark 氛围，欢迎关注公众号！

扫描下方二维码入 Databricks 数据洞察产品交流钉钉群一起参与交流讨论！