Apache Kyuubi 内存优化：解决 FetchOrcStatement 驱动内存溢出问题

背景与问题分析

Apache Kyuubi 作为一个企业级数据湖管理平台，在处理大规模数据查询时提供了 FetchOrcStatement 功能，该功能通过 ORC 文件格式高效地获取查询结果。然而，在实际生产环境中，当处理超大规模数据集时，我们发现驱动节点（Driver）会出现内存溢出（OOM）问题。

问题的根源在于当前实现中，FetchOrcStatement 会为每个 ORC 文件预先初始化 RecordReaderIterator 对象。每个 RecordReaderIterator 在初始化其内部的 OrcMapreduceRecordReader 时，会预读取部分数据行到内存中。当查询结果包含大量 ORC 文件（这在启用自适应查询执行（AQE）或其他配置时很常见），这些预读取的数据会迅速耗尽驱动节点的内存资源。

技术细节剖析

在 ORC 文件读取机制中，OrcMapreduceRecordReader 的设计初衷是为了优化 MapReduce 作业中的并行读取性能。它会在初始化阶段执行以下操作：

1. 读取文件元数据信息
2. 预加载首个数据条带（Stripe）的部分数据
3. 建立列式存储的读取通道

这种设计在分布式处理场景下能提高吞吐量，但在 Kyuubi 的客户端获取结果场景下，却成为了内存瓶颈。特别是在以下情况会加剧问题：

• 查询结果被 Spark 划分为大量小文件
• 表包含宽列（大量字段）
• ORC 文件采用较大的条带大小配置

解决方案设计

经过深入分析，我们提出了惰性初始化（Lazy Initialization）的优化方案：

1. 按需加载机制：仅在客户端实际请求数据时，才初始化对应的 RecordReaderIterator
2. 单文件活跃原则：确保内存中同一时间只保留一个活跃的文件读取器
3. 资源及时释放：完成文件读取后立即释放相关资源

这种设计显著降低了驱动节点的内存压力，同时保持了原有的数据吞吐能力。实现要点包括：

• 重构 OrcFileIterator 的迭代器管理逻辑
• 引入文件读取状态跟踪机制
• 确保线程安全的惰性初始化过程

实施效果验证

优化后的实现通过了以下验证：

1. 功能测试：确保所有数据能正确无误地返回给客户端
2. 性能测试：验证吞吐量不受惰性加载影响
3. 内存测试：确认驱动节点内存使用量大幅下降
4. 稳定性测试：长时间运行大规模查询不再出现 OOM

最佳实践建议

基于此问题的解决经验，我们建议在使用 Kyuubi 处理大规模数据时：

1. 合理配置 spark.sql.shuffle.partitions 控制输出文件数量
2. 根据数据规模调整 spark.driver.memory 参数
3. 考虑使用 kyuubi.operation.result.saveToFile.minSize 控制文件保存阈值
4. 定期监控驱动节点的内存使用情况

这项优化不仅解决了内存溢出问题，也为 Kyuubi 处理超大规模数据集提供了更稳健的基础架构，体现了开源社区通过实际问题推动技术演进的价值。