Apache Kyuubi 项目中 Spark Driver 因 Ranger Solr 审计插件无法退出的问题分析

问题背景

在 Apache Kyuubi 项目中，当用户通过 spark-submit 提交 SparkSQL 作业时，发现了一个关键问题：作业执行完成后，Spark Driver 进程无法正常退出。该问题出现在使用开源 Spark 引擎（3.3.1 版本）和 Kyuubi 授权模块（1.8.0 版本）的环境中，特别是在 YARN 客户端模式下运行时。

问题现象

作业虽然成功执行完成，但 Spark Driver 进程持续运行，无法自动终止。通过日志分析发现，Ranger 的 PolicyRefresher 线程仍在持续轮询策略，导致整个进程无法退出。这种状况最终需要人工干预手动终止作业。

根本原因分析

经过深入排查，发现问题根源在于 Ranger Solr 审计插件创建的线程。具体表现为：

1. 线程类型问题：SolrZkClient 创建的线程被设置为非守护线程（non-daemon thread），这是 Java 中一种特殊的线程类型。非守护线程会阻止 JVM 退出，即使主线程已经完成。

2. Spark 执行模式影响：该问题在 YARN 客户端模式和 Kubernetes 集群模式下尤为明显，因为这些模式下 Driver 进程需要自行管理生命周期。而在 YARN 集群模式下通常不会出现此问题，因为该模式下 Driver 运行在 Application Master 中，生命周期由 YARN 管理。

3. 审计插件机制：Ranger 的 Solr 审计插件为了实现审计日志的可靠传输，建立了与 ZooKeeper 的持久连接，这些连接管理的线程被设计为非守护线程，以确保审计日志不会丢失。

解决方案

针对这一问题，我们提出了多层次的解决方案：

1. 临时解决方案：通过配置 xasecure.audit.destination.solr=false 禁用 Solr 审计功能。这种方法简单有效，但牺牲了审计能力。

2. 根本解决方案：修改 SolrZkClient 的线程创建逻辑，将其设置为守护线程（daemon thread）。这种修改已经通过 Solr 社区的 PR 提交，并验证可以有效解决问题。

3. 最佳实践建议：

   • 对于第三方组件集成到 Spark Driver 的场景，强烈建议使用守护线程
   • 在开发类似插件时，应该考虑 Spark 不同运行模式下的生命周期管理需求
   • 对于必须使用非守护线程的场景，应该提供明确的关闭机制

技术深度解析

从技术实现角度看，这个问题涉及几个关键层面：

1. JVM 退出机制：JVM 在所有非守护线程结束后才会退出。这是 Java 线程模型的基本特性，也是此问题的根本原因。

2. Spark 生命周期管理：在客户端模式下，Spark Driver 作为独立进程运行，其退出完全依赖于 JVM 的退出机制。任何非守护线程都会阻止这一过程。

3. 分布式系统协调：Solr 使用 ZooKeeper 进行协调，建立的连接需要精心管理。将相关线程改为守护线程是一种合理的折中，因为：

   • 在 Spark 作业结束时，审计日志的可靠性可以适当降低优先级
   • 守护线程不会阻止系统关闭，符合 Spark 作业的生命周期模型

经验总结

这个案例为我们提供了宝贵的经验：

1. 第三方集成注意事项：在 Spark 生态中集成第三方组件时，必须特别注意线程管理问题，尤其是在客户端模式下。

2. 问题诊断方法：通过 jstack 分析线程状态是诊断此类问题的有效手段，可以快速定位阻止 JVM 退出的线程。

3. 社区协作价值：这个问题通过跨项目（Kyuubi、Ranger、Solr）的协作得到解决，体现了开源社区的优势。

4. 文档重要性：类似问题的解决方案应该纳入项目文档，帮助其他用户避免重复踩坑。

结语

Spark 生态系统的强大之处在于其丰富的集成能力，但这种集成也带来了复杂的管理挑战。通过这个案例，我们不仅解决了一个具体的技术问题，更重要的是建立了一套处理类似问题的思维框架和方法论。未来在设计和实现类似集成时，应该从一开始就考虑组件的生命周期管理，确保系统各部分的协调一致。