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

主旨

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

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

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

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

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

$ git checkout main
$ git pull
$ dvc pull

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

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

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