Kyuubi介绍

Spark thriftServer的问题

STS面临以下的问题：

• 无法适应多租户场景。STS后端引擎仅仅启动一个application提供服务，提交用户和队列均为固定。
• 服务健壮性问题。STS同时需要接受客户端的并发连接和调度task，在高负载下OOM风险大大增加，同时有性能瓶颈。
• 无高可用和负载均衡。单点提供服务，无法满足生产SLA要求。

Kyuubi架构

• kyuubi内部维护session，引擎端可以提交不同的application。并且生命周期、缓存和回收都由kyuubi维护，对用户透明。
• 可利用zookeeper来实现高可用及负载均衡
• 提供和hiveserver2、spark thriftserver一样的通用JDBC接口
• 提供完整的身份验证和身份验证服务，以确保数据和元数据的安全性

所以，本质上与Spark thriftServer类似，但功能更丰富。

共享域

不难看出，灵活性在于session与引擎侧的联系。共享域就决定了它们之间的联系。可以根据共享域和资源损耗方面做取舍选择。

参数

kyuubi.engine.share.level 默认为USER

CONNECTION

• 每个session一个引擎。隔离性比较高，相对共享性就较低。比较适合大规模的数据处理
  

USER

• 相同用户的session共享一个引擎，也就是SparkContext唯一(包括Classes/Classloaders, SparkConf, Driver/Executors)。
• 但每个session仍然是独立的SparkSession实例，包含单独的session状态、sql配置、UDF等。
• 可以通过设置kyuubi.engine.single.spark.session为true，让SparkSession实例为单例，从而可以在session之间共享
  

GROUP

• 属于同一组的用户共享一个引擎
  

SERVER

• 类似sts，整个kyuubi server共享一个引擎。安全性差