Apache Kyuubi 内存溢出问题分析与解决方案

问题背景

Apache Kyuubi是一个开源的分布式SQL引擎，它提供了JDBC接口来执行Spark SQL查询。在最新版本中，Kyuubi引入了一个新特性：通过FetchOrcStatement直接从ORC文件中获取查询结果，而不是通过传统的Spark结果收集方式。这个特性原本旨在提高大数据量查询的性能和效率。

问题现象

当用户执行大数据量查询时，特别是当查询结果被分成大量ORC文件时，Kyuubi的Driver进程会出现内存溢出(OOM)错误。这个问题在启用了自适应查询执行(AQE)或其他可能导致结果被分成多个文件的配置时尤为明显。

问题根源分析

通过深入分析，我们发现问题的根本原因在于当前实现方式中，Kyuubi会一次性初始化所有ORC文件的RecordReaderIterator。每个RecordReaderIterator在初始化时都会创建一个OrcMapreduceRecordReader，而这个Reader会预取一定数量的行数据到内存中。

当查询结果被分成大量ORC文件时，比如在测试案例中设置了40个executor实例，就会产生大量RecordReaderIterator同时存在于内存中，每个都持有预取的数据，从而导致Driver进程内存耗尽。

技术细节

1. 内存消耗机制：

   • 每个OrcMapreduceRecordReader在初始化时会预取数据
   • 预取的数据量取决于ORC文件的存储格式和压缩方式
   • 默认情况下，每个Reader会预取一个stripe的数据

2. 问题代码路径：

   • FetchOrcStatement在获取结果时，会为每个ORC文件创建一个RecordReaderIterator
   • 这些Iterator被保存在内存中，直到所有数据被消费完毕

3. 关键影响因素：

   • ORC文件数量（与executor数量和AQE配置相关）
   • 每个ORC文件的大小和内部结构
   • Driver进程配置的内存大小

解决方案

针对这个问题，我们提出了一个优化方案：延迟初始化RecordReaderIterator。具体实现思路如下：

1. 不再一次性初始化所有文件的RecordReaderIterator
2. 改为按需初始化，即只有在客户端需要读取某个文件时才创建对应的Iterator
3. 确保同一时间内存中只保持一个活跃的RecordReaderIterator

这种方案的优势在于：

• 显著降低Driver进程的内存压力
• 保持原有的功能完整性
• 对性能影响最小化

实现验证

该解决方案已经在实际环境中进行了验证：

1. 使用TPCDS sf3000数据集中的catalog_returns表进行测试
2. 设置40个executor实例以产生大量ORC文件
3. 配置Driver内存为5GB

测试结果表明：

• 优化前：Driver因OOM而崩溃
• 优化后：查询成功执行，内存使用稳定

最佳实践建议

对于使用Kyuubi处理大数据量查询的用户，我们建议：

1. 合理配置executor数量，避免产生过多小文件
2. 根据查询结果大小适当调整Driver内存
3. 考虑使用ORC文件的高级配置选项优化存储格式
4. 监控Driver内存使用情况，及时发现潜在问题

总结

通过分析Kyuubi在处理ORC格式查询结果时的内存使用模式，我们识别并解决了一个可能导致Driver OOM的关键问题。这个优化不仅解决了内存溢出的风险，还为Kyuubi处理超大规模数据集提供了更可靠的基础。未来，我们还将继续优化结果获取机制，进一步提升系统的稳定性和性能。