ReadMerger

不要再使用 find 和 cat 合并您的读取操作了！

推荐用法

Readmerger 目前处于开发初期阶段。许多不应包含在生产代码中的 Rust 习惯用法仍然写入源代码，这使得它更容易出错且难以预测（请放心，任何错误都不是内存相关的，多亏了 Rust 内置的内存安全性）。尽管如此，应用程序的整体框架已建立，并且它似乎可以快速合并 gzip 或 zstd 压缩的 FASTQ 文件。我们邀请任何感兴趣的用户谨慎使用和测试。

对于这些非正式用例，我们建议用户按照以下步骤进行

0. 确保已安装 Rust 工具链。
1. 使用以下命令克隆此仓库 git clone https://github.com/nrminor/readmerger.git。
2. 使用以下命令构建 readmerger cargo build readmerger/。
3. 按照如下方式运行它

./target/release/readmerger /path/to/fastq/files/ merged.fastq.gz > readmerger.log

这将运行 readmerger 并将输出保存到日志文件中。这些输出包括，最重要的是，一个格式化的合并树，它详细说明了文件合并的顺序。请注意，readmerger 也将通过 crates.io 在将来提供，这将简化安装。

问题

Readmerger 还未完成，但其愿景是成为使用 cat 将 Oxford Nanopore FASTQ 文件合并成一个文件的更快替代品。通常，Nanopore 读取操作在基线调用和去复用后会产生许多 FASTQ 文件，然后必须合并。这通常通过以下命令实现

cat ~/workdir/basecall/*runid*.fastq.gz > ~/workdir/basecall/basecall.fastq.gz

这种方法的好处是它使用了全球计算机上都可用的 Unix 命令。问题是，cat 一次将一个 FASTQ 流入输出文件，这意味着对于非常大的序列数据集，可能需要很长时间。我在我的工作流程中，读取合并是速度最慢的步骤。此外，由 * 表达式派生的通配符扩展有一个上限；超过一定数量的文件，它将出错。这导致更冗长的合并代码，可能看起来像这样

find . -type f -name *barcode01*.fastq.gz > fastq_list.txt
touch barcode01.fastq
for i in `cat fastq_list.txt`;
do
    zcat $i >> barcode01.fastq
done
gzip barcode01.fastq

虽然这段代码解决了通配符展开问题，但它仍然一次合并一个FASTQ，为了避免压缩损坏，它还需要进行解压缩和再压缩。为了解决通配符展开问题，我们最终得到的代码甚至更慢！

Readmerger的方案

readmerger的愿景是解决这些问题，并且像cat一样容易运行（同时安装也容易）。程序的调用方式如下

readmerger barcode01/

或者也可能像这样

readmerger --verbose --show-progress --high-memory --collect-stats barcode01/

该工具将使用我所说的“合并树”或“分层合并”。例如，假设在条形码目录中有八个FASTQ文件。Readmerger将取四对FASTQ文件中的每一对，并并行合并每一对，产生4个合并的FASTQ文件。然后，它会做同样的事情，并行合并每一对并输出两个FASTQ文件，此时它会合并最后两个并给出最终的FASTQ文件。就像March Madness淘汰赛一样，readmerger将从FASTQ树的许多末端开始，最终结束于一个胜者。

重要的是，该工具将通过使用追加模型来避免冗余的文件读取和写入：在合并树的第一个“轮次”中，它将一个FASTQ读取转移到新的FASTQ文件中，然后在剩余的合并过程中将该文件中的读取追加到其他FASTQ文件。