​导读： 本文将对 Apache Kyuubi 1.6.0 版本特性进行解读。

主要包括以下四个部分：

1. 服务端增强

2. 客户端增强

3. 引擎插件

4. 社区展望

分享嘉宾｜蒋晓峰 Bilibili 资深开发工程师

编辑整理｜张建闯 BOSS直聘

出品社区｜DataFun

01/服务端增强

1. 支持批（JAR）任务提交

Apache Kyuubi 是网易数帆开源的一款企业级的数据湖探索平台，也是一款分布式和多租户网关，为数据湖查询例如 Spark、Flink 或者 trino 等提供 SQL 查询服务。Kyuubi 支持多租户、高可用以及多工作负载等功能特性，可以满足企业内部诸如 ETL、BI 报表、交互式分析以及批数据处理等多种大数据场景的应用。

首先介绍一下 Apache Kyuubi 1.6.0 针对服务端增强引入了一些新特性。

Kyuubi 1.6.0 支持批（JAR）任务提交。Kyuubi 本身支持 SQL，但是很多公司不仅有 SQL 任务，还有 JAR 任务，在这里称之为 Batch 任务，这时 Kyuubi 已有的功能就无法满足 ETL 需求。在 Kyuubi 1.6.0 版本中提供了一个通过 Restful API 形式提交 Batch 任务，实现 Kyuubi Batch 的功能。

Kyuubi Batch 功能的实现设计如图所示，用户首先需要通过 POST 方式向 Kyuubi Server 发送一个 Create Batch 的请求，Kyuubi Server 接收到请求后，会立即返回 BatchId，Kyuubi Server 会使用这个 BatchId 作为一个 tag 传入 Spark 中，加入到 Spark submit 的 conf 中。这里是使用 Yarn 作为 resource manager，所以这里会把这个 tag 传到 Yarn context 中，这样 BatchId 同时会和 Kyuubi Server 以及 Yarn 都进行一次绑定。最后能够通过这个 BatchId 去访问 Kyuubi Server 获取 Batch Report，Kyuubi Server 也能够通过 BatchId 去访问 Yarn 获取 application report。同时 Kyuubi Server 也可以去合并 Kyuubi Server 端的一些信息，比如 Batch 任务的创建时间，创建的节点，这些信息可以返回给用户，用户也能够通过这个 BatchId 去获取 Spark submit 的日志，能够清楚知道 Spark submit 执行到了哪些阶段，以及 Kyuubi Server 端发生了什么，如果出现异常，也能够清楚的找到异常信息。

对于用户来说，还可以通过 DELETE 方式关闭目前正在运行的 Batch 任务，如果 Batch 任务没有提交到 Yarn 集群，Kyuubi Server 需要 kill 掉本地的 spark submit 进程，如果已经提交到yarn集群，对于 Kyuubi Server 来说需要通过 BatchId kill 掉正在运行的 Batch 任务，并返回给用户这个 close 的结果。

在示意图左半部分的 4 个 API，是针对 Kyuubi 单个节点的，比如拉取 local job，kill 本地进程，都是需要在Kyuubi进程启动节点处理的。一般在生产环境为了实现 HA 和 SLB，需要部署多台 Kyuubi 节点，为了实现多个节点的 HA，我们在这个功能特性里面引入了 Metadata Store，以及 Kyuubi 内部节点的请求的转发机制。

Metadata Store是用来存储一些 Batch 任务的元数据，比如 BatchId，创建 Batch 任务的 conf 和参数，还有 Kyuubi 节点的一些信息，比如哪个节点创建的 Batch，都会加入到这个元数据中。有了 Metadata Store 之后，Batch 元数据会对多个 Kyuubi 节点都可见，包括目前的状态，以及哪个节点创建的 Batch。关于 Kyuubi Server 之间的 rest 请求转发，我们可以在这里举一个简单的例子，比如采用 K8S 的 loadbalance 作为 Kyuubi Server 的服务发现，每个 rest 请求都会从这个 loadbalance 中去随机选择一个 Kyuubi 节点来处理，比如在处理 Kyuubi Batch 的时候，是在 Kyuubi 节点 1 创建的，当用户需要拉取 local job 的时候，会向 loadbalance 节点发送请求，load balance 会选择 Kyuubi 节点 2 来处理这个请求，这个时候 Kyuubi 节点 2 会首先在内存中寻找这个 Batch 任务，如果没有找到，就会去访问 Metadata Store，去查询这个任务的元数据信息。此时发现任务是由 Kyuubi 节点 1 创建的，就会把拉取日志的请求发送给 Kyuubi 节点 1，由 Kyuubi 节点 1 拉取本地日志，返回给 Kyuubi 节点 2，Kyuubi 节点 2 这个时候就会把这个结果返回给用户。这样用户就可以成功的通过 Kyuubi 节点 2 获取到 Spark submit 的日志。通过 Metadata Store 和节点内部转发，实现了多节点的 HA，换句话来说，用户是通过 load balance 连接到任意节点，都可以拿到 Batch 的信息。

通过运用 Metadata Store 和 Kyuubi Server，也可以在服务重启的时候，做到恢复重启前在运行的 Batch 任务。如果这个 Batch 任务没有提交到 Yarn 集群，Kyuubi Server 会通过 Metadata Store 里面的元信息进行重新提交，如果已经提交给 Yarn 集群，Kyuubi Server 会监控运行的 Batch 任务的状态。

在 Kyuubi1.6.0 版本中，对 Metadata Store 做了一些增强，当 Metadata Store 有问题，比如 MySQL 短时间不可用，这个时候会把更新 Metadata Store 的一些请求存储在内存中，进行异步的重试，而不是打断用户的主线程。同时当 Metadata Store 不可用的时候，对于 Batch 任务的状态请求会 fallback 到 Yarn 上获取任务的状态，对这个状态进行一些补充，然后 Kyuubi Server 会返回给用户。

同时在 1.6.0 版本中，Kyuubi 提供了 restful 的 CLI 和 SDK，可以让用户很方便的使用其提供的服务，而不需要使用 curl 命令或者一些很原始的 rest API，直接使用 CLI 对用户来说更加友好，restful SDK 可以让平台层的用户使用编程的方式进行集成。同时拥有这种中心化提交 Batch 任务的服务，可以方便的去监管 Spark submit 的行为，比如做一些提交权限的校验，拒绝不合理的 JAR 提交，来提高整个集群的安全性。

刚才也提到了，Kyuubi1.6.0 提供了 restful SDK 和 Command Line 来给用户使用。restful 的 SDK 对于一些平台团队来说，通过编程的方式很容易集成。这里主要介绍命令行工具的使用，上图右侧展示了命令行的使用，类似于 K8S 的 ctl。命令结构为 kyuubi-ctl + action 命令 + batch + yml 文件。其中 action 包括 create、get、logs、delete，分别对应前文提到的 4 个 API，还有一个复合命令 Submit，包含了其它 4 个 action。配置文件中指定了 JAR 的位置，Batch 类型，目前已经支持了 Spark，正在支持 Flink，还有提交 JAR 的主程序和它的参数以及配置。

这样对于用户来说非常便捷，只需一行命令就能完成任务的提交，不需要配置很多 Spark 的本地环境，这里会使用最新的 Spark 版本，减少了用户的维护成本。

2. 统一 API 接口和认证机制

在 Kyuubi1.6.0 版本中，统一了 API 接口和认证机制。到 Kyuubi1.6.0 为止提供了 Thrift，Rest、JDBC 和 ODBC 的 API，提供了 Kerberos 和 Password 的认证机制，在之前的版本中，对于 Thrift 协议来说，只支持一种认证机制，在 1.6.0 版本中，两种认证机制都支持了。对于 rest 请求 1.6.0 之前是不支持认证的，在 1.6.0 版本中，这两种认证机制也都做了支持。有了统一的 API 和认证机制，1.6.0 基本上覆盖了用户所有的使用方式。

--

02/客户端增强

刚刚介绍的是 1.6.0 服务端的增强，在这个版本中对客户端也做了增强。

1. 增强内置 JDBC 驱动能力

增强了内置 JDBC 的驱动能力：

① 剥离了 Hive 和 Hadoop 的依赖；

② 支持使用 keytab 进行 Kerberos 身份认证。

2．增强 Beeline

1.6.0 版本增强了 Beeline，在 Beeline 中可以显示 Spark 控制台的进度条，如图所示，可以清楚地看到 Spark 每个 Stage 的执行情况和总体执行情况。

--

03/引擎插件

在计算引擎方面，Kyuubi1.6.0 提供了非常成熟稳定的 Spark 支持，同时 Flink、trino 以及 Hive 等计算引擎的支持也得到了充分的验证。

1. Kyuubi Spark Engine

我们首先来看 Spark 引擎。Kyuubi 作为 Spark 的引擎，支持的已经是非常成熟了，有一套完善的生命周期管控，也经过了很多公司的大规模生产验证，在业界有众多的生产环境的落地案例。对于版本支持这块，Kyuubi Spark Engine 支持了 3.0 到 3.3 的所有版本，对于这些版本也都进行了充分的验证。在 Spark 引擎中兼容了所有的部署模式，比如 Spark on Local/Standalone 或者 Spark on Yarn/K8S，不论是 Client 还是 Cluster mode 都是支持的。

Kyuubi Spark Engine 从 Spark3.1 版本开始就提供了一个企业级插件，比如自动小文件合并，限制扫描的最大分区数，以及限制查询结果大小，并提供了一个开箱即用的 Z-Order 优化来支持计算写入 Stage 的配置隔离。同时在 1.6.0 中，又新增了 Spark TPC-DS 和 TPC-H 连接器，以及 Authz 认证的插件。

Kyuubi 社区依然还在陆续开发一些比如像血缘插件等企业级的功能。

2. Kyuubi Flink Engine

再来看一下 Flink Engine，在 Kyuubi1.6.0 中基本成熟稳定了，并且 Kyuubi 的 Flink Engine 是对所有社区开发者和用户去关注的，也在不断的迭代演进中，在 1.6.0 版本中，Flink Engine 支持了 Flink1.14、1.15 版本，1.16 还没有发布，社区这边已经在逐步支持。

对于部署模式而言，Flink Engine 支持 on Local、on Yarn(PerJob and Session mode)，关于 on Yarn/K8S Application mode 会在 1.7.0 版本进行发布，因为 Application mode 非常契合 Kyuubi 的部署模式，目前是在开发阶段。

3. Kyuubi Trino Engine， Kyuubi Hive/JDBC Engine

Trino Engine 是一个生产可用，经过移动云等社区用户的生产验证状态。Hive 和 JDBC Engine 提供了一个 Beta 版本，欢迎大家使用反馈，以及生产验证。

--

04/社区展望

最后和大家分享一下 Kyuubi 社区的未来展望。

从 2021 年开始加入到 Apache 孵化器之后，Kyuubi 社区一直在发展迭代，到目前为止一共发布了 4 个大特性版本。随着社区的发展和社区开发者的参与，Kyuubi 的基础定位也在发生改变，Kyuubi 的愿景从最初的 Serverless Spark 转变成了现在的 Serverless SQL on Lakehouse。

到了 1.6.0 版本，大部分的之前计划的 roadmap 已经全部实现。后面 Kyuubi 社区还会提供更多的企业级特性。

Apache Kyuubi 社区的发展离不开社区的用户，有很多企业来使用，为 Kyuubi 贡献了大量的使用反馈和实践案例。如果你也在使用 Kyuubi，或者有一些 Kyuubi 的实践案例，可以在上图下方链接进行登记。

最后我们来看一下 Kyuubi 社区目前的进展，Apache Kyuubi 社区目前有 12 位 PPMC，以及 17 位 Committer，有 96+ 的 Contributor，dev 的订阅者已经超过 65 位，Kyuubi 社区最近两年举办了 4 次社区Meetup，参加了 20+ 项活动，比如 ApacheCon 等。

对于 Kyuubi 项目本身来说，已经发布了 8 个版本，每个版本由不同的 Release Manager 发布，1400+PR 被 Merge，900+Issue 被解决。

Apache Kyuubi 其实是一个 Apache 的孵化项目，截止到目前已经经过了孵化毕业的讨论，讨论已经通过，目前是处于孵化毕业投票的阶段，对 Kyuubi 有兴趣或正在使用 Kyuubi 的同学欢迎进入投票。

今天的分享就到这里，谢谢大家。

分享嘉宾