Apache DataFusion物理执行计划与数据源依赖关系设计分析

在分布式查询引擎Apache DataFusion的架构设计中，物理执行计划(physical-plan)与数据源(datasource)模块之间的依赖关系一直是一个值得深入探讨的技术话题。本文将从架构设计的角度，分析当前依赖关系的合理性，并探讨可能的优化方案。

当前依赖关系现状

DataFusion目前的设计中，datasource模块依赖于physical-plan模块。这种设计意味着：

1. 物理执行计划模块无法直接访问真实的数据源执行计划
2. 所有数据源实现却能访问全部物理执行计划代码
3. 关键组件如DataSourceExec位于datasource模块，而DataSinkExec却位于physical-plan模块

这种不对称的依赖关系在架构上显得不够优雅，也带来了一些实现上的不便。特别是当开发者需要实现自定义数据源和数据接收器时，这种设计会导致代码组织上的困扰。

依赖关系设计原则

在分布式查询引擎的架构设计中，理想的依赖关系应该遵循自底向上的原则：

Catalog → Schema → Table → File → PhysicalPlan

这种层级关系确保了高层模块可以依赖于低层模块，而低层模块不应该了解高层模块的实现细节。按照这个原则，physical-plan作为更高层次的抽象，理论上不应该反向依赖于datasource模块。

现有问题分析

当前设计存在几个值得关注的问题：

1. 概念不对称：DataSourceExec和DataSinkExec这两个对称概念被放置在不同模块中
2. 依赖方向：datasource对physical-plan的依赖使得physical-plan无法直接使用数据源实现
3. 扩展困难：开发者在实现自定义数据源/接收器时面临模块边界问题

特别是当需要实现同时包含数据源和数据接收功能的连接器时，开发者不得不将部分实现放在不合适的模块中，以绕过现有的依赖限制。

可能的解决方案

方案一：引入公共模块

提出引入physical-plan-common模块，将ExecutionPlan trait定义等公共部分提取出来：

datasource → physical-plan-common
physical-plan → physical-plan-common
physical-plan → datasource

这种设计可以：

1. 保持核心接口定义在公共模块
2. 允许物理执行计划访问具体数据源实现
3. 减少不必要的依赖传递

方案二：重构模块职责

另一种思路是将所有与IO相关的组件(包括DataSinkExec)统一移动到datasource模块(或重命名为connectors等更贴切的名称)。这种重构可以：

1. 保持依赖关系的单向性
2. 将IO相关功能集中管理
3. 提供更清晰的模块边界

架构权衡考量

在决定采用哪种方案时，需要考虑以下因素：

1. 概念完整性：确保相关功能放在概念上最合适的模块中
2. 依赖简洁性：尽量减少模块间的交叉依赖
3. 扩展便利性：为开发者提供清晰的扩展点
4. 性能考量：避免因模块拆分引入不必要的运行时开销

结论与建议

DataFusion当前的依赖关系设计虽然能够工作，但从架构清晰度和长期可维护性角度考虑，确实存在优化空间。引入公共模块的方案提供了较好的平衡，既能解决当前的依赖问题，又不会对现有代码造成太大冲击。

对于项目维护者来说，建议：

1. 明确各模块的职责边界
2. 评估重构对现有用户的影响
3. 考虑分阶段实施重构，先引入公共模块，再逐步调整组件位置

这种渐进式的改进可以在保证系统稳定性的同时，逐步优化架构设计，为DataFusion的长期发展奠定更坚实的基础。