新粉请关注我的公众号
我很久没写大数据的东西了，最主要的原因是因为我不知道写啥。这个领域里面还在发生着很多事情，但是有深度的，有意义的事情不多，有趣的事情也不多。
最近看到了Apache Kyuubi这个项目，应该严格的说是Apache Kyuubi（incubating）。项目还在孵化器中，并没有升级成为Apache的正式项目。
这是一个挺有趣的项目，所以我打算来写写。
我花了一点时间去了解这个项目的实际情况，发现这个项目是由网易开源的，还是有点吃惊。
Kyuubi是一个什么项目呢？我们用它自己的英文介绍来说明一下：
Kyuubi is a distributed multi-tneant Thrift JDBC/ODBC server for large-scale data management, processing, and analytics, built on top of Apache Spark and designed to support more engines(Apache Flink). It has been open-sourced by NetEase since 2018. We are aiming to make Kyuubi an "out-of-the-box"tool for data warehouses and data lakes.
这个英文比较简单，我就不翻译了。我们还是用通俗易懂的方式来说一下吧。我在这里提到过，HIVE严格意义上来说是个数据仓库。
假设回到2012年，某个互联网公司用HIVE建了一个巨大无比的数据仓库，存储用HDFS，计算用MapReduce/Tez。
HIVE这个东西的架构在有些方面还是很好的，比如说，它实现了一个Thrift JDBC/ODBC server，这样，客户端用JDBC就可以直接和HIVE打交道了。用户只需要输入HIVE-QL就可以对数据进行查询和操作了。
当然这是理想情况，当然计算很慢。当然有很多缺陷。但是这并不妨碍一个公司围绕这个HIVE的数据仓库做一些周边开发，包括内部的web tool的开发，无非就是通过JDBC连过去。
然而现在我们是在2022年了，Spark/Flink/Trino无论哪个作为SQL的计算引擎，显然都比HIVE自带的强多了。然而我们很难把它们作为一个数据仓库来使唤。
最起码的一点，我们不能简单的像HIVE那样，通过一个JDBC链接，输入SQL,就可以操作数据了。
Kyuubi做的事情很简单，就是搭了一个多租户的JDBC/ODBC Thrift server，这个server的通讯方式和HIVE Server 2兼容。然后在后台对租户绑定一个计算引擎，比如说Spark。
理论上讲，把HIVE的整个数据仓库迁移到Kyuubi上很简单，只需要把HIVE Server 2换成Kyuubi，把后面换成Spark的cluter，然后再把查询语言换成Spark SQL就行了。
当然实际上可能要更复杂一点，因为Spark SQL对HIVE-QL的兼容性问题，其实没有想的那么好。网易踩了很多坑，也替社区挖出了很多兼容性问题。所以现在其他人再用，就不会有同样的烦恼了。
Spark作为一个计算引擎来说，用作纯数仓的环境下也有可以提高的地方。所以Kyuubi也提供了一些Spark的插件，对一些东西，主要是Adaptive Query Execution的方面，进行了额外的优化。
当然，关于这个项目，我的介绍就非常简单了。我本人的目的也不是说要给出技术细节。毕竟我花休息时间去看看学习一下这个东西，能够了解的技术细节是有限的。
重点来了，为什么我觉得这个项目很有趣呢？因为它解决了一个很多企业迫切需要，但是Databricks却不会去做的事情。
这件迫切需要的事情就是很多企业希望一个更快的但是能够和HIVE很好兼容的数仓。
这事情说容易也容易，说不容易也不容易。因为大家都知道，最好的办法就是用Spark SQL作为语言，背后依托Spark的强大计算能力。
但是这样一个纯数仓的模式，把Spark的使用限定在纯Spark SQL的范围内，却不太符合Databricks自己对Spark的定义。Databricks更喜欢LakeHouse，就是既是湖又是仓，杂交的那个东西。
所以需求一直存在，Spark社区却不会真的投入大量精力来解决。即使要解决，也就是给个玩具。
我相信不止一个公司肯定想要这样一个解决方案，但是网易做了，系统开源了，而且整体设计上很灵活，给SQL爱好者提供了很多的想象空间。
虽然到今天纯SQL已经不是唯一的数据处理和查询的方案了，然而SQL的生命力始终都是强盛，纯SQL依然也有很大的空间。
这个项目和相关信息一开始是我在看ApacheCon视频的时候看到的。我觉得有趣以后又花了时间去研究了一下。
