Apache Kyuubi 大数据查询中 Socket 关闭问题分析与解决方案

问题现象

在使用 Apache Kyuubi 1.10.0 版本进行大数据查询时，当用户通过 DataGrip 客户端执行全表扫描查询（如 SELECT * FROM catalog.namespace.sample）时，系统返回"Socket is closed by peer"错误。该表包含约190万行数据，查询执行约10-15秒后出现此错误，而在Spark应用UI中却显示查询已成功完成。

问题分析

根本原因

经过深入分析，该问题主要由以下几个因素共同导致：

1. 结果集格式设置：客户端配置了 kyuubi.operation.result.format=arrow，使用Apache Arrow格式传输数据。Arrow格式虽然高效，但对内存要求较高。

2. 内存限制：Spark驱动程序的堆内存配置为3GB（spark.driver.memory=3g），对于190万行数据的全量传输明显不足。

3. 数据传输机制：当结果集过大时，Kyuubi尝试将所有结果缓存在内存中再传输给客户端，导致驱动程序内存溢出。

技术细节

在Thrift协议层，当驱动程序因内存不足无法继续处理请求时，会主动关闭Socket连接，这就是客户端收到"Socket is closed by peer"错误的原因。而此时Spark作业可能已经完成了数据计算阶段，只是无法完成结果传输阶段。

解决方案

短期解决方案

1. 增加驱动程序内存：根据数据规模适当增加 spark.driver.memory 参数值，建议至少设置为8-16GB。

2. 使用分页查询：改写查询为分页形式，如 SELECT * FROM catalog.namespace.sample LIMIT 10000 OFFSET 0。

3. 调整结果格式：临时切换回传统的结果格式 kyuubi.operation.result.format=thrift。

长期最佳实践

1. 增量获取结果：配置 kyuubi.operation.incremental.collect 为true，启用结果集增量获取模式。

2. 结果集分片：设置合理的 kyuubi.operation.result.max.rows 参数，控制每次返回的数据量。

3. 查询优化：避免全表扫描，只查询必要的列，如 SELECT col1, col2 FROM catalog.namespace.sample。

4. 资源监控：实施完善的资源监控体系，提前预警可能的OOM情况。

技术原理深入

Apache Kyuubi在Spark SQL查询结果传输过程中，会根据配置的结果格式采用不同的序列化方式。当使用Arrow格式时：

1. 驱动程序需要先将所有结果转换为Arrow格式的二进制数据
2. 这个转换过程会在内存中创建完整的Arrow RecordBatch
3. 对于大数据集，这个内存占用可能远超预期
4. 当超过JVM堆内存限制时，会触发OutOfMemoryError
5. Thrift服务端会因此异常终止连接，导致客户端收到Socket关闭错误

相比之下，传统的Thrift序列化方式虽然效率较低，但对内存的压力更小，更适合大数据量传输场景。

总结

大数据查询中的结果传输是一个需要特别关注的环节。通过合理配置Kyuubi的参数、优化查询方式以及建立完善的资源监控机制，可以有效避免类似"Socket is closed by peer"的问题。对于生产环境，建议采用增量获取和结果分片的组合方案，既能保证查询效率，又能确保系统稳定性。