如果只把 Apache DataFusion 描述成“一个用 Rust 写成的 SQL 引擎”，它的价值很容易被低估。这个说法成立，却把视线引向了较窄的方向。更有用的理解方式在架构层面：DataFusion 把查询规划和执行变成一条可复用边界，其他系统可以嵌入它、扩展它，并把它放在自己的产品表面之下。项目本身把 DataFusion 描述为一个用 Rust 编写的可扩展查询引擎，使用 Apache Arrow 作为内存格式，提供 SQL 和 DataFrame API，内置 CSV、Parquet、JSON、Avro 支持，并提供大量定制点。[2]

这种组合让 DataFusion 更像共享机房，而不是已经封装好的数据库设备。上方的服务器机架照片比应用截图更贴近本文，因为有意思的工作发生在可见应用层之下。[1] 一个产品可以继续保留自己的 catalog、安全模型、存储布局、文件生命周期、API 与用户体验，同时把数据库工作中困难的一段交给通用 planner、optimizer 和 executor。

由此产生的实际问题，不是“DataFusion 会取代每一种数据库吗”。问题在于：团队应该在哪里停止手写查询行为，并开始把查询引擎当作基础设施。

可复用的部分是计划

DataFusion 最强的边界是逻辑计划。它的文档把逻辑计划定义为数据库查询的结构化表示，用来描述过滤、排序、连接等高层操作，同时抽离实现细节。[3] 这个定义初看平常，直到你看到它允许什么：SQL、DataFrame API 和自定义前端可以在优化与物理执行之前汇入同一个中间表示。

这种汇合正是重点。一个数据应用常常从狭窄需求开始：让用户过滤一张表、在 Parquet 上运行聚合、给事件存储加上 SQL、提供本地分析模式。最初的实现往往会长成一堆特殊分支。谓词变成自定义代码。投影变成自定义代码。连接会被推迟，直到客户要求它。到最后，产品在无意间拥有了一套查询 planner。

DataFusion 提供了另一条界线。构造或接收一个逻辑计划，让 optimizer rules 重写它，把它降到物理计划，再针对 Arrow-native 数据执行生成的算子。项目文档指出，逻辑计划位于查询输入与优化后的物理执行之间，LogicalPlan 类型也包含一个 extension 变体，供需要自定义逻辑算子的项目使用。[3] 这个扩展钩子很重要，因为嵌入式引擎很少生活在完全通用的世界里。它们处在带有特定领域表、函数、权限和存储事实的产品内部。

物理计划让现实进入系统

逻辑计划与物理计划之间的清晰分离，不是学术装饰。DataFusion 的 explain-plan 指南直接画出了边界：逻辑计划由 SQL、DataFrame 或另一种语言生成，不带有对底层数据组织的认识；物理计划则从逻辑计划生成，并考虑硬件配置与数据布局。[4]

这正是嵌入式查询引擎所需要的分工。产品代码可以描述一个查询意味着什么。引擎代码可以决定如何运行它。Parquet 扫描、分区数据源、向存储侧推进的过滤、连接策略、可用 CPU 核心数量，这些都属于物理层关注点。它们不应渗入每一个只想得到“这个分群里的客户，按周分组”的调用方。

DataFusion 近期发布说明显示，这条边界一直处在活动状态，已经超出理论层面。2026 年 4 月 DataFusion 53.0.0 文章突出了一系列规划与执行改进，包括感知 limit 的 Parquet row group pruning、更广范围的 filter pushdown、更快的规划、更快的函数，以及数据源中的嵌套字段 pushdown。[9] 这些属于引擎层改进。嵌入 DataFusion 的系统可以从中受益，省去在自己的应用代码里重新发明每一种优化的成本；不过升级仍然需要测试，因为发布说明也提到 parser、optimizer 和 physical-plan API 的变化。[9]

Arrow 是底层契约

这条引擎边界能够成立，是因为 DataFusion 没有在中心位置发明私有行格式。它自己的 Arrow 指南说明，DataFusion 使用 Apache Arrow 作为原生内存格式，并介绍 RecordBatch 作为 Arrow 打包数据的标准单位：在同一 schema 下具有相同长度的列式数组，适合流式处理与并行执行。[6] Arrow 列式规范把 record batch 描述为一组有序数组，它们共享长度与 schema，并定义了可以在不复制底层数据 buffer 的情况下重建 batch 的序列化路径。[7]

这让 DataFusion 的 executor 比只使用私有结构的引擎更容易跨宿主系统移植。调用方可以围绕 table provider、batch、stream 和列式数组来思考，而不是面对不透明 record。集成工作仍然存在，只是这项工作被移到一个被广泛使用的内存契约之上。

这种收益在分析型系统里尤其清楚。向量化执行需要列。Parquet 这类文件格式需要 projection 和 predicate pushdown。Python、Rust、Java 以及其他运行时越来越多地在 Arrow 形态的数据周围相遇。当 DataFusion 生成并消费 Arrow batch 时，它进入的是更大的生态，而不是要求每个嵌入它的产品都穿过一套定制内部布局。

扩展点决定嵌入是否真实

可复用引擎如果只在演示里可复用，最终会失效。DataFusion 的架构更强，原因在于扩展本身就是设计表面的一部分。项目主页称，DataFusion 可以在许多位置定制，包括数据源、查询语言、函数、自定义算子等。[2] 它的 custom table-provider 文档把这件事具体化：逻辑计划描述一个查询计算什么，而逻辑优化器可以重写关系树以减少工作，包括把谓词推向更靠近数据源的位置。[5]

table-provider 边界是采纳的枢纽。团队可以保留专门的存储系统、object-store 布局、catalog 或领域数据源，再教会 DataFusion 如何扫描它。table provider 成为产品特定数据所有权与通用关系执行之间的契约。只要 provider 可以报告 schema、暴露统计信息、尊重 projection，并在条件允许时 push filter，引擎就有足够信息避免把每个数据源都当作迟钝文件。

函数和算子也一样。产品常常需要领域表达式：地理空间谓词、可观测性函数、时间序列窗口、向量搜索衔接、计费计算，或者为另一种 SQL dialect 提供兼容函数。查询引擎边界只有在这些差异可以接入、同时不分叉整套引擎时才有用。DataFusion 的公开设计和 SIGMOD 论文都强调了前端、catalog 与表集成、计划重写、执行节点等层面的模块化与扩展能力。[2][8]

采纳边界不是“到处使用 DataFusion”

合适的结论比热闹叙事更窄，也更有用。当团队正在构建类似数据库或类似分析系统的产品，同时不想独自拥有一整套查询引擎时，DataFusion 很适合进入评估。它尤其适合嵌入式分析、数据质量工具、lakehouse 工具、可观测性存储、local-first 分析功能、自定义格式之上的 SQL 层，以及已经依赖 Arrow 或 Parquet 的产品。

当目标是开箱即用的数据库服务时，它的适配度会变弱。DataFusion 不能替团队消除认证、授权、租户、catalog 设计、存储压实、元数据事务、备份、复制、负载治理、运维 UI、计费集成或支持边界。它给团队的是查询引擎，不是完整数据平台。

这种区别应该塑造评估方式。第一个原型不应只问 DataFusion 能否运行一条示例 SQL 查询。它还应该问：产品能否通过 table provider 表达自身数据模型，filter 和 projection 是否被充分推向存储侧，自定义函数能否保持可维护，Arrow batch 是否自然流经系统其余部分，以及升级测试能否吸收 optimizer 与 physical-plan 的变化。

架构信号

DataFusion 的意义在于，它让数据库组件可以复用，同时不把每个产品都推成同一种数据库。SQL 和 DataFrame 输入汇入逻辑计划。Optimizer rules 改进这些计划。物理规划纳入数据布局和硬件。执行过程产出 Arrow-native batch。扩展点让产品保留各自的存储、函数和前端。

这就是本文的架构札记：DataFusion 的重心不在命令行、benchmark 图表或某一个单独版本上。它位于这样一条边界上，产品团队可以在这里停止无意间继续生长私有查询引擎。当它让团队保留系统中的独特部分，同时共享规划、优化和向量化执行这套困难机器时，这个项目的价值就显现出来。

来源

  1. Wikimedia Commons，〈Front of server racks at NERSC.jpg〉- Derrick Coetzee 拍摄的照片，本文题图来源。
  2. Apache DataFusion，〈Apache DataFusion〉- 项目概览，描述 Rust 查询引擎、Arrow 内存格式、SQL 与 DataFrame API、内置格式和定制点。
  3. Apache DataFusion，〈Building Logical Plans〉- library guide，解释逻辑计划、作为后续步骤的物理执行，以及 LogicalPlan extension 变体。
  4. Apache DataFusion，〈Reading Explain Plans〉- user guide，区分逻辑计划与物理计划，并解释物理规划如何纳入数据组织和硬件。
  5. Apache DataFusion，〈Custom Table Provider〉- library guide，描述逻辑规划、优化器重写、predicate pushdown 与 table-provider 集成。
  6. Apache DataFusion，〈Gentle Arrow Introduction〉- guide，解释 DataFusion 对 Arrow 的原生使用，以及 RecordBatch 作为适合流式处理和并行执行的列式单位。
  7. Apache Arrow，〈Arrow Columnar Format〉- 规范，描述 record batch、schema、buffer，以及 Arrow IPC 格式中的零复制重建。
  8. Andrew Lamb 等，〈Apache Arrow DataFusion: A Fast, Embeddable, Modular Analytic Query Engine〉- SIGMOD 2024 论文，讨论 DataFusion 可嵌入、模块化的架构以及计划/执行阶段。
  9. Apache DataFusion Blog，〈Apache DataFusion 53.0.0 Released〉- 2026 年 4 月发布说明，涵盖规划、pushdown、函数、嵌套字段、发布工程和升级表面变化。