想定する読者：
画像データセットを管理して共有する必要に迫られている人
前提：
- gitは使ったことがある。
- 社内のwindowsサーバーをZ:ドライブとしてアクセスできる
- フォルダやファイル名にスペースを含めないで管理している。
管理済みのデータを利用する
DVCを使っているリポジトリを見てみる。
$ git clone リポジトリ
$ cd 生成されたフォルダ名
$ dvc pull
$ ls 生成されたサブフォルダ
こういう流れになります
管理済みのデータを利用する人に必要なもの
git
dvc
DVCのデータの保管先へのアクセス権
dvc コマンドがインストールされていないときは
、pythonの環境でpip install dvc をします。
身近に、dvcで管理済みのリポジトリがあれば、dvc pullまでの流れをたどってみましょう。
dvc pull に失敗する場合
- データは、あなたがアクセスできるようになっているのかを確認します。
- dvc remote がどこにあるのかそのURLを確認します。
- 社内のwindowsサーバーなのか、AWSやGoogle Cloud Storageなどの外部のクラウドサービスなのか、
- どちらであっても、あなたのアクセス許可を発行してもらえていることが前提です。
- 社内のサーバーの場合には、その管理者に問い合わせてくだい。
- AWSやGoogle Cloud Storageなどの外部のクラウドサービスを社内で利用している場合には、そのDVCのリポジトリの運用者に設定を聞いてください。
データ管理の環境構築後にデータの追加者が行うこと
git checkout main
git pull
dvc pull
git checkout -b feature/ブランチ名
# 対象フォルダにデータを追加します。
dvc add 対象フォルダ
git add 対象フォルダ.dvc
# README.md を編集して何を追加したのかを加筆するといいでしょう。
git add README.md
git commit -m "メッセージ"
git push
dvc push
Githubのリポジトリで
上記のコミットからPRを作り、マージする。
すでに、DVCの設定が済んであれば、データの追加処理は簡単なことです。
大事なことは、データの登録の作業は、一箇所に集中させることです。
異なる作業者・異なるPCからの作業は、データ処理の一貫性を損ないがちです。
データ管理の環境構築をする人
DVCへの導入の不安は、以下の複数の要因あるだろう。
- まわりにDVCを使ったことが少ないこと
- データを壊してしまったらどうしよう
- AWSやGoogle Cloud Strorageなどの有料のサービスを使わなきゃいけないんだおうか。
- 作った環境を社内のメンバーがちゃんと利用・引き継いでくれるだろうか
DVCの環境構築の始め方
- 身近にDVCの環境構築をした人が入れば、その人に聞くのがいちばん。
環境構築済みのDVCのリポジトリは何がどう設定されているのか
- 使えているDVCの状況
.dvc/config
どのフォルダを管理しようとしているのかの記載
それに対するリモートをどこに設定しようとしているのかの記載
.dvcignore
DVCで管理しなくてもいいものの記載
環境構築前に決めておくこと
-
ほんとうにDVCが適したデータですか？
-
データによっては、SQLなどのデータベースの方が適しているということはないですか。
-
そのデータセットの利用目的
利用目的の異なるものを同一のデータセットとして管理するのは、間違いの始まり。
利用目的が異なるものは、別のDVCのリポジトリとして管理するのがいい。
git pull; dvc pull したあとのディスクの消費量巨大にならないようにする。 -
データ管理するフォルダ名
-
フォルダの階層構造
-
そこに含めるファイルの種類
-
データ管理しなくてよいものをはっきりさせる。
簡単に再計算できるものはバージョン管理する必要がない。 -
データの保存先
-
AWS, Google Cloud Storage、 社内のWindowsサーバーのどれにするのか
以下のような処理の流れとなります。
dvc add するフォルダ名やgit add する*.dvcファイル名は、あなたの事例に合わせて書き換えてください。
git init
dvc init
git add .dvc .gitignore
git commit -m "Initialize DVC"
dvc add data/raw_data.csv
git add data/raw_data.csv.dvc .gitignore
git commit -m "Add raw_data.csv with DVC"
dvc remote add -d myremote <ストレージURL>
# 認証情報など設定
dvc push
Github でテンプレートリポジトリを作っておくと便利
DVCでの画像の管理は
対象のフォルダ名の違い、階層構造の違いくらいしかない。
dvcを便利に使いたいための設定は共通であることが多い。
だから、githubでそれらをテンプレートリポジトリ化しておくと便利だ。
画像ファイルのフォルダをDVCで管理して欲しくなるツールの例
- Githubに反映させる範囲に、フォルダ構成やファイル数などが表示できるようにさせたい。
- 登録している画像ファイルがopencvなどで読めることの確認ができるツール
DVCでデータを管理することの利点
Git の考え方：
ネットワークに接続していない状況でもgitでデータを管理できることを前提としています。
例：過去の履歴のリビジョンに戻ることが、ネットワークに接続していない状況でもできる。
例：ブランチをローカルで操作している限り、いくらでもロカールのブランチにコミットできる。PRを作成してgit push しない限り（もしくはgit push を更新しないかぎり）、ネットワークに接続しないで作業を継続できる。
- Gitで管理することの代償
- 過去の履歴のリビジョンを復元できるようにするためには、そのための.git/の下に大量のデータを持っている。
- そのために、ローカルのPCのディスクスペースを圧迫してしまう。
- これはGit LFSを用いても生じる問題である。
DVC の考え方
- DVC でデータを取得するのは、DVCのデータが保存されている先のネットワーク（もしくはローカルドライブ）に接続されているときだけにしています。
- そのため、大量のデータの履歴データをローカルPCに保存する必要がありません。
- DVC では、Gitが管理するのは、対象フォルダのハッシュ値だけです。そのハッシュ値を元に、DVCデータの保存先からリポジトリのデータフォルダに復元します。
恩恵
- ローカルに大量の履歴データを持たないので、ローカルPCのディスクを大量に消費することがなくなります。