在分析型数据库领域，存储格式与执行引擎的协同设计往往是性能差异的关键所在。DuckDB 作为嵌入式分析数据库的代表，其向量化执行引擎一直是性能优化的核心。而 Vortex 作为新兴的列式文件格式，通过计算下推与延迟物化等设计理念，为这一引擎注入了新的加速潜力。本文将从工程实践角度，剖析两者的协同机制与性能表现。
列式存储格式的演进与瓶颈
Apache Parquet 长期占据列式存储的事实标准地位，其块级压缩、按列存储、分页编码等特性极大提升了分析查询的 IO 效率。然而，随着查询模式的多样化与硬件架构的演进，Parquet 的设计约束逐渐显现。最突出的瓶颈在于其块压缩模式：引擎必须在解压完整数据页之后才能执行过滤、聚合等操作，这意味着大量中间数据仍需在内存中完整物化。对于需要频繁执行谓词下推的短查询场景，这一特性导致了显著的 CPU 与内存资源浪费。
Vortex 的出现正是为了解决这一痛点。作为 SpiralDB 团队于 2025 年 8 月捐赠给 Linux Foundation 的开源列式格式，Vortex 采用可扩展的架构设计，将物理存储与逻辑模式完全解耦。其核心创新在于支持轻量级编码（如 ALP 浮点编码、FSST 字符串编码）的同时，允许引擎在压缩数据上直接执行任意表达式。这一特性被称为「计算函数」（Compute Functions），它使得过滤、下推等操作可以在不解压的情况下完成，大幅减少了数据移动与转换开销。
向量化引擎的内部工作机制
理解 Vortex 与 DuckDB 的协同，首先需要把握 DuckDB 向量化执行引擎的核心设计。DuckDB 采用批量处理模型，所有算子均以向量为单位进行优化。这一固定批次大小在代码中定义为 STANDARD_VECTOR_SIZE，默认值为 2048 个元组。这意味着每次算子调用处理的不是单行数据，而是一个包含 2048 行的向量块。
在向量内部，DuckDB 支持多种物理表示格式以适应不同数据特征。扁平向量（Flat Vector）是最基础的格式，逻辑数据与物理存储完全一致，适用于随机访问场景。常量向量（Constant Vector）则仅存储单一常量值，用于消除字面量重复，特别在投影操作中可显著降低内存占用。字典向量（Dictionary Vector）通过选择向量间接引用子向量，是字典压缩解码后的自然表示形式。序列向量（Sequence Vector）则以增量形式存储序列数据，专为行号等连续值优化。
这些向量格式的统一视图通过 UnifiedVectorFormat 实现，使得算子实现无需针对每种组合编写专门代码。当 Vortex 读取器从文件解码数据时，会根据编码类型选择相应的向量格式：字典压缩的列直接输出字典向量，ALP 编码的浮点列则维持压缩状态等待后续计算。这一设计确保了压缩信息在全链路中得以保留，避免了传统格式中「解码 — 计算 — 再编码」的冗余循环。
Vortex 与 DuckDB 的集成工程实践
Vortex 扩展的集成方式体现了 DuckDB 扩展系统的成熟度。安装过程仅需两条 SQL 命令：首先通过 INSTALL vortex 获取扩展包，随后 LOAD vortex 完成加载，此后即可像使用 Parquet 一样直接读取 Vortex 文件。读写接口保持了与现有格式的一致性：SELECT * FROM read_vortex('my.vortex') 完成读取，COPY ... TO 'my.vortex' (FORMAT vortex) 执行写入。
在工程部署中，有几个关键参数值得关注。首先是批次大小与向量尺寸的匹配：DuckDB 的 2048 批次与 Vortex 的存储段设计存在自然对齐，理论上可最大化 SIMD 指令的利用率。其次是压缩编码的选择：对于数值型数据，ALP 编码在保持可接受压缩率的同时，提供了极高的解码速度；对于字符串类型，FSST 编码在压缩率与解压开销之间取得了良好平衡。第三是延迟物化策略的启用时机：当查询涉及多列投影且过滤条件可下推时，Vortex 的优势最为明显；而对于覆盖查询（Covering Query），传统格式的线性扫描往往更为高效。
TPC-H 规模因子 100 的基准测试提供了量化的性能参考。测试环境为 Mac M1（10 核、32GB 内存），每个查询执行 5 次取平均值，且每次执行后关闭连接以避免缓存干扰。结果显示：Vortex 的几何平均执行时间为 1.51 秒，相比 Parquet v2 的 1.84 秒提升约 18%，相比 Parquet v1 的 2.32 秒提升约 35%。更具意义的是标准差指标：Vortex 在所有运行中的标准差仅为 0.079 秒，而 Parquet v2 达到 0.183 秒，表明 Vortex 的性能表现更为稳定，冷启动与热缓存场景下的差异更小。
适用场景与迁移决策框架
基于上述技术特性与基准数据，可以建立清晰的场景决策模型。Vortex 的核心优势在于高随机访问效率与计算下推能力，因此以下场景应优先考虑：交互式即席查询中的快速过滤与切片操作；机器学习特征工程管线的低延迟数据读取；统一数据湖中多模态数据（数值、文本、向量）的混合存储；以及对冷启动性能有严格要求的无服务器分析工作负载。
然而，Vortex 并非在所有场景下都是最优选择。当数据以顺序扫描为主、对压缩率有极高要求、或者需要与现有 Parquet 生态系统深度集成时，Parquet 仍具竞争力。特别值得注意的是，Vortex 文件体积在 TPC-H 测试中为 28.57GB，同等 Parquet v2 文件为 25.40GB—— 虽然差异主要源于 Vortex 选择了轻量级编码而非通用压缩算法，但若存储成本是主要约束，这一因素需要纳入考量。
对于已有 Parquet 数据资产的团队，渐进式迁移是稳妥策略：可在新数据集上试用 Vortex，积累性能与稳定性经验后再逐步扩展；利用 DuckDB 的多格式支持能力，在同一查询中混用两种格式评估差异；建立基于真实工作负载的基准测试，而非仅依赖公开 benchmark。
Vortex 与 DuckDB 的协同代表了列式存储与向量化执行深度融合的趋势。延迟物化与计算下推的设计理念，不仅降低了数据传输开销，更释放了 SIMD 指令集的并行处理潜力。随着格式规范的持续演进与生态系统的逐步成熟，这一组合有望成为分析型工作负载的新范式。
参考资料
- DuckDB 官方公告：《Announcing Vortex Support in DuckDB》：https://duckdb.org/2026/01/23/duckdb-vortex-extension.html
- DuckDB 执行格式文档：《Execution Format》：https://duckdb.org/docs/stable/internals/vector.html