KnowForge/Apache DataFusion 简体中文
贡献者指南

路线图与改进建议

师成师成· 更新于 2026-09-28· 阅读 9 分钟· 0 次阅读
登录后可跨设备保存划线和私人笔记登录

路线图与改进提案

项目介绍 说明了 DataFusion 的概览与目标，我们的开发工作也很大程度上与这一愿景保持一致。

规划 EPIC

DataFusion 使用 GitHub issues 来跟踪计划中的工作。我们通过带有 EPIC 标签的跟踪 issue 来汇总相关工单，这些 issue 包含讨论内容以及指向更详细条目的链接：

Epic 提供了一份高层次的路线图，展示 DataFusion 社区正在思考的方向。Epic 并非为了限制可能性，而是帮助组织社区，让人们更容易看清开发方向、协调我们的工作，并激发更多的贡献。

我们也欢迎针对 Epic 未涵盖条目的贡献。不过，在提交大型 PR 之前，我们强烈建议并请求你先按照下文 讨论新功能 中的说明发起讨论。

季度路线图

DataFusion 的路线图由贡献者的优先事项驱动，而非由任何单一组织或协调委员会决定。我们通常通过 GitHub issues 大约每季度讨论一次路线图，并欢迎你加入讨论。

当前的路线图讨论是 DataFusion 2026 Q3-Q4 路线图讨论。

更多信息：

  1. 搜索带有 roadmap 标签的 issue
  2. DataFusion 2026 Q3-Q4 路线图讨论
  3. DataFusion 路线图：2026 年 Q1
  4. DataFusion 路线图：2025 年 Q3-Q4
  5. 2024 Q4 / 2025 Q1 路线图

改进提案

讨论新功能

如果你计划开发一个尚无现有工单的新功能，先创建一个工单用于讨论是个好主意。通过前期讨论，可以在投入大量时间之前确定该功能是否适合 DataFusion，从而避免浪费精力。在工单上讨论有助于收集社区的反馈，而且通常比讨论一个上千行的 PR 更容易。

维护者会将重大提案标记为 PROPOSED EPIC，以提高其可见性，但我们的评审带宽非常有限。如果你创建了工单却迟迟没有回应，可以尝试在工单中用 @ 提及最近活跃的社区成员，或者发送到邮件列表或 Discord。

监督维护者

我们发现，大多数成功的 Epic 都有一位或多位「监督维护者」，他们由提交者（当前名单见此）担任，负责主导 PR 的评审与提交、协助设计，并与社区协调沟通。如果你想交付一个大型功能，我们建议提前找到这样的维护者；否则，你的 PR 可能会长时间无人评审。

监督维护者并没有额外的正式权力，目前也没有正式的流程来任命、批准或跟踪某个 Epic 中谁担任这一角色。相反，我们依靠工单或 PR 上的讨论来决定。协助完成一个 Epic 需要投入大量时间，因此维护者更倾向于帮助那些他们特别感兴趣、或与自身项目对 DataFusion 的使用相契合的功能。

如果你愿意担任某个功能的监督维护者，请明确说明。如果你不确定，建议直接询问有谁愿意担任该角色，因为有时很难判断某位提交者只是在参与并给出一般性反馈。

哪些贡献更合适？

DataFusion 的设计高度可扩展，许多功能都可以作为扩展实现，而无需修改或新增核心代码。对新函数、数据格式等类似功能的支持，都可以通过这些扩展 API 添加，并且扩展列表中已经列出了许多由社区维护的扩展。

查询引擎是复杂且难以开发和维护的软件。鉴于我们的维护带宽有限，我们尽量让 DataFusion 核心保持简单和专注，同时仍然满足易于上手的初始体验这一设计目标。

基于以上考虑，符合以下标准的贡献更有可能被接受：

  1. 修复现有功能的 Bug
  2. 提升现有功能的测试覆盖率
  3. 改进文档 / 增加示例
  4. 提升现有功能的性能（附带基准测试）
  5. 对现有功能的“小”幅功能改进（前提是不改变现有行为）
  6. 用于扩展 DataFusion 能力的附加 API
  7. 改进 CI

在被接受之前可能需要更多讨论（参见上文「讨论新功能」）的贡献包括：

  1. 重大新功能（即使它属于“标准 SQL”的一部分）
  2. 新函数，尤其是不属于“标准 SQL”的函数
  3. 新数据源（例如对 Apache ORC 的支持）

边构建边设计 vs. 事前完整设计

通常，DataFusion 社区通过逐步解决的方式来攻克大型问题，并在 main 分支上以一系列 Pull Request 的形式迭代地完善解决方案。这与那些在前期投入大量精力进行更全面设计流程的项目不同。

通过“推进前沿”，社区始终能够取得切实进展，这种策略在依赖个人贡献者的项目中尤为有效，因为他们可能没有时间和资源投入到大规模的前期设计工作中。然而，这种“逐步推进的方法”并不总是一帆风顺，有时我们会陷入困境或走上错误的方向，随后再调整方向。

我们的流程在某些情况下不可避免地会导致不够完善的解决方案成为“当前代码状态”，更大的愿景也尚未完全实现。然而，从长远来看，社区非常擅长推动事情走向完成。如果你发现某些地方需要改进，或某个领域尚未完全实现，请考虑提交 issue 或 PR 来加以改进。我们始终欢迎更多的贡献。

评论

登录后参与评论

正在加载评论…