Arrow DataFusion 物理执行计划与数据源依赖关系设计探讨

在分布式查询引擎Arrow DataFusion的架构设计中，物理执行计划(physical-plan)与数据源(datasource)模块之间的依赖关系一直是一个值得深入探讨的技术话题。本文将详细分析当前架构中存在的依赖问题，探讨可能的解决方案，并给出专业的设计建议。

当前依赖关系分析

DataFusion当前的设计中，datasource模块依赖于physical-plan模块。这种设计导致了一个有趣的架构现象：physical-plan模块无法直接访问真实的datasource执行计划，而所有数据源却能访问所有物理计划（尽管它们实际上只需要访问trait定义）。

这种依赖关系在datasource模块从core分离之前就已经存在。从技术实现角度看，这种设计确实带来了一些架构上的不一致性。例如，DataSourceExec位于datasource模块中，而DataSinkExec却位于physical-plan模块中，这种不对称的分布可能导致下游用户在实现自定义source和sink时遇到困惑。

依赖关系设计考量

从架构设计原则来看，理想的依赖关系应该遵循从高层到底层的方向。多位开发者提出了不同的观点：

1. 一种观点认为依赖链应该是：Catalog → Schema → Table → File → PhysicalPlan，因此physical-plan访问datasource违反了这一依赖方向。

2. 另一种观点认为，物理执行计划采用树形表示，节点需要访问其子节点（自上而下方法）。在这种视角下，物理计划需要持有其数据源执行计划（如DataSourceExec），因此physical-plan应该能够访问datasource。

解决方案探讨

针对这一架构问题，提出了几种可能的解决方案：

方案一：引入physical-plan-common模块

建议引入一个新的physical-plan-common模块，包含ExecutionPlan trait定义和其他共享组件。依赖关系将变为：

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

这种设计的优势包括：

• physical-plan可以访问实际的datasource执行计划，不再依赖mock
• 通过集中管理执行计划定义，改善了代码组织结构
• 在保持必要访问的同时，最小化datasource的依赖

方案二：重构模块职责

另一种思路是将DataSinkExec和相关内容也移动到datasource模块中，并可能将模块重命名为"connectors"或其他与IO相关的名称。这种方案更强调将所有与数据源/接收器相关的实现集中管理。

技术权衡与建议

经过深入讨论，社区更倾向于保持现有的依赖方向，即datasource依赖于physical-plan。这种设计更符合物理计划是更高层次抽象的理念。同时，可以通过以下方式优化当前架构：

1. 减少datasource对physical-plan的依赖，仅保留必要的trait引用
2. 引入更明确的配置结构（如FileFormatFactoryConfig）来隔离不同层次的依赖
3. 仔细审查Session等跨模块依赖，确保它们确实必要

对于需要共享的公共组件，确实值得考虑创建一个新的common模块，但需要谨慎评估其范围和影响，避免过度工程化。

总结

在分布式查询引擎的架构设计中，模块间的依赖关系直接影响系统的可维护性和扩展性。DataFusion面临的这一设计挑战反映了在保持架构清晰与满足功能需求之间的平衡。当前的设计虽有改进空间，但已能较好地支持核心功能。未来可能的优化方向包括更精细的模块划分和依赖管理，以及更清晰的接口定义。