質問:
分析中にコードとデータをバージョン管理するにはどうすればよいですか?
Iakov Davydov
2017-05-18 14:27:51 UTC
view on stackexchange narkive permalink

現在、研究でコードとデータの両方をバージョン管理できるシステムを探しています。

データを分析する方法は珍しくないと思います。これは、多くの人がバイオインフォマティクスを行い、再現性を目指しています。

要件は次のとおりです。

  • 分析は複数のマシン(ローカル、クラスター、サーバー)で実行されます。
  • すべてのコードはマシン間で透過的に同期されます。
  • ソースコードのバージョン管理。
  • 生成されたデータのバージョン管理。
  • 多数の小さな生成ファイルのサポート(> 10k)。これらも削除される可能性があります。
  • 大きなファイル(> 1Gb)のサポート。ある時点で、古い生成ファイルは完全に削除される可能性があります。それらを透過的に同期するのは非常識ですが、オンデマンドで同期できると便利です。

これまでのところ gitを使用しています + rsync / scp。ただし、いくつかの欠点があります。

  • 複数のマシン間の同期は少し面倒です。つまり、作業を開始する前にgit pullを実行し、更新のたびにgitpushを実行する必要があります。私はそれで生きることができます。
  • リポジトリ内に生成された大きなデータファイルや多数のファイルを保存することは想定されていません。
  • したがって、rsyncを使用してデータファイルを手動で同期する必要があります。これはエラーが発生しやすいです。

git annexと呼ばれるものがあります。それは私が必要としているものに本当に近いようです。ただし、:

  • gitよりも少し手間がかかりますが、問題ありません。
  • 残念ながら、多数のファイルではうまく機能しないようです。多くの場合、分析には1万を超える小さなファイルがあります。 インデックス作成を改善するにはいくつかのトリックがありますが、それでも問題は解決しません。必要なのは、ディレクトリの全内容を表す1つのシンボリックリンクです。

1つの考えられる解決策は、Dropboxまたは同様のもの( syncthingなど)をgitと組み合わせて使用​​することです。ただし、欠点は、ソースコードバージョンとデータバージョンの間に接続がないことです。

推奨できる要件を満たすコードとデータのバージョン管理システムはありますか?

それはあなたが探しているものではなく、私がフルタイムで使用する立場でもありませんが、私は `chitin`と呼ばれるソフトウェアを書いています:https://github.com/SamStudio8/chitin /。これは、ファイルがどのように作成され、ファイルに何が起こったかを追跡するように設計されています。変更(gitなど)を保存するようには設計されていませんが、実際には、メタデータは実際の変更よりもはるかに便利です(もちろん、gitに存在するコードは別として)。
@SamStudio8は面白そうです。私はまだ完全には確信していませんが、私見は答えとして投稿する価値があります。
これに対する通常のアプローチは、さまざまなマシン(ローカル、クラスター、サーバー)にエクスポートされる単一のディレクトリを持つことです。一元化されたリポジトリを使用するのではなく、なぜこの方法でデータを複製するのでしょうか。
@terdonは、多くの場合、クラスターにルートアクセス権を持っていないため、ネットワークファイルシステムをそこにマウントすることはできません(パフォーマンスのために望まない小さなファイルや大きなファイルが多数ある場合)。他の意味では、これはsyncthing / dropboxソリューションに似ており、適切なバージョン管理とソースコードとデータ間の対応が欠けています。
さて、GBのデータを同期する必要がある場合は、間違っています。ルートアクセスが必要な場合は、sysadminに、ドライブを共有できるようにシステムをセットアップするように依頼します。私があなたが説明したように誰かが働いているのを見たことがありません。私が働いた3つの場所はすべて、常に共有ネットワークドライブを持っていました。または、 `sshfs`を使用して、rootアクセスを必要とせずに自分でマウントすることもできます。ネットワークI / Oの負荷は確かに要因ですが、データをローカルドライブにコピーし、分析後に削除することがあります。
@terdonの複数の小さなファイルも、ほとんどのネットワークファイルシステムの問題です。ギガバイトのデータを同期することは必ずしも良い考えではありませんが、避けられない悪の場合もあります(git annexは自動的に同期しないことに注意してください。それで問題ありません)。私の大学には非常に多くの生物情報学グループが非常によく似た問題を抱えているのを目にします。少なくともそれは珍しいことではありません。 `sshfs`はオプションですが、これもネットワークファイルシステムです。そして、多くのクラスターでは、fuseはカーネルで利用できません(私が知っている最大のバイオインフォマティクスのみのクラスターの1つである私たちを含みます)。
@terdon,に同意する必要があります。複数のノード間で多数の大きなファイルを同期する必要がある理由はありません。ネットワークストレージドライブをマウントするためのルートアクセス権がない場合は、それを取得する必要があります。そのファイル同期はすべてネットワークを詰まらせるため、管理者はこれを回避する必要があります。ファイルの複数のコピーを保持することは災害のレシピです。これは絶対に避けてください。
@woemler私は十分に明確ではなかったようです。データのギグの透過的な同期は必要ありません。これをバージョン管理して取得できるようにしたいだけです。質問を更新して明確にしました。また、ネットワークfsに10万個の小さなファイルを保持することは、災害のレシピでもあります。とにかく、大きなファイルの問題はgitannexで簡単に解決できます。小さなファイルはもっと複雑です。
セブン 答え:
#1
+14
Michael Schubert
2017-05-18 21:57:58 UTC
view on stackexchange narkive permalink

ここで考慮すべき点がいくつかあります。以下に概要を示します。ここでの目標は、すでに git を使用していることに加えて、煩わしさを最小限に抑えるワークフローを見つけることです。

現時点では、すべてのユースケースをカバーする理想的なワークフローはありませんが、以下に概説するのは、私がそれに到達できる最も近いものです。

再現性はすべてのデータを保持するだけではありません

プロジェクトを開始するための生データがあります。

プロジェクトディレクトリ内の他のすべてのデータは、単に「そこにある」だけでなく、どこから来たのかを記録する必要があります。データ処理スクリプトは、生データから分析データ、そして分析に必要なファイルへの移行方法をすでに文書化しているため、これに最適です。

そして、これらのスクリプトは次のことができます。適切な単一の処理エントリポイント(スクリプトの実行方法を説明する Makefile など)を使用してバージョン管理されます。

このようにして、すべてのプロジェクトファイルの状態が定義されます。生データ、および処理スクリプトのバージョン(および外部ソフトウェアのバージョンですが、これはまったく異なる種類の問題です)。

バージョン管理する必要があるデータ/コードとバージョン管理しないデータ/コード

生成されたコードファイルをバージョン管理しないのと同じように、分析の実行時に作成した10kの中間データファイルをバージョン管理しないでください。 バージョン管理する必要があるデータは生データ(パイプラインの開始時)であり、自動生成されたファイルではありません。

取得することをお勧めしますプロジェクトディレクトリのスナップショット。ただし、これまでに作成されたすべてのファイルのすべてのバージョンを保持するわけではありません。これにより、問題はすでにかなり削減されています。

アプローチ1:データの実際のバージョン管理

生データまたは分析データの場合、 Git LFS(または既に言及した Git Annex)は、これを正確に解決するように設計されています問題:Gitツリーにファイルの追跡情報を追加しますが、それらのファイルのコンテンツをリポジトリに保存しないでください(そうしないと、変更を加えるたびに差分不可能なファイルのサイズが追加されるためです)。

中間ファイルの場合は、中間コードファイルの場合と同じように、 .gitignore に追加し、バージョン管理しないでください。

これにはいくつかの考慮事項があります。

  • GitLFSはGithubの有料サービスです(無料利用枠は1か月あたり1 GBのストレージ/帯域幅に制限されており、ごくわずかです)。また、他の同等のクラウドストレージソリューションよりも高価です。 Githubでストレージの料金を支払うか、独自のLFSサーバーを実行することを検討できます(リファレンス実装がありますが、これはまだかなりの労力になると思います)
  • Git Annexは無料ですが、ファイルを次のように置き換えます。リンクし、タイムスタンプを変更します。これは、たとえばGNU Makeベースのワークフロー(私にとっての大きな欠点)。また、ファイルのフェッチは手動またはコミットフックを介して行う必要があります

アプローチ2:バージョン管理コードのみ、データの同期

分析データが同じままの場合ほとんどの分析では、(バックアップしてデータの出所を文書化するのではなく)実際にバージョン管理する必要が限られている場合があります。

これを機能させるための鍵は、すべてを配置することです .gitignore のstrong>データファイルと rsync のすべてのコードファイルを無視し、プロジェクトルート(拡張機能とディレクトリは一例にすぎません):

 #!/ bin / bashcd $(dirname $ 0)rsync -auvr \ --exclude "* .r" \ --include "* .RData "\ --exclude"ローカルで必要のない巨大なファイルを含むdir "\ yourhost:/ your / project / path/*。 

ここでの利点は、実行している rsync コマンドを覚えておく必要がないことです。スクリプト自体がバージョン管理に入ります。

これは、コンピューティングクラスターで重い処理を行うが、ローカルマシンの結果ファイルからプロットを作成する場合に特に便利です。私はあなたが一般的に双方向同期を必要としないと主張します。

ちなみに、少なくともbiomakeではタイムスタンプの代わりにファイルハッシュを使用できます(doi:10.1093 / bioinformatics / btx306)。
@IakovDavydov私はこれを知っていますが、それが機能するかどうか実際に試していません
生データのすべての変更に対する+1は、ファイルハッシュに対する+1として文書化する必要があります。私は自分自身が読み書きのできるプログラミングの大ファンであり、そのアプローチを利用して、分析に使用したツール/パッケージのバージョンと生データのハッシュを文書化しました。したがって、私が結果またはプロットを見るとき、私はその生産の文脈も持っています。
#2
+9
Sam Nicholls
2017-05-18 14:51:52 UTC
view on stackexchange narkive permalink

あなたの質問はややオープンですが、興味深い議論になると思います。作成したデータを git に保存する価値があるとは思わないことがよくあります。お気づきのとおり、これは大きなファイル用には設計されておらず( git-lfs もありますが)、 BAM などのバイナリ形式用には設計されていません。

ファイルが作成された方法と、それ以降にファイルに対して何が行われたかが重要であると私は考えています。作成に多大な労力を費やした大きなファイルは、どこかにミラーリングする必要があります(ただし、必ずしもバージョン管理システムにミラーリングする必要はありません)。失われたり、破壊されたり、その他の方法で汚染された他の重要性の低い(または作成が難しくない)ファイルは、それらがどのようになったかを知っている限り、再生成できます。

その価値について、私は chitin と呼ばれるソフトウェアの一部に取り組んでいます(無秩序な生物情報学者のためのシェルとして自己記述されています)。また、これが私にとって必要なプロジェクトであると思った理由について長いブログ投稿を書きましたが、主な理由は、ファイルシステムを整理して実験の優れたアーカイブを作成しようとしたにもかかわらず、時間の経過とともに省略形のディレクトリ名の意味や、どのプログラムがどのデータを生成したかを忘れてください。

chitin の目標は、コマンドの実行中にファイルシステムに加えられた変更を自動的にキャプチャすることです。 。特定のファイルを再作成するために実行するコマンド、そのファイルを使用したコマンドを認識しており、そのファイルがいつ、なぜ変更されたのか(そして誰が変更したのか)もわかります。

完了していません。 (何もありません)が、実際にはすべてのデータとそのバージョンを保存したいので、間違った道を進んでいるのではないかと思います。ほとんどの人は、変更を引き起こしたコマンドを知りたいだけだと思います。データ履歴が重要である(そしてコードが適切にバージョン管理されている)場合は、コミットをチェックアウトし、分析を実行してデータを再生成するだけです。

申し訳ありませんが、私はこれに反対票を投じています。興味深い議論のポイントですが、OPの質問には答えていません。
#3
+6
Daniel Standage
2017-05-21 12:27:58 UTC
view on stackexchange narkive permalink

まず、バージョニングを真剣に受け止めてくれたことを称賛します。この問題に注意しているという事実は、責任ある研究を行いたいという良い兆候です!

多くのバイオインフォマティクスプロジェクトでは、データファイルが非常に大きいため、gitなどのツールを使用してデータを直接バージョン管理できます。実用的ではありません。しかし、あなたの質問は実際にはいくつかの異なる問題に直面しています。

  • どのように再現性のある調査を行い、各データポイントと生成した結果の完全な証明を示すのですか?
  • 複数のマシン間で調査作業を管理および同期するにはどうすればよいですか?

簡単な答え

  • プライマリデータをアーカイブします。
  • ワークフローをバージョン管理下に置きます。
  • 大きなデータファイルのバージョンチェックサム。
  • GitHubを使用して、マシン間でワークフローを同期します。

長い答え

プライマリデータをアーカイブします

再現性に関する限り、最も重要なのは一次データです。つまり、機器から収集した未処理の未処理データです。他の人が公開したデータを分析している場合は、主要な公式ソースからデータをダウンロードするタスクを自動化するスクリプトを作成し、そのスクリプトをバージョン管理下に置きます。

ラボの仲間または同僚がデータを作成し、まだ公開されていない場合は、アーカイブに送信する計画がすでにあるはずです。実際、ほとんどの雑誌や資金提供機関は、出版前にこれを要求しています。データが収集されたらすぐに提出する必要があると言っても過言ではありません。科学者はデータが盗まれたりアイデアがすくわれたりすることを心配していますが、統計的に言えば、だれもデータに触れたり論文を読んだりする可能性ははるかに低いです。しかし、あなたやアドバイザーが主張する場合、ほとんどのデータアーカイブでは、裏付けとなる原稿が公開されるまで、長期間にわたってデータを非公開にすることができます。

(たとえば)Fastqファイルをgitリポジトリに配置することは、多くの理由から悪い考えです。大きなファイルをサポートするホスティングサービスはありません。gitは大きなファイルでは非常に遅くなりますが、最も重要なのはgit / GitHubがアーカイブではないことです。適切なデータアーカイブを使用してください!

ワークフローをバージョン管理下に置きます

生データを読み取り専用として扱います。スクリプトを使用して生データのみを処理し、これらのスクリプトをバージョン管理下に置きます。 Vince Buffaloは、彼の著書 Bioinformatics Data Skillsでこれについて詳しく説明しています。チェックしてください!

大きなデータファイルのバージョンチェックサム

追跡したいがバージョン管理下に置くには大きすぎるデータファイルがある場合は、チェックサムを計算してこれらはバージョン管理下にあります。チェックサムは非常に小さい英数字の文字列であり、すべての実用的な目的で、各データファイルに固有です。したがって、その5GBのトリミングされたFastqファイルまたは7GBのBAMファイルをバージョン管理下に置く代わりに、それらのチェックサムを計算し、チェックサムをバージョン管理下に置きます。チェックサムはファイルの内容を教えてくれませんが、ファイルの内容がいつ変更されたかは教えてくれます。

これにより、分析のすべてのデータポイントについて完全な開示と完全な来歴が得られます。ワークフローには、一次データをダウンロードするためのスクリプト/コマンド、データを処理するためのスクリプト/コマンド、および中間および最終出力ファイルを検証するための署名として機能するチェックサムがあります。これにより、誰でも分析を再現できるようになります!

GitHubを使用してワークフローをマシン間で同期します

ワークフローがすでにgitでバージョン管理されている場合は、これをプッシュするのは簡単です。 GitHub、GitLab、BitBucketなどのホスティングサービスに。次に、 git push git pull を使用して、さまざまなマシンでコードを最新の状態に保つだけです。

#4
+5
H. Gourlé
2017-05-18 17:46:13 UTC
view on stackexchange narkive permalink

Open Science Frameworkはすべてのファイルにバージョン管理を使用し、無料で使用できます: https://osf.io

次のようなさまざまなソースからのデータまたはコードを統合できます。 github、dropbox、googleドライブ、figshare、amazonクラウド

OSFデータストレージを使用してサーバーにファイルを保存することもできますが、ファイルサイズの制限が正確にはわかりません。

#5
+4
Ian Sudbery
2017-05-19 14:33:59 UTC
view on stackexchange narkive permalink

これに対処する方法は次のとおりです。

  • すべての作業はクラスターにマウントされた単一のファイルシステムで行われます
  • このファイルシステムはsshfsを介してローカルマシンにマウントされます/ samba(ネットワーク上の現在の「ローカル」マシンの場所によって異なります)。
  • コードはgitハブでバージョン管理されます
  • すべての計算は軽量の自動パイプラインを介して実行されます。社内のユーティリティレイヤーと組み合わせてruffusを使用します。パイプラインに別のステップを追加する作業が手動で実行するよりも多くない限り、システムは実際には重要ではありません。
  • 疑わしい設計上の決定はすべて、構成ファイルにエンコードされます。これらの構成ファイルは、パイプラインによって出力された非常に詳細なログ(何が実行されたか、コード実行のgit commitは何か、実行されたファイルのタイムスタンプは何であったかなど)および初期入力ファイルは次のとおりです。バージョン管理されています。
  • これの利点は、コード+構成+時間=出力です。何かが変更されるたびにパイプライン全体が再実行されることは期待されていませんが、パイプラインは何かが古くなっているかどうかを通知し(タイムスタンプまたはファイルハッシュを使用できます)、公開前にすべてを一度に実行できます。
  • その他の分析は、juptyerノートブックで実行されます。これらはバージョン管理されています。

要約すると、複数のCPUロケーションを使用している場合でも、1つのディスクロケーションからしか作業しないため、同期しません。バージョン管理:

  • コード
  • 入力、構成、ログ
  • Juptyerノートブック

ログには現在の出力を生成するために使用されるgitcommit。

興味深いイアン、これは私が目指している種類のデザインですが、実際には実行されていません。ラッファスの上にあるこの社内レイヤーに興味がありますが、それは何ですか?
秘訣は、パイプラインタスクの記述をクラスタージョブ送信スクリプトよりも簡単にすることです。ユーティリティレイヤーはCGATPipelines(www.github.com/CGATOxford/CGATPipelines)によって提供されます
#6
+3
woemler
2017-05-18 18:44:31 UTC
view on stackexchange narkive permalink

バージョン管理コードにGitを使用することは良い習慣ですが、大きなデータファイルのバージョン管理には適していません。複数のノード間でデータを手動で同期すると問題が発生します。この同期を管理環境で自動的に処理するか、ネットワークに接続された単一のストレージデバイスにファイルを保持するだけです。

1つのツール調べたいのは Arvadosです。これは、複数のマシン間でバイオインフォマティクスデータとワークフローを同期するために設計されています。プロジェクトのウェブサイトから:

Arvadosは、ゲノムデータやその他のビッグデータを保存、整理、処理、共有するためのプラットフォームです。このプラットフォームは、データサイエンティストが分析を開発し、開発者がゲノムWebアプリケーションを作成し、IT管理者が大規模なコンピューティングおよびストレージゲノムリソースを管理しやすくするように設計されています。プラットフォームは、クラウドまたは独自のハードウェアで実行するように設計されています。

Arvadosを使用するのは、それが以前よりもはるかに良くなった場合のみです。
@nuin:具体的に何が不足していると思いますか、および/またはOPの問題の解決策として適切でないと思いますか?
@woemier最近は試していませんが、正しく覚えていれば、簡単なことをセットアップして実行するのはPITAでした。しかし、私が言ったように、良くなったかどうかはわかりません。
#7
+3
weiji14
2018-03-27 08:17:13 UTC
view on stackexchange narkive permalink

この回答は、ビッグデータの部分、つまり100MBを超えるもののみを対象とし、分析パイプラインがPythonエコシステムと連携している場合にのみ適用されます。少し学習する必要があります

「データのドッカー」( Githubページ)のようなキルトを使用してみてください。

  $ pip install quilt $ quilt install uciml / iris -x da2b6f5#短いハッシュに注意$ python>>> from quilt.data.uciml import iris#データがあります 

長所:

  • パブリックパッケージにはファイルサイズの制限がないようです(ただし、これをストレステストしていません)
  • 再現性を確保するためにデータをハッシュします
  • バージョン管理とタグのサポート

短所:

  • プライベートデータの保存は、ユーザーあたり月額7ドルから最大1TBのデータまで li>
  • この時点でのみPythonのほとんどが使用されており、一部のコミュニティでは Rのサポート

詳細はこちらです。



このQ&Aは英語から自動的に翻訳されました。オリジナルのコンテンツはstackexchangeで入手できます。これは、配布されているcc by-sa 3.0ライセンスに感謝します。
Loading...