Kyuubi项目中Spark历史服务器UI显示问题的分析与解决

问题背景

在Kyuubi项目的最新版本中，用户在使用Spark历史服务器查看不完整应用程序时，遇到了Kyuubi查询引擎UI的错误。具体表现为当访问历史应用的Kyuubi页面时，系统抛出"java.lang.Integer cannot be cast to java.lang.Long"的异常，导致HTTP 500错误。

错误现象

用户在使用Spark 3.3.2版本时，发现以下两种场景存在差异：

1. 通过ApplicationMaster直接访问Kyuubi查询引擎页面时，功能正常
2. 通过Spark历史服务器查看不完整应用程序时，访问Kyuubi查询引擎页面会报错

错误堆栈显示类型转换异常，具体是尝试将Integer类型转换为Long类型时失败。这一错误发生在Spark UI的StatementStatsPagedTable组件处理行数据时。

问题根源分析

经过技术团队分析，这个问题与Jackson库处理Scala数据类型时的行为有关。具体来说，当Jackson反序列化某些数值类型时，可能会错误地将某些本应为Long类型的字段识别为Integer类型，导致后续的类型转换失败。

这种情况在Jackson处理Scala数据类型时较为常见，特别是在处理Option类型包装的数值时。Jackson有时无法准确推断出Scala数值类型的具体大小，导致选择了较小的数值类型（如Integer）而非预期的较大类型（如Long）。

解决方案

针对这个问题，技术团队提出了两种解决方案：

1. 直接修改类型转换逻辑：在相关代码处显式处理类型转换，确保数值类型的一致性。这种方法在用户环境中验证有效，但不够优雅。

2. 使用Jackson注解：更优雅的解决方案是使用@JsonDeserialize注解显式指定字段的反序列化类型。具体做法是在operationRunTime和operationCpuTime字段上添加@JsonDeserialize(contentAs = classOf[java.lang.Long])注解，强制Jackson将这些字段反序列化为Long类型。

最终采用了第二种方案，因为它：

• 更符合Jackson的最佳实践
• 在代码层面更清晰明确
• 解决了根本问题而非表面症状
• 具有更好的可维护性

技术实现细节

在具体实现中，开发团队在相关的Scala case类中添加了Jackson注解，确保以下字段始终被正确反序列化：

• 操作运行时间(operationRunTime)
• 操作CPU时间(operationCpuTime)

这些字段在Kyuubi的查询统计信息中用于记录各项操作的耗时情况，必须保证其数值范围足够大（使用Long而非Integer），以避免潜在的数值溢出问题。

验证与效果

修复后，经过验证：

1. 通过Spark历史服务器查看不完整应用程序时，Kyuubi查询引擎页面可以正常显示
2. 所有数值字段都被正确反序列化为Long类型
3. 原有功能保持不变，不会引入新的兼容性问题

总结

这个问题展示了在Scala和Java混合环境中处理JSON序列化/反序列化时可能遇到的类型系统挑战。通过使用Jackson的注解功能，我们能够精确控制反序列化行为，确保类型安全。这也提醒开发者在处理跨语言数据交换时，需要特别注意数值类型的范围和精度问题。

对于使用Kyuubi和Spark集成的用户，建议在升级到包含此修复的版本后，验证历史服务器中Kyuubi页面的显示功能是否正常。