获取spark dataframe某列的数据类型_DataBricks推出新一代开源大杀器Delta Lake，助力Spark一统天下...

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

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

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

https://youtu.be/whaV6bMaf5o

的内容。讲课的小哥是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这样既全心全意为人民服务，更全心全意为人民币服务的公司，任何的举动我们都应该从技术和商业两个方面去分析。