Apache Kyuubi(Incubating)（下文简称Kyuubi）是⼀个构建在Spark SQL之上的企业级JDBC网关，兼容HiveServer2通信协议，提供高可用、多租户能力。Kyuubi 具备可扩大的架构设计，社区正在致力使其可能反对更多通信协议（如 RESTful、 MySQL）和计算引擎（如Flink）。

Kyuubi的愿景是让大数据平民化。一个的典型应用场景是替换HiveServer2，帮忙企业把HiveQL迁徙到Spark SQL，轻松取得10~100倍性能晋升（具体晋升幅度与SQL和数据无关）。另外最近比拟火的两个技术，LakeHouse和数据湖，都与Spark联合得比拟严密，如果咱们能把计算引擎迁徙到Spark上，那咱们离这两个技术就很近了。

Kyuubi最早起源于网易，这个我的项目自诞生起就是开源的。在Kyuubi倒退的前两年，它的应用场景次要在网易外部。自从2020年底进行了一次架构大降级、公布了Kyuubi 1.0之后，整个Kyuubi社区开始沉闷起来了，我的项目被越来越多的企业采纳，而后在往年6月进入了Apache基金会孵化器，并在往年9月公布了进入孵化器后的第一个版本1.3.0-incubating。

Kyuubi vs SparkThriftServer vs HiveServer2

咱们通过Kyuubi和其余SQL on Spark计划的比照，看看用Kyuubi替换 HiveServer2能带来什么样的晋升。图中对Hive Server2标记了Hive on Spark，这是Hive2的一个性能，最早的Hive会把SQL翻译成MapReduce来执行，Hive on Spark计划其实就是把SQL翻译成Spark算子来执行，然而这仅仅是物理算子的替换，因为复用了Hive的SQL解析逻辑，所以SQL方言还是HiveQL，包含后续SQL的改写、优化走的都是Hive的优化器。Spark2放弃了Hive on Spark计划，抉择从头开始做SQL解析、优化，发明了Spark SQL和Catalyst。所以说，Spark Thrift Server只是兼容了HiveServer2的Thrift通信协议，它整个SQL的解析、优化都被重写了。

Kyuubi也是用Spark来解析、优化和执行SQL，所以对于用户来说，客户端与服务端的通信协议是截然不同的，因为大家兼容的都是HiveServer2的通信协议。然而在SQL方言上，Kyuubi和Spark Thrift Server是Spark SQL，HiveServer2是HiveQL。SQL的编译和优化过程，HiveServer2在本过程上进行，Spark是在Driver端进行。对于STS，Thrift Server和Driver在同一个过程内；对于Kyuubi，Thrift Server和Spark Driver是拆散的，它们能够跑在同一台机器上的不同过程（如YARN Client模式），也能够跑在不同的机器上（如YARN Cluster模式）。

对于执行阶段，当一条SQL提交后，HiveServer2会将其翻译成了一个Spark Application，每一次SQL提交就会生成一个全新的Spark的利用，都会经验Driver的创立、Executor的创立过程，SQL执行完结后再将其销毁掉。Spark Thrift Server则是齐全相同的形式，一个Spark Thrift Server只持有一个Driver，Driver是常驻的，所有的SQL都会由这一个Driver来编译、执行。Kyuubi不仅对这两种形式都反对，还反对了更灵便的Driver共享策略，会在后续具体介绍。

Kyuubi on Spark与CDH集成

CDH是应用最宽泛的Apache Hadoop发行版之一，其自身集成了Spark，然而禁用了Spark Thrift Server性能和spark-sql命令，使得用户只能通过spark-shell、spark-submit应用Spark，故而在CDH上应用Spark SQL具备肯定的门槛。在CDH上SQL计划用得更多的往往是Hive，比如说咱们能够通过Beeline、HUE连贯HiveServer2，来进行SQL批工作提交或交互式查问，同时也能够通过Apache Superset这类BI工具连贯到HiveServer2上做数据可视化展现，背地最终的计算引擎能够是MapReduce，也能够是Spark。

当咱们引入Kyuubi后，图中左侧的这些Client都是不须要更改的，只须要部署Spark3和Kyuubi Server（以后Kyuubi仅反对Spark3），再把Client连贯地址改一下，即可实现从HiveQL到Spark SQL的迁徙。当然其间可能会碰到HiveQL方言跟Spark SQL方言的差异性问题，能够联合老本抉择批改Spark或者批改SQL来解决。

Kyuubi中有一个重要的概念叫作引擎共享级别（Engine Share Level），Kyuubi通过该个性提供了更高级的Spark Driver共享策略。Spark Engine与Spark Driver概念是等价的，都对应一个Spark Application。Kyuubi目前提供了三种Engine共享级别，SERVER、USER和CONNECTION，缺省是USER模式。

SERVER模式相似Spark Thrift Server，Kyuubi Server只会持有一个Spark Engine，即所有的查问都会提交到一个Engine上来跑。USER模式即每个用户会应用独立的Engine，能做到用户级别的隔离，这也是更具普适性的一种形式，一方面不心愿太浪费资源，每个SQL都起一个Engine，另一方面也心愿放弃肯定的隔离性。CONNECTION模式是指Client每建设一个连贯，就创立一个Engine，这种模式和Hive Server2较为相似，但不完全一致。CONNECTION模式比拟适宜跑批计算，比方ETL工作，往往须要数十分钟甚至几个小时，用户不心愿这些工作相互烦扰，同时也心愿不同的SQL有不同的配置，例如为Driver调配2G内存还是8G内存。总的来说，CONNECTION模式比拟适宜跑批工作或者大工作，USER模式比拟适宜HUE交互式查问的场景。

大家可能会放心，咱们是不是对Spark做了很厚的一层包装，限度了很多性能？其实不是的，所有的Spark的configuration在Kyuubi中都是可用的。当一个申请发送给Kyuubi时，Kyuubi会去找一个适合的Engine跑这个工作，如果找不到它就会通过拼接spark-submit命令来创立一个Engine，所以所有的Spark反对的configuration都能够用。如图中列举了YARN Client和YARN Cluster两种模式，怎么写配置，Spark Driver就跑在什么中央，改成K8s，Driver就跑在Kubernetes外面，所以Kyuubi对Kubernetes的反对也是瓜熟蒂落的。

还有一个用户常问的问题，是不是USER模式或者CONNECTION模式，每一个场景都须要独自部署一套Kyuubi Server？不须要。咱们能够把罕用的配置固化在kyuubi-defaults.conf外面，当Client连贯Kyuubi Server时，能够通过在URL外面写一些配置参数来笼罩默认配置项，比方缺省应用的是USER模式，提交批工作时抉择CONNECTION模式。

Kyuubi 引擎隔离级别的实现

Kyuubi多种灵便的隔离级别是怎么实现的？下图绿色的组件即Service Discovery Layer，目前通过ZooKeeper实现，但它实质上是一个服务注册/发现的组件。咱们曾经发现有开发者把Kyuubi集成到Kubernetes上，用API Server来实现Service Discovery Layer，该性能目前还没有提交给社区。

上图中的User Side即Client侧，社区目前策略是齐全兼容Hive的Client，以更好的复用Hive生态。Hive自身通过ZooKeeper实现了Client侧的HA模式，Server启动当前，会将本身依照肯定的规定注册到ZooKeeper外面，Beeline或者其余Client连贯的时候，将连贯地址设置成ZooKeeper集群的地址，Client即能够发现指定的门路下所有的Server，随机抉择其中一个来连贯。这是HiveServer2协定的一部分，Kyuubi是齐全兼容的。

Kyuubi Server与Engine之间也应用了相似的服务注册与发现机制，Engine在Zookeeper上的注册门路会恪守肯定的规定，例如在USER隔离级别下，门路规定是/kyuubi_USER/{username}/{engine_node}。Kyuubi Server接到连贯申请，会依照规定从特定门路下查找可用的Engine节点。若找到，间接连贯该Engine；若找不到，创立一个Engine并期待其启动实现，Engine启动实现后，会依照雷同的规定在指定门路下创立一个engine节点，并把本人的（蕴含连贯地址、版本等）填写到节点里。在YARN Cluster模式下，Engine会被调配到YARN集群任意节点启动，正是通过这种机制，Server能力找到并连贯Engine。

对于CONNECTION模式，每一个Engine只会被连贯一次，为了实现这个成果，Kyuubi设计了如下的门路规定，/kyuubi_CONNECTION/{username}/{uuid}/{engine_node}，通UUID的唯一性来实现隔离。所以Kyuubi实现引擎隔离级别的形式是一个非常灵活的机制，咱们目前反对了SERVER、USER和CONNECTION，但通过简略的扩大，它就能够反对更多更灵便的模式。在代码主线分支上，社区目前曾经实现了额定的两个共享级别，一个是GROUP，能够让一组用户来共享一个Engine；另外一个是Engine Pool，能够让一个用户来应用多个Engine以进步并发能力，一个实用的场景是BI图表展现，例如为Superset配置一个Service Account，对应多个Engine，当几百个图表一起刷新时，能够将计算压力摊派到不同Engine上。

Kyuubi实际 | 编译Spark3.1以适配CDH5并集成Kyuubihttps://mp.weixin.qq.com/s/lgbmM1qNetuPB0-j-TAzkQApache Kyuubi on Spark 在CDH上的深度实际https://my.oschina.net/u/4565392/blog/5264848

咱们在Kyuubi的官网公众号提供了两篇文章，内容蕴含了将Kyuubi集成到CDH平台上的具体操作过程，第一篇形容了与CDH5(Hadoop2，启用Kerberos)的集成，第二篇形容了CDH6(Hadoop3，未启用Kerberos)的集成。对于集成其余非CDH平台的Hadoop发行版，也具备肯定的参考价值。

Spark 3 个性以及 Kyuubi 带来的加强

动静资源分配

首先是动静资源分配，Spark自身曾经提供了Executor的动静伸缩能力。能够看到，这几个参数配置在语义上是十分明确的，形容了Executor起码能有多少个，最多能有多少个，最大闲置时长，以此管制Executor的动态创建和开释。

spark.dynamicAllocation.enabled=truespark.dynamicAllocation.minExecutors=0spark.dynamicAllocation.maxExecutors=30spark.dynamicAllocation.executorIdleTimeout=120

引入了Kyuubi后，联合方才提到的Share Level和Engine的创立机制，咱们能够实现Driver的动态创建，而后咱们还引入了一个参数，engine.idle.timeout，约定Driver闲置了多长时间当前也开释，这样就实现Spark Driver的动态创建与开释。

kyuubi.engine.share.level=CONNECTION|USER|SERVERkyuubi.session.engine.idle.timeout=PT1H

这里要留神，因为CONNECTION场景比拟非凡，Driver是不会被复用的，所以对于CONNECTION模式，engine.idle.timeout是没有意义的，只有连贯断开Driver就会立即退出。

Adaptive Query Execution

Adaptive Query Execution（AQE）是Spark 3带来的一个重要个性，简而言之就是容许SQL边执行边优化。就拿Join作为例子来说，等值的Inner Join，大表对大表做Sort Merge Join，大表对小表做Broadcast Join，但大小表的判断产生在SQL编译优化阶段，也就是在SQL执行之前。

咱们思考这样一个场景，两个大表和大表Join，加了一个过滤条件，而后咱们发现跑完过滤条件之后，它就变成了一个大表和一个小表Join了，能够满足Broadcast Join的条件，但因为执行打算是在没跑SQL之前生成的，所以它还是一个Sort Merge Join，这就会引入一个不必要的Shuffle。这就是AQE优化的切入点，能够让SQL先跑一部分，而后回头再跑优化器，看看能不能满足一些优化规定来让SQL执行得更加高效。

另一个典型的场景是数据歪斜。咱们讲大数据不怕数据量大，然而怕数据歪斜，因为在现实状况下，性能是能够通过硬件的程度扩大来实现线性的晋升，然而一旦有了数据歪斜，可能会导致劫难。还是以Join为例，咱们假设是一个等值的Inner Join，有个别的partition特地大，这种场景咱们会有一些须要批改SQL的解决方案，比方把这些大的挑出来做独自解决，最初把后果Union在一起；或者针对特定的Join Key加盐，比方加一个数字后缀，将其打散，然而同时还要放弃语义不变，就是说右表对应的数据要做拷贝来实现等价的Join语义，最初再把增加的数字后缀去掉。

能够发现，这样的一个手工解决计划也是有肯定法则可循的，在Spark中将该过程自动化了，所以在Spark3外面开启了AQE后，就能主动帮忙解决这类Join的数据歪斜问题。如果咱们的ETL工作外面有很多大表Join，同时数据品质比拟差，有重大的数据歪斜，也没有精力去做逐条SQL的优化，这样状况从HiveQL迁到Spark SQL下面能够带来十分显著的性能晋升，10到100倍一点也不夸大！

Extension

Spark通过Extension API提供了扩大能力，Kyuubi提供了KyuubiSparkSQLExtension，利用Extension API在原有的优化器上做了一些加强。这里列举了其中一部分加强规定，其中有Z-order性能，通过自定义优化器规定反对了数据写入时Z-order优化排序的的性能，并且通过扩大SQL语法实现了Z-order语法的反对；也有一些规定丰盛了监控统计信息；还有一些规定限度了查问分区扫描数量，和后果返回数量等。

以RepartitionBeforeWriteHive为例做下简略介绍，这条规定用于解决Hive的小文件写入问题。对于Hive动静分区写入场景，如果执行打算最初一个stage，在写入Hive表之前，DataFrame的Partition散布与Hive表的Partition散布不统一，在数据写入时，每一个task就会将持有的数据写到很多Hive表分区外面，就会生成大量的小文件。当咱们开启RepartitionBeforeWriteHive规定当前，它会在写入Hive表之前按照Hive表的分区插入一个Repartition算子，保障雷同Hive表分区的数据被一个task持有，防止写入产生大量的小文件。

Kyuubi为所有规定都提供了开关，如果你只心愿启用其中局部规定，参考配置文档将其关上即可。KyuubiSparkSQLExtension提供一个Jar，应用时，能够把Jar拷贝到${SPAKR_HOME}/jars上面，或命令参数--jar增加Jar，而后开启KyuubiSparkSQLExtension，并依据配置项来抉择开启特定性能。

Spark on ClickHouse

Data Source V2 API也是Spark3引入的一个重要个性。Data Source V2最早在Spark 2.3提出，在Spark 3.0被从新设计。下图用多种色彩标记不同的Spark版本提供的Data Source V2 API，咱们能够看到，每个版本都加了大量的API。能够看出，DataSourceV2 API 性能非常丰盛，但咱们更看重的是它有一个十分良好的扩展性，使得API能够始终进化。

Apache Iceberg在现阶段对Data Source V2 API提供了一个比拟残缺的适配，因为Iceberg的社区成员是Data Source V2 API次要设计者和推动者，这也为咱们提供了一个十分好的Demo。

ClickHouse目前在OLAP畛域，尤其在单表查问畛域能够说是一骑绝尘，如果咱们能联合Spark和ClickHouse这两个大数据组件，让Spark读写ClickHouse像拜访Hive表一样简略，就能简化很多工作，解决很多问题。

基于Data Source V2 API，咱们实现了并开源了Spark on ClickHouse，除了适配API晋升Spark操作ClickHouse的易用性，也非常重视性能，其中包含了反对本地表的通明读写。ClickHouse基于分布式表和本地表实现了一套比较简单的分布式计划。如果间接写分布式表，开销是比拟大的，一个变通的计划是批改调整逻辑，手动计算分片，间接写分布式表背地的本地表，该计划繁琐且有概率出错。当应用Spark ClickHouse Connector写ClickHouse分布式表时，只需应用SQL或者DataFrame API，框架会自动识别分布式表，并尝试将对其分布式表的写入转化成对本地表的写入，实现主动透写本地表，带来很大的性能晋升。

我的项目地址：
援用
https://github.com/housepower...

下图描述了通过革新之后的新一代数据平台，革新带来了非常显著的收益。在硬件资源不变的状况下，首先，Daily Batch ETL从8个小时降落到了2个小时；其次，通过引入Iceberg和增量同步，数据的时效性是从天级降至十分钟级；第三，膨胀计算引擎，原有平台须要搭配Hive、Elasticsearch、Presto、MongoDB、Druid、Spark、Kylin等多种计算引擎满足不同的业务场景，在新平台中，Spark和ClickHouse能够满足大部分场景，大大减少了计算引擎的保护老本；最初，缩短了数据链路，在以前，受限于RDMS的计算能力，咱们往往在数据展现前须要进行一遍一遍的加工，最终把聚合后果放到MySQL外面，然而当引入ClickHouse当前，通常只有把数据加工成主题大宽表，报表展现借助ClickHouse强悍的单表计算能力，现场计算就能够了，所以数据链路会短很多。

Kyuubi 社区瞻望

最初瞻望一下Kyuubi社区将来的倒退。方才提到了Kyuubi架构是可扩大的，目前Kyuubi兼容HiveServer2，是因为仅实现了Thrift Binary协定；Kyuubi目前仅反对Spark引擎，Flink引擎正在开发中，这项工作由T3出行的社区搭档在做。RESTful Frontend社区也正在做，这样咱们也能够提供RESTful API。咱们还打算提供MySQL的API，这样用户就能够间接应用MySQL Client或MySQL JDBC Driver来连贯。前面附了社区外面相干的issue或者PR。

如下是行将呈现在1.4版本中的一些个性，包含方才曾经提到过的Engine Pool、Z-order、Kerberos相干的解决方案，以及新公布的Spark 3.2的适配工作。

[KYUUBI #913] Support long running Kerberos enabled SQL engine[KYUUBI #939] Add Z-Order extensions to support optimize SQL[KYUUBI #962] Support engine pool feature[KYUUBI #981] Add more detail stats to kyuubi engine page[KYUUBI #1059] Add Plan Only Operations[KYUUBI #1085] Add forcedMaxOutputRows rule for limitation[KYUUBI #1131] Rework kyuubi-hive-jdbc module[KYUUBI #1206] Support GROUP for engine.share.level[KYUUBI #1224] Support Spark 3.2. . .

最初展现一下已知应用Kyuubi的企业，如果你也应用Kyuubi，或者在调研企业级的Spark SQL Gateway计划，有任何相干的问题，欢送能够到咱们社区外面分享、探讨。

GitHub分享页面：
援用
https://github.com/apache/inc...

结语

本文依据网易数帆大数据平台专家、Apache Kyuubi(Incubating) PPMC成员潘成在 Apache Hadoop Meetup 2021 北京站的分享内容整顿，重点结合实际落地的案例讲述了如何实现 Apache Kyuubi(Incubating) on Spark和CDH集成，以及该计划为企业数据平台建设带来的收益，并瞻望了Apache Kyuubi(Incubating) 社区将来的倒退。

Apache Kyuubi(Incubating)我的项目地址：

https://github.com/apache/inc...

视频回放：

https://www.bilibili.com/vide...

案例分享：

Apache Kyuubi 在 T3 出行的深度实际