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 同时会和 Ky uubi 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 Serve r 的服务发现，每个 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 版本，缩小了用户的保养老本。
在 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 基本上笼罩了用户一切的经常使用方式。
刚刚引见的是 1.6.0 服务端的增强，在这个版本中对客户端也做了增强。
增强了内置 JDBC 的驱动才干：
② 允许经常使用 keytab 启动 Kerberos 身份认证。
1.6.0 版本增强了 Beeline，在 Beeline 中可以显示 Spark 控制台的进展条，如图所示，可以分明地看到 Spark 每个 Stage 的口头状况和总体口头状况。
在计算引擎方面，Kyuubi1.6.0 提供了十分成熟稳固的 Spark 允许，同时 Flink、trino 以及 Hive 等计算引擎的允许也失掉了充沛的验证。
咱们首先来看 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 社区依然还在陆续开发一些比如像血统插件等企业级的性能。
再来看一下 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 的部署形式，目前是在开发阶段。
Trino Engine 是一个消费可用，经过移动云等社区用户的消费验证形态。Hive 和 JDBC Engine 提供了一个 Beta 版本，欢迎大家经常使用反应，以及消费验证。