Як боротися з контролем версій великої кількості (бінарних) даних

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

У своїх магістерських роботах я працював над наборами даних однакового розміру (також зображень) і мав багато проблем із відстеженням різної версії на різних серверах / пристроях. Відмінність 100 Гб по мережі насправді не задоволення, і це коштувало мені багато часу і сил.

Я знаю, що схожі проблеми мають і інші в науці, але я не зміг знайти хорошого рішення.

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

Нарешті, мені дуже потрібно щось, що може використовувати інший дослідник, тому це не потрібно бути надто простим, але має бути вивченим за кілька годин.

Я оцінив багато різних рішень, але жодне, здається, не відповідає законопроекту:

• svn дещо неефективний і потребує розумного сервера
• рт.ст. большой_файл / largefile може використовувати тільки один пульт дистанційного керування
• git bigfile / media також може використовувати лише один пульт, але це також не дуже ефективно
• Мабуть, горище не має журналу чи інших можливостей
• bup виглядає дійсно добре, але для роботи потрібен "розумний" сервер

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

Як дослідники поводяться з великими наборами даних та які інші дослідницькі групи використовують?

Щоб було зрозуміло, мене насамперед цікавить, як інші дослідники поводяться з цією ситуацією, а не лише з цим конкретним набором даних. Мені здається, що майже всі повинні мати цю проблему, але я не знаю нікого, хто її вирішив. Чи повинен я просто зберігати резервну копію оригінальних даних і забути всі ці елементи керування версіями? Це те, що роблять усі інші?

Що я закінчую використовувати, це своєрідне гібридне рішення:

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

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

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

Типовий контроль версій, як svn та git, не є практичним для цієї обставини, оскільки він просто не призначений для цього типу даних. Натомість ми застосували рішення "хмарного зберігання", зокрема DropBox та Bittorrent Sync. DropBox має перевагу в тому, що він робить принаймні якийсь примітивний журнал та контроль версій та керує серверами для вас, але недоліком є ​​те, що це комерційна послуга, ви повинні заплатити за велике сховище, і ви розміщуєте свої неопубліковані дані на комерційне зберігання; вам не доведеться платити багато, але це життєздатний варіант. Bittorrent Sync має дуже схожий інтерфейс, але ви запускаєте його самостійно на власних серверах зберігання даних, і він не має контролю над версіями. Обидва вони зачепили мою душу програміста, але вони є найкращими рішеннями моїх співробітників і я знайшов досі.

Я використовував версії на відро Amazon S3 для управління 10-100 ГБ в 10-100 файлів. Передача може бути повільною, тому вона допомогла стискати та переносити паралельно або просто виконувати обчислення на EC2. Бібліотека boto має приємний інтерфейс python.

Спробуйте переглянути велике сховище файлів Git (LFS) . Це нове, але може бути річ, на яку варто звернути увагу.

Як я бачу, в дискусії про Hacker News згадується кілька інших способів боротьби з великими файлами:

• git-annex (і, наприклад, використання його з Amazon S3 )
• Розширення Mercurual Largefiles

Ми не контролюємо версії фактичних файлів даних. Ми б не хотіли, щоб навіть якби ми зберігали його як CSV, а не у двійковій формі. Як сказав Ріккардо М. , ми не збираємось витрачати свій час на перегляд змін по рядках на наборі даних 10М рядків.

Натомість, разом з кодом обробки, я керую версією метаданих:

• Дата зміни
• Розмір файлу
• Підрахунок рядків
• Назви стовпців

Це дає мені достатньо інформації, щоб знати, чи змінився файл даних, і уявлення про те, що змінилося (наприклад, додані / видалені рядки, нові / перейменовані стовпці), не підкреслюючи VCS.

Це досить поширена проблема. Цей біль я відчував, коли робив дослідницькі проекти в університеті, а зараз - в наукових проектах з промислових даних.

Я створив і нещодавно випустив інструмент з відкритим кодом для вирішення цієї проблеми - DVC .

Він в основному поєднує ваш код у Git та дані на локальному диску або хмарах (сховище S3 та GCP). DVC відстежує залежність між даними та кодом та будує графік залежності (DAG). Це допомагає зробити ваш проект відтворюваним.

Проект DVC можна легко поділити - синхронізуйте свої дані до хмари (команда синхронізації dvc), надайте спільний доступ до свого сховища 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 manager.
Це дуже простий VCS для бінарних файлів для особистого користування (без співпраці).
Він використовує SHA1 для контрольної суми та блокування дедупликації. Повна синхронізація P2P.
Одна унікальна особливість: adhoc одноразовий TCP-сервер для потягу / натискання.
Він також може використовувати SSH для транспорту.

Він ще не випущений, але може стати гарною відправною точкою.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/

Ви можете спробувати використовувати ангар . Це відносно новий гравець у світі контролю версій даних, але робить дуже гарну роботу, оновлюючи тензори замість версії блобу. Документація повинна бути найкращим місцем для початку. Оскільки дані зберігаються як тензори, ви можете мати можливість використовувати їх безпосередньо у вашому коді ML (плюс у ангарі тепер є завантажувачі даних для PyTorch та Tensorflow). За допомогою ангару ви можете отримати всю користь від git, таких як нульове розгалуження, злиття, подорож у часі через історію. Однією приємною особливістю клонування в ангарі є те, що ви могли зробити часткове клонування . Це означає, що якщо у вас на відстані 10 ТБ даних і вам потрібно лише 100 Мбайт для прототипування вашої моделі, ви можете отримати лише 100 Мб через часткове клонування замість повного клонування.