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

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との相性が悪いという問題を回避できる。

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

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