聊聊DatabricksSQL和Apache Kyuubi

新粉请关注我的公众号

昨天写了一篇文章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搭个更现代化的数仓。

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

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