企业官网建设流程全解析

• 大数据
• 数据分析
• 后端

Apache DataFusion 是使用 Rust 编写、以 Apache Arrow 为内存格式的可扩展查询引擎。无论是作为 Rust 库嵌入自有项目，还是下载官方源码发布包进行审计与部署，都需要先正确理解其分发渠道与校验流程。本篇指南以 docs/source/download.md 为核心骨架，结合仓库源码与发布脚本，系统讲解 DataFusion 的两种获取方式（crates.io 依赖与 ASF 官方源码包）、各历史版本的存放位置，以及发布物的 OpenPGP 签名与 SHA-512 校验码验证方法。读完后你将能安全、正确地获取并核验任意版本的 Apache DataFusion。

作为 Cargo 依赖引入：最主流的获取方式

绝大多数开发者以库的形式在 Rust 项目中使用 DataFusion——在项目的Cargo.toml的[dependencies]段声明依赖，由 Cargo 从 crates.io 包注册表下载。当前仓库的版本为55.1.0，因此最简单的方式是：

[dependencies] datafusion = "55.1.0"

该版本号并非随意填写，它与仓库根目录 Cargo.toml 中[workspace.package]定义的version = "55.1.0"严格一致。发布流程中维护者会手工更新根Cargo.toml的版本号，并同步更新 docs/source/download.md 等文档中的版本引用（见 dev/release/README.md），因此文档中的版本号与实际发布版本始终对齐。

一个 crate、多个子 crate：workspace 结构提示

datafusion主 crate 实际位于 datafusion/core，其 datafusion/core/Cargo.toml 中的包名即为datafusion，描述为"使用 Apache Arrow 作为内存模型的内存查询引擎"。仓库是一个大型 Cargo workspace（见根 Cargo.toml），除主 crate 外还拆分出datafusion-common、datafusion-optimizer、datafusion-physical-plan、datafusion-functions等 30 余个子 crate，统一继承 workspace 的版本号（全部为55.1.0）。如果你只依赖主datafusioncrate，大部分默认能力（SQL、Parquet、压缩、表达式函数等）都会通过defaultfeature 自动开启。

引入时的版本与 feature 选择

引入依赖时，你可以按需裁剪或增强功能。以 docs/source/user-guide/crate-configuration.md 中的说明为参考：

• 仅使用已发布到 crates.io 的稳定版本：datafusion = "55.1.0"；
• 测试尚未发布的最新代码，可直接引用 GitHub 分支（在 DataFusion 中即main分支）：

datafusion = { git = "https://github.com/apache/datafusion", branch = "main" }

• 也可在包级别引用并组合 feature：

datafusion = { git = "https://github.com/apache/datafusion", branch = "main", default-features = false, features = ["unicode_expressions"] }

主 crate 的默认 feature 集合定义于 datafusion/core/Cargo.toml，包括nested_expressions、crypto_expressions、datetime_expressions、encoding_expressions、regex_expressions、string_expressions、unicode_expressions、compression、parquet、recursive_protection与sql。按需关闭default-features可显著缩小二进制体积。

构建优化的补充提示

crate 配置文档还给出了两个常见的构建调优手段（详见 docs/source/user-guide/crate-configuration.md）：

• 为当前 CPU 生成针对性指令，例如RUSTFLAGS='-C target-cpu=native' cargo run --release，可让过滤、聚合、连接等算子受益于 AVX2/AVX512；
• 在[profile.release]中设置lto = true与codegen-units = 1以跨 crate 边界做链接期优化，代价是显著增加 release 构建时间。

官方发布物：ASF 源码制品才是权威发布

需要特别澄清的是：虽然 DataFusion 通过 crates.io 分发带来了极大便利，但 crates.io 上的发布仅是一种分发通道；Apache DataFusion 的官方发布物是经过 PMC（项目管理委员会）投票批准、由 Apache 软件基金会发布的源码制品。这一点在下载文档中明确强调，并与发布流程文档中的描述相互印证——官方发布流程以"签署过的源码 tarball 经 PMC 批准"为核心，随后才将获批制品中的代码发布到 crates.io（见 dev/release/README.md）。

因此，对发布物做安全审计、离线部署或参与投票验证时，应优先使用 ASF 官方发布的源码 tarball，而不是 crates.io 上的编译缓存。

版本存放位置速查

• 最新版本：发布物（tarball、签名与校验文件）存放在 ASF 发布站点（dist.apache.org的datafusion目录）。
• 历史版本归档：早期发布物可在 ASF 归档站点（archive.apache.org/dist/datafusion/）中找到。
• 37.0.0 之前的版本：需要到 Arrow 项目的归档站点（archive.apache.org/dist/arrow/）查找——这是因为 DataFusion 早期随 Apache Arrow 项目一同发布。

也就是说，如果你需要 36.x 或更早的版本，请直接前往 Arrow 归档目录；37.0.0 及之后的版本才归档在 DataFusion 自己的目录下。

发布物的命名与生成方式

了解发布物如何产生，有助于理解校验过程。仓库中的 dev/release/create-tarball.sh 展示了完整的打包签名流程：

• 从 git 标签（如55.1.0-rc1）用git archive导出源码，压缩为apache-datafusion-<version>.tar.gz；
• 用 GPG 生成分离式 ASCII 签名：gpg --armor --output ${tarball}.asc --detach-sig ${tarball}；
• 在制品目录内生成相对路径的校验文件：shasum -a 256与shasum -a 512，分别产出.sha256与.sha512文件；
• 上传到 ASF 的dist仓库 dev 目录供社区投票。

因此你下载到的每个 tarball 都会配套一个.asc签名文件与.sha256/.sha512校验文件。

下载后的完整性验证：签名与校验码

下载文档专门提醒：下载发布物后，必须验证 OpenPGP 兼容签名（若不可行，则至少校验 SHA-512），且这些验证材料应当从 Apache 主站点获取，而不是第三方镜像。

前置材料：KEYS 文件

ASF 使用 GPG 对发布物签名，签名公钥集中存放在一个名为KEYS的文件中。下载时请同时下载：

• 发布物本身（apache-datafusion-<version>.tar.gz）；
• 对应的.asc签名文件；
• KEYS公钥文件（含所有签名者公钥的 ASCII 文本）。

文档进一步建议：尽可能建立"信任网"（web of trust）来确认这些公钥的身份，而不是盲目信任公钥文件内容本身。签名者的公钥如何进入 KEYS，可见 dev/release/README.md：发布者将自己的公钥通过 SVN 提交到dist.apache.org的 dev 与 release 两处 KEYS 文件，添加公钥的典型命令为：

(gpg --list-sigs "John Doe" && gpg --armor --export "John Doe") >> KEYS

验证 OpenPGP 签名（推荐）

按以下步骤验证发布物的签名：

1. 下载KEYS文件与目标发布物的.asc签名文件；
2. 将 KEYS 导入 GPG 密钥环：

gpg --import KEYS

3. 校验发布物的签名：

gpg --verify <artifact>.asc <artifact>

例如，对于apache-datafusion-55.1.0.tar.gz：

gpg --verify apache-datafusion-55.1.0.tar.gz.asc apache-datafusion-55.1.0.tar.gz

若输出包含Good signature，说明该 tarball 确实由持有对应私钥的发布者签名，且内容未被篡改。

这一流程与仓库中官方发布候选验证脚本 dev/release/verify-release-candidate.sh 的实现完全一致：该脚本先download_dist_file KEYS并执行gpg --import KEYS（见 L85-L88），随后对每个.asc文件执行gpg --verify $sigfile $artifact（见 L107-L121）。它是 DataFusion 官方验证发布候选的标准程序，你的手工验证可视为其单制品简化版。

验证 SHA-512 校验码（兜底方案）

如果无法完成签名验证（例如环境缺少 GPG），则应至少校验 SHA-512 校验码。你需要下载发布物与对应的.sha512校验文件，然后执行：

shasum -a 512 -c <artifact>.sha512

校验文件中的哈希值生成自制品目录内（使用相对路径名），因此通常需要在包含 tarball 与校验文件的同一目录下执行，输出OK即表示文件内容与官方哈希一致。shasum是 macOS 自带工具，在 Linux 上亦可用sha512sum -c替代；仓库脚本对两种工具均做了兼容（见 dev/release/verify-release-candidate.sh 与 L90-L96）。

常见问题与操作要点

• 从 crates.io 引入是否也需要校验？不需要。crates.io 由 Rust 生态统一管理分发，Cargo 会基于 registry 的校验和机制保证下载完整性；签名与 SHA-512 校验仅针对 ASF 官方源码发布物。
• 下载哪个版本的文件？每个发布物有 tarball、.asc、.sha256、.sha512共 4 个文件。进行签名验证至少需要 tarball +.asc+KEYS；进行校验码验证至少需要 tarball +.sha512。
• 验证失败怎么办？任何Bad signature或WARNING: ... FAILED都意味着文件不完整或被篡改，应立即停止使用，并从 Apache 官方站点重新下载后再次验证。
• 发布物在仓库中的镜像说明：本文所涉仓库为 DataFusion 源码镜像，完整源码、Cargo 配置、发布脚本与历史 changelog 均可直接查看：版本定义见 Cargo.toml，核心 crate 配置见 datafusion/core/Cargo.toml，发布流程见 dev/release/README.md，签名/校验脚本见 dev/release/create-tarball.sh 与 dev/release/verify-release-candidate.sh，各版本更新说明见 dev/changelog/55.1.0.md。

小结

获取 Apache DataFusion 有两条路径：日常开发以 Rust 库形式通过 crates.io 依赖引入（datafusion = "55.1.0"），生产审计与离线部署则以 ASF 官方源码 tarball 为准。无论选择哪条路径，都建议理解其发布治理模型：crates.io 仅为便利分发通道，官方发布物是经 PMC 投票批准的签名源码制品；下载官方制品后，务必使用gpg --import KEYS+gpg --verify验证 OpenPGP 签名，或以shasum -a 512 -c校验 SHA-512 兜底，确保获取到的是未被篡改的权威版本。结合 dev/release/verify-release-candidate.sh 的实现，你可以把上述手工步骤自动化，融入自己的 CI 或发布流水线。

• 大数据
• 数据分析
• 后端