Apache DataFusion 排序执行中的 Tokio 阻塞线程优化

在 Apache DataFusion 项目中，SortExec 操作在处理大数据量时会将中间结果溢出(spill)到磁盘文件。当可用内存较少时，系统可能会生成大量溢出文件，这会导致 Tokio 运行时创建过多的阻塞线程，进而引发系统资源耗尽的问题。

问题的核心在于 SortExec 的合并(merge)阶段。当需要合并大量溢出文件时，每个文件都会被包装成一个由阻塞线程支持的流。例如，当有183个溢出文件需要合并时，系统会创建至少183个阻塞线程。这种设计在资源受限的环境下(如Comet运行时)会导致线程饥饿，使查询操作"挂起"。

针对这一问题，社区提出了多级合并的解决方案。传统的单级合并方式会一次性尝试合并所有溢出文件，而改进后的方案采用分阶段合并策略：

1. 首先将大量溢出文件分组进行初步合并(例如将183个文件分成约18组，每组合并10个文件)
2. 然后对初步合并后的结果文件进行最终合并

这种方案虽然会增加约一倍的I/O操作(因为每个数据行需要被读写两次)，但能有效控制并发线程数量。更重要的是，初步合并阶段可以并行执行，充分利用系统资源。

该优化不仅适用于SortExec操作，同样适用于使用SortPreservingMergeStream的其他操作，如AggregateExec的row_hash聚合。这提示我们可以考虑将排序和哈希操作的溢出处理统一到相同的代码路径中，便于集中优化。

在实现层面，需要注意Tokio运行时对阻塞线程数量的隐式限制。虽然Tokio不直接暴露其配置的最大阻塞线程数，但在资源受限环境下(如Comet默认只配置10个阻塞线程)，合理的并发控制尤为重要。

未来可能的优化方向包括预取(prefetch)机制的引入，以及更精细的I/O调度策略。同时，随着Comet运行时计划从"每个计划一个Tokio运行时"改为"每个执行器一个全局运行时"，这种优化将变得更加重要。

这种多级合并策略代表了大数据处理中经典的"分而治之"思想，通过增加少量I/O开销换取系统稳定性和可扩展性的提升，是资源受限环境下处理大规模数据排序的有效解决方案。