Delta Lake的演进历史及现状【Databricks 数据洞察公开课】

本文涉及的产品
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介: 从大数据平台架构的演进、Delta Lake关键特性、版本迭代、重要功能等多方面,介绍Delta Lake的演进和优势。

作者:王晓龙 阿里云开源大数据平台技术专家

一、Delta Lake介绍

图片 1.png

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

图片 2.png

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

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

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

图片 3.png

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

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

图片 4.png

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

图片 5.png

有了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,可以做更高级别的分析。

图片 6.png

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

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

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

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

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

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

二、发展回顾

图片 7.png

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的方式直接将parque转成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 Lake1.0+

图片 8.png

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

图片 9.png

首先是Generated Columns特性,这里将以一个示例对特性做介绍。
大数据开发场景里有一个比较典型需求:对数据表做分区。比如对日期字段做分区,但是在写入表之前的原始数据里可能并没有日期字段,而是时间戳字段。如上图,eventTime本身是时间戳,但是数据中并没有eventDate的类型。那么应该如何做分区?

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

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

图片 10.png

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

图片 11.png

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的支持也正在开发中。

图片 12.png

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

图片 13.png

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

图片 14.png

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

图片 15.png

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

四、未来展望

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

图片 16.png

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

图片 17.png

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

图片 18.png

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

图片 19.png

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

相关实践学习
基于EMR Serverless StarRocks一键玩转世界杯
基于StarRocks构建极速统一OLAP平台
快速掌握阿里云 E-MapReduce
E-MapReduce 是构建于阿里云 ECS 弹性虚拟机之上,利用开源大数据生态系统,包括 Hadoop、Spark、HBase,为用户提供集群、作业、数据等管理的一站式大数据处理分析服务。 本课程主要介绍阿里云 E-MapReduce 的使用方法。
目录
相关文章
|
3月前
|
机器学习/深度学习 数据采集 分布式计算
【颠覆传统!】揭秘Databricks如何助力零售业需求预测——从数据到洞察,一秒钟变销售预言家!
【8月更文挑战第9天】随着大数据技术的发展,数据驱动决策日益关键,尤其在零售业中,通过分析历史销售数据预测未来趋势变得至关重要。本文探讨如何运用Databricks平台优化零售业需求预测。Databricks是一个基于Apache Spark的统一数据分析平台,能高效处理大规模数据任务。通过示例代码展示数据读取、预处理及建模过程,相较于传统方法,Databricks在数据处理能力、可扩展性、内置机器学习库以及协作版本控制方面展现出显著优势,帮助零售商优化库存管理、提升客户体验并增加销售额。
87 8
|
存储 分布式计算 数据挖掘
【数据湖仓架构】数据湖和仓库:Databricks 和 Snowflake
【数据湖仓架构】数据湖和仓库:Databricks 和 Snowflake
|
存储 SQL 分布式计算
【数据湖仓】数据湖和仓库:Databricks 和 Snowflake
【数据湖仓】数据湖和仓库:Databricks 和 Snowflake
|
消息中间件 存储 SQL
使用Databricks+Confluent进行实时数据采集入湖和分析【Databricks 数据洞察公开课】
本文介绍网约车模拟数据从产生,发布到流数据服务 Confluent,通过Databricks Structured Streaming进行实时数据处理,存储到LakeHouse,并使用spark和spark sql进行分析的应用实践。
696 0
使用Databricks+Confluent进行实时数据采集入湖和分析【Databricks 数据洞察公开课】
|
机器学习/深度学习 存储 数据采集
使用 Databricks 进行营销效果归因分析的应用实践【Databricks 数据洞察公开课】
本文介绍如何使用Databricks进行广告效果归因分析,完成一站式的部署机器学习,包括数据ETL、数据校验、模型训练/评测/应用等全流程。
747 0
使用 Databricks 进行营销效果归因分析的应用实践【Databricks 数据洞察公开课】
|
机器学习/深度学习 存储 弹性计算
使用Databricks+Mlflow进行机器学习模型的训练和部署【Databricks 数据洞察公开课】
介绍如何使用Databricks和MLflow搭建机器学习生命周期管理平台,实现从数据准备、模型训练、参数和性能指标追踪、以及模型部署的全流程。
1067 0
使用Databricks+Mlflow进行机器学习模型的训练和部署【Databricks 数据洞察公开课】
|
存储 SQL JSON
Delta Lake基础介绍(开源版)【Databricks 数据洞察公开课】
针对社区版本Delta Lake提供的几大核心特性进行讲解,并通过示例演示如何使用这些特性。
878 0
Delta Lake基础介绍(开源版)【Databricks 数据洞察公开课】
|
SQL 分布式计算 资源调度
使用Databricks进行零售业需求预测的应用实践【Databricks 数据洞察公开课】
本文从零售业需求预测痛点、商店商品模型预测的实践演示,介绍Databricks如何助力零售商进行需求、库存预测,实现成本把控和营收增长。
537 0
使用Databricks进行零售业需求预测的应用实践【Databricks 数据洞察公开课】
|
存储 SQL 人工智能
如何使用Delta Lake构建批流一体数据仓库【Databricks 数据洞察公开课】
Delta Lake是一个开源存储层,它为数据湖带来了可靠性。Delta Lake提供了ACID事务、可扩展的元数据处理,并统一了流式处理和批处理数据处理。Delta-Lake运行在现有数据湖之上,并且与Apache Spark API完全兼容。希望本篇能让大家更深入了解Delta Lake,最终可以实践到工作当中。
470 0
如何使用Delta Lake构建批流一体数据仓库【Databricks 数据洞察公开课】
|
SQL 存储 分布式计算
Delta Lake的演进历史及现状【Databricks 数据洞察公开课】
从大数据平台架构的演进、Delta Lake关键特性、版本迭代、重要功能等多方面,介绍Delta Lake的演进和优势。
1086 4
Delta Lake的演进历史及现状【Databricks 数据洞察公开课】