Databricks 开源存储层 Delta Lake，欲取代传统数据湖

近日，Databricks 官方博客宣布开源 Delta Lake 项目。Delta Lake 是一个存储层，为Apache Spark和其他大数据引擎提供可伸缩的 ACID 事务，让用户可以基于 HDFS 和云存储构建可靠的数据湖。此外，Delta Lake 还提供了内置的数据版本控制，可以方便地回滚以及重新生成报告。

数据湖面临的挑战

数据湖是现代数据体系结构中的一个常见元素。对于组织试图收集和挖掘的海量数据，它们扮演着摄取中心的角色。虽然在控制数据范围方面已经迈出了良好的一步，但它们还存在以下常见问题：

1. 对数据湖进行的读写操作不可靠。数据工程师经常遇到数据湖写入不安全的问题，这会导致读取方在写入期间看到垃圾数据。它们必须构建变通方案，确保读取方在写操作期间看到的数据始终一致。

2. 数据湖的数据质量较差。将非结构化数据转储到数据湖中很容易。但这是以数据质量为代价的。如果没有任何机制验证模式和数据，那么数据湖就会受到数据质量差的影响。因此，试图挖掘这些数据的分析项目也会失败。

3. 随着数据量的增加，性能变差。随着转储到数据湖中的数据量的增加，文件和目录的数量也会增加。处理数据的大数据作业和查询引擎在处理元数据操作上花费了大量时间。这个问题在流作业的情况下会更加明显。

4. 更新数据湖中的记录非常困难。工程师需要构建复杂的管道来读取整个分区或表，修改数据并将其写回。这样的管道效率低下，难以维护。

由于这些挑战，许多大数据项目未能实现其愿景，有时甚至完全失败。为了使数据从业者能够在保证数据质量的同时利用他们现有的数据湖，Databricks 构建了这个解决方案。

Delta Lake 特性

Delta Lake 解决了上述问题，简化了数据湖构建。以下是 Delta Lake 提供的主要功能：

• ACID 事务：Delta Lake 提供多个写操作之间的 ACID 事务。每个写操作都是一个事务，事务日志中记录的写操作有一个串行顺序。事务日志会跟踪文件级的写操作，并使用乐观并发控制，这非常适合数据湖，因为尝试修改相同文件的多个写操作并不经常发生。在存在冲突的场景中，Delta Lake 会抛出一个并发修改异常，以便用户处理它们并重试它们的作业。Delta Lake 还提供了强大的序列化隔离级别，允许工程师不断地对目录或表进行写操作，而用户可以不断地从相同的目录或表中读取数据。读取者将看到读操作开始时存在的最新快照。

• 模式管理：Delta Lake 会自动验证正在写入的 DataFrame 模式是否与表的模式兼容。表中存在但 DataFrame 中不存在的列会被设置为 null。如果 DataFrame 中有额外的列在表中不存在，那么该操作将抛出异常。Delta Lake 具有可以显式添加新列的 DDL 和自动更新模式的能力。

• 可伸缩的元数据处理：Delta Lake 将表或目录的元数据信息存储在事务日志中，而不是存储在元存储（metastore）中。这使得 Delta Lake 能够在固定的时间内列出大型目录中的文件，并且在读取数据时非常高效。

• 数据版本控制和时间旅行：Delta Lake 允许用户读取表或目录先前的快照。当文件在写期间被修改时，Delta Lake 将创建文件的新版本并保存旧版本。当用户希望读取表或目录的旧版本时，他们可以向 Apache Spark 的读操作 API 提供一个时间戳或版本号，Delta Lake 根据事务日志中的信息构建该时间戳或版本的完整快照。这使得用户可以重新进行试验并生成报告，如果需要，还可以将表还原为旧版本。

• 统一的批处理和流接收（streaming sink）：除了批处理写之外，Delta Lake 还可以使用Apache Spark的结构化流作为高效的流接收。再结合 ACID 事务和可伸缩的元数据处理，高效的流接收现在支持许多接近实时的分析用例，而且无需维护复杂的流和批处理管道。

• 记录更新和删除（即将到来）：Delta Lake 将支持合并、更新和删除 DML 命令。这使得工程师可以轻松地维护和删除数据湖中的记录，并简化他们的变更数据捕获和 GDPR 用例。由于 Delta Lake 在文件粒度上跟踪和修改数据，因此，比读取和覆写整个分区或表要高效得多。

• 数据期望（即将到来）：Delta Lake 还将支持一个新的 API，用于设置表或目录的数据期望。工程师将能够通过指定布尔条件及调整严重程度来处理数据期望。当 Apache Spark 作业写入表或目录时，Delta Lake 将自动验证记录，当出现违规时，它将根据所预置的严重程度处理记录。

Delta Lake ACID 保证是建立在存储系统的原子性和持久性基础之上的。具体来说，该存储系统需要提供以下特性：

• 原子可见性：必须有一种方法使文件完全可见或完全不可见。

• 互斥：只有一个写入者能够在最终目的地创建（或重命名）文件。

• 一致性清单：一旦在目录中写入了一个文件，该目录未来的所有清单都必须返回该文件。

Delta Lake 仅在 HDFS 上提供所有这些保证。通过插件的方式加入LogStore API的自定义实现，可以使它与其他存储系统一起工作。

在接受ZDNet采访时，Apache Spark 联合创建者兼 Databricks 首席技术官 Matei Zaharia 指出：

Delta Lake 位于你的存储系统之上，它不会取代它们。Delta Lake 是一个事务型存储层，它既可以工作在 HDFS 上，也可以工作在像 S3、Azure Blob 存储这样的云存储之上。用户可以下载开源的 Delta Lake，并将其与 HDFS 一起在本地使用。用户可以从任何支持 Apache Spark 数据源的存储系统读取数据，并向 Delta Lake 写入数据，Delta Lake 以 Parquet 的格式存储数据。

Apache Parquet是 Databricks 的首选格式。它是 Hadoop 生态系统中任何项目都可以使用的一种开源列式存储格式，而且与选择哪种数据处理框架无关。因此，Delta Lake 似乎是其所支持的数据存储格式之上的一层。

谈到可靠性，Ghodsi 表示：

所有这些都有助于增加数据湖的可靠性。数据版本控制和回滚是 Delta Lake 提供的开箱即用的功能。该功能是完全开源的，不需要任何特定的 Databricks 集成。

Delta Lake 希望标准化大数据在本地和云中的存储方式。目标是使数据湖为分析和机器学习做好准备。为了实现这一目标，Delta Lake 提供了一种开放格式和事务性协议。

Delta Lake 项目的最终目标是数据科学和机器学习，Ghodsi 告诉 ZDNet：

我们从一开始就相信创新源于合作而不是隔离。这种信念推动了 Spark 项目和 MLflow 的创建。Delta Lake 将培育一个蓬勃发展的开发者社区，他们将合作提高数据湖的可靠性，并加快机器学习创新。

Viacom、Edmunds、Riot Games、McGraw Hill 等公司都已经在生产中使用了这种技术。Ghodsi 指出，Databricks 希望 Delta Lake 成为存储大数据的标准，并致力于建立一个欣欣向荣的开源社区：

我们一些最大的终端用户已经表现出了很大的兴趣，他们对把这个系统延伸到他们自己的特定场景中的前景感到兴奋，因为它是开源的。我们希望 Delta Lake 成为存储大数据的标准。为此，我们决定开放源代码，让整个社区从中受益。

另外， ZDNet 在报道中指出：

这不是向数据湖添加事务支持的唯一方法：对于基于 HDFS 的存储，Apache Hive是另一种方法。但是，Delta Lake 增加的价值来自事务和统一数据格式的组合。Cloudera 的 Ozone 项目是另一项将云存储和内部存储（包括事务）统一起来的工作，但它还没有准备好用于生产环境。Hive 和 Ozone 的结合可能可以带来类似 Delta Lake 所提供的东西，但现在还没有发展到这一步。

Delta Lake 已经发布到 Maven 中央存储库，可以通过在 POM 文件中添加依赖项来使用它。

<dependency>  <groupId>io.delta</groupId>  <artifactId>delta-core_2.11</artifactId>  <version>0.1.0</version></dependency>

Delta Lake 目前需要 Apache Spark 2.4.2。它目前提供的唯一稳定的公共 API 是通过 DataFrameReader/Writer（即 spark.read、df.write、spark.readStream 和 df.writeStream）提供的。这些 API 的选项在 Delta Lake 的主要版本（例如 1.x.x）中将保持稳定。这个库中的所有其他接口都被认为是内部接口，并且可能会在次要版本/补丁版本之间进行更改。

要了解更多信息，请查看Delta Lake文档或快速入门指南。你也可以加入 Delta Lake 项目邮件列表或通过Slack频道与社区进行讨论。要在云中试用 Delta Lake，则可以在 Databricks （Azure | AWS）上免费注册试用。