Kyuubi项目中查询状态提前返回但作业仍在执行的问题分析

Apache Kyuubi是一个开源的分布式SQL引擎，为用户提供了统一的JDBC/ODBC接口来访问不同的计算引擎。在实际生产环境中，用户报告了一个重要问题：当通过Kyuubi提交查询到Spark时，Kyuubi会快速返回查询完成状态(FINISH_STATE)，但实际上Spark作业仍在继续执行。

问题现象

用户在使用Kyuubi 1.8.0至1.9.0版本与Spark 3.4.2组合时，发现特定类型的SQL查询会出现状态不一致的情况。具体表现为：

1. 执行包含空表与大表连接的查询时
2. Kyuubi在几秒内返回FINISHED状态
3. 但Spark UI显示相关作业仍在运行，持续占用集群资源
4. 手动取消操作后，作业才会真正停止

问题复现与定位

通过分析用户提供的复现案例，可以确定问题出现的典型场景是：当查询中包含一个空表(0行)与大表(数亿行)的连接操作时，Kyuubi会过早地认为查询已完成。

技术团队尝试复现该问题，发现关键在于：

1. 查询必须包含连接操作
2. 其中一侧的表必须是空表
3. 另一侧的表数据量需要足够大
4. 使用Spark自适应查询执行(AQE)特性

技术原理分析

深入分析该问题的技术原理：

1. Spark查询优化机制：当Spark检测到连接操作的一侧为空表时，会优化掉整个连接操作，直接返回空结果。这是Spark的合理优化行为。

2. 状态报告机制：Kyuubi基于Spark的作业状态来判断查询状态。当Spark优化掉主要操作后，Kyuubi会立即收到完成信号。

3. 资源释放问题：虽然主查询逻辑已被优化，但Spark仍可能继续执行另一侧表的计算任务，这些任务实际上已无意义但仍占用资源。

4. API差异：通过REST API提交的查询比通过Beeline提交的查询更容易出现此问题，这与会话生命周期管理有关。

解决方案

针对这一问题，社区提出了以下解决方案：

1. 主动取消机制：在查询逻辑完成后，主动取消剩余的Spark作业。这需要修改Kyuubi核心代码，在适当位置调用SparkContext的cancelJobGroup方法。

2. 会话生命周期管理：确保通过REST API创建的会话能够正确关闭，释放所有相关资源。

3. 用户侧临时方案：在应用代码中，当收到FINISHED状态后，手动关闭操作以释放资源。

最佳实践建议

基于这一问题的分析，建议用户：

1. 对于生产环境，考虑升级到包含修复的Kyuubi版本

2. 在编写SQL时，对于可能产生空结果的子查询，添加适当的过滤条件

3. 监控长时间运行的Spark作业，及时发现并处理异常情况

4. 在使用REST API时，确保正确处理会话和操作的生命周期

这一问题的解决不仅修复了特定场景下的行为异常，也完善了Kyuubi与Spark集成的健壮性，为大规模数据处理提供了更可靠的保障。