Kyuubi基本架构

介绍

Kyuubi 是一个高性能的通用 JDBC 和 SQL 执行引擎。 Kyuubi 的目标是方便用户像处理普通数据一样处理大数据。

它提供了标准化的JDBC接口，方便大数据场景下的数据访问。终端用户可以专注于开发他们的业务系统和挖掘数据价值，而无需了解底层的大数据平台（计算引擎、存储服务、元数据管理等）。

Kyuubi 依靠 Apache Spark 提供高性能的数据查询能力，引擎能力的每一次提升都可以帮助 Kyuubi 的性能实现质的飞跃。此外，Kyuubi 通过引擎缓存的方式提高了 ad-hoc 响应能力，并通过水平扩展和负载均衡来增强并发性。

它提供完善的鉴权和鉴权服务，保证数据和元数据的安全。

它提供强大的高可用性和负载平衡，以帮助您保证 SLA 承诺。

它提供两级弹性资源管理架构，有效提升资源利用率，同时覆盖所有场景的性能和响应需求，包括交互、或批处理、点查询或全表扫描。

它包含 Spark 并在其上构建生态系统，这允许 Kyuubi 扩展其现有生态系统并快速引入新功能，例如云原生支持和 Data Lake/Lake House 支持。

Kyuubi 的愿景是建立在 Apache Spark 和 Data Lake 技术之上，以统一门户并成为理想的数据湖管理平台。它可以支持数据处理，例如ETL 和分析，例如BI，以纯 SQL 方式。所有工作负载都可以在一个平台上完成，使用一份数据副本和一个 SQL 接口。

架构概览

Kyuubi 系统的基本技术架构如下图所示。

该图的中间部分显示了 Kyuubi 服务器的主要组件，该组件处理图像左侧所示的客户端连接和执行请求。在 Kyuubi 内部，这些连接请求作为 Kyuubi 会话维护，执行请求作为绑定到相应会话的 Kyuubi 操作支持。

Kyuubi Session的创建可以分为轻量级和重量级两种情况。大多数会话创建都是轻量级的并且用户不知道。唯一的重量级情况是用户的共享域中没有实例化或缓存 SparkContext，这通常发生在用户第一次连接或长时间没有连接时。这种一次性成本会话维护模型可以满足大部分的 ad-hoc 快速响应需求。

Kyuubi 以松散耦合的方式维护与 SparkConext 的连接。这些 SparkContext 可以是该服务实例在客户端部署模式下本地创建的 Spark 程序，也可以是集群部署模式下在 Yarn 或 Kubernetes 集群中创建的 Spark 程序。在高可用模式下，这些 SparkConexts 也可以由不同机器上的其他 Kyuubi 实例创建并由该实例共享。

这些 SparkConexts 实例本质上是由 Kyuubi 服务托管的远程查询执行引擎程序。这些程序在 Spark SQL 上实现，并端到端编译、优化和执行 SQL 语句以及与元数据（例如 Hive Metastore）和存储（例如 HDFS）服务的必要交互，最大限度地发挥 Spark SQL 的功能。他们可以管理自己的生命周期、缓存和回收自己，并且不受 Kyuubi 服务器上的故障转移的影响。

接下来，让我们分享一下Kyuubi的一些关键设计理念。

统一的接口

Kyuubi 实现了 Hive Service RPC 模块，它提供了与 HiveServer2 和 Spark Thrift Server 相同的数据访问方式。在客户端，您可以仅通过 Hive JDBC 模块构建出色的业务报告、BI 应用程序甚至 ETL 作业。

您只需要熟悉结构化查询语言 (SQL) 和 Java 数据库连接 (JDBC) 即可处理海量数据。它可以帮助您专注于业务系统的设计和实施。

SQL 是访问关系数据库的标准语言，在大数据生态中也非常流行。事实证明，每个人都知道 SQL。

JDBC 为工具/数据库开发人员提供了一个标准 API，并使得使用纯 Java API 编写数据库应用程序成为可能。

有很多免费或商业的 JDBC 工具。

运行时资源恢复能力

Kyuubi 和 Spark Thrift Server(STS) 之间最显着的区别在于 STS 是一个单一的 Spark 应用程序。例如，如果它运行在 Apache Hadoop Yarn 集群上，那么这个应用程序也是一个单独的 Yarn 应用程序，创建后只能存在于 Yarn 集群的特定固定队列中。 Kyuubi 支持提交多个 Spark 应用程序。

Yarn 失去了作为资源管理器的资源管理器的角色，并没有发挥相应的资源隔离和共享的作用。当来自客户端的用户拥有不同的资源队列权限时，这种情况下 STS 将无法处理。

对于数据访问，单个 Spark 应用程序在全局范围内只有一个用户，即 sparkUser，我们必须授予它类似超级用户的角色，以允许它对不同的客户端用户执行数据访问，这在生产环境中是一种太不安全的做法。

Kyuubi 根据来自客户端的连接请求创建不同的 Spark 应用程序，这些应用程序可以放在不同的共享域中，以供其他连接请求共享。

Kyuubi 在启动期间不占用集群管理器（例如 Yarn）的任何资源，如果没有任何活动会话与 SparkContext 交互，Kyuubi 将归还所有资源。

Spark 还提供了动态资源分配功能，可以根据工作负载动态调整应用程序占用的资源。这意味着如果不再使用资源，您的应用程序可能会将资源返还给集群，并在以后有需求时再次请求它们。如果多个应用程序共享 Spark 集群中的资源，此功能非常方便。

凭借这些特性，Kyuubi 提供了两级弹性资源管理架构，有效提高资源利用率。

例如：

./beeline -u "jdbc:hive2://kyuubi.org:10009/;\
hive.server2.proxy.user=tom#\
spark.yarn.queue=thequeue;\
spark.dynamicAllocation.enabled=true;\
spark.dynamicAllocation.maxExecutors=500;\
spark.shuffle.service.enabled=true;\
spark.executor.cores=3;\
spark.executor.memory=10g"

如果名为 tom 的用户打开了类似上述的连接，Kyuubi 将尝试在 Yarn 集群中名为 thequeue 的队列中创建一个具有 [3, 500] 个执行器（3 个核心，每个 10g mem）的 Spark SQL 引擎应用程序。

一方面，由于tom开启了Spark的动态资源请求功能，Spark会根据SQL操作规模和队列中可用资源，高效地请求和回收程序内的executors。另一方面，当 Kyuubi 发现应用程序空闲时间过长时，它也会回收它的应用程序。

高可用与负载均衡

对于企业服务，服务水平协议 (SLA) 承诺必须非常高。并发性需要足够强大以支持整个企业的请求。 Spark Thrift Server 作为一个单一的 Spark 应用，没有高可用，很难满足 SLA 和并发的要求。当有大的查询请求时，Spark Driver 的元数据服务访问、调度和内存压力，或者应用程序的整体计算资源限制，都存在潜在的瓶颈。

Kyuubi 提供基于 Zookeeper 的高可用和负载均衡解决方案，如下图所示。

让我们尝试根据上图从上到下分解它。

图的顶部是客户端层。客户端可以从服务发现层的命名空间中找到多个注册的 Kyuubi 实例（k.i.），然后选择连接。注册到相同命名空间的 Kyuubi 实例提供了相互负载平衡的能力。
选定的 Kyuubi 实例将从服务发现层的引擎名称空间中选择一个可用的引擎实例（e.i.）以建立连接。如果没有找到可用的实例，它将创建一个新实例，等待引擎完成注册，然后继续连接。
如果同一个人请求新的连接，连接将被设置到同一个或另一个 Kyuubi 实例，但引擎实例将被重用。
对于来自不同用户的连接，将重复第 2 步和第 3 步。这是因为在服务发现层，用于存储引擎实例地址的命名空间是基于用户隔离的（默认情况下），不同的用户不能跨命名空间访问其他的实例。