DataBricks新项目Delta Lake的深度分析和解读。

本文属于比较深度的分析文章,需要读者对大数据架构有一定的了解。初学者慎入。

DataBricks最近新开源了一个项目Delta Lake。这其实不算是个新项目了。DataBricks在其商业版里面提供这样的功能已经有一段时日了。对我来说Delta Lake就是久闻大名,但是不知道庐山真面目。

当然以DataBricks一贯的既要为人民服务,更要为人民币服务的做法,开源出来的Delta Lake肯定不是其内部商业版的全部。但是即便如此也可以让我们管中窥豹了。

文章分两部分。第一部分介绍一下Delta Lake的一些情况,主要是基于:

的内容。如果要看原版视频的话,可能需要一点科学上网的技巧。讲课的小哥是DataBricks的大神Michael Armburst。他负责Structured Stream和Delta Lake。第二部分会给出我个人的一些看法。

图中展示的是一个之前非常著名的lambda架构,简单来说就是数据的一部分用批处理来获取准确值,但是需要时间,另外一个pipeline用streaming的方式来获取非精确但是及时的值。当然这张图里面是有点给Spark贴金了。标准Lambda出来的时候,流引擎主要是storm,而批处理引擎最常用的HIVE。当然作为DataBricks公司出品的PPT,这样去写也是可以理解的。

如上面的图片,我基本上完整的保留了整个PPT。Delta Lake可以理解为一个文件存储方式。它在一个目录上同时存了transaction log和数据文件。并且它可以通过用spark处理transaction log来生成不同的checkpoint,和对应的数据文件。它同时也支持了事务处理。Delta Lake同时可以作为Streaming的Source和Sink,这无疑是很强有力的。

从一个做数据库的人的角度来说,Delta Lake的实现机制上,没有让我觉得特别吃惊的先进技术,有的是数据库系统几十年内使用过的经典技术。但是没有新技术不代表Delta Lake这个东西不好。Delta Lake这个东西解决的是问题很多之前BI和数仓,现在大数据应用里必不可少的。从这个角度上来说,这个开源项目很有前途。

Delta Lake里面很多的地方采用复用Spark的方式来处理Delta Lake的问题。比如说可以通过读取transaction log来分析出哪些partion哪些文件是需要读的,做Partition pruning。又比如说来做checkpoint。Partition pruning本身不是什么新鲜技术。使用引擎自己去处理自身的想法,我在微软做的时候也实现过一些类似的东西。但是大数据开源项目里这应该是头一遭。这是非常精细的想法。

这里我需要补充一点我个人的经验。要了解数据库和大数据的动向,一定要时刻关注Michael Stonbraker的讲话,论文等等。他虽然经常夹杂着很多个人的私货,但是依然是数据库圈子里最有洞见的人。你所需要做的,就是区分哪些是私货,哪些是真知灼见。

比如说2015年他来清华给了21世纪的计算的讲话,里面大量夹杂自己私货的同时也给出了很多真知灼见。对Spark他当时说这个东西现在只是个数据处理引擎,但是很有意思。它会变,要关注。我当时在想,数据处理引擎和传统DB来说还是差很多的,DataBricks是不是会一脚伸进存储层,后来就听说了Delta Lake。

当然万事不能尽善尽美。个人喜好也不同。Delta Lake也有一些我不喜欢的地方。比如说,把transaction log和数据文件放在一个目录里,但是并没有任何保护措施。这就意味着用户可以不经过spark就去读取和改变数据文件或者日志文件,从而造成两者之间的不一致。这是我在产品设计开发里面不喜欢的。一个东西如果很容易就被人破坏,那就有很多潜在的危险。好的软件不应该是这样的。

Delta Lake选择用Parquet来做数据文件,我可以理解是兼容性的问题。为了让社区放心不会被lock in。但是既然有了metadata存储的地方,其实是不是应该用parquet就是一个两可的问题了。有些数据类型也许其他的格式会更合适。

在Talk里Michael Armburst提到,他一开始以为只要有了transaction log就不需要HCatalog了,后来发现HCatalog还是有用的,因为那里可以给一个组织提供一个全局视图,告诉大家有哪些数据。他还提到HCatalog的整合会指向这些transaction log。

说实话都9102年了,开源社区都还没有一个让我满意的Catalog,实在是一个遗憾。一个好用的Catalog,其实不是那么难。但是一系列的后续技术实现都构建在一个好用的Catalog上。比如说最简单的企业需要的权限管理。没有Catalog简直寸步难行。

我很难想象一个企业不需要权限管理。尤其是精确到某行某列的权限管理。这种东西对企业是刚需,而Delta Lake现在的做法是搞不定的。总不能这些东西全写进transaction log吧。

有一个好的Catalog,另外一个方面,对最新版本的数据的metadata,也可以直接从Catalog里读取。而不需要再去transaction log里扒。很多简单的partition pruning可以直接做掉了。用不着再起一个spark job去做。

所以这个Delta Lake的设计里,没有一个Catalog,在我看来是挺遗憾的。尤其是企业市场上,精细的权限管理完全没办法做。当然你可以说Hadoop里本来就没办法做。这也是我觉得开源社区折腾那么多年居然连一个像样的Catalog都没有做出来,实在是有点joking。

以上是我的一些简单分析和看法。当然我更好奇的是DataBricks的企业版和这个开源版有什么区别。为什么内部折腾那么久之后最终开源了一个阉割版给大家。毕竟对于DataBricks这样既全心全意为人民服务,更全心全意为人民币服务的公司,任何的举动我们都应该从技术和商业两个方面去分析。