Trino项目BigQuery连接器在高并发查询时的阻塞问题分析

在Trino与BigQuery集成使用过程中，我们发现了一个影响系统性能的关键问题：当对大型表执行重复SELECT查询时，会导致后续简单查询被阻塞。这个问题最初在Trino的22279号PR合并后被发现，虽然根本原因可能在此之前就已存在，但并行度的调整加剧了问题的出现频率。

问题现象

具体表现为：

1. 对包含1.84亿行数据、30列的大型表执行"SELECT * FROM table LIMIT 10"这类简单查询
2. 当连续执行10-15次此类查询后，原本只需数秒完成的查询会延长至1分钟以上
3. 此时执行"SHOW CATALOGS"等简单命令也会被阻塞，直到前面的SELECT查询完成

技术分析

从线程转储文件分析，问题主要出现在BigQueryStorageArrowPageSource类的getNextSourcePage方法中。该方法在等待nextResponse Future完成时没有正确处理阻塞状态，导致查询线程被长时间占用。

核心问题在于：

• 当前实现中，当nextResponse Future未完成时，getNextSourcePage方法没有返回null
• 这导致驱动槽(driver slot)无法通过isBlocked方法返回的Future来正确释放
• 最终结果是查询线程被不必要地占用，影响系统整体吞吐量

解决方案建议

技术团队提出的修复方案是修改BigQueryStorageArrowPageSource类的getNextSourcePage方法实现：

1. 当nextResponse Future未完成时，方法应返回null
2. 这样系统可以正确利用isBlocked方法返回的Future来管理阻塞状态
3. 确保驱动槽能够及时释放，避免不必要的线程占用

问题影响

该问题对生产环境的影响包括：

• 系统吞吐量下降，特别是在高并发查询场景下
• 简单元数据查询被阻塞，影响用户体验
• 资源利用率降低，可能导致查询超时等问题

后续进展

虽然25422号PR提供了一定程度的缓解，但问题在master分支中仍然存在。技术团队正在深入分析根本原因，以提供更彻底的解决方案。建议用户在使用Trino查询BigQuery大型表时，注意监控查询并发度，避免出现此类性能问题。

该案例也提醒我们，在分布式查询引擎中，资源管理和阻塞处理机制的设计对系统稳定性至关重要，特别是在与外部数据源集成时更需要谨慎处理异步操作和线程管理。