На сколько я могу ок. уменьшить объем диска с помощью DV c? - PullRequest
5 голосов
/ 23 февраля 2020

Я хочу классифицировать документы ~ 1m + и иметь систему контроля версий для ввода и вывода соответствующей модели.

Данные меняются со временем:

  • размер выборки увеличивается со временем
  • могут появиться новые функции
  • процедура анонимизации может изменяться со временем

Таким образом, в принципе, «все» может измениться: количество наблюдений, особенности и значения. Мы заинтересованы в том, чтобы сделать воспроизводимую модель ml Building без использования 10/100 + ГБ дискового тома, поскольку мы сохраняем все обновленные версии входных данных. В настоящее время объем данных составляет ~ 700 МБ.

Самый многообещающий инструмент, который я нашел: https://github.com/iterative/dvc. В настоящее время данные хранятся в базе данных, загруженной в R / Python оттуда.

Вопрос:

Какой объем диска может быть (очень приблиз.) сохранено с помощью DV c?

Если можно грубо это оценить. Я попытался выяснить, сохраняются ли только «различия» данных. Я не нашел много информации, прочитав: https://github.com/iterative/dvc#how -dv c -works или другую документацию.

Я знаю, что это очень расплывчатый вопрос. И это будет сильно зависеть от набора данных. Однако мне все равно было бы интересно получить очень приблизительную идею.

1 Ответ

6 голосов
/ 23 февраля 2020

Позвольте мне кратко описать, как DV C хранит данные, и я надеюсь, что из этого вы сможете определить, сколько места будет сэкономлено / использовано в вашем конкретном c сценарии.

DV C хранит и дедуплицирует данные на отдельном уровне файла . Итак, что это обычно означает с практической точки зрения.

Я буду использовать dvc add в качестве примера, но тот же лог c применяется ко всем командам, которые сохраняют файлы данных или каталоги в кэш DV C - dvc add, dvc run, et c.

Сценарий 1: Изменение файла

Давайте представим, что у меня есть один файл 1GB XML. Я начинаю отслеживать его с DV C:

$ dvc add data.xml

В современной файловой системе (или, если включены hardlinks, symlinks, см. this для более подробной информации) после эта команда по-прежнему потребляет 1 ГБ (даже если файл перемещен в кэш DV C и все еще присутствует в рабочей области).

Теперь давайте немного изменим его и сохраним снова:

$ echo "<test/>" >> data.xml
$ dvc add data.xml

В этом случае у нас будет 2 ГБ. DV C не делает различий между двумя версиями одного и того же файла , а также не разбивает файлы на куски или блоки, чтобы понять, что изменилась только небольшая часть данных.

Чтобы быть точным, он вычисляет md5 каждого файла и сохраняет его в адресно-ориентированном хранилище значений ключей содержимого. md5 файлов служит ключом (путь к файлу в кэше), а значением является сам файл:

(.env) [ivan@ivan ~/Projects/test]$ md5 data.xml
0c12dce03223117e423606e92650192c

(.env) [ivan@ivan ~/Projects/test]$ tree .dvc/cache
.dvc/cache
└── 0c
   └── 12dce03223117e423606e92650192c

1 directory, 1 file

(.env) [ivan@ivan ~/Projects/test]$ ls -lh data.xml
data.xml ----> .dvc/cache/0c/12dce03223117e423606e92650192c (some type of link)

Сценарий 2: Изменение каталога

Давайте теперь представьте, что у нас есть один большой каталог 1 ГБ images с большим количеством файлов:

$ du -hs images
1GB

$ ls -l images | wc -l
1001

$ dvc add images

На данный момент мы все еще потребляем 1 ГБ. Ничего не изменилось. Но если мы изменим каталог, добавив дополнительные файлы (или удалив некоторые из них):

$ cp /tmp/new-image.png images

$ ls -l images | wc -l
1002

$ dvc add images

В этом случае после сохранения новой версии мы по-прежнему приблизимся к потреблению 1 ГБ . DV C вычисляет diff на уровне каталога. Он не будет сохранять все файлы, которые существовали ранее в каталоге.

Тот же лог c применяется ко всем командам которые сохраняют файлы данных или каталоги в кэш DV C - dvc add, dvc run, et c.

Пожалуйста, дайте мне знать, если это понятно, или нам нужно добавить больше деталей, разъяснений.

...