ラベル NGS の投稿を表示しています。 すべての投稿を表示
ラベル NGS の投稿を表示しています。 すべての投稿を表示

2020年6月9日火曜日

Fastq/Fasta からのリードのリサンプリング




fastqファイルやfastaファイルとしてシークエンスデータを持っているときに、より小さいデータ、リード数の少ないデータにしたい場合がある。このようなリードのダウンサンプリング(あるいは、サブサンプリング)は、データ全体からランダムに一部を取り出すことによって行われる。小さいデータセットを作りたくなる理由は色々あるだろうが、思いつくところでは、以下のようなものが挙げられる。


  • [QCなど] データの性質についてQCを行いたいときに、全部のデータでは負荷がかかるので、一部を取り出して傾向を見たいと言ったとき
  • [条件検討など] 解析の結果がデータ量で変化するかどうか見てみたいとき
  • [ツール側の問題] 用いるプログラムやスクリプト、解析環境が処理できるサイズにデータ量を変更してやらないといけないとき
  • [手軽なtest fileを作りたいとき] ツールの使い方を確かめたり、オプションを試したりしたいときに取り回しの良いファイルを作りたい時がある


Fastqファイルやfastaファイルから、指定した割合やリード数だけリードをサンプリングしたい場合にどうするのかをまとめた。何通りかやり方はあるだろうが、ここではバイオインフォマティクス ツールのseqkitを利用することを想定した。また、同じくよく使われるseqtkのコマンドを併記した。




用いるツール



fastaやfastqファイルを操作するためのツールで、バイナリファイルをダウンロードする他、condaでも導入できるようになっている。



こちらもfastq/fastaを操作するツールで、condaでも導入可能。



Fastq/fasta ファイルの内容確認



リサンプリングの前に、もしそのデータについて概要を知らない場合、リード数などの統計量をあらかじめ知っておきたいかもしれない。その場合は、seqkit statsを使って統計量を出すことができる。

$ seqkit stats input.fastq.gz


複数のファイルがある場合は、以下のように指定してもいいかもしれない。

$ seqkit stats *.fastq

fastaとfastqが混じっていてもいいらしい。

$ seqkit stats *.fa*

結果は以下のように示される。

$ seqkit stats bud_L001.fastq.gz
file               format  type    num_seqs        sum_len  min_len  avg_len  max_len
bud_L001.fastq.gz  FASTQ   DNA   29,342,622  2,195,350,462       50     74.8       75



リード数を指定してのリサンプリング



(1) seqkitを使う場合のコマンド: seqkit sample


bud_L001.fastq.gzから、100リードをサンプルして、bud_L001.n100.fastq.gzとして出力する場合、

$ seqkit sample -n 100 -s 100 bud_L001.fastq.gz -o bud_L001.n100.fastq.gz



実際に確かめると、100リードのファイルができている。

$ seqkit stats bud_L001.n100.fastq.gz




ここで-sで指定されているのは、乱数を発生させるときのrandom seedで、デフォルトは11。同じrandom seedを使えば同じ配列が得られる。



single readではなく、PEのデータの場合は、R1とR2で同じrandom seedを使う必要がある。

$ seqkit sample -n 100 -s 100 seq_R1.fastq.gz -o seq_R1.fastq.gz
$ seqkit sample -n 100 -s 100 seq_R2.fastq.gz -o seq_R2.fastq.gz



使えるスレッドに余裕がある場合は、-jオプションでスレッド数を増やすことができる
$ seqkit sample -100 -s 100 -j 8 bud_L001.fastq.gz -o bud_L001.n100.fastq.gz



(2) seqtkを使う場合のコマンド:seqtk sample


$ seqtk sample -s 100 bud_L001.fastq.gz 1000 > subseq_bud.fastq



PEの場合、やはり-sを同一に指定する。
$ seqtk sample -s 100 bud_R1.fastq.gz 1000 > subseq_bud_R1.fastq
$ seqtk sample -s 100 bud_R2.fastq.gz 1000 > subseq_bud_R2.fastq



割合を指定してのリサンプリング


(1) seqkitを使う場合:seqkit sampleで、オプション-p (0,1)を使う

$ seqkit sample -p 0.01 -s 100 bud_L001.fastq.gz -o bud_L001.n100.fastq.gz



(2) seqtkを使う場合:seqtk sampleで、割合を指定する

$ seqtk sample -s 100 bud_L001.fastq.gz 0.01 > subseq_bud.fastq




注意点


  • 元ファイルに含まれている以上のリード数を指定した場合、出力ファイルは元のファイルと同一になる。
  • proportionで1以上を指定するとエラーになる。
  • seqtkで読み込んで標準出力すると、ファイルのフォーマットはASCII txtになる (うっかり.gzとか拡張子をつけてもcompressされていない)
  • 多分読み込みにかなりのメモリを食う作業なので、下手なパソコンで始めるとメモリ不足でフリーズする。

2019年11月28日木曜日

SRAデータのダウンロードツールがfastq-dumpからfasterq-dumpへ

次世代シークエンスのデータをncbiのSRAからダウンロードする際に用いられていたのが、ncbiのSRA toolkitに含まれる、fastq-dumpだった。
 https://trace.ncbi.nlm.nih.gov/Traces/sra/sra.cgi?view=toolkit_doc&f=fastq-dump

ペアエンドのリードをダウンロードする際は、二つのファイルを生成するように以下のようなオプションを使っていた。
> fastq-dump -I --split-files SRR000001

しばらく使っていなかったのだが、久しぶりに見てみると、クラウド移行した上にマルチスレッドにも対応したfasterq-dumpというコマンドが使えるようになっていた。2.9.1からということだが、現在の最新は2.10.0だった。
 githubのREADMEにアナウンスメントがあり、まだfastq-dumpも使えるが、今後fasterq-dumpに移行していくようだ。

ANNOUNCEMENT:

With release 2.10.0 of sra-tools we have added cloud-native operation for AWS and GCP environments (Linux only for this release), for use with the public SRA. prefetch is capable of retrieving original submission files in addition to ETL data.
With release 2.9.1 of sra-tools we have finally made available the tool fasterq-dump, a replacement for the much older fastq-dump tool. As its name implies, it runs faster, and is better suited for large-scale conversion of SRA objects into FASTQ files that are common on sites with enough disk space for temporary files. fasterq-dump is multi-threaded and performs bulk joins in a way that improves performance as compared to fastq-dump, which performs joins on a per-record basis (and is single-threaded).
fastq-dump is still supported as it handles more corner cases than fasterq-dump, but it is likely to be deprecated in the future.

Wikiに詳しく使い方が書いてあり、メモリをtmpに使用する方法やディスクの空き容量を調べる方法など色々解説してあって勉強になる。
https://github.com/ncbi/sra-tools/wiki/HowTo:-fasterq-dump


 まずは、wgetでダウンロードしたのちに、展開する。binの中にプログラムが入っているので、パスを通す。
> wget http://ftp-trace.ncbi.nlm.nih.gov/sra/sdk/2.10.0/sratoolkit.2.10.0-centos_linux64.tar.gz
> tar xzf ./sratoolkit.2.10.0-centos_linux64.tar.gz

これでまずはSRRファイルを一つダウンロードすることを試みたのだが、以下のエラーメッセージが帰ってきた。
> fasterq-dump SRR6453566 -t /dev/shm -e 8 -p

Can't locate XML/LibXML.pm in @INC (you may need to install the XML::LibXML module) 

 XML::LibXMLをcpanで入れようとしたのだが、なぜかエラーでうまくいかなかった。

仕方がないので試しに以前のバージョン(2.9.2)をインストールして使ってみると、今度はうまくダウンロードすることができた。 
> fasterq-dump SRR6453566 -t /dev/shm -e 8 -p
 

join   :|-------------------------------------------------- 100.00%
concat :|-------------------------------------------------- 100.00%
spots read      : 9,980,987
reads read      : 19,961,974
reads written   : 19,961,974


ここで、-tは一時的にできるファイルの場所を指定するオプションで、指定しない場合は今いるところに作られ、ダウンロード終了の際に消去されるようだ。ここで-t /dev/shmと指定することで、メモリをtmpの場所として指定することができるようで、ダウンロードの高速化が見込める。他にも、-tでSSDなどを指定しても良いらしい。-eは使うスレッドの数で、デフォルトは6。ただ、これは増やしたからといって必ずしもずっと高速化するわけではなく、I/Oの速さの制約を受けると書いてある。

これで、試しにBrassica napusについて大規模に解析した論文のデータをダウンロードしてみることにした。B. napusについては、違うグループから大規模集団解析の結果が立て続けにNature communicationsに掲載されている。

 Whole-genome resequencing reveals Brassica napus origin and genetic loci involved in its improvement.
https://www.nature.com/articles/s41467-019-09134-9

Transcriptome and organellar sequencing highlights the complex origin and diversification of allotetraploid Brassica napus.
https://www.nature.com/articles/s41467-019-10757-1

この2番目の方のデータをダウンロードしてみることにした。data availabilityの情報から、SRAの番号がSRA128554であることから、これをSRA Run Selectorで探した。
https://trace.ncbi.nlm.nih.gov/Traces/study/?acc=srp128554

Run Selectorも昔のサイトよりもすごくモダンな感じになっており、見やすくなっていた。ここからSRRのリストをダウンロードし、シェルスクリプトを書いてLinux機で実行した。

time fasterq-dump SRR6453567 -t /dev/shm -e 8 -p
time fasterq-dump SRR6453568 -t /dev/shm -e 8 -p
time fasterq-dump SRR6453569 -t /dev/shm -e 8 -p
time fasterq-dump SRR6453570 -t /dev/shm -e 8 -p
time fasterq-dump SRR6453571 -t /dev/shm -e 8 -p
time fasterq-dump SRR6453573 -t /dev/shm -e 8 -p
time fasterq-dump SRR6453574 -t /dev/shm -e 8 -p

///

全体のデータ量が935.18Gbとあるので、だいぶん大きい。しばらく時間がかかりそうだ。
扱うデータが大きくなると、ストレージの確保もだが、大きなデータの効率的な扱い方を覚えないと軽く死ねそうだ。



2019年7月22日月曜日

MinION 来たる

研究室にOxford nanoporeの卓上ロングリードシークエンサーであるMinIONが購入された。数年前に登場した時には、実験室や野外でもシークエンス可能な機器の大きさと、それでいてロングリードのシークエンスが可能という性能に驚かずにはいられなかった。東大界隈で盛り上がっている話とか、実際の論文に使用例が出てきたことで、その能力や可能性、制約などいろいろな情報も揃ってきている。研究室のいくつかのテーマに利用可能とPIが判断して、今年度の予算で購入された。話で聴いていただけだが、nanopore社に登録してアカウントを作らなければならなかったり、学内手続きに時間がかかったりして結構大変だったようだ。

本体はこんな感じの箱に入ってきた。なんだかスマホとか、ちょっと高めのIT機器みたいな感じだ。本体が収められているだけで、この箱自体はとても小さい。


中を開けると、金属製の本体が入っていた。なんだろう、本当に外付けディスクか何かのようだ。


取り出してみたところ。本体の下にはUSBケーブルが入っていた。データの転送スピードが違うのだろうか、コネクタの部分の色が金色だ。


機能的に重要なのは、この本体というよりは、そこにセットするフローセルのようだ。フローセルは個別包装で、4℃保存だった。最初は、ゲノムシークエンス用のキットがちょっと多めに購入された。下は、フローセルの袋の写真だ。


これから使い方を習得しないといけないが、本体やキットには説明書らしいものは一切添付されていない。詳細情報はWebページを通して、ということらしい。また、初回のキットの購入で、チュートリアルコースの受講ができるそうだが、東京(?)まで出席しないといけないそうで、人を出すのかどうかはまだ決まっていない。

どんな使い方ができるのか、これまでの実績やラボでのニーズをよく考えてみる必要があると思う。数年前の論文の段階で、エボラ熱の監視にポータブルシークエンサーを使う、というnatureの記事があったが、サイトでの利用例も出てきていて、本当にすごい時代になったなと思う。自分が大学院生の頃、学科のABi3700系のキャピラリシーケンサーを運用していたが、データ量、シークエンサーの可搬性など、この10数年で本当に想像できないくらいの進展だと思う。


2019年4月1日月曜日

2019年度 解析まわりでやりたいこと

解析まわりで、今年度やりたいこと、導入したいシステムなどを列挙しておきたい。

1. Dockerの導入

カラのlinux機かmacを準備してとりあえず使ってみたい。再現性の面でも、解析環境をまとめておくことができる方が望ましいだろう。

2. Windows OS の習熟

解析はほとんどmacOSとLinux OSで行なっているので、あまり必要性があるわけではないが、ある程度使える方が便利そうだ。また、他の人に何かを伝えるときも、大抵の場合相手はwindowsを使用しているので、分かっている方が会話がしやすい。

3. Jupyter Notebookなどを使った、プロトコル整備

自分が後から見返して分かりやすいようにということもあるが、学部生に見せて、自分でいじらせるためのプロトコルが必要だと感じる。

4. Rapsberry Piを使ったデバイス作り

植物写真や温湿度などをログする簡易記録機を安価に作れるのならば、いろいろな場所に設置しておきたい。水やりも半自動化できれば、ブレが少なくなりそうだ。そんなにシビアな植物生理の実験をしていないので、お金をつぎ込んでまでやる必要性はないが、簡易な設備を自分で作れるのなら便利そう。

5. Linux解析機のパワーアップ

現在96Gb RAM, 12Tb HDDのWSにもう少し付け足す。CentOS6で動かしているが、解析している論文が出た時点でOSをupgradeしたい。ssd化も検討したい。

6. バイオインフォマティクスのアルゴリズム、線形代数、統計の学習と、それらをプログラミングにつなげること

これまでにもっと勉強しておけばよかったと切実に思う。

2019年2月15日金曜日

Jupyter notebookを使って、解析のスクリプトを一つのファイルに書いていく

ここ数日、一つのプロジェクトの解析で使うスクリプトをJupyter notebookを使って書いている。カーネルをpython3、bash、Rと使えるようにしておいて、ノートブックの途中でカーネルを変えながら、シェルスクリプトやpythonのプログラムを一つのファイルで記述していっている。こういう風にしていく理由の一つは、プロジェクト全体でどのようにデータ処理をしていったのか、流れがわかりやすくなるかなと思ったからだ。

これまではプロジェクトのディレクトリの色々な箇所にスクリプトが分散して置かれているような状態になっていて、一気に読めなかった。また、それぞれの処理の順番などが、後で見返したときにわかりにくいような気がしていた。

notebookにまとめると、そういった点は分かりやすくなったような気がする。標準出力も保存できるので、記録にもなる。あと、その都度アイデアなどをmarkdownでまとめていって、解析の流れの中で見れるのも便利だった。ただ、スクリプトや解析が長くなると逆に見づらくなってしまう。試行錯誤をしながら短いスクリプトの処理を積み重ねていくような場合だと、notebookが良いのだろうととりあえずの結論。


2019年1月30日水曜日

illuminaがPacBioを買収、の記事を読んだ時の話

数日前、illuminaがPacific Biosciencesを買収するという記事が居室で話題になった。Nature Biotechnologyの記事を見つけてきた人がいてそれを見せてもらった。ゲノムの方で覇権を握り続けるための措置なのだろうか。今いる研究室でもPacBioでシークエンスをしている。まだ論文を出せていないが、アブラナ科植物のde novo アセンブルでpacbioを使うと、HiSeqのショートリードのみの場合よりもN50が大幅に長くなった。非モデル生物や育種系の需要では、しばらくは、illuminaが提供するショートリード+ロングリードでの新規ゲノム解析が定石の方法となるのだろうか?

ここからはilluminaの話とは別になるが、この記事を見つけてきた人が、ふとGoogle翻訳を使って記事を訳したらどうなるのかを試してみた。結果を見てびっくりした。日本語としてかなり読みやすい訳になっていたからだ。前々からGoogle翻訳の能力が上がっていることには気付いていたが、こんなにいい感じに機械が翻訳できることに単純に驚いた。

学部生には、どこの大学でも「科学英語」のような授業があるし、自分も学生の時それで論文を読んだり英語の文章を読んだりした記憶がある。一般科目の方には普通の英語の講義もたくさんあった。そこでは単純に単語を覚えたり、和訳したりする課題もたくさんあった。でも、これだけ進んだ自動翻訳の技術を見せられたら、科目としての英語も変化しないといけないんじゃないかという気がしてくる。どう変えるか、まで答えられるほどの知識も知恵もないが、課題解決型、英語でなにがしかのアクションが実際にできることそのものが評価の対象になるのではと感じる。その過程では、Google翻訳などのような、昔ならサボるための道具として忌避されていたツールを逆に使いこなすことが評価されるようになるのかもなと思った。素人考えなので実際はわからないが。


2019年1月17日木曜日

Anacondaの導入

昨年末の話になるが、anacondaをメインのMacBook Proにインストールした。ブログやWebページ、qiitaで紹介や解説などを一通り見て、一回 macOS の仮想化デスクトップに導入してみて、やっぱり便利そうだったので、メインのパソコンにもようやく導入することにした。嫌っている人が書いているように、確かに .bash_profile に色々書き込んだ上でシステムのpythonはマスクされ、condaで入れたpythonの方が使われるようにpathが書き加えられていた。pipをある条件で使うと不都合が起こる場合があると解説している人もいる。

素人にはよく分かっていないことが多いが、anacondaで便利になることも多い。特に、(anacondaで諸々インストールしなくても、minicondaを使えば良いが、)パッケージ管理の機能を使って、バイオインフォマティクスのプログラムをストレスなく導入できるのは、初めてやったときは感動した。また、jupyter notebookは、研究室内で教えたり記録を残しながら解析したりするのにも役立ちそう。他の研究室の人を手伝う時にも(導入の煩わしさはあると思うが)、スクリプトファイルひとつ渡すよりもとっつきやすいのではないかと思う。Rやbashを使えるようにすることもできる。これらは、ラボ内のドキュメント整理にすごい便利だと思う。

jupyterではないが、spyderは12月末にラボPCで3年生がデータを解析する時に早速使ってもらった。共有パソコンのwindowsにanacondaを導入、簡単なスクリプトを書いて渡し、ちょっと書き直しながら動かしてデータ解析してもらった。1万行を超えるエクセルシートからコピペを繰り返すという苦行のようなことをしていたので、改善しなければと思っていたが、スクリプトを渡して気軽に実行できる環境を整えるのに役立った。データ解析について、ラボ全体でよくやる作業をまとめ、再利用可能な形でjupyterのファイルとして共有することもありえるかなと思う。

2019年1月15日火曜日

Windows10でLinuxのシステムを有効化する


Windows Subsystem for Linuxを有効化して、Ubuntuをインストールした。


以前から興味があったが、WindowsでLinuxのシステムを使えるように設定した。普段自分の解析には、macOSやLinux系のOSを使っているが、研究室としてはwindowsのPCを主に使っている。また隣近所でも、windowsシステムの方が馴染みがある人も多い。コマンドラインを使った処理を勧めるにも、システムごと新しく導入というのはちょっと難しい。仮想化デスクトップでlinux系OSを導入するのもいいけれど、少し面倒だと感じていた。

実習等でコマンドライン操作を教えるときにも、Win機だとLinuxサーバーへの接続が必要だが、Win10の正式な機能としてWSLが使えるのであれば、そちらの方が手軽な気がする。



今回のテストでは、Macの仮想化デスクトップ上で使用しているWindows10を使った。ここのサイトを参考にして作業したら、10分もかからずに設定は終わった。WSLのシステムはWindows10のシステムとの関係はまだよくわかっていないので調べたい。