Kyuubi项目中Spark Jars在Scala模式下的使用限制分析

在Kyuubi项目使用过程中，发现了一个关于Spark Jars配置在Scala模式下无法正常使用的技术问题。这个问题影响了多个Kyuubi版本，包括master分支及1.7.3至1.9.0的多个稳定版本。

问题现象

当用户通过beeline连接Kyuubi服务时，使用spark.jars参数指定额外的JAR包路径，例如：

beeline -u "jdbc:kyuubi://kyuubi:10009/default" --hiveconf spark.jars=hdfs:///tmp/kyuubi-hive-jdbc-shaded-1.9.0.jar --hiveconf kyuubi.operation.language=scala

虽然Spark UI的环境信息显示JAR包已正确加载，但在Scala模式下使用时却出现了不一致的行为：

1. 通过反射方式可以正常加载类：

Class.forName("org.apache.kyuubi.jdbc.KyuubiHiveDriver").getSimpleName
Class.forName("org.apache.kyuubi.jdbc.KyuubiHiveDriver").newInstance

2. 直接导入或实例化类时失败：

import org.apache.kyuubi.jdbc.KyuubiHiveDriver
new org.apache.kyuubi.jdbc.KyuubiHiveDriver()

错误信息显示："object jdbc is not a member of package org.apache.kyuubi"，这表明Scala编译器无法识别通过spark.jars添加的依赖。

技术背景

Kyuubi是一个基于Spark SQL的分布式SQL引擎服务，它支持多种操作语言模式，包括SQL和Scala。当使用Scala模式时，Kyuubi实际上是在Spark REPL环境中执行用户代码。

Spark REPL（Read-Eval-Print Loop）是Spark提供的交互式Scala shell环境，它有自己的类加载机制和依赖管理方式。与常规的Spark应用不同，REPL环境需要特殊处理额外的依赖项。

问题根源

这个问题的根本原因在于Spark Jars的加载机制与Scala REPL的类加载机制之间的差异：

1. spark.jars配置的JAR包会被Spark分发到集群节点并添加到执行器的classpath中，这使得反射机制可以正常工作。

2. 但是Scala REPL在编译用户代码时需要这些依赖在编译时可用。常规的spark.jars配置不会将这些依赖添加到REPL的编译classpath中，导致编译时无法解析相关类。

解决方案

针对这个问题，Kyuubi社区已经提供了修复方案。修复的核心思路是：

1. 在Scala模式下，需要将spark.jars指定的依赖显式地添加到REPL的编译classpath中。

2. 可以通过修改Kyuubi的Scala执行逻辑，在初始化REPL环境时主动加载这些额外的依赖。

3. 另一种方案是建议用户使用Spark的--packages参数或spark.repl.addJars配置来确保依赖在REPL环境中可用。

影响范围

这个问题在以下环境中均能复现：

• Spark 3.3版本
• YARN和Kubernetes集群模式
• 本地模式

影响多个Kyuubi版本，说明这是一个长期存在的设计问题而非特定版本的回归错误。

最佳实践

对于需要在Kyuubi Scala模式下使用额外依赖的用户，建议：

1. 优先考虑使用Spark的--packages参数而不是spark.jars来声明依赖。

2. 如果必须使用JAR文件，可以尝试设置spark.repl.addJars配置项。

3. 对于关键依赖，考虑将其预先部署到所有节点的classpath中。

4. 在必须使用反射的场景下，可以采用Class.forName的方式作为临时解决方案。

这个问题展示了分布式计算框架中类加载机制的复杂性，特别是在交互式环境中。理解不同组件间的类加载隔离对于开发和调试此类问题至关重要。