从 10 分钟到 1 分钟：一次 fasterq-dump 转换测试

这篇文章整理自 2026 年 2 月归档的一份 fasterq-dump 使用记录，以一次约 9 GB SRA 文件的单机测试为起点，重点复盘线程、临时空间、I/O 与输出校验之间的关系。

为什么转换速度不能只看线程数

从 SRA 转换为 FASTQ，不只是 CPU 计算。任务还要持续读取源文件、写入 FASTQ，并使用临时空间完成中间处理。线程增加后，瓶颈可能从计算转移到磁盘吞吐。

因此，评估转换任务时至少要同时观察：

实际经过时间，也就是终端中 real 或 total 所反映的等待时间；
CPU 使用情况；
输出目录与临时目录的可用空间；
输出目录和临时目录是否位于同一个文件系统；
最终 FASTQ 的完整性与命名方式。

源笔记中的一次测试

当时使用同一个约 9 GB 的 SRA 文件比较了两个命令：

time fastq-dump --split-3 -O test SRR5318040.sra
time fasterq-dump --split-3 SRR5318040.sra -e 20 -o SRR5318040

记录到的实际经过时间分别约为：

工具	实际经过时间
`fastq-dump`	9 分 52 秒
`fasterq-dump`	1 分 02 秒

在这一次测试中，实际等待时间缩短到原来的约十分之一。与此同时，fasterq-dump 使用了更多 CPU 和系统调用时间。这说明加速主要来自并行处理与更积极的 I/O，而不是任务所需总计算量凭空消失。

这个数字只能描述当时的文件和机器。换一个 accession、存储介质或线程设置，结果可能完全不同。

运行前先估算磁盘空间

转换后 FASTQ 通常比压缩的 SRA 文件大，而且任务还需要临时空间。比起直接运行，我更倾向于先检查：

vdb-dump --info SRR_ACCESSION
df -h .
df -h /path/to/scratch

如果输出目录空间不足，任务可能在运行很久后才失败。临时目录可以通过 -t 指定：

fasterq-dump SRR_ACCESSION \
  --split-files \
  -e 8 \
  -O /path/to/output \
  -t /path/to/scratch \
  -p

当条件允许时，可以让输出与临时目录位于不同的高速文件系统，降低读写竞争。但是否更快仍应通过实际测试判断。

线程数不是越多越好

-e 控制线程数。线程增加后，如果磁盘已经达到吞吐上限，继续加线程只会提高资源占用，不一定缩短实际时间。

我的做法是选一个规模适中的 accession，分别测试几个线程档位：

for threads in 4 8 12; do
  time fasterq-dump SRR_ACCESSION \
    --split-files \
    -e "${threads}" \
    -O "test_${threads}" \
    -t /path/to/scratch
done

测试时需要保持输入文件、输出介质和其他负载尽可能一致，否则比较没有意义。

转换完成不等于任务完成

转换结束后还应检查：

预期的单端或双端文件是否都已生成；
文件是否为空、大小是否异常；
FASTQ 行数是否能被 4 整除；
压缩前后文件是否完整；
日志中是否出现缺失 spot、磁盘不足或读取错误；
accession、样本名和输出文件名之间是否保留了映射。

例如，可以做一个最基础的结构检查：

lines=$(wc -l < SRR_ACCESSION_1.fastq)
test $((lines % 4)) -eq 0

更严格的流程还应保留软件版本、运行命令、开始和结束时间，以及输出文件校验值。

这次记录真正留下的经验

这次测试值得保留的不是“fasterq-dump 一定快 9 倍”，而是一个更稳妥的判断顺序：

先估算数据规模
→ 检查输出与临时空间
→ 用小任务测试线程与 I/O
→ 批量转换
→ 校验输出
→ 保存日志和版本

对于大规模公开数据下载，速度只是其中一个指标。能否在中断后恢复、能否解释失败原因、能否确认文件完整，往往比跑出一次最快时间更重要。

不同机器、存储介质和软件版本会改变基准结果。复测时应同步记录硬件、版本、命令、输入规模与原始日志，便于解释性能差异。