Как бороться с управлением версиями больших объемов (двоичных) данных

Я аспирант геофизики и работаю с большими объемами графических данных (сотни ГБ, десятки тысяч файлов). Я хорошо знаю svnи gitприхожу оценивать историю проекта в сочетании с возможностью легко работать вместе и иметь защиту от повреждения диска. Я нахожу gitтакже чрезвычайно полезным для создания последовательных резервных копий, но я знаю, что git не может эффективно обрабатывать большие объемы двоичных данных.

Во время обучения в магистратуре я работал над наборами данных одинакового размера (также изображениями), и у меня было много проблем с отслеживанием разных версий на разных серверах / устройствах. Распределение 100 ГБ по сети действительно не весело, и стоило мне много времени и усилий.

Я знаю, что у других в науке, похоже, есть похожие проблемы, но я не смог найти хорошего решения.

Я хочу использовать хранилища моего института, поэтому мне нужно что-то, что может использовать «тупой» сервер. Я также хотел бы иметь дополнительную резервную копию на переносном жестком диске, потому что я хотел бы избежать передачи сотен ГБ по сети, где это возможно. Итак, мне нужен инструмент, который может обрабатывать более одного удаленного местоположения.

Наконец, мне действительно нужно что-то, что может использовать другой исследователь, так что это не должно быть очень простым, но должно быть доступно для изучения за несколько часов.

Я оценил множество различных решений, но ни одно из них не отвечает требованиям:

• SVN несколько неэффективен и нуждается в умном сервере
• hg bigfile / largefile может использовать только один пульт
• git bigfile / media также может использовать только один пульт, но также не очень эффективен
• на чердаке , похоже, нет лога или различий
• bup выглядит действительно хорошо, но для работы нужен «умный» сервер

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

Как исследователи работают с большими наборами данных, и что используют другие исследовательские группы?

Чтобы было ясно, меня в первую очередь интересует, как другие исследователи справляются с этой ситуацией, а не только с этим конкретным набором данных. Мне кажется, что почти у всех должна быть эта проблема, но я не знаю никого, кто бы ее решил. Должен ли я просто сохранить резервную копию исходных данных и забыть обо всех этих элементах управления версиями? Это то, что все остальные делают?

В конечном итоге я использую гибридное решение:

• резервное копирование необработанных данных
• мерзавец рабочего процесса
• ручные снимки рабочего процесса + обработанные данные, которые актуальны, например:
  • стандартная предварительная обработка
  • действительно много времени
  • для публикации

Я считаю, что редко бывает разумно иметь полную историю изменений большого количества двоичных данных, потому что время, необходимое для проверки изменений, в конечном итоге будет настолько огромным, что в долгосрочной перспективе оно не окупится. Возможно, была бы полезна полуавтоматическая процедура моментального снимка (в конечном итоге, чтобы сэкономить место на диске, не реплицируя неизмененные данные между различными моментальными снимками).

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

Типичный контроль версий, такой как svn и git, не подходит для этого случая, потому что он просто не предназначен для этого типа набора данных. Вместо этого мы перешли на использование решений «облачного хранилища», в частности DropBox и Bittorrent Sync, Преимущество DropBox состоит в том, что он, по крайней мере, выполняет примитивное ведение журнала и контроль версий, а также управляет серверами для вас, но недостатком является то, что это коммерческий сервис, вы должны платить за большое хранилище, и вы помещаете свои неопубликованные данные в коммерческое хранение; вам не нужно много платить, так что это приемлемый вариант. Bittorrent Sync имеет очень похожий интерфейс, но вы запускаете его самостоятельно на своих собственных серверах хранения и не имеете никакого контроля версий. Оба из них ранили мою душу программиста, но они - лучшие решения, которые мои коллеги и я нашли до сих пор.

Я использовал управление версиями в корзинах Amazon S3 для управления 10-100 ГБ в 10-100 файлах. Передача может быть медленной, поэтому она помогает сжимать и передавать параллельно или просто выполнять вычисления в EC2. Библиотека boto предоставляет приятный интерфейс Python.

Попробуйте посмотреть на Git Large File Storage (LFS) . Это новое, но, возможно, стоит обратить на это внимание.

Как я вижу, в обсуждении Hacker News упоминается несколько других способов работы с большими файлами:

• git-annex (и, например, используя его с Amazon S3 )
• Расширение Mercurual Largefiles

Мы не контролируем версию реальных файлов данных. Мы бы не хотели, даже если бы мы хранили его как CSV, а не в двоичном виде. Как сказал Риккардо М. , мы не собираемся тратить время на анализ построчных изменений в наборе данных 10M.

Вместо этого, наряду с кодом обработки, я управляю версией метаданных:

• Дата модификации
• Размер файла
• Количество строк
• Имена столбцов

Это дает мне достаточно информации, чтобы знать, изменился ли файл данных, и представление о том, что изменилось (например, добавленные / удаленные строки, новые / переименованные столбцы), не подчеркивая VCS.

Это довольно распространенная проблема. У меня была эта боль, когда я занимался исследовательскими проектами для университета, а теперь - проектами в области промышленных данных.

Я создал и недавно выпустил инструмент с открытым исходным кодом для решения этой проблемы - DVC .

Он в основном объединяет ваш код в Git и данные на локальном диске или в облаках (хранилище S3 и GCP). DVC отслеживает зависимость между данными и кодом и строит график зависимости (DAG). Это поможет вам сделать ваш проект воспроизводимым.

Проект DVC может быть легко распространен - ​​синхронизируйте свои данные в облаке (команда dvc sync), предоставьте общий доступ к своему хранилищу Git и предоставьте доступ к своей корзине данных в облаке.

«Обучаем за несколько часов» - это хороший момент. У вас не должно быть проблем с DVC, если вы знакомы с Git. Вам действительно нужно выучить только три команды:

1. dvc init- нравится git init. Должно быть сделано в существующем Git-хранилище.
2. dvc import- импортировать ваши файлы данных (источники). Локальный файл или URL.
3. dvc run- шаги вашего рабочего процесса, как dvc run python mycode.py data/input.jpg data/output.csv. DVC автоматически определяет зависимость между вашими шагами, создает DAG и сохраняет ее в Git.
4. dvc repro- воспроизведите ваш файл данных. Пример: vi mycode.py- изменить код, а затем dvc repro data/output.csvвоспроизведет файл (и все зависимости.

Вам нужно выучить еще пару команд DVC для обмена данными через облако и базовые навыки S3 или GCP.

Учебник DVC - лучшая отправная точка - «Контроль версий данных: итеративное машинное обучение»

Я не использовал их, но в финансовой группе было похожее обсуждение

предложения программного обеспечения для хранилища данных scidb , zfs, http://www.urbackup.org/

Вы можете взглянуть на мой проект под названием DOT: Менеджер хранилища Distrubuted Object Tracker.
Это очень простая VCS для двоичных файлов для личного использования (без совместной работы).
Он использует SHA1 для проверки контрольных сумм и дедупликации. Полная синхронизация P2P.
Одна уникальная особенность: adhoc одноразовый TCP-сервер для pull / push.
Он также может использовать SSH для транспорта.

Это еще не выпущено, но могло бы быть хорошей отправной точкой.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/

Вы можете попробовать использовать ангар . Это относительно новый игрок в мире контроля версий данных, но он делает действительно хорошую работу, выполняя версионирование тензоров, а не версионирование BLOB-объектов. Документация должна быть лучшим местом для начала. Поскольку данные хранятся в виде тензоров, вы должны иметь возможность использовать их непосредственно внутри своего кода ML (плюс в ангаре теперь есть загрузчики данных для PyTorch и Tensorflow). С помощью ангара вы можете получить все преимущества git, такие как разветвление с нулевой стоимостью, слияние, путешествие во времени по истории. Хорошая особенность клонирования в ангаре - это возможность частичного клонирования . Это означает, что если у вас есть 10 ТБ данных на вашем удаленном компьютере и вам нужно только 100 МБ для создания прототипа вашей модели, вы можете получить только 100 МБ с помощью частичного клонирования вместо полного клонирования.