从零构建 DuckDB 嵌入式分析引擎：列存向量化执行与 SIMD 优化实战

引言：嵌入式分析数据库的崛起

在数据分析领域，我们长期面临一个两难选择：要么使用轻量级的 SQLite 但牺牲分析性能，要么部署重型 OLAP 系统（ClickHouse、Doris）带来运维负担。DuckDB 的出现打破了这一格局——它将完整的分析数据库引擎嵌入到应用中，无需外部依赖，却能提供媲美专用 OLAP 系统的查询性能。

DuckDB 的核心定位是"进程内 OLAP 数据库"，与 SQLite 的"进程内 OLTP"形成互补。它被设计为嵌入到 Python、R、Node.js、Rust 等宿主语言中运行，通过共享内存直接与宿主程序交互，零网络开销、零序列化成本。2024 年以来，DuckDB 已成为数据分析生态中增长最快的引擎之一，被广泛用于本地数据科学、边缘计算、浏览器内分析（WASM 版本）等场景。

本文将深入拆解 DuckDB 的内部架构：从列式存储格式、向量化执行模型、SIMD 优化，到查询编译与并行执行，并通过 Rust 实战展示如何构建一个基于 DuckDB 的本地分析管道。

一、列式存储与压缩引擎

1.1 列存格式设计

OLAP 查询的典型模式是：只读取表中少数几列，但在这些列上进行全量聚合扫描。行式存储在这种情况下会读取大量无关数据，而列式存储天然匹配这一访问模式。

DuckDB 的列存格式以 Row Group 为基本存储单元（默认约 122,880 行），每个 Row Group 内部按列组织数据：

Row Group (122,880 行)
├── Column A: [压缩数据段1, 压缩数据段2, ...]
├── Column B: [压缩数据段1, 压缩数据段2, ...]
├── Column C: [压缩数据段1, 压缩数据段2, ...]
└── ...

每个列数据段（Segment）独立压缩，支持多种编码方式：

• Constant Encoding：单列仅一个值时直接存储为常量
• Dictionary Encoding：低基数列使用字典压缩，将字符串映射为整数ID
• RLE (Run-Length Encoding)：连续重复值压缩为 (值, 计数) 对
• Bit-Packing：小整数按位打包，减少空间占用
• Delta Encoding：递增序列存储差值
• FOR (Frame of Reference)：以最小值为基准存储偏移量

1.2 自适应压缩选择

DuckDB 的压缩选择器在写入时采样数据，动态选择最优压缩算法。例如，对于字符串列，它会检测基数比：当唯一值比例低于 10% 时启用 Dictionary Encoding；对于整数列，会根据数值范围选择 Bit-Packing 或 Delta+RLE 组合。

// 模拟 DuckDB 的压缩选择逻辑
fn select_compression<T: ArrowNativeType>(column: &[T]) -> Compression {
    let unique_ratio = count_unique(column) as f64 / column.len() as f64;

    if unique_ratio < 0.1 {
        Compression::Dictionary
    } else if is_monotonically_increasing(column) {
        Compression::DeltaRLE
    } else {
        Compression::BitPack(bit_width(column))
    }
}

1.3 内存中的列向量（Data Chunk）

查询执行过程中，数据以 Data Chunk 为单位在算子间流转。每个 Data Chunk 是一个列向量的集合，默认大小为 2048 行。DuckDB 使用列优先（Column-major）的内存布局，使得 SIMD 指令可以高效地在连续内存上操作：

Data Chunk (2048 行 × N 列)
列0: [v0, v1, v2, ..., v2047]  // 连续内存，适合 AVX-512 操作
列1: [v0, v1, v2, ..., v2047]

二、向量化执行引擎

2.1 Volcano 模型的代价

传统数据库使用 Volcano 迭代器模型：每个算子暴露 next() 接口，逐行向上层返回数据。这种"拉取"模式在 OLAP 场景下的问题是：当扫描数十亿行时，next() 的调用开销会被急剧放大——每次调用只处理一行数据，函数调用开销、虚函数分发、分支预测失败等因素叠加，CPU 利用率极低。

2.2 DuckDB 的向量化执行

DuckDB 采用 向量化执行（Vectorized Execution） 模型，核心思想是：每次算子以 Data Chunk（一批数据）为单位进行处理，而非逐行处理。这带来了多重收益：

1. 减少函数调用次数：处理 100 万行数据，Volcano 模型调用 100 万次 next()；向量化模型只需要约 488 次（100万/2048）
2. 提升缓存局部性：连续内存访问模式让 CPU 预取器充分发挥作用
3. SIMD 友好：连续的同质数据可以直接交给 SIMD 指令批量处理

DuckDB 的执行引擎有两种模式：

• Pull-based（拉取）：顶层算子通过 GetData() 从底层获取 Data Chunk
• Push-based（推送）：底层算子将 Data Chunk 推送给上层算子

实际执行中，DuckDB 会根据算子组合自适应选择最优模式。例如，Pipeline 中连续的 Filter + Project 算子会被合并为一个 Push-based 阶段，减少中间物化。

2.3 算子内联与代码生成

对于简单的表达式运算，DuckDB 在编译时直接将表达式内联到算子代码中，避免解释执行开销。例如，一个 SELECT a * 2 + b FROM t WHERE c > 100 查询，DuckDB 生成的伪代码类似：

for (size_t i = 0; i < chunk_size; i++) {
    if (c_data[i] > 100) {
        result_data[i] = a_data[i] * 2 + b_data[i];
        // 将结果写入输出 chunk
    }
}

这种 "一次编译，批量执行" 的模式消除了表达式树的遍历开销。

三、SIMD 优化实战

3.1 比较操作的 SIMD 优化

OLAP 查询中最常见的操作是 Filter（WHERE 子句）。以 WHERE age > 30为例，我们需要将列中每个值与 30 比较，并生成一个选择向量（Selection Vector），仅保留满足条件的行。

使用 AVX2 指令集，可以一次处理 32 位整数中的 8 个值：

use std::arch::x86_64::*;

unsafe fn filter_gt_i32_avx2(
    data: *const i32,
    len: usize,
    threshold: i32,
    output_sel: &mut Vec<u32>,
) {
    let threshold_vec = _mm256_set1_epi32(threshold);
    let mut i = 0;

    // 每次处理 8 个 i32
    while i + 8 <= len {
        let vals = _mm256_loadu_si256(data.add(i) as *const __m256i);
        let mask = _mm256_cmpgt_epi32(vals, threshold_vec);
        let mask_bits = _mm256_movemask_ps(_mm256_castsi256_ps(mask));

        // 根据 mask_bits 中的位设置选择对应的行索引
        for bit in 0..8 {
            if mask_bits & (1 << bit) != 0 {
                output_sel.push((i + bit) as u32);
            }
        }
        i += 8;
    }
    // 处理尾部
    for j in i..len {
        if *data.add(j) > threshold {
            output_sel.push(j as u32);
        }
    }
}

DuckDB 内部使用 memcmp + 位运算的批量比较来进一步优化，并针对不同数据类型（i32、i64、float、double、字符串）提供特化的 SIMD 实现。

3.2 聚合操作的 SIMD 优化

SUM 聚合是 OLAP 的核心操作。朴素实现是逐行累加，但 SIMD 可以一次对多行求和：

unsafe fn sum_i32_avx2(data: *const i32, len: usize) -> i64 {
    let mut sum_vec = _mm256_setzero_si256();
    let mut i = 0;

    // 累加为 i64 以避免溢出，分高低两部分
    let mut sum_lo = _mm256_setzero_si256();
    let mut sum_hi = _mm256_setzero_si256();

    while i + 8 <= len {
        let vals = _mm256_loadu_si256(data.add(i) as *const __m256i);
        // 将 i32 扩展为 i64 后累加（简化示意）
        let lo = _mm256_cvtepi32_epi64(_mm256_castsi256_si128(vals));
        sum_lo = _mm256_add_epi64(sum_lo, lo);
        i += 4;
    }

    // 水平归约
    let mut result: [i64; 4] = [0; 4];
    _mm256_storeu_si256(result.as_mut_ptr() as *mut __m256i, sum_lo);
    result.iter().sum::<i64>() 
        + data[i..].iter().map(|&x| x as i64).sum::<i64>()
}

DuckDB 的 SUM 实现更为精细，它会使用两阶段累加减少精度损失，并针对 NULL 值进行特殊处理。

3.3 字符串操作的 SIMD 优化

字符串比较和哈希是字符串列筛选/连接的瓶颈。DuckDB 对短字符串（≤12 字节）使用 前缀压缩：直接将字符串内联到存储中，用整数比较替代 memcmp。

对于长字符串，DuckDB 只存储前 3 个字符的前缀 + 字符串哈希值（128 位萼块哈希）。比较时先比较前缀和哈希，仅在匹配时才读取完整字符串。这种"布隆过滤器式"的预筛选能大幅减少实际的字符串比较次数。

四、查询优化与并行执行

4.1 基于代价的优化器

DuckDB 内置了一个基于代价的查询优化器（CBO），支持：

• 谓词下推（Predicate Pushdown）：将 WHERE 条件下推到尽可能靠近数据源的位置，减少读取数据量
• 列裁剪（Column Pruning）：只读取查询中实际引用的列
• Join 重排序：基于基数估计调整 Join 顺序，让小表先做
• 统计信息收集：维护每列的 min/max、null 比例、近似唯一值数（HyperLogLog）

-- 谓词下推示例：DuckDB 会推导出 o.total > 100 在扫描 orders 表时就能应用
SELECT c.name, SUM(o.total)
FROM customers c
JOIN orders o ON c.id = o.customer_id
WHERE o.total > 100 AND c.region = 'APAC'
GROUP BY c.name;

4.2 并行执行架构

DuckDB 实现了基于 Pipeline 的并行执行引擎。每个查询被分解为多个 Pipeline，Pipeline 之间通过 Exchange 算子（Shuffle）连接：

Pipeline 1 (扫描阶段):
  TableScan(orders) → Filter(total > 100) → HashJoin(customers)

Pipeline 2 (聚合阶段):
  Exchange(Shuffle by name) → HashGroupby(name) → FinalAgg

每个 Pipeline 内部可以多线程并行执行。DuckDB 的并行策略包括：

1. 数据并行：多个线程同时扫描不同的 Row Group
2. 任务并行：不同 Pipeline 可以流水线化执行
3. 向量化并行：单个线程内使用 SIMD 进一步加速

并行度由 SET threads=N 控制，DuckDB 默认使用机器的 CPU 核心数。

4.3 Hash Join 优化

Join 是 OLAP 查询中最重的算子之一。DuckDB 使用 Radix Hash Join：

1. 先扫描 Build 侧数据，对 Join Key 进行散列分区（Radix Partitioning），按散列值的高位将数据分到多个分区
2. 每个分区内的数据再构建 Hash Table
3. 然后 Probe 侧同样散列分区后，逐个分区执行 Hash Probe

这种分区策略的优势是：每个分区的 Hash Table 可以完全放入 L2 /L3 缓存中，避免了传统 Hash Join 因 Hash Table 过大导致的 TLB 抖动和缓存未命中。

五、事务与 MVCC

5.1 多版本并发控制

DuckDB 支持基于 MVCC 的事务隔离。每个事务开始时获取一个事务 ID，每个元组（Row）标记了创建它的 txn_id 和删除它的 delete_txn_id。

读操作执行 快照隔离：事务只能看到在该事务开始前已提交的版本。这意味着读操作不会阻塞写操作，写操作也不会阻塞读操作——这是分析场景的核心需求。

5.2 增量存储与合并

DuckDB 将新写入的数据存储在增量文件（Undo Log / Delta Store）中，读取时需要合并主存储与增量存储。随着时间的推移，增量存储会变大，DuckDB 会定期触发 Checkpoint 将增量合并回主存储。

这种设计与 LSM-Tree 有相似之处，但更轻量——DuckDB 不像 RocksDB 那样维护分层结构，而是直接在写入路径上记录 Undo/Redo 日志。

六、扩展生态与 WASM 部署

6.1 Extensions 架构

DuckDB 的核心引擎精简，通过 Extension 机制支持更多功能：

• parquet：读写 Parquet 文件
• httpfs：直接查询 HTTP/S3 上的数据
• json：JSON 解析与生成
• full_text_search：全文检索
• python：在 DuckDB 中执行 Python 函数（UDF）
• jemalloc：使用 jemalloc 替换默认内存分配器

Extensions 是动态加载的共享库（.so/.dll/.dylib），可以在运行时按需加载，避免了编译时绑定导致二进制膨胀。

6.2 DuckDB-WASM：浏览器内分析

DuckDB 提供了 WebAssembly 编译版本，让浏览器成为数据分析的最前端：

import duckdb from '@duckdb/duckdb-wasm';

async function analyze() {
    const db = new duckdb.AsyncDuckDB(logger, worker);
    await db.instantiate();

    // 直接在浏览器中查询 Parquet 文件
    const conn = await db.connect();
    const result = await conn.query(`
        SELECT category, SUM(amount) as total
        FROM auto_read_parquet('https://example/sales.parquet')
        GROUP BY category
        ORDER BY total DESC
    `);

    return result;
}

DuckDB-WASM 使用了异步 I/O 和流式结果集，避免了大查询阻塞主线程。它甚至可以与 Pyodide（浏览器内的 Python）配合使用，在浏览器中完成完整的数据分析流水线。

七、Rust 实战：构建本地分析管道

7.1 使用 duckdb-rs 库

DuckDB 提供了官方 Rust 绑定 duckdb-rs，通过 FFI 调用 DuckDB C API：

# Cargo.toml
[dependencies]
duckdb = { version = "1.0", features = ["bundled"] }
arrow = "52"
polars = "0.41"

use duckdb::{Connection, Result, params};

fn main() -> Result<()> {
    let conn = Connection::open_in_memory()?;

    // 创建测试数据
    conn.execute(
        "CREATE TABLE orders (
            id INTEGER,
            customer VARCHAR,
            amount DOUBLE,
            ts TIMESTAMP
        )", [])?;

    conn.execute(
        "INSERT INTO orders VALUES 
        (1, 'Alice', 150.0, '2024-01-01 10:00:00'),
        (2, 'Bob', 200.0, '2024-01-02 11:00:00'),
        (3, 'Alice', 300.0, '2024-01-01 14:00:00')", [])?;

    // 复杂分析查询
    let mut stmt = conn.prepare(
        "SELECT 
            customer,
            COUNT(*) as cnt,
            SUM(amount) as total,
            AVG(amount) as avg_amount,
            MAX(amount) - MAX(amount) as spread
        FROM orders 
        GROUP BY customer
        HAVING SUM(amount) > 200
        ORDER BY total DESC"
    )?;

    let rows = stmt.query_map([], |row| {
        Ok((
            row.get::<_, String>(0)?,
            row.get::<_, i64>(1)?,
            row.get::<_, f64>(2)?,
            row.get::<_, f64>(3)?,
        ))
    })?;

    for row in rows {
        let (customer, cnt, total, avg) = row?;
        println!("{}: orders={}, total={:.2}, avg={:.2}", 
            customer, cnt, total, avg);
    }

    Ok(())
}

7.2 零拷贝读取 Parquet

DuckDB 读取 Parquet 文件时可以直接映射内存或通过流式读取，并与 Arrow 格式零拷贝互转：

use duckdb::Connection;
use arrow::array::{StringArray, Float64Array};

fn analyze_parquet(path: &str) -> Result<()> {
    let conn = Connection::open_in_memory()?;

    // 直接查询 Parquet，无需加载到内存
    let mut stmt = conn.prepare(&format!(
        "SELECT category, SUM(amount) as total 
         FROM read_parquet('{}')
         GROUP BY category", path
    ))?;

    // 获取 Arrow RecordBatch 实现零拷贝
    let rbs = stmt.query_arrow([])?;
    for rb in rbs {
        let categories = rb.column(0)
            .as_any()
            .downcast_ref::<StringArray>()
            .unwrap();
        let totals = rb.column(1)
            .as_any()
            .downcast_ref::<Float64Array>()
            .unwrap();

        for i in 0..rb.num_rows() {
            println!("{}: {:.2}", categories.value(i), totals.value(i));
        }
    }
    Ok(())
}

7.3 自定义标量函数（UDF）

DuckDB Rust API 支持注册自定义标量函数：

use duckdb::{Connection, Result, ScalarFunction, FunctionFlags};

// 自定义函数：计算 Z-Score
fn register_zscore(conn: &Connection) -> Result<()> {
    conn.register_scalar_function(
        "zscore",
        3,
        FunctionFlags::new().with_deterministic(true),
        |args| {
            let value = args.value::<f64>(0)?;
            let mean = args.value::<f64>(1)?;
            let std = args.value::<f64>(2)?;
            if std == 0.0 { Ok(0.0) } else { Ok((value - mean) / std) }
        },
    )?;
    Ok(())
}

// 使用自定义函数
fn main() -> Result<()> {
    let conn = Connection::open_in_memory()?;
    register_zscore(&conn)?;

    conn.execute(
        "SELECT x, zscore(x, 50, 15) as z 
         FROM generate_series(1, 100) t(x)
         WHERE zscore(x, 50, 15) > 2.0",
        [],
    )?;
    Ok(())
}

八、性能基准与选型建议

与 ClickHouse 的典型对比

在单机 OLAP 场景（1亿行订单表，聚合查询）：

操作	DuckDB	ClickHouse
全表 SUM	0.15s	0.08s
带 WHERE 的大型聚合	0.4s	0.5s
多表 Join（星型模型）	2.1s	1.8s
高基数 GROUP BY	1.2s	0.9s

可以看到 DuckDB 与 clickhouse 在单机场景下性能差距在 2 倍以内，但对于嵌入式场景，DuckDB 的零部署、零运维优势往往比这微小的性能差距更重要。

适用场景总结

选择 DuckDB 的场景： - 嵌入式分析（嵌入到应用程序中） - 数据科学家在本地处理 GB 级数据 - 边缘计算/轻量级 ETL 流水线 - 浏览器内数据分析（WASM） - 替代 Python pandas 处理内存放不下的数据

选择 ClickHouse/Doris 的场景： - TB 级以上的分布式分析 - 高并发实时查询（数百并发） - 需要跨节点横向扩展 - 有专业运维团队支持

九、未来展望

DuckDB 的发展方向正在从"单机嵌入式分析引擎"向"云原生分析底座"演进：

1. 云存储集成：原生支持 S3、GCS 的谓词下推，只下载需要的 Row Group
2. 增量物化视图：支持流式数据的增量更新，实现真正的实时分析
3. GPU 加速：探索将聚合算子卸载到 GPU 执行
4. LangChain/Pydantic AI 集成：将 DuckDB 作为 AI Agent 的工具调用数据库，让 LLM 直接查询结构化数据

DuckDB 团队提出的愿景是"SQLite for Analytics"——让每个人都能在进程内享有世界级的数据分析能力，无需运维基础设施。这一愿景正在逐步成为现实。

总结

DuckDB 通过列式存储、向量化执行、SIMD 优化、并行 Pipeline 等技术，在嵌入式场景下提供了卓越的 OLAP 性能。它的架构设计告诉我们：高性能不一定依赖分布式系统——通过优化单机 CPU 利用率（缓存局部性、SIMD、并行化），一个进程内的数据库引擎也能处理数十亿行数据。

对于开发者而言，DuckDB 代表的是一种"极简运维"的数据处理哲学：将复杂性留在引擎内部，把简洁的 API 交给用户。在 AI Agent 日益普及的今天，这种"零依赖、即插即用"的特性将使 DuckDB 成为智能应用数据处理的重要基础设施。