架构

DataFusion 的代码结构与组织方式在 crates.io 文档中有所描述，以尽可能保持其与源码一致。你可以在源代码中找到最新版本。

分叉（Fork）与扩展 API

DataFusion 是一个快速演进的项目，内部变动频繁。这有利于 DataFusion 的发展，使其能够快速演进并响应各种需求，但同时也意味着，维护一个包含重大修改的分叉（fork）有时需要不小的投入。

公开 API（即你使用 crates.io 上的 DataFusion 发行版时可以访问的部分）通常要稳定得多（尽管它在不同版本之间也会发生变化）。

因此，我们建议不要使用分叉，而是通过众多扩展 API（例如 TableProvider、OptimizerRule 或 ExecutionPlan）之一来定制 DataFusion。如果你无法用现有 API 实现所需的功能，我们非常欢迎你与我们一起添加新的 API 来支持你的用例，具体内容见下一节。

请参阅扩展章节，以了解现有的 DataFusion 扩展以及如何将你的扩展贡献给社区。

创建新的扩展 API

DataFusion 致力于成为一个通用查询引擎，因此核心 crate 包含了对各类用例都有用的功能。特定用例的功能（例如非常专门的时间序列或流处理功能）通常通过扩展 API 来实现。

如果你的用例未被现有 API 覆盖，我们很乐意与你一起设计新的通用 API。通常也会有其他人对类似的扩展感兴趣，而定义 API 这一过程往往能让所有人都受益，从而整体改进代码。

提供「安全」默认行为的扩展 API 更有可能适合纳入 DataFusion，而需要对内置算子做出重大改动的 API 则不太可能被纳入。例如，如果为支持某个流处理特性而添加 API 会导致内置算子性能下降，那么添加该 API 可能就没有太大意义。为这类特性添加扩展 API 仍可能是合理的，但可以把这类算子的实现留在下游项目中。

创建新的扩展 API 的流程通常是：

• 查找描述你想实现内容的已有 issue，若尚不存在则提交一个。
• 讨论该 API 应该是什么样子。欢迎通过 @ 提及向贡献者征求反馈（可以通过查看最近变更的 PR 和 issue 找到这些人）
• 为新 API 编写原型，通常做法是添加一个示例（放在 datafusion-examples 中）或重构现有代码，以展示其工作方式
• 创建包含新 API 的 PR，并与社区协作将其合并

采用基于示例的方法有以下一些好处：

• 未来的 API 变更也会同步让你的示例保持可用，从而确保功能不会出现回归
• 如果 API 确实发生变化，你的代码需要做哪些改动会有明确的蓝图（只需查看示例中发生了什么变化）

这一流程的一个例子是创建 SQL 扩展规划 API。