作者

王晓龙（筱龙），阿里云开源大数据平台技术专家

Delta Lake 介绍

大数据平台架构发展至今，已经经历了三个阶段的技术演进：从最早的数仓，到数据湖+数仓的架构，再到最近两年的 Lakehouse 架构。

最早的数仓架构是 Schema-on-write 的设计。如上图，数据首先由关系型数据库经过 ETL 导入数据仓库里，可以做一些 BI 分析以及报表分析。它的底层是数据库技术，因此能够提供比较好的数据管理能力，比如能够支持 ACID 事务，能够基于 Schema-on-write 在上游数据写入的时候提供比较强的 Schema 约束，以此保证数据的质量。

同时，基于它自身的诸多优化特性，数仓架构对分析型场景能够提供非常好的支持。但是支持的场景比较有限，基本局限于常用的分析场景。而在大数据时代，随着数据规模的逐渐增加，企业对于数据分析的场景要求越来越多，逐渐产生了一些高级的分析场景需求，比如数据科学类或者机器学习类的场景，而数据仓库对此类需求难以支持。

另外，数据仓库也无法支持半结构化以及非结构化的数据。

2003年前后，Hadoop 面市。伴随着数据规模体量的爆炸式增长，我们对低成本存储的需求也愈发迫切。于是第二代大数据平台架构雏形初现。它以数据湖为基础，能够支持对结构化、非结构化以及半结构化数据的存储。与数据仓库相比，它是一种 Schema-on-read 的设计，数据能够比较高效地存入数据湖，但是会给下游的分析提供较高的负担。

因为数据在写入之前没有做校验，随着时间的推移，数据湖里的数据会变得越来越脏乱，数据治理的复杂度非常高。同时因为数据湖底层是以开放的数据格式存储在云对象存储上，云对象存储的一些特性会导致数据湖架构缺少像数仓一样的数据管理特性。另外因为云对象存储在大数据查询场景上的性能上不足，导致很多场景下都无法很好地体现数据湖的优势。

于是第三代大数据平台架构——Lakehouse 应运而生。它在数据湖之上抽象出了事务管理层，能够提供传统数仓的一些数据管理特性，还可以针对云对象存储中的数据做一些数据的性能优化。从而能够针对大数据时代各种复杂的分析场景提供支持，且对于流批两种场景也能够提供统一的处理方式。

有了 Lakehouse 架构的背景之后，Delta Lake 也应运而生，它是由 Databricks 开源的一个数据库解决方案，架构清晰简洁，能够提供比较可靠的保障。

上图呈现了 Delta lake 的 Multi-hop Medallion 架构，即通过多个表结构来提供不同分析场景的支持。数据可以通过 streaming 的方式流入 Delta Lake，也可以使用 batch 方式导入。

Delta Lake 里的表可以分为三类：

第一类：数据最先导入的表称为 bronze table。direct 事务的特性能够保证在 bronze table 中数据的可靠性，因此它是整个数据湖的 source of truth（事实表）。某些场景可以直接读取 bronze table。
第二类：如果对数据有更高的要求，希望对数据做一些清洗，可以通过 silver 表来实现。它的结构更清晰也更规范，能够支持一些机器学习或其他简单的分析场景。
第三类：如果分析对数据的质量要求非常严格，可以在 Gold table 的基础之上做进一步演进，特征抽取和聚合之后生成 Gold table，可以做更高级别的分析。

Delta lake 底层提供了一种基于事务日志的机制来实现 ACID 的事务特性，能够实现读写数据的一致性，同时提供较高质量的数据保证。

在 ACID 事务的基础之上，Delta lake 提供了更多的数据管理及性能优化特性，比如时间回溯、数据版本等，能够基于它的事务日志回溯到某个时间或某个版本的数据；同时还可以实现数据的高效 upsert 和 delete，以及可扩展的元数据管理的能力。

在大数据的场景下，元数据管理本身可能会成为一种负担，因为对于较大的表来说，元数据本身就能成为大数据。所以如何高效地支持元数据管理，也是对架构挑战。

Delta lake 事务日志场景下，元数据是以文件形式存储在事务 log 里，因此可以借助 Spark 这种大数据引擎，来实现数据元数据的扩展性。同时 Delta lake 还能够提供统一的流批方式，可以以统一的方式对数据的注入提供支持，上述实现的前提是说因为 Delta lake 能够支持可串行化的隔离级别，实现一些典型的流式需求，比如 CDC。

同时，为了保证数据湖中的数据质量，Delta lake 也提供了 Schema 的强制约束以及自动演化的能力。

此外，在 Delta lake 的商业版本里，还提供了数据库中的数据布局自动优化的能力，同时实现了传统数仓数据库一系列性能优化特性，比如缓存、索引等优化能力。

发展回顾

Delta lake 项目最早开源在2019年4月，事务、流批一体等最核心的功能在0.1版本都已实现。此后，Delta Lake 便致力于易用性和开放性的方向在不断努力，Lakehouse 也开放了更多技术在开源社区。

0.2-0.4版本：提供了对不同云对象存储的支持；0.3版本在 API 层面的能力也逐渐增强，同时支持了一些常见的 DML 操作；0.4版本支持了将 parquet 表格式直接转换成Delta。
0.5版本：Delta lake 开始尝试对 Spark 之外的查询引擎提供读场景的支持，这也是社区第一次在 Spark 之外提供引擎的支持，也是 Delta lake 开放性目标的一部分；同时0，5版本还提供了一些优化的特性，以及通过 SQL 的方式直接将 parquet 转成 Delta 。
0.6版本：Delta Lake 做了一些 Schema 的演化性支持，同时对 merge 性能也提供了进一步优化，对比如 describe history 的命令提供了更多 metrics 信息。
0.7版本：随着 Spark3.0的开源，Delta lake 提供了 Spark3.0的兼容。并且基于 Spark3.0提供了更多特性：在元数据层面，支持读取 Hive metastore 元数据，因为元数据本身是 transaction log 事务日志的一部分，所以有了 Hive metastore 的支持，就能够与其他引擎比如 presto 去共享元数据；在易用性方面，从 SQL 层面提供了对 dml 的支持。
0.8版本：Delta lake 主要贡献是在 merge 操作上提供了更多性能增强的特性，同时支持了 VACUUM 的并发删除能力。
2021年5月，Delta lake1.0版本正式发布。

纵观 Delta lake 的发展历程，可以清晰地看出，它一直坚定地朝着 Everywhere——支持更多元、更开放的生态发展。

Delta Lake 1.0+

上图展示了 Delta lake 1.0的一些核心特性。

首先是 Generated Columns 特性，这里将以一个示例对特性做介绍。

大数据开发场景里有一个比较典型需求：对数据表做分区。比如对日期字段做分区，但是在写入表之前的原始数据里可能并没有日期字段，而是时间戳字段。如上图，eventTime 本身是时间戳，但是数据中并没有 eventDate 的类型。那么应该如何做分区？

方案1：直接使用时间戳的字段做分区。时间戳是一个比较细粒度的字段，使用它来做会产生大量的分区，对于查询性能会造成非常大的影响。因此，此方案被排除。
方案2：数据写入表之前手动维护额外字段。比如从 eventTime 字段中抽取得到 eventDate。但这需要人工维护字段，而但凡涉及到人工，就容易引入错误，尤其是多种数据源同时写入的情况，要求对多种数据源同时做转换，极易出现差错。

因此 Delta Lake1.0 提供了 generated columns，它是一种特殊类型的列，它的值可以根据用户指定的函数自动生成。

可以通过如上图简单的 SQL 语法，将 eventTime 转换成 date 类型，从而生成 eventDate 字段。整个过程自动完成的，用户只需要在最开始创建表的时候提供这个语法即可。

Delta lake1.0提供的第二个重要特性是Standalone。它的目标是可以在Spark之外对接更多引擎，但是诸如Presto、Flink等引擎本身并不需要依赖Spark，如果Delta lake只能强绑定Spark就违背了Delta lake开放性的目标。

于是社区推出了Standalone，它在jvm层面实现了对Delta lake事务协议的处理。有了Standalone，后面会有更多引擎接入进来。Standalone最早版本只提供了Reader，随着今年年初Delta Connector 0.3.0版本的发布，Standalone也正式开始支持写操作。此外，社区对Flink Sink/Source、Hive以及Presto的支持也正在开发中。

此外，Delta Lake1.0还提供了 Delta-rs Rust 库。目标也是希望通过 Delta-rs 库实现对更多高层编程语言的支持，使 Delta Lake 更加开放。有了 Delta-rs 库，更多的编程语言，比如 Python、Ruby 语言可以直接访问 Delta Lake table。

依赖 Delta-rs Rust 库，Delta Lake1.0版本提供了两种 Python 库的安装选项，可以直接使用 pip install 的方式安装；此外，如果不想依赖于 Spark，也可以简单地使用 pip install Deltalake 命令行完成对 Delta Lake 的安装。安装完之后，即可直接使用 Python 读取 Delta 表的数据。

最早的 Delta Lake 是 Spark 的一个子项目，因此 Delta Lake 对 Spark 引擎的兼容性做得非常好。同时，由于 Spark 社区发展迅速，能够第一时间兼容 Spark 也是 Delta Lake社区的首要目标。所以在1.0版本，Delta Lake 首先兼容了 Spark 3.1，并对其提供的一些特性进行优化，以便第一时间在 Delta Lake 里投入使用。

很多企业在使用 Delta Lake 的时候，一个常用场景是使用单一集群去访问/关联一个存储系统。有 Delta Lake1.0对此提供了 Delegating Log Store 功能，通过 log store 的方式来支持不同云厂商的对象存储系统，以便能够支持混合云部署的场景，同时也可以避免对单一云服务商产生 locking 绑定的情况。

未来展望

未来，Delta Lake 社区会朝着一个更加开放的方向发展。

除了借助于前文提到的核心功能，Delta Lake 还能够连接 Spark 之外的引擎类产品。上图展示了相关功能的上线计划。

社区版的 Delta Lake 里，目前有两个特性的呼声比较高，分别是 Optimize 和 Z-Ordering。这两个特性在 Databricks 目前开源的 Delta Lake 版本里面并没有提供，但是在商业版本里已经做了很好的支持。目前阿里云已经推出了基于 Databricks 商业版本引擎的全托管 Spark 产品 – Databricks 数据洞察，除了此处列出的 Optimize 及 Z-Ordering，可以在上面体验到更多商业版 Spark 及 Delta 引擎特性。除此之外，阿里云 E-MapReduce 产品上也对 Optimize 和 Z-Ordering 提供了阿里云自研的实现。

Databricks 数据洞察产品是基 Databricks 的引擎提供的全托管数据平台，它最核心的部分是 Databricks 引擎，Databricks RunTime 提供了商业版的 Delta Engine 以及 Spark 引擎。相比于开源的 Spark 和 Delta，商业版在性能上有非常大的提升。

最后，看一下 Delta Lake 当前在全球范围内的应用情况，越来越多的企业已经开始使用 Delta Lake 来构建 Lakehouse。从 Databricks 给的数据看，目前已有超过3000+客户在生产环境中部署了 Delta Lake，每天处理 Exabytes 级别数据量，其中超过75%的数据已采用 Delta 格式。

加入我们

阿里云计算平台事业部开源大数据生态企业团队负责阿里云上大数据开源生态方向的商业化产品接入，合作伙伴包括 Databricks、Confluent、Cloudera、Starburst 等开源领域的明星级企业，目前团队在火热招聘中，期待你的加入，邮箱请联系zongze.hzz@alibaba-inc.com。

我们会在钉群推送精彩文章，邀请技术大牛直播分享。
欢迎钉钉扫码加入交流群一起参与讨论~