分享

深度分析Spark最新大杀器Delta Lake

 Richard孝恩 2019-07-13

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

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

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

https:///whaV6bMaf5o

的内容。讲课的小哥是DataBricks的大神Michael Armburst。他负责Structured Stream和Delta Lake。第二部分会给出我个人的一些看法。

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

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

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

深度分析Spark最新大杀器Delta Lake

如上面的图片,我基本上完整的保留了整个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这样既全心全意为人民服务,更全心全意为人民币服务的公司,任何的举动我们都应该从技术和商业两个方面去分析。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多