Apache DataFusion 深度拆解：当 Rust 遇上向量化查询引擎——从 Arrow 内存模型、查询优化器到 Comet 加速 Spark 的工程全貌（2026）

如果你在 2026 年做数据基础设施，会发现一个有趣的现象：你手机里几乎没有装过 Apache DataFusion，但它大概率已经在你依赖的某条数据链路上默默跑了无数次。它是一个"查询引擎库"而非"数据库"，是 DuckDB 在湖仓场景里经常被拿来对比的那个 Rust 引擎，更是苹果开源的 DataFusion Comet 用来给 Apache Spark "换心"的原生执行内核。本文从内存模型、向量化执行、查询优化器一路拆到生产级代码实战与 Comet 加速 Spark 的工程全貌，目标只有一个：让你真正理解 DataFusion 为什么是当下数据工具的"隐形底座"。

一、背景：为什么 DataFusion 是 2026 年数据基础设施的"隐形引擎"

1.1 一个被低估的事实

2024—2026 这几年，数据圈最热闹的叙事是"向量数据库""Lakehouse""大模型 RAG"。但很少有人注意到，在这些叙事背后，有一批用 Rust 重写的数据组件正在悄悄接管执行层：

• DuckDB 用 C++ 把嵌入式分析数据库做到了极致；
• Polars 用 Rust + Arrow 重新定义了 DataFrame；
• Apache DataFusion 则走了一条更"底层"的路——它不做一个数据库，而是做一个可以被任意上层系统嵌入的查询引擎库。

DataFusion 的 GitHub 仓库（apache/datafusion）在 2026 年依然保持高频提交，它背后的公司阵容（Apple、Microsoft、Databricks 系创业者、各大云厂商）和下游项目（Ballista 分布式执行、Comet 的 Spark 加速、InfluxDB 3.0 的存储引擎、多个 Lakehouse 查询层）让它成为事实上的"查询引擎标准件"。

1.2 引擎（Engine）与数据库（Database）的根本区别

理解 DataFusion 的第一个关键点：它是查询引擎，不是数据库。

这意味着 DataFusion 的核心能力是：给定一个查询（SQL 或 DataFrame），在一批已经加载进内存的数据上，以最高的效率算出结果。它天生适合做"嵌入"——把它塞进你的数据管道、你的 Agent 记忆系统、你的 Spark 执行层，而不是再起一个服务。

这也是为什么 DataFusion 和 DuckDB 经常被并列讨论，却走的是两条路：DuckDB 想替你管理一切（包括存储），DataFusion 只负责把"算"这件事做到极致，把"存"和"管"交还给宿主。

1.3 为什么是现在

三个趋势在 2026 年同时成熟，把 DataFusion 推到了舞台中央：

1. Arrow 成为内存事实标准：跨语言、零拷贝的列式内存格式，让 Rust/Python/Java/C++ 之间传递数据不再需要序列化。DataFusion 的全部内存都是 Arrow，这是它高性能的根。
2. 向量化执行成为共识：行式"逐行解释"的时代过去了，按列批量（RecordBatch）算才是正道。
3. 嵌入式 + 本地优先（Local-first）复兴：随着端侧推理、AI Agent、本地数据处理的爆发，开发者更愿意把一个引擎编译进自己的二进制，而不是连一个远程数据库。Rust 无 GC、可编译成单二进制的特性在这里价值巨大。

二、核心概念：DataFusion 到底在算什么

2.1 Apache Arrow：零拷贝的列式内存

DataFusion 的每个数据单元都是一个 RecordBatch——一块列式内存，包含 N 行、若干列，每一列是一个 Arrow Array。

为什么 Arrow 这么重要？传统行式处理里，CPU 要顺着指针跳来跳去读一条记录的多个字段，缓存命中率低。Arrow 把同一列的所有值连续存放：

// 行式（Row-wise）：一条记录在内存里是 [id, name, age] 连续，下一条又是 [id, name, age]
// 列式（Columnar / Arrow）：id 列连续、name 列连续、age 列连续

ages:   [25, 30, 41, 19, 52]   // 连续内存，SIMD 友好
names:  ["a", "b", "c", "d", "e"]

连续内存带来两个直接收益：

• SIMD 友好：一条 CPU 指令可以并行处理 8/16/32 个值（比如"age > 30"可以一次比较一整段）。
• 压缩与编码友好：同类型数据连续存放，字典编码、RLE 等压缩更有效。

更重要的是 Arrow 是跨语言的：Rust 侧生成的 RecordBatch，在 Python 侧通过 pyarrow 可以直接零拷贝拿到，无需序列化。DataFusion Python 绑定正是靠这一点，把 Rust 的执行性能和 Python 的易用性缝合在一起。

2.2 向量化执行（Vectorized Execution）

DataFusion 的执行模型是**按批（batch）**的：每个算子（operator）不处理"一行"，而是处理一个 RecordBatch（默认 4096 行）。

Scan(Parquet) ──▶ Filter(age>30) ──▶ Project ──▶ HashAggregate ──▶ 输出
   ▲ 每次吞吐一个 RecordBatch（4096 行），整批流过所有算子

对比行式解释执行（Volcano 模型，每行的 next() 在上百个算子间反复调用），向量化有两个压倒性优势：

• 函数调用开销被摊薄：一次调用处理 4096 行，而不是 4096 次调用处理 1 行。
• 分支预测与流水线更稳：整批走同一条代码路径，CPU 分支预测命中率高。

2.3 逻辑计划与物理计划（LogicalPlan / PhysicalPlan）

DataFusion 把"查询"拆成两层：

• LogicalPlan（逻辑计划）：关系代数的树，描述"要算什么"，与具体执行无关。例如 Projection -> Filter -> TableScan。
• PhysicalPlan（物理计划）：描述"怎么算"，是真正能跑的执行算子。例如 ProjectionExec -> FilterExec -> ParquetExec。

中间经过 Analyzer（语义分析） 和 Optimizer（基于规则的优化），最后由 PhysicalPlanner 翻译成可执行计划。这是经典数据库架构，DataFusion 的可玩之处在于：每一层都暴露了扩展点。

2.4 几个你一定会用到的核心类型

• SessionContext：一切的起点，持有配置、Catalog、注册的表与 UDF。
• DataFrame：惰性（lazy）的查询构建器，调用 .show() / .collect() 才真正触发执行。
• Expr：表达式树（col("a").gt(lit(1)) 就是一个 Expr）。
• TableProvider：数据源抽象，让你把任何数据接进 DataFusion。
• ExecutionPlan：物理算子的 trait，自定义数据源/算子要实现它。

三、架构分析：一条 SQL 是怎么跑完的

3.1 总体流水线

SQL 字符串
   │  DFParser
   ▼
AstNode（sqlparser AST）
   │  SqlToRel
   ▼
LogicalPlan（关系代数树）
   │  Analyzer（类型推导、字段解析、CTE 展开）
   ▼
LogicalPlan（已分析）
   │  Optimizer（Rule-based：常量折叠、谓词下推、子查询消除…）
   ▼
LogicalPlan（已优化）
   │  PhysicalPlanner
   ▼
PhysicalPlan（ExecutionPlan 树）
   │  调度到 tokio 任务，按 partition 并行
   ▼
RecordBatch 流 ──▶ 输出给调用方

整条链路是 异步 的（基于 tokio），这意味着 IO 密集的扫描（读 S3 上的 Parquet）不会阻塞计算线程。

3.2 Frontend：SQL 与 DataFrame 双入口

DataFusion 同时接受两种查询写法：

• SQL：走 sqlparser 解析成 AST，再经 SqlToRel 转成 LogicalPlan。好处是用户友好、生态兼容。
• DataFrame API：直接构造 LogicalPlan 的链式调用。好处是类型安全、可组合、能被 Rust 编译器检查。

两者最终都汇聚到同一个 LogicalPlan，所以"SQL 党"和"代码党"享受的是同一套优化器和执行引擎。

3.3 Analyzer：把"名字"变成"类型"

Analyzer 干的是语义层的事：

• 把 SELECT name 里的 name 绑定到具体表的字段；
• 推导每个表达式的返回类型（比如 age + 1 是 Int64 还是 Float64）；
• 展开 CTE、处理 GROUP BY 的隐式字段引用。

如果这一步失败（比如引用了不存在的列），会立刻报错，而不是等到执行时才崩。

3.4 Optimizer：规则驱动的"重写游戏"

DataFusion 的优化器是一组 Rule，每条 Rule 都是一个能"看一眼计划树并可能改写它"的函数。常见的 Rule 包括：

• 常量折叠（ConstantFolding）：WHERE 1 + 1 > 2 直接算成 false，整棵子树可能被干掉。
• 谓词下推（Predicate Pushdown）：把 WHERE age > 30 尽可能往下推到 TableScan，让扫描阶段就少读数据。
• 投影下推（Projection Pushdown）：只读取查询真正用到的列，Parquet 这种列存格式可以跳过无关列，IO 直接下降一个数量级。
• 子查询非关联化（Subquery Eliminate）：把 IN (SELECT ...) 改写成 JOIN。
• 公共子表达式消除、Limit 下推、Join 重排 等。

这些 Rule 跑完一轮后，通常会再跑一轮（因为上一条 Rule 的改写可能让另一条 Rule 又能生效），直到计划树稳定。

3.5 PhysicalPlan：从"描述"到"真正能跑的算子"

逻辑计划优化完后，PhysicalPlanner 把它翻译成 ExecutionPlan。例如：

• LogicalPlan::TableScan → ParquetExec / CsvExec（具体看数据源）
• LogicalPlan::Filter → FilterExec
• LogicalPlan::Aggregate → HashAggregateExec（带哈希分组的聚合）

每个 ExecutionPlan 的关键方法是 execute(partition)：返回一个异步 Stream<RecordBatch>。DataFusion 调度器会把不同 partition 的执行分发到不同 tokio 任务，实现并行。

3.6 执行：流式（Streaming）而非物化全部

关键认知：DataFusion 不会因为一张表大就 OOM。它按 RecordBatch 流式处理，算子之间用 Rust 的 Stream 连接。上游产出一个 batch，下游立刻消费一个 batch。只有在必要的算子（如全局 HashAggregate、全局排序、Join）才需要攒一部分状态——而这些算子的内存是可以被监控和限定的。

四、代码实战：从"Hello World"到生产级扩展

下面所有示例基于当前 DataFusion 主线（Rust 侧引入方式：datafusion = "xx"；Python 侧 pip install datafusion pyarrow）。核心 API 在不同小版本间偶有微调，但 SessionContext / DataFrame / Expr 的主干用法长期稳定。

4.1 Rust 快速开始：SessionContext + SQL

use datafusion::prelude::*;

#[tokio::main]
async fn main() -> datafusion::error::Result<()> {
    // 1. 创建会话上下文（所有配置、Catalog、表的容器）
    let ctx = SessionContext::new();

    // 2. 注册一个 CSV 数据源（也可注册 Parquet / MemTable / 自定义 TableProvider）
    ctx.register_csv("trips", "trips.csv", CsvReadOptions::new())
        .await?;

    // 3. 写 SQL —— 注意是异步、返回 DataFrame
    let df = ctx
        .sql("SELECT passenger_count, COUNT(*) AS cnt \
              FROM trips WHERE fare_amount > 50 \
              GROUP BY passenger_count ORDER BY cnt DESC")
        .await?;

    // 4. 触发执行并展示（collect 才是真正落地计算）
    df.show().await?;
    Ok(())
}

要点：ctx.sql(...) 只是构建计划，df.show() / df.collect() 才真正执行。这是惰性求值的典型特征——在你调用 .collect() 之前，DataFusion 都在做"计划优化"，而不是"数据计算"。

4.2 DataFrame API 实战：类型安全地组装查询

当你想在 Rust 代码里动态拼查询（而不是拼字符串），DataFrame API 更香：

use datafusion::prelude::*;

#[tokio::main]
async fn main() -> datafusion::error::Result<()> {
    let ctx = SessionContext::new();
    ctx.register_csv("trips", "trips.csv", CsvReadOptions::new())
        .await?;

    let df = ctx
        .read_csv("trips.csv", CsvReadOptions::new())
        .await?
        // 谓词
        .filter(col("fare_amount").gt(lit(50.0)))?
        // 聚合：按 passenger_count 分组，数 trip_id
        .aggregate(
            vec![col("passenger_count")],
            vec![count(col("trip_id"))],
        )?
        // 排序
        .sort(vec![col("COUNT(trip_id)").sort(false, true)])?;

    df.show().await?;
    Ok(())
}

col(...)、lit(...)、count(...) 这些都是构造 Expr 的helper。它们最终和 SQL 走的是同一棵逻辑计划，所以优化器一视同仁。

4.3 自定义标量函数（ScalarUDF）：把你的业务逻辑塞进引擎

DataFusion 最强大的地方之一，是你能把任意 Rust 函数注册成 SQL 里可直接调用的 UDF：

use std::sync::Arc;
use datafusion::arrow::array::{ArrayRef, Float64Array};
use datafusion::arrow::datatypes::DataType;
use datafusion::error::Result;
use datafusion::logical_expr::{Volatility, create_udf};
use datafusion::physical_expr::functions::make_scalar_function;
use datafusion::prelude::*;

#[tokio::main]
async fn main() -> Result<()> {
    let ctx = SessionContext::new();

    // 用闭包表达"一批值进、一批值出"的向量化语义
    let sqrt_double = make_scalar_function(|args: &[ArrayRef]| {
        let a = args[0]
            .as_any()
            .downcast_ref::<Float64Array>()
            .expect("输入必须是 Float64");
        let mut builder = Float64Array::builder(a.len());
        for i in 0..a.len() {
            if a.is_null(i) {
                builder.append_null();
            } else {
                builder.append_value((a.value(i) * 2.0).sqrt());
            }
        }
        Ok(Arc::new(builder.finish()) as ArrayRef)
    });

    // 注册：名字、参数类型、返回类型、易变性、实现
    let udf = create_udf(
        "sqrt_double",
        vec![DataType::Float64],
        Arc::new(DataType::Float64),
        Volatility::Immutable,
        sqrt_double,
    );
    ctx.register_udf(udf);

    // 现在 SQL 里可以直接用
    let df = ctx
        .sql("SELECT sqrt_double( CAST(4 AS DOUBLE) ) AS r")
        .await?;
    df.show().await?;
    Ok(())
}

注意 make_scalar_function 的闭包签名是 &[ArrayRef] -> Result<ArrayRef>：一次处理一整批（Array），而不是一个标量。这正是向量化的关键——你的 UDF 天然就是批处理语义，DataFusion 不会逐行调用它。

除了 ScalarUDF，还有 AggregateUDF（自定义聚合，如自定义分位数）、WindowUDF（自定义窗口函数）。三件套齐了，基本上任何业务语义都能表达。

4.4 自定义数据源（TableProvider）：把任何数据接进来

假设你的数据不在 CSV/Parquet 里，而在某个 API、某个内存结构、某个自研存储里——实现 TableProvider 即可：

use std::any::Any;
use std::sync::Arc;
use async_trait::async_trait;
use datafusion::arrow::datatypes::{Schema, SchemaRef, Field, DataType};
use datafusion::catalog::TableProvider;
use datafusion::datasource::TableType;
use datafusion::execution::context::SessionState;
use datafusion::logical_expr::Expr;
use datafusion::physical_plan::ExecutionPlan;
use datafusion::error::Result;

struct MyApiSource {
    schema: SchemaRef,
}

impl MyApiSource {
    fn new() -> Self {
        let schema = Arc::new(Schema::new(vec![
            Field::new("id", DataType::Int64, false),
            Field::new("score", DataType::Float64, true),
        ]));
        Self { schema }
    }
}

#[async_trait]
impl TableProvider for MyApiSource {
    fn as_any(&self) -> &dyn Any { self }
    fn schema(&self) -> SchemaRef { self.schema.clone() }
    fn table_type(&self) -> TableType { TableType::Base }

    async fn scan(
        &self,
        _state: &SessionState,
        projection: Option<&Vec<usize>>,
        _filters: &[Expr],
        _limit: Option<usize>,
    ) -> Result<Arc<dyn ExecutionPlan>> {
        // 真实场景：在这里调用你的 API / 读取你的存储，
        // 把结果组织成一个自定义的 ExecutionPlan 返回。
        // 下面用 todo! 示意"你需要实现自己的 ExecutionPlan"。
        let _ = projection;
        todo!("返回一个实现了 ExecutionPlan 的自定义算子，产出 RecordBatch 流")
    }
}

// 注册后即可像普通表一样查询
// ctx.register_table("my_api", Arc::new(MyApiSource::new()))?;
// ctx.sql("SELECT * FROM my_api WHERE score > 0.9").await?;

真实生产里，scan 返回的 ExecutionPlan 要实现 execute(partition) -> 异步 Stream<RecordBatch>。这正是 DataFusion 能"嵌入"进各种系统的根本：存储在你那，计算交给它。

4.5 Python 实战：Rust 引擎 + Python 语法

DataFusion 的 Python 绑定让数据工程师用熟悉的语法，跑的是 Rust 的原生性能：

from datafusion import SessionContext
import pyarrow as pa

ctx = SessionContext()

# 注册 Parquet（直接读 S3 / 本地都行）
ctx.register_parquet("logs", "s3://my-bucket/logs/*.parquet")

# DataFrame 风格
df = (
    ctx.read_parquet("s3://my-bucket/logs/*.parquet")
       .filter(df_col("level") == "ERROR")
       .aggregate([df_col("service")], [f.count(df_col("id"))])
)
df.show()

# 或者直接用 SQL
res = ctx.sql("""
    SELECT service, COUNT(*) AS err_cnt
    FROM logs
    WHERE level = 'ERROR'
    GROUP BY service
    ORDER BY err_cnt DESC
""")
print(res.to_pyarrow_table())  # 零拷贝拿到 pyarrow.Table，可直接喂 pandas / polars

这里有个很多人忽略的细节：to_pyarrow_table() 拿到的是 pyarrow.Table，因为 DataFusion 的内存就是 Arrow，所以 Python 侧不需要任何序列化拷贝。你可以直接 .to_pandas() 或交给 Polars，全程零转换成本。

4.6 DataFusion Comet：给 Spark 换上一颗原生心

这是 DataFusion 在工程界最"出圈"的应用。DataFusion Comet 是 Apache 顶级项目（源自 Apple 开源），它把 DataFusion 当成 Apache Spark 的原生执行后端，让 Spark SQL 在不改一行业务代码的前提下，把计算密集算子 offload 给 Rust 向量化引擎。

它的架构是四件套：

1. Spark 插件框架：实现 DriverPlugin + ExecutorPlugin，在 Spark 启动时把 Comet 能力挂上去；
2. Protobuf 序列化：把 Spark 的逻辑计划 / 物理计划 / 表达式序列化成紧凑二进制，传给 Rust 侧；
3. DataFusion 执行引擎：真正干活的向量化内核，内存全是 Arrow；
4. Shuffle 桥接：原生算子之间用列式 Arrow 数据传递，必要时回落到 Spark 原生的行式 Shuffle。

启用方式（Spark 配置）：

spark.plugins=org.apache.comet.CometSparkSessionExtension
spark.comet.enabled=true
spark.comet.exec.enabled=true
spark.comet.cast.allowIncompatible=true        # 容忍部分类型转换差异
spark.comet.explain.verbose.enabled=true        # 打印哪些算子被 Comet 接管
spark.comet.memoryOverhead=4g                   # 给原生执行预留 off-heap 内存

启用后，Spark 的 Aggregate、Filter、Project、Join、Scan(Parquet) 等算子会被 Comet 透明替换成原生实现。对业务方完全无感——同样的 spark.sql("...")，底层已经不是 JVM 的 WholeStage Codegen，而是 Rust 的向量化执行。

五、性能优化：为什么它快，以及怎么让它更快

5.1 向量化 vs 行式解释：不是 2 倍，是数量级

行式 Volcano 执行模型里，每读一行数据，要在 Scan → Filter → Project → Agg 上百个算子间来回 next()。函数调用本身的开销、CPU 分支预测失败、缓存未命中，会把大量时间浪费在"调度"而非"计算"上。

DataFusion 的向量化模型里，每个算子一次吃一个 4096 行的 RecordBatch，内部用紧凑循环 + SIMD 处理。在 TPCH 这类分析型负载上，向量化相对行式解释通常有 数倍到十倍级 的差距——不是因为你代码写得好，而是因为"批量"把固定开销摊薄了。

5.2 谓词下推与投影下推：少读就是快

这是 DataFusion 性价比最高的两个优化，而且自动发生：

• 投影下推：SELECT name FROM users 只会让 ParquetExec 去读 name 那一列。Parquet 是列存，其他几十列根本不进内存。
• 谓词下推：WHERE ts > '2026-01-01' 会被推到扫描阶段，Parquet 还能利用行组（row group）的 min/max 统计直接跳过整块不相关的数据（谓词下推 + 谓词消除 / 行组裁剪）。

实战建议：永远只 SELECT 你需要的列，并尽量把过滤条件写成"能被下推"的简单表达式（避免包在不可下推的 UDF 里）。

5.3 并行度：target_partitions

DataFusion 用 target_partitions 控制并行度，等价于"把输入数据切成多少片并行算"：

let mut config = SessionConfig::new();
config.options_mut().execution.target_partitions = 8; // 8 路并行
let ctx = SessionContext::new_with_config(config);

经验法则：target_partitions 设成 CPU 逻辑核心数附近。太小则浪费多核，太大会因调度和碎片反而变慢，且哈希聚合的 partition 数越多，每个 partition 的状态越小但哈希开销上升。一般从"核心数"起步，用真实负载压测微调。

5.4 与 DuckDB / Polars / Spark 的选型对比

一句话总结：DuckDB 是"买一台整机"，DataFusion 是"买发动机自己造"。你是想立刻用，还是想造自己的车，决定你的选择。

5.5 Comet 的真实收益从哪来

Comet 加速 Spark 的本质，是把 JVM 上"为通用性妥协"的执行，换成 Rust 上为"分析型批处理"特化的执行：

• 无 GC 停顿：JVM 的 WholeStage Codegen 虽快，但对象分配仍受 GC 牵制；Rust 无 GC，延迟更稳定。
• Arrow 列式贯穿：Spark 原生 Shuffle 是行式、要序列化；Comet 在原生算子间尽量保持列式 Arrow，减少转换。
• 向量化算子：同样的逻辑（如 COUNT、SUM、字符串过滤）用 SIMD 批量算。

注意：Comet 不是银弹。它最擅长的是计算密集、可向量化的算子；遇到无法原生化的表达式（复杂 UDF、特定 Hive 兼容行为）会回落到 Spark 原生执行（fallback）。所以生产落地要开 comet.explain.verbose 观察回落比例，针对性优化。

六、总结与展望：DataFusion 不是终点，是底座

6.1 它已经无处不在

到 2026 年，DataFusion 已经不是"一个小众 Rust 项目"，而是数据基础设施的公共底座：

• InfluxDB 3.0 的查询层基于 DataFusion；
• Apache Comet 用它在加速 Spark；
• Ballista 在它之上做分布式执行；
• 无数 Lakehouse / 湖仓查询层、可观测性引擎、AI Agent 记忆系统，把它当成"算"的内核。

你也许从没 cargo add datafusion，但你的数据很可能已经经过了它的手。

6.2 2026 年的几个趋势

1. DataFusion 吞噬更多"执行层"：随着更多系统选择"存储与计算分离 + 嵌入引擎"，DataFusion 这种"纯计算库"会被更广泛复用。
2. 与 Lakehouse 格式深度整合：Iceberg / Delta / Hudi 的元数据与 DataFusion 的扫描下推进一步打通，让"直接 SQL 打在对象存储上"成为默认体验。
3. AI Agent 记忆层：RAG 的向量检索 + 结构化过滤，越来越倾向于用一个嵌入式引擎同时做"向量 + SQL"，DataFusion 的可嵌入性在这里很吃香。
4. Comet 把 Spark 拉进原生时代：零代码改造的向量化加速，会成为 Spark 集群的标配插件。

6.3 你应该什么时候选 DataFusion

• ✅ 你在写一个自己的数据处理系统 / 查询层 / 管道，需要可嵌入、可扩展的执行引擎。
• ✅ 你受够了"为了查点数据要起一个数据库服务"，想把它编译进你的二进制。
• ✅ 你已有 Spark，想零改动提速 → 上 Comet。
• ❌ 你只是想"本地跑个分析 SQL" → DuckDB 更省心。
• ❌ 你只想要顺手的 DataFrame API 做数据科学 → Polars 更对味。

6.4 写在最后

DataFusion 的价值，不在于它比谁"快一点"，而在于它重新定义了**"查询引擎"该以什么形态存在**——不再是一个你部署的服务，而是一个你编译进产品的零件。当 Rust 的工程性、Arrow 的内存模型、向量化的执行范式三者叠加，我们得到的不是一个更快的数据库，而是一个能让所有数据系统都更快的"发动机"。

对于程序员来说，理解 DataFusion，本质上是在理解 2026 年数据基础设施的"底层物理定律"：列式、零拷贝、向量化、可嵌入。掌握这几条，无论上面跑的是 Spark、Lakehouse 还是你自己的 Agent，你都能看穿它的性能本质。

参考与延伸阅读

• Apache DataFusion 官方文档：https://datafusion.apache.org/
• GitHub：apache/datafusion、apache/datafusion-comet
• Apache Arrow 规范与内存格式
• InfluxDB 3.0 架构博客（基于 DataFusion 的查询层）
• DataFusion Comet 性能基准（TPC-H / TPC-DS 对比 Spark 原生）

本文基于 2026 年 7 月公开的 DataFusion 主线能力与社区实践撰写，API 细节请以你所使用的版本为准。