Kyuubi项目中Spark Jars在Scala模式下的加载问题分析

问题背景

在Kyuubi项目中，当用户通过spark.jars参数添加额外的JAR包时，发现在Scala模式下无法正常使用这些JAR包中的类。这是一个值得关注的技术问题，因为它影响了Kyuubi作为Spark SQL服务网关的核心功能。

问题现象

用户在使用Kyuubi时，通过以下命令指定了额外的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编译器无法识别已加载的JAR包中的类。

技术分析

这个问题涉及到Spark和Scala编译器的类加载机制，我们可以从几个方面来分析：

1. Spark类加载机制：Spark通过spark.jars参数添加的JAR包会被分发到集群节点，并被添加到执行器的classpath中。这使得运行时反射可以找到这些类。

2. Scala REPL/编译器行为：Scala交互式环境(REPL)在编译代码时，需要明确知道所有依赖的类路径。仅将JAR包添加到运行时classpath是不够的，还需要将其显式告知Scala编译器。

3. Kyuubi执行环境：Kyuubi在Scala模式下会创建一个Scala解释器来执行用户代码。这个解释器需要正确配置classpath才能识别额外的依赖。

根本原因

问题的核心在于Spark和Scala编译器对类路径的处理方式不同：

• Spark将spark.jars指定的JAR包添加到执行环境的classpath，支持运行时反射
• 但Scala编译器需要显式地将这些JAR包添加到其编译classpath才能识别其中的类定义

这种差异导致了反射可用但直接引用不可用的现象。

解决方案

解决这个问题需要确保Scala编译器能够访问spark.jars指定的所有JAR包。可能的实现方式包括：

1. 在创建Scala解释器时，主动将spark.jars的值解析并添加到解释器的classpath中
2. 通过反射获取Spark环境中实际加载的JAR列表，并将其传递给Scala编译器
3. 在Kyuubi服务端统一处理所有JAR包依赖，确保执行环境和编译环境的一致性

影响范围

这个问题影响多个Kyuubi版本，包括master分支和1.7.3至1.9.0的稳定版本。它出现在各种部署模式下，包括YARN、Kubernetes集群模式以及本地模式。

总结

Kyuubi项目中Spark Jars在Scala模式下的加载问题揭示了分布式计算框架与语言编译器在类加载机制上的差异。理解这种差异对于构建稳定的数据服务网关至关重要。通过正确处理JAR包在运行时和编译时的加载路径，可以确保用户在不同操作模式下获得一致的体验。