聊聊DatabricksSQL和Apache Kyuubi

2022-05-05 13:47:42 浏览数 (1)

新粉请关注我的公众号

昨天写了一篇文章Apache Kyuubi:一个有趣的大数据开源项目,介绍了网易开源的Apache Kyuubi,是如何把Spark变成为一个数仓的。

有一些人联系我,有问我是不是不知道有个产品叫Databricks SQL的,也有问我Databricks SQL和这个比起来怎么样。

有这么多问题,我想我应该没办法一个接一个回答。所以我还是简单写一篇文章。

首先,大家不用怀疑我知道还是不知道Databricks SQL这个产品。我是不是大数据专家这一点大家可以质疑。我是不是大数据八卦专家,大家就不用质疑了。

对于大数据领域的各个产品,不管是收费的还是免费的,尤其是拳头公司的产品,我始终都保持一定的关注度的。所以Databricks SQL这个东西呢,它宣布的时候我就知道了。

那么我为什么不大张旗鼓的介绍Databricks SQL呢?也很简单,收费的大数据产品,到底有多少开源社区的人和互联网企业愿意掏钱用,肯定是个问题。尤其是国内的用户。

我日常工作的时候需要研究收费的东西,往往也是很少的情况下才需要。当然,如果有个公司愿意给飞总恰饭的机会,来聊聊收费的产品,我是很乐意的。

Databricks SQL是不是个好东西呢?肯定有很多方面比Apache Kyuubi强。我简单举两个吧。第一个呢,它用的引擎是C 的,跑出了最快的TPC-DS,还和Snowflake撕逼了一把,创始人连发好几篇blog。

这事情出来我就写过文章了:刺刀见血,Databricks说Snowflake为了测试结果好看改了TPC-DS的输入数据

而Apache Kyuubi用的是开源的Spark。开源Spark是干儿子不是亲儿子,Databricks肯定不会把最好的那些东西都开源出来的。穷人的快乐,不值得享受那些高档货。

再举个例子,Databricks有个叫Cloud Fetch的功能,号称可以大幅度提高BI工具取回查询结果的速度。具体原理呢,就是查询可以并行的写到cloud storage里,比如S3,然后给BI端返回一系列的URL。用的格式是ARRO这个标准的开源内存格式。

当然Databricks也承认,如果文件足够小,写进S3也是要时间的,还不如直接传来的快,所以它们搞Hybrid模式。

这一听就高大上多了,比Kyuubi的简单的JDBC/ODBC Thrift Server牛逼太多了。

这篇文章里我不想深入去分析Databricks SQL。有很多原因。其中一个原因是所有闭源的东西,我的读者里面很多是不愿意花钱去用的,受众的问题。里面即使有想用Databricks的,中国的人可能给钱也不见得能用圈套,虽然阿里巴巴上已经上线了。

另外一个原因就是既然不是开源的,我对它的技术分析也好,了解也罢,只能基于Databricks公开的信息,和我个人在这个领域的经验去猜测,这不仅累还容易吃力不讨好。

所以我对Databricks SQL也就点到即止。

但是Databricks SQL和Apache Kyuubi最大的不同就是前者你交钱给Databricks。Databricks也没兴趣开源。

如果不是Iceberg在折腾的很凶的话,我估计Databricks连Delta Lake都不见得开源。而且即使开源了,最核心的Data Skipping和Z-Order也没开源出来。

所以除非将来Apache Kyuubi真的很牛逼了,牛逼到威胁到Databricks的生意了,否则的话,我觉得两个产品就没有任何可比性。

Databricks SQL是完全云端的服务,需要交钱才能用。更重要的一点,一些功能比如说Cloud Fetch,是需要有云存储才能实施的。

而Apache Kyuubi就简单了,你当年HIVE怎么用,现在还是可以怎么用。当然,也没反对你基于云端的存储和Spark on K8S搭个更现代化的数仓。

但是核心的问题就一个,穷人的快乐和有钱人的快乐的区别。至于我呢,我从来都不反对有钱人的快乐啊。但是也不妨碍我介绍介绍穷人的快乐吧。

有钱人的快乐我就留着给机会恰饭好了。穷人的快乐,是如此的朴实无华,我估计想恰饭都难。

0 人点赞