Arrow DataFusion 执行计划重分区机制问题分析

问题现象

在 Arrow DataFusion 项目中，近期出现了一个与执行计划重分区相关的稳定性问题。多位开发者在不同场景下都遇到了类似的 panic 错误，错误信息指向 repartition/mod.rs 文件的第 618 行，提示"partition not used yet"。

这个问题最初是在 CI 测试中发现的，当时运行 custom_datasource 示例时出现了 panic。随后多位开发者在不同场景下复现了相同问题：

1. 运行 TPCH SQL 逻辑测试时出现 panic
2. 执行 topk_aggregate 基准测试时出现 panic
3. 运行 TPCH 基准测试时出现 panic

问题根源

经过开发者们的排查，这个问题与近期合并的一个优化 PR 有关。该 PR 移除了 HashJoinExec 中的 CoalescePartitions 操作，目的是优化执行计划。然而这一改动与现有的重分区机制产生了冲突。

问题的核心在于 RepartitionExec 执行器的实现逻辑。当执行计划被修改后，某些情况下会导致分区状态管理出现不一致，最终触发了"partition not used yet"的断言失败。

技术细节

RepartitionExec 是 DataFusion 中负责数据重分区的物理执行器。它通过以下方式工作：

1. 接收上游数据
2. 根据指定的分区策略重新分配数据
3. 将重分区后的数据发送给下游操作

在问题版本中，执行计划优化移除了不必要的 CoalescePartitions 操作，这本应提升性能。但由于某些执行路径中分区状态的跟踪机制不够完善，导致在某些情况下：

1. 分区被创建但未被正确初始化
2. 执行器尝试使用未准备好的分区
3. 触发断言失败

解决方案

开发团队迅速采取了以下措施：

1. 确认问题根源后，决定回退引起问题的变更
2. 在回退前进行了详细的版本验证，确认回退后问题不再出现
3. 计划在未来以更安全的方式重新实现该优化

经验教训

这个事件为分布式查询引擎的开发提供了几个重要启示：

1. 执行计划优化需要全面考虑：即使是看似局部的优化，也可能影响执行器的状态管理
2. 状态跟踪机制需要健壮性：分区等资源的生命周期管理需要更严谨的设计
3. 测试覆盖的重要性：这类问题在 CI 中偶尔出现，说明需要增强相关测试场景

后续改进

基于此问题，DataFusion 项目可能会考虑：

1. 增强分区状态管理的鲁棒性
2. 增加更多边界条件的测试用例
3. 改进执行计划变更的审查流程
4. 考虑引入更细粒度的分区状态跟踪机制

这类问题的解决有助于提升 DataFusion 作为高性能查询引擎的稳定性，特别是在处理复杂查询和分布式执行场景下的可靠性。