Velox：把执行引擎拆成可拼装的 C++ 库，而非又一个数据库

它解决的是引擎重复造轮子的问题

数据管理系统有很多种，批处理、交互式查询、流处理、AI/ML，各有各的优化目标。但底层那套东西，列式内存布局、表达式求值、哈希连接、聚合、排序、序列化，几乎每个引擎都要重写一遍。Velox 的定位就是把这一层抽出来，做成一个可复用的 C++ 库。它不提供 SQL 解析器，没有 dataframe 层，也没有查询优化器。它接受一个已经优化好的查询计划，然后执行。这意味着它的用户不是终端数据分析师，而是那些正在构建或改造计算引擎的开发者。Meta 创建了它，现在与 IBM/Ahana、Intel、Voltron Data、Microsoft、ByteDance 等公司一起开发。

从 Type 到 Resource Management，组件边界怎么划

Velox 把执行引擎拆成七个高层组件。Type 是类型系统，支持标量、复杂和嵌套类型，包括 struct、map、array。Vector 是列式内存布局模块，兼容 Arrow，提供 Flat、Dictionary、Constant、Sequence/RLE 编码，还支持惰性物化和乱序写入。Expression Eval 是向量化表达式求值引擎，跑在 Vector 之上。Functions 实现了标量、聚合、窗口函数，语义跟随 Presto 和 Spark。Operators 覆盖扫描、写入、投影、过滤、分组、排序、shuffle、连接（hash、merge、nested loop）、unnest 等关系算子。I/O 是连接器接口，支持 ORC/DWRF、Parquet、Nimble 格式，以及 S3、HDFS、GCS、ABFS 和本地文件。Network Serializers 定义线上协议接口，支持 PrestoPage 和 Spark 的 UnsafeRow。Resource Management 处理内存 arena、buffer 管理、task、driver、线程池、spilling 和缓存。每个组件都可以单独替换或扩展。

扩展点在哪里，能自定义什么

Velox 的扩展性不是口头承诺，而是有明确的接口位置。你可以自定义类型，写简单函数或向量化函数，也可以实现聚合函数、窗口函数、算子、文件格式、存储适配器、网络序列化器。这意味着如果你要接入一种新的文件格式，不需要改 Velox 核心，只需要实现对应的 connector 接口。同样，如果你要支持一种新的线上协议，只需要写一个 Network Serializer。这种设计把引擎的固定部分和可变部分分开，固定部分是执行框架，可变部分是你的业务逻辑。但这也意味着，扩展不是写几个配置文件就完事，每一种扩展都需要你理解 Velox 的内部 API 和数据结构。

构建与依赖，门槛比想象中高

Velox 的构建不是简单的 cmake && make。它提供了平台相关的脚本来安装依赖，用 DEPENDENCY_DIR 环境变量控制下载和构建位置，默认是当前目录下的 deps-download。INSTALL_PREFIX 控制安装目录，Linux 上默认是 /usr/local，macOS 上默认是 deps-install，但文档明确建议 macOS 不要用 /usr/local，因为会和 Homebrew 冲突。编译器的要求不低：Linux 最低 gcc 11 或 clang 15，macOS 最低 clang 15。推荐组合是 Ubuntu 22.04 配 gcc 11，或 macOS 配 clang 16。依赖构建的并行度可以用 BUILD_THREADS 控制。文档还提到，如果你同时使用 Prestissimo 这样的客户端，可以共享 DEPENDENCY_INSTALL 和 INSTALL_PREFIX 目录。这个流程意味着，第一次构建可能耗费大量时间，而且对网络和磁盘空间有要求。如果你在一个受限的 CI 环境里，这可能是最大的障碍。

一个真实的限制：它不帮你做决策

Velox 的输入是一个完全优化的查询计划。它自己不做优化，也不解析 SQL。这意味着你的系统必须已经有一个优化器，能生成 Velox 能理解的计划。如果你的项目还在早期，连 SQL parser 都没有，Velox 帮不上忙。它假设你已经解决了查询编译和优化的问题，它只负责执行。另一个限制是，它的函数语义跟随 Presto 和 Spark，如果你需要的是其他语义，比如 PostgreSQL 的窗口函数行为，你得自己实现或者接受差异。还有，它面向分析型负载，批处理、交互式、流处理、AI/ML 都算，但没有提到事务处理或点查场景。如果你的引擎需要行级更新和并发控制，Velox 的列式 Vector 设计可能不是最优选择。

替代方案：自己写，还是用完整的引擎

如果你不想用 Velox，大致有两条路。一条是直接用完整的查询引擎，比如 Presto 或 Spark。它们自带 SQL parser、优化器、执行引擎，你只需要写 connector。但代价是你被绑在一个固定的执行框架里，很难替换底层的向量化或算子实现。另一条是自己写执行引擎，从零实现列式布局、表达式求值、算子。这条路灵活，但工程量巨大，而且容易在性能调优上反复折腾。Velox 处在中间位置，它给你执行引擎的骨架和默认实现，但把解析和优化留给你。这个取舍很明确：你获得的是经过大量工程投入的列式执行代码，失去的是对执行细节的完全控制。如果你只需要向量化表达式求值，单独抽出这个模块可能比引入整个 Velox 更轻。

维护成本与许可证

Velox 采用 Apache-2.0 许可证，可以自由使用、修改和分发，只要保留版权声明。维护成本主要体现在几个方面。依赖管理是脚本化的，这意味着升级 Velox 版本时，你需要重新跑依赖安装流程，而且依赖版本由 Velox 的脚本控制，你无法轻易锁定。编译器要求会跟着版本走，文档列出的最低版本是 gcc 11 和 clang 15，如果你的工具链更老，可能无法构建。社区治理有明确的文档，维护者列表也公开，主沟通渠道是 Slack 和 GitHub Issues。项目没有发布正式 release，默认分支是 main，这意味着你跟踪的是一个持续变动的代码库，可能需要频繁适应 API 变化。如果你要长期使用，建议锁定一个 commit 或 fork，而不是直接跟踪 main。

编辑结论

Velox 适合正在自研数据引擎、且愿意投入 C++ 工程能力的团队，尤其是需要列式矢量执行、Presto/Spark 语义兼容或跨格式 I/O 的场合。不适合只想给现有系统加一个 SQL 层、或期望开箱即用的团队，因为它没有解析器、优化器，也没有终端用户接口。采用前先验证三件事：你的编译器是否满足最低版本（Linux 上 gcc 11 或 clang 15，macOS 上 clang 15），你的依赖管理能否接受 Velox 的脚本化下载构建流程，以及你的引擎是否真的需要复用它的算子与函数集，而非只想要一个向量化表达式的求值器。若只需表达式求值，单独抽出该模块比引入整个 Velox 更轻。最终判断：Velox 是一个工程能力要求高的库，不是产品，你的团队必须能独立消化其构建与调试成本。

官方来源

1. Official documentation
2. Official README
3. Project repository