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

想定する読者：
画像データセットを管理して共有する必要に迫られている人

前提：

• gitは使ったことがある。
• 社内のwindowsサーバーをZ:ドライブとしてアクセスできる
• cloud Storageのどれかを利用できる。
• フォルダやファイル名にスペースを含めないで管理している。

管理済みのデータを利用する

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のディスクを大量に消費することがなくなります。

DVCのStrage先をクラウドストレージにする。

• DVCのストレージ先をGoogle Cloud Storageなどにする。
• 利点：
• データのバックアップ作業を社内の工数を割かなくて良くなる.
• ハードウエアが損傷する危険についての心配をしなくてよい。
• ファイルの転送がマルチスレッドで実行される。
• NASはDVCとの相性が悪いという問題を回避できる。

その他こまごまとしたこと

windows PCの場合：

• C:ドライブのディスク領域はなにかと不足しやすい。
• そのために、DVCが利用するキャッシュ領域はC:ドライブではない別のディスク領域に設定したい。
• そのための設定は .dvc/cofig.localに記載する。
• .dvc/configはgit の管理対象。
• .dvc/config.localはgitの管理対象には含めない。
• この設定は、リポジトリの利用者によって変わるので、git の管理下にはおかない。

各種クラウドストレージに関連して

• 各種クラウドストレージには、アクセスするための認証が必要になる。
• それらの認証に関する設定は、Gitのリポジトリにはおかないこと
• それらが漏れれば、クラウドストレージが不正アクセスされてしまいます。

DVC入門ガイド - バイナリデータ管理

付記 DVC を新規に導入する人の場合、LFSを使わないので、以下の記事では役に立たないことに気づいた。

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