CWLを半年ちょい触ってみて思ったアレコレ

# 自己紹介

@kmoooooog です。
博士号取得後民間で機械学習エンジニアやってたのですがアカデミアに舞い戻り、今年の二月からはJAMSTECでメタゲノム解析をやっております。

また、その他の活動として株式会社tayoの代表として「イケてるJREC-IN」みたいなサービスである https://tayo.jp を作っておりますのでそちらもよろしくお願いいたします。[取材記事。](https://startuptimes.jp/2019/12/02/136596/)

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">何を書くかは決めていませんが、読むほうはバイオインフォ業界みんな気になるワークフローエンジンに関する知見とかの記事がだれか書いてくれたらうれしいなあとか思っていたりします。</p>&mdash; Ken Kuroki (@enuroi) <a href="https://twitter.com/enuroi/status/1194221022523715589?ref_src=twsrc%5Etfw">November 12, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

後輩がこんなことをつぶやいていたのでじゃあここ最近使ってたcwlについてなんか書くかなと思って登録したら、

https://qiita.com/advent-calendar/2019/workflow

もっとふさわしいやつがありましたので、詳しく知りたい方はそちらでお願いします。こちらではレベル低めの記事をお送りいたします。

# CWLとの出会い

CWLにいくまでいくつかのワークフローエンジンを検討しました。メタゲノムなので特殊なやつが混じってます。

- snakemake (pythonのパイプライン構築ツール)
 - 留学先のラボで使っていたのだが最近下火っぽかったのでやめた

- MOCAT2 (メタゲノム特化のパイプライン)
 - TARA projectで使われているがメンテされていない
 - インストールすらできなかった

- NG-meta-profiler (メタゲノム特化の言語)  
 - 習得コスト高そう & あまりに開発始まったばっかでちょっと使うの不安

- luigi (pythonのパイプライン構築ツール)
 - 前職で使っていたので最初はこれを使っていた

- cwl
 - luigiと比べた結果これにした

# luigi vs CWL

- luigi
 - pythonのパッケージ
 - pythonなのでなんでもできちゃう(->なんでもできるとコードが汚くなる。)
 - spotifyが作っていて基本はインダストリで使われる用なので、僕の用途的には機能がtoo much
 - spotifyが作っているためチュートリアルの例が「再生回数データからのトップヒット曲の解析」とかで全然頭に入ってこない

- CWL
  - ただのyaml
  - できることの制限が多い一方、書き方がガチガチに決まっているのでコードが汚くなりにくい
  - やれることが少ないのでラーニングコスト低め
  - バイオインフォ業界だと一番使われてるっぽい

総じてpythonでやりたい、かつpythonで綺麗なコード書ける人はluigiで、プログラミングに対するこだわりが薄く「楽にかければなんでもいい」的なノリの人にはcwlに軍配上がるんじゃないでしょうか。
機械学習の人がluigi好きなのもその辺が理由でしょう。

cwlに満足したのであんま調べてないですが、周りの話を聞く限り `nextflow` も良さそうな気がしています。

# cwlでできないこと

cwlでは一つ一つの処理(ソフトウェアやコマンド)に関して

- コマンド
- 入力ファイル
- 出力ファイル
- 要求するパラメータ

を書いたyamlを用意し、それを

- 実行順
- パラメータの指定
- 入力ファイルのパス
- 出力ファイルのパス

などを指定したworkflowファイルとしてまとめていきます(これもyamlです)。

このような特性上、苦手なこととして以下のようなものがあります。

- if文やfor文による分岐
 - 出力ファイルや入力ファイルの性質により処理を分ける、とかができない
 - 無理やりやるならpythonとかシェルでちっちゃなワークフロースクリプト書いて繋げるとか苦しい感じになる
 - yamlの内部にスクリプト埋め込む黒魔術もあるらしいですが多分やめたほうがいい
- パイプによる結合
 - `cat hoge | grep "piyo" > out` とかする場合でもcatとgrepでそれぞれyaml作って繋げる、とかしなきゃいけない

パイプの方は慣れればなんということはないですが、分岐の方は多少不便に感じる時はあるかもしれません。
でかいパイプラインで、いっぱい分岐があるよーなものを組むなら一直線の処理系をそれぞれworkflowとして切り出して、そのラッパースクリプトを別に書くとかしなきゃいけないかもしれませんが、まぁそんなん組もうとしたらどんな方法でも苦しくはなるかと思います。

この辺はそもそもパイプライン自体の苦しみとも関わってくるので、そのあたりはantiplastics さんの以下の記事を参考にしてください。

https://qiita.com/antiplastics/items/1f2221332ea509af3328

ぼくのモチベだとあんまりこの辺りが問題にはなりませんでした。

# cwlのイケてるところ
 - `rabix composer` というcwl用のIDEみたいなやつがとにかくイケてます
 - [阪大医学部python会のHPの動画](https://www.google.co.jp/amp/s/pythonoum.wordpress.com/2018/12/07/common-workflow-language%25E5%2585%25A5%25E9%2596%2580/amp/)とかを見ると最高っぽさがわかると思います

# ジョブスケジューラとの相性

cwlは最高なのですが、ぼくが一番苦しみ感じてるところはスパコン使う上で避けられないジョブスケジューラー(UGEとか)との兼ね合いです。具体的には、「どの粒度でqsub投げるねん問題」というのが生じます。

よくあるメタゲノムの解析フローだと、例えばサンプルが200あったときに、前処理はqsubを200回やって並列に処理する→前処理後のデータをマージしたものに関してはqsub一回、みたいに処理の粒度が変わってきます。

パイプライン化する粒度はどうしてもqsub投げる粒度になってしまうので、ワークフロー一個にまとめる、とかはなかなかできません

マッピングなど、マージしたデータに対して個々のデータを並列処理することとかもよくあるので、この辺はワークフローいっぱいできちゃいます。qsubのコマンドとかは実行環境に依存するので、スクリプト公開したとしても「コマンド一発で全部の処理走ります！」という状況にはできないのも辛いところです。

# visualizeとの相性

データの可視化はだいたい自動化できずアドホックにやることになるんですが、そうするとパイプラインに組み込むためには「ビジュアライズのためのテーブル作成」のスクリプトと「とにかく見た目をいじるスクリプト」とかを分ける必要とかが出てきます。具体的にはPCAとかNMDSとかすかね。主成分ごとのテーブル作る、まではパイプラインに入れ込むみたいな感じになるかと思います。

# 終わりに

いかがでしたでしょうか？

なんかつらつらと書きましたが、昔書いたシェルとかpythonで書いたクソスクリプトを見返して2年前の自分を殺したくなったことがある人にとって、cwlは本当に最高なツールだと思います。

国内に強力なコミュニティがあるのもいいところなので、興味あるけどよくわからない方は、[workflow meetup](https://github.com/manabuishii/workflow-meetup/wiki/20190327)とかに顔出して強い知り合いを作るとかもいいかと思います。