Git LFS からDVC(Data Version Control) に移行した話

主旨

従来、Git　LFSを用いて機械学習のデータを管理してきた。最近、その代わりにDVCを使うようになったので、その過程で感じたことを示す。DVCをどう使っていいのか、使い方に迷っている人の参考になれば幸いです。

Git LFS の状況

• 機械学習のデータを指定のフォルダ以下をファイル単位の粒度で管理できるツールである。
  • 変更があったファイル名を知ることができるし、テキストファイルの場合にはdiffを表示することもできる。
  • GithubなどでPRの差分をwebブラウザで表示させる場合には、画像ファイルの変更前と変更後とを表示させることもできる。
• 「Git LFSは、リポジトリに実際のファイルではなく、ファイルへの参照を保存することで大きなファイルを扱います」
• 通常のGitとの違いは、LFSで管理するファイルをファイルパターンで指定して、そのファイルについては、ファイルへの参照を保存するようになっています。
• github などのgitのサービスでは、2 GBを超えるリポジトリを作ってはならない制限があります。
• Git LFSを使うことで、例えば *.jpg のファイルはgit lfs track "*.jpg" とすることで、LFSに対象にすることができます。
• その結果、Git LFSを使うことで、大量なデータがあっても2GBの制約の範囲にリポジトリを留めることができます。（LFSで管理しているデータは、リポジトリとは別に容量を消費しているのは変わらない）

複数のデータセットからなるデータセットの場合

• 複数のデータセットからなるデータセットの場合に、git submoduleで管理したことがある。
• git submoduleの使い方はweb上に多数説明があるのでここでは省略する。
  • git のリポジトリの中に、他のリポジトリを含めて管理するやり方です。

git submodule, git lfs の併用は複雑さを高めすぎる。

• ある機械学習のデータセットをsubmodule で複数のリポジトリに分割すると、それぞれのsubmodule での管理と、submoduleとしての管理と、管理作業が格段に増える。
• 感想：
  • 一人で管理運用しているリポジトリだからできた作業
  • 複数名で分業して登録・改変作業をするには、おすすめしない。

DVCの導入

• DVCのサイトの例題をvideoで見てどんなことができるのか、どのような手順で行うのかを見てみよう。

DVC は何をどうするツールなのか

• 対象のフォルダをまとめて管理するツール。
• ある時点のスナップショットをリモートフォルダに保存する。
• そのスナップショットをフォルダに対するmd5sumで状態を覚えておく(*.dvc)。
• *.dvcファイル自体は、git で管理させる。
• *.dvcの値を元に、dvc pull でそのときのフォルダ構成を、リモートフォルダから再構築する。
• DVC自体は、ファイル保存のサービスを行っていない。既存のリモートフォルダサービスのどれかをユーザーが選択して利用する。（Google Drive, Google Cloud Storage, AWS(S3)など）
• ちなみに、どの時点のスナップショットでも再現できるようにしているリモートのフォルダは、DVCを介して扱えるようになっているので、DVCを介せずにアクセスしても、意味不明の状況になる。

DVCではしないこと

• ある時点でのdvc、git への登録内容と、別の時点のdvc, gitへの登録内容の比較
  • 知りうるのは、sizeとnfilesとhash値だ。
  • そのため、どのファイルが変更になったのかさえ知ることができない。

DVCをデータ管理に利用する

• DVCのビデオとDVCの公式サイトのドキュメントをたどるように設定を行うことで、DVCを利用したデータ管理を導入できた。

個人的に割り切った使い方

• 変更は、subfolderの追加を基本としよう。
• subfolderへのファイルの追加はしない。
• DVC管理下のフォルダ構成の情報は、テキストファイルに自動で保存させる。そのファイルをgit で管理する。
• そうすれば、gitで見たときに、subfolder の状況の変化がGithub上などで確認できる。
• Github のPRの中で、変更点についてのヒントを記載し、gitの側で変更状況をたどれるようにする。

DVC 以降の利点

• 参照するだけの利用者にとっての利点

$ git checkout main
$ git pull
$ dvc pull

これだけの作業で済む。
このため、git submodule, git LFS を使ったときの場合にくらべ手順が単純になる。

DVC に移行する上で必要な発想の転換

• 全ての操作において、どこをどう変更したという差分を表示して、変更点を明示的に管理しようと考えを断念しよう。
• どういう手順で、元画像を加工して学習用の画像に変換したとか経緯とかは、DVCで管理するべきではない。
• あとは利用するだけになったデータだけをsubfolderで追加するだけという単純化をした。
• dvc add; dvc push とかをする時点での対象フォルダのファイル構成・ファイルがとにかく正しいとするものである、as-is（あるがまま）のデータ管理であるというのを受け止めること。
  • 不用意に意図しない変更を対象フォルダに対してしないこと。
  • subfolderやsubfolder中のファイルを削除・破壊していても、dvcは警告をしない。

まとめ

• DVCを使うためには、Gitと発想が違うことを理解する必要がある。
• そのことを理解して運用すれば、運用の手順自体はgit submodule, git LFS を使うよりははるかに簡単である。
• git はローカルに履歴を持つので、git の管理対象が増えれば増えるほど、ローカルPCでの領域を圧迫してしまう。しかし、DVCでは*.dvcファイルをgit で登録させるだけなので、ローカルに持つ履歴が少なくなる。
• そのような違い方を理解すればDVCは使いやすい

関連記事

DVC(Data Version Control) を使って画像データセットを管理する

DVCでのデータの登録を複数人で行う場合の注意　ー 手順を間違えるとデータを失える ー