バイオインフォマティクス解析においては、多数のOSS(オープンソースソフトウェア)を組み合わせてパイプラインを構築することがよくあります。パイプラインの構築は、自分の好きな言語を選んで自己流で行うことも可能ですが、パイプライン構築用のフレームワークを使用することで、可読性が高く、簡潔なプログラムを書くことができるようになります。
多くのフレームワークではDockerコンテナに対応しているため、多数のOSSの実行環境を整備するといった手間のかかる作業を短縮することができます。また、Dockerコンテナを使用すると、パイプラインのポータビリティが高まりますので、他の研究者へパイプラインを渡したり、クラウド上でパイプラインを実行したりすることも容易になります(再現性の向上)。
パイプライン構築用のフレームワークは、awesome-pipelineにまとめられています。たくさんありますので、そのうち主なものを以下にまとめました。
snakemake
Pythonベースのフレームワーク。Pythonの記法が使えるので、柔軟なワークフローが設計できる。ただ、柔軟なワークフローが設計できる分、タスクごとにDockerで実行環境を分離する考え方と相性が悪く、パイプラインのポータビリティはあまり良くない印象。
例)
rule targets: input: "plots/dataset1.pdf", "plots/dataset2.pdf" rule plot: input: "raw/{dataset}.csv" output: "plots/{dataset}.pdf" shell: "somecommand {input} {output}"
Common Workflow Language(CWL)
ワークフローを記述するための統一言語。CWLを実行するためのソフトウェアはcwltool、Arvados、toil等たくさん開発されている。
例)
#!/usr/bin/env cwl-runner cwlVersion: v1.0 class: CommandLineTool baseCommand: echo inputs: message: type: string inputBinding: position: 1 outputs: []
Nextflow
CWLと目指す方向はほぼ一緒であるが、CWLは言語仕様と実行エンジンが分離しているのに対して、Nextflowは同一である。その分、Nextflowの方がCWLと比べて柔軟にワークフローを記述できる印象。
例)
params.query = "$HOME/sample.fa" params.db = "$HOME/tools/blast-db/pdb/pdb" process blast { output: file top_hits """ blastp -query ${params.query} -db ${params.db} -outfmt 6 \ | head -n 10 \ | cut -f 2 > top_hits """ } process extract { input: file top_hits output: file sequences "blastdbcmd -db ${params.db} -entry_batch $top_hits > sequences" } process align { input: file sequences echo true "t_coffee $sequences 2>&- | tee align_result" }
メモ
NextflowのGitHubスター数が635、CWLのGitHubスター数が815(2018年11月19日)であることから、CWLがやや優勢?