大学の課題でワークフローについてまとめることになったためメモとして掲載．間違っているところばかりだと思うので，随時フィードバックを受けて更新していきます．
課題が終わり、先生からも内容的に大きな間違いはないという評価を頂いたので、とりあえずこれを完成版とさせていただきます。これからもコメントなどがあれば内容を修正していきます。
概要
ワークフロー言語は現在あまりにもたくさんあり，初心者はどの言語を使えばいいのか分からない(し，それぞれの学習コストも高い)というのが現状．
ネットは混乱を極めており...
そこでバイオインフォマティクス分野の主要ワークフロー言語である
についてそれぞれ簡単に解説して，ワークフローをとりあえず使ってみたいという人がどの言語を採用すればいいか目安を作ってみた．
参考: バイオインフォマティクスのツール、ワークフロー、コンテナ関連調査
また私もワークフロー初心者なので環境構築のヒントになりそうなこともメモしておこうと思う．
そもそもワークフローとは？
(少なくとも)バイオインフォの解析は単一のプログラムで解決することは稀であり，ほとんどの場合は結果が得られるまでに複数のプログラムを組み合わさって実行されることが多い(step-by-stepの実行)．下の図はSnakemake Tutorialから抜粋したもの．
このように依存関係があるプログラム群のことをまとめて一つのワークフローであるという．扱うデータ量やワークフロー自体が大きくなると人間の手による逐一の実行は非効率的であり，また再現性の観点からも望ましくない．実際にヒトゲノムなど大規模な解析になるとワークフローを構成するプログラムの数は200以上になるようである．
これらの問題点を軽減するために使われているのがワークフロー記述言語である．ワークフロー記述言語に求められる機能には
- ワークフローの各ステップの自動化
- input, outputファイルの依存関係(一般にDAGで表される)の解決
- DockerやSingularityなどコンテナシステムとの連携
- 並列計算時のコア数の指定など計算資源の管理
などがある．これにより複雑な解析であっても環境依存せず再現可能な形で記述することができる．また数日単位の大規模な解析になるとエラー処理は不可欠であり，(必ずしも全てではないが)そのようのな場合を想定したエラー処理機能を備えた言語も存在している．
Nature ToolBoxの記事があったので，そちらを読んでおくとわかりやすいかもしれない．
環境
- macOS Catalina 10.15.5 + Docker Desktop for Mac version 20.10.5
ワークフロー言語の共通点
それぞれの言語には解釈のための実行エンジンがセットで存在する．
これはC言語に対するgcc(コンパイラ)のようなもので，実際の挙動はどの実行エンジンを選ぶかに依存しているのだが，以降では実行エンジンの種類に依存しないような言語の特徴を挙げていく．
たかったのだが，実行エンジンの存在は切っても切れないようなので，実行エンジン依存である場合はできるだけそれを明記して書いていく．
4言語それぞれの利点と欠点
WDL(Workflow Description Language)/Cromwell
環境構築と参考になるサイト
初心者は公式サイトのWDL Tutorialsに沿って進めるがいいと思われる．
ただ"(howto) Install software for WDL workshops"通りにすると，womtoolのJavaのバージョンとDocker Containerのバージョンが合わずにエラーになるので，代わりにwdltoolを使った方がいい．ダウンロードはこちら
GATKは本来関係ないのだが，Tutorialを進めるためには必要．GATKのimageが3.7GBもあるので電波がいい所でしよう...
例 (/wdldataにwdltoolとCromwell，GATK用のサンプルデータが入っている)
docker pull broadinstitute/gatk:4.1.3.0
docker docker run --name gatk -it -v wdldata:/gatk/wdl-tool broadinstitute/gatk:4.1.3.0
という感じ．
利点と欠点
WDLの利点としてまず挙げられるのは大規模計算に強いということだろう．実際に数万人規模の解析で使われたことがあるのはWDLのみであり，大規模計算の場合の第一候補として考えられる．
参考: The Genome Aggregation Database (gnomAD)
これはWDLが例外処理・資源管理機能をサポートしているためであり，実行エンジンであるCromwellはエラー時再実行やメモリ使用量やCPUコア数を変更してのリトライ，など大規模計算に欠かせない機能を備えている．
欠点はWDLは事実上Cromwellという実行エンジンでしか動かないということ?
CWL(Common Workflow Language)
環境構築と参考になるサイト
とりあえず実行エンジンはあればいいので，初心者的にはcwltoolを使うのがいい．これはPyPIにあるのでインストールは
pip install cwltool
でOK.実際にワークフローを実行するときは
cwltool [tool-or-workflow-description] [input-job-settings]
としよう．
どのように書くかの勉強はCommon Workflow Language User Guide(英語)とCWL Start Guide JPがまとまっていてわかりやすいと思う．
利点と欠点
まずCWLがワークフロー言語を互換するためのマークアップ型言語であることに注意しよう．これはCWLはYAMLやJSONなどのフォーマットに近いということである．当然CWLはループ処理や条件分岐などはサポートしていない(厳密には実装依存).
修正：CWLはVersion1.2から簡潔なループ処理などは必須要件としてサポートしているようです。ただあくまで単純なものなので、複雑なループ処理、条件分岐を書きたい場合は他の言語を使うべきというのは変わりません。
なぜこんなことになっているのかというと，冒頭で紹介したワークフローについての記事にあるように，CWLは異なるワークフロー言語を統合的に記述する言語であることを目指しているからである．
Goble, who is building a searchable registry of CWL workflows, says: “The CWL’s job is really to be the workflow language in common. And that’s it. It does exactly what it says on the tin.”
Nature 573, 149-150 (2019)から引用
この理念からCWL自体に実装されている機能は最大公約数的なものになっている．同様にCWLは多くの挙動が厳密にオプショナルになっており，結局どの実行エンジンを使うかに依存するところが大きい． "なんでも書けるけどなんにも書けない"といった感じ．
CWLはワークフロー記述言語のなかで大きな位置を占めているが，学習コストはかなり高め．
またマークアップ型言語は労働集約的であると言われるが，CWLも例に漏れない．CWLについて検索するとCWLユーザーの悲痛な叫びを聞くことができる．
最近先述のCromwellがCWLをサポートするようになった(が使用準拠がいまいちらしい)．
Cromwell supports the WDL and CWL workflow languages. The Cromwell team is actively developing WDL, while maintenance for CWL is primarily community-based.
Nextflow
環境構築と参考になるサイト
Javaのバージョンが8以上の環境で
curl -s https://get.nextflow.io | bash # wgetでも可
とすると，カレントディレクトリにnextflowという実行ファイルが作られるので，PATHが通っているディレクトリに移すだけ！
Docker imageもあるのでこちらを使ってもいい．
どうやって書くかは，Nextflow Tutorialにまとめてあるのでそれを見て勉強するしかない．長い...
利点と欠点
何といっても柔軟性が高く，scriptフィールドにコマンドを書くのだが，ここにはLinuxで実行可能な言語ならなんでも書くことができる．Nextflowの理念が"the Linux platform is the lingua franca of data science. "であることからもLinuxとの一貫性を重要視しているのだろう．
In practice a Nextflow pipeline script is made by joining together different processes. Each process can be written in any scripting language that can be executed by the Linux platform (Bash, Perl, Ruby, Python, etc.). こちらから引用
下のNCBIチームのページではワークフロー言語としてNextflowを採用するに至った経緯が書いてあり非常に参考になる．
欠点は，Nextflow独特の文法に慣れる必要があることだろうか．他にchannelというNextflow独特のデータ構造もあるが，こちらは使えれば強力なだけで，絶対使わなければいけないというわけではない．
Snakemake
環境構築と参考になるサイト
SnakemakeはPythonを拡張したものなのでPyPIにある．したがって
pip install snakemake
でOK.使い方はやはりSnakemake Tutorialを見るしかないが，こちらに日本語版に翻訳してくださったものがありとても参考になる．
利点と欠点
Snakemakeをmakeを拡張し，Pythonのインタプリタに読ませるようにしたものである．
利点としては，文法がPythonそのものなので非常に使いやすい．またPythonのコードを途中で挟むことができるので，少しワークフロー中に少し複雑な処理があっても対応しやすい．
学習コストが低く，かつ標準的なワークフローの機能は揃っているので，とりあえず使いたいならSnakemakeが一番向いている．作者がバイオインフォの人のこともあってか，個人的にはバイオインフォで試行錯誤しながら小さなワークフローを回していくのにとても向いていると思う．
欠点はしばしば遅いことであり，ワークフローが大きくなると依存関係を解決するのに時間を要する場合があるそうだ．
結局どの言語を使うべきか？
長くなってしまったので，結局どういった場合にどの言語を使えばいいのか私の考えをまとめる．
ワークフローの規模が非常に大きい(数日単位)場合は，例外処理・資源管理機能に強いWDLを使い，ワークフローの規模がそこまで大きくない場合は，NextflowもしくはSnakemakeを使う．
ワークフローを一般向けに公開する場合にはCWLでの実装が検討に入る．
ただし一般的な学習コストはおおよそ
Snakemake <<< Nextflow <= WDL <<<<< CWL
といった感じである．NextflowとWDLの差は日本語で解説しているサイトの数から判断した．