日付；2022/09/19（月）、2022/10/02（日）改定と追記
ゲノム解析で遊ぼうと思っても、肝心なデータがない。そういう場合は、NCBI（National Center for biotechnology Information）のSRA（Sequence Read Achive）からダウンロードして使用する。
しかし、２０２１年くらいからNCBIが一部データをon-premisesで管理するのを止めて、AWSやGCPに保存するようになった（https://www.ncbi.nlm.nih.gov/sra/docs/sra-cloud/）。新しいデータ、例えばCOVID-19のシークエンスリードなんかがAWSやGCPに保存されているようだ（https://www.ncbi.nlm.nih.gov/sra/docs/sra-aws-download/）。
何が嫌だって、これは場合によってはダウンロードにお金がかかる場合がある。このsra-toolsの機能をフル活用するためには、AWSのEC2インスタンスとS3にサインアップしないといけない。言うても、かなりの量のダウンロードや長時間インスタンスを走らせなければ大金が請求されることはないのだろう。しかし、シークエンサーで読んだデータはかなり大きいので、注意しなくてはならないだろう。長時間のダウンロードならばEC2のランニングでもお金を取られる可能性もある。本当にこれらのデータが必要な場合は、職場からお金を支払ってもらうなどの対処が必要になりそうだ。これはSRA toolkitのインストラクションにも書いてあった。しかし、フリーと言っておきながら金がかかる場合があるってのは、どうも腑に落ちないところだ。
そういうことで、それが発表されて以来、 sra-toolsを使うのを、インストールでされ敬遠してきた。しかし、現職場でこの手の解析を行うようになってからは、どうしてもこれを使ってテストしたりしなければならなくなった。なので、今回はこの sra-toolsを使ってみようと思う。そのインストール時のメモをここに記しておこうと思う。
ポイントとしては「ちゃんとマニュアルを読んだ」ってところだ。金がかかるかもしれないとか、本当に嫌だ。結論としては、特に金がかかることはなさそうだった。ただ自分の勉強不足で怯えていただけらしい。
重要なこと
一番重要なことは、AWS（GCP）を使ってダウンロードしなくてはならないのか、ということである。結論は、ちゃんと設定さえしていれば、AWSやGCPにわざわざサインアップする必要はない。
SRA toolkitのインストラクション（マニュアル）
2022年の時点では、ここにある。https://github.com/ncbi/sra-tools/wiki
sra-toolkitをインストールする
まずはここから sra-toolsのバイナリーをダウンロードして、どこか都合の良いディレクトリに展開し、パスを通す。インストールはとりあえずこれでOK。
vdb-config -i で設定する
次に、以下のコマンドを流す。もしsudoが必要なら、そうする。
vdb-config -iそうすると、以下の画像のような画面になる。ここではEnable Remote Accessにチェックする。
次に以下の画面になる。ここではPCに保存したいので、location of user-repositoryにダウンロードしたsraファイルを保存するための場所を入れる。あと、RAMもテキトウに入れる。このRAM、直接に数字が入力できないので、かなりダルい。+と-で増減させる必要がある。何度も言う。かなりダルい。
次に、以下の画像が、個人的に最も注意すべきところ。まず、Accept charges for AWSにチェックを入れてしまうと、おそらく、と言うか、よく知らないんだが、ダウンロードとデータ保存（S3とかを使う場合）に請求されるかもしれないので、ここは外しておく。重要なことだが、これを使うためにはEC2とS3を使える状態にする必要がある（知らんけど）。AWSにサインアップすると、 free tierが付いてくる（確か1年間。2022年現在ではどうなってるかわからん。）ので、そのときに全力でダウンロードするのもありだと思う。
なので、report cloud instance identityのみにチェックを入れる。インストラクションによれば、「The cloud instance identity only reports back in what cloud (AWS v GCP) you are working so you can access data for free.」だそうだ。ここにチェックを入れておけば、sra-toolsはAWSやGCPにレポートを入れることができるらしく、データにフリーにアクセスできるようだ。GCPも基本的に同じらしい。
次は、よく知らん。無視。
次は何気にけっこう大事。デフォルトではcurrent directolyになっているので、ここをuser-repositoryにチェックする。そうしないと、気がついたらhomeがsraファイルでいっぱいになっていたってことになり、かなり後悔すると思う。これで設定は一応終了。もしなにか必要ならば、またvdb-config -iを走らせて設定し直せば良いと思う。
prefetchでsraファイルをダウンロードする
SRAで必要なアクセッションナンバーを調べて、prefetchでsraファイルを取得する。アクセッションナンバーはスペースで区切れば、一気にダウンロードできる。以下は例。これは、2年前に試しに解析してみたファイルである。以前の自分の研究ネタとも関連するデータである。
prefetch SRR6173165 SRR6173166 SRR6173167 SRR6173168 SRR6173169 SRR6173170 SRR6173171 SRR6173172 SRR6173173 SRR6173174これらはlocation of user-repositoryで設定したディレクトリーに入っているはず。
あと、このあたりはマニュアルにいい感じに書いてあるので、必要に応じて変えてももちろん良い。https://github.com/ncbi/sra-tools/wiki/08.-prefetch-and-fasterq-dump
fastq-dumpでfastqに落とす
SRAに登録された実験条件やサンプルの説明を確認して、それがPaired-endならばリード１と２に落とし込むのが良いと思う。そのためには、fastq-dumpを使用する。 これでOK。 詳しくはfastq-dump –helpを見てほしい。
for SRR in SRR6173165 SRR6173166 SRR6173167 SRR6173168 SRR6173169 SRR6173170 SRR6173171 SRR6173172 SRR6173173 SRR6173174
do
fastq-dump --split-files --gzip --outdir /home/XXXX/Output_Fastq_dump/PRJNA414291 /home/XXXX/SRA/sra/${SRR}.sra
doneただし、これは以前の方法である。利点としては、gzipでストレージを節約できることである。一方、 欠点はそのスピードである。すごく遅い。これもsra-toolsの嫌いなところだった。
fasterq-dumpで高速化
上記のfastq-dumpはすごく遅かったと思う。それはどうやらNCBIの人らもそう思っていたらしい。おそらく、コンピューターの発展も伴って登場したのが、このコマンドだろうと思う。これはスレッドや使用するメモリ領域も指定でき、かなり早いコマンドである。以下がprefetchからfasterq-dumpまでの流れである。
prefetch SRR8537880
fasterq-dump /home/XXXX/SRA/sra/SRR8537880.sra -O /home/katsu/Output-fasterq-dump -m 2G -e 12 -v -S
gzip -v /home/XXXX/Output-fasterq-dump/SRR8537880_1.fastq
gzip -v /home/XXXX/Output-fasterq-dump/SRR8537880_2.fastqかなり早い。この fasterq-dumpとfastq-dumpの違いについて、マニュアル（https://github.com/ncbi/sra-tools/wiki/03.-Quick-Toolkit-Configuration）には以下のように書いてある。
Important differences to fastq-dump include the following:
- The -Z|–stdout option does not work for split-3 and split-files. The tool will fall back to producing files in these cases.
- There is no –gzip|–bizp2 option. You have to compress your files explicitly after they have been written.
- There is no -A option for the accession, only the ability to specify the accession or a path directly. The tool will extract the output-name from the given accession or path.
- The fasterq-dump-tool does not take multiple accessions, just one.
- There is no -N|–minSpotId and no -X|–maxSpotId option. The tool always processes the entire accession.
別に–gzipのオプションを消す必要はなかったと思うのだが。開発チームの中でも悪いんだろうか。
fasterq-dumpの致命的欠点
最近、このfasterq-dumpを使っていてかなり面倒な、致命的とも言える欠点に気がついた。このfasterq-dumpは、設定しているメモリ（物理メモリ・SWAP領域）がsraファイルからfastqファイルへの変換中に不足してしまった場合、強制終了される。実はマニュアルにそれっぽいことが書いてかるが、直接的にそうは言っていない。たしか、元のsraファイルの10倍は必要ですよ、と書いてある。しかし、それがこんな重要なことだとは思わなかった。それに、そのエラーを避けようとしてちゃんとメモリの割り振りについて設定しようとしても、各パラメーターが一体どういう動作をするのかちゃんとマニュアルに書いていないので、どうしようもない。問題になるのが、エクソームシークエンスをしているような場合である。RNA-seqでは、各ファイルが10GBまで行くことはなかなかないから大丈夫だが、エクソームでは圧縮されたsraだったとしても20GBくらいはある。試していなないのではっきりしないが、おそらく合計メモリは元のsraファイルの10倍では足りず、もしかしたら512GBとか1TBとか必要になるのではないかと思っている。そんなこと、このためだけにいちいち設定しなおすのは面倒だし、それに、1TBのメモリなんてなかなか使えない。こういうことになるのであれば、事前にどのくらいのメモリが必要になるのか計算してくれても良いようなものである。それとも、もともとAWSのEC2とS3などを使って変換することを想定しているのだろうか。でもその場合は、一体値段はいくらになるのだろうか。超高額とは行かないまでも、自分では支払いたくない額が一連の実験ごとに請求されてきそうである。
fastq-dumpのほうが早い場合がある
それに、職場では予算の関係上、一番安かったCore i9-12900Kを使っているが、これ、どうもCPUコアが変わった配置をしているらしく、ソフトによってはCPUのコアを認識できない場合があるようだ。現時点でうまく行っていないのはが、fastqc、FusionCatcher、そしてこのsra-toolsである。それに加えて、上述したようにfasterq-dumpはマニュアルが充実していないので、詳しく知ることができず、自分ような素人ではそのようなトラブルに対処できなかった。
なので、仕方なくfastq-dumpを使ってみると、驚くことにfasterq-dumpよりも明らかに早いか、同等である。Core i9-12900Kではfaster1-dumpよりもfastq-dumpのほうが早いということで、職場ではfastq-dumpを使っている。
圧縮はpigzを使用したほうが良い
fasterq-dumpでもfastq-dumpでも、変換後にはストレージの節約のために.gzに圧縮して保存するのが一般的だと思う。ただし、従来通りgzipを使っていては一生かかっても終わらないので、pigzを使用したほうがよい。これはマルチスレッドに対応した圧縮ソフトである。このpigzを使って、後の解析に支障がでないか不安だったが、全く問題なく解析できた。なので、圧縮はpigzのほうが圧倒的に良い。
