Comment gérer le contrôle de version de grandes quantités de données (binaires)

Je suis étudiant au doctorat en géophysique et travaille avec de grandes quantités de données d'images (des centaines de Go, des dizaines de milliers de fichiers). Je sais svnet gitassez bien et viens valoriser un historique du projet, combinée à la possibilité de facilement travailler ensemble et une protection contre la corruption disque. Je trouve gitégalement extrêmement utile d’avoir des sauvegardes cohérentes, mais je sais que git ne peut pas gérer efficacement de grandes quantités de données binaires.

Dans mes études de master, j'ai travaillé sur des ensembles de données de taille similaire (également des images) et j'ai eu beaucoup de difficultés à garder trace de versions différentes sur différents serveurs / périphériques. Diffuser 100 Go sur le réseau n'est vraiment pas amusant et me coûte beaucoup de temps et d'efforts.

Je sais que d'autres scientifiques semblent avoir des problèmes similaires, mais je ne pouvais pas trouver de bonne solution.

Je veux utiliser les installations de stockage de mon institut, j'ai donc besoin de quelque chose qui puisse utiliser un serveur "idiot". Je souhaite également une sauvegarde supplémentaire sur un disque dur portable, car je souhaite éviter de transférer des centaines de Go sur le réseau dans la mesure du possible. Il me faut donc un outil capable de gérer plusieurs sites distants.

Enfin, j’ai vraiment besoin de quelque chose que d’autres chercheurs puissent utiliser, ce qui n’a pas besoin d’être très simple, mais qui devrait pouvoir être appris en quelques heures.

J'ai évalué beaucoup de solutions différentes, mais aucune ne semble correspondre à la facture:

• svn est quelque peu inefficace et a besoin d'un serveur intelligent
• hg bigfile / largefile ne peut utiliser qu'une seule télécommande
• git bigfile / media peut également utiliser une seule télécommande, mais n’est pas très efficace
• le grenier ne semble pas avoir un journal, ou diffing capacités
• bup a l' air vraiment bien, mais a besoin d'un serveur "intelligent" pour fonctionner

J'ai essayé git-annex, ce qui fait tout ce dont j'ai besoin (et bien plus), mais il est très difficile à utiliser et pas bien documenté. Je l'utilise depuis plusieurs jours et je n'arrive pas à comprendre, alors je doute qu'un autre collègue soit intéressé.

Comment les chercheurs traitent-ils de grands ensembles de données et à quoi servent les autres groupes de recherche?

Pour être clair, je suis principalement intéressé par la façon dont d’autres chercheurs traitent cette situation, et pas seulement par cet ensemble de données. Il me semble que presque tout le monde devrait avoir ce problème, mais je ne connais personne qui l'ait résolu. Devrais-je conserver une copie de sauvegarde des données d'origine et oublier tout ce contrôle de version? Est-ce ce que tout le monde fait?

Ce que je finis par utiliser est une sorte de solution hybride:

• sauvegarde des données brutes
• git du flux de travail
• instantanés manuels du flux de travail + données traitées, qui sont pertinents, par exemple:
  • prétraitement standard
  • prend beaucoup de temps
  • pour publication

Je pense qu’il est rarement judicieux de disposer d’un historique complet de la révision d’un grand nombre de données binaires, car le temps requis pour examiner les modifications sera finalement trop long pour qu’il ne soit pas rentable à long terme. Peut-être qu'une procédure d'instantané semi-automatique (éventuellement pour économiser de l'espace disque, en ne répliquant pas les données inchangées sur différents instantanés) serait utile.

J'ai traité de problèmes similaires avec de très grands ensembles de données de biologie synthétique, où nous avons beaucoup, beaucoup de données de cytométrie en flux réparties sur de très nombreux milliers de fichiers, et nous devons les conserver de manière cohérente entre les groupes de collaboration de plusieurs institutions différentes.

Un contrôle de version typique comme svn et git n'est pas pratique dans cette situation, car il n'est tout simplement pas conçu pour ce type de jeu de données. Au lieu de cela, nous avons eu recours à des solutions de "stockage en nuage", en particulier DropBox et Bittorrent Sync. DropBox présente l’avantage d’effectuer au moins une partie de la journalisation et du contrôle de version primitifs et de gérer les serveurs pour vous, mais le désavantage qu’il s’agit d’un service commercial, vous devez payer pour un stockage important, et vous mettez vos données non publiées sur un ordinateur. stockage commercial; vous n'avez pas à payer beaucoup, cependant, c'est donc une option viable. Bittorrent Sync a une interface très similaire, mais vous l’exécutez vous-même sur vos propres serveurs de stockage et n’a aucun contrôle de version. Les deux me font mal au programmeur, mais ce sont les meilleures solutions que mes collaborateurs et moi avons trouvées jusqu'à présent.

J'ai utilisé le contrôle de version sur des compartiments Amazon S3 pour gérer 10-100 Go en fichiers 10-100. Le transfert peut être lent, il a donc été utile de compresser et de transférer en parallèle ou d’exécuter des calculs sur EC2. La bibliothèque de boto fournit une belle interface en python.

Essayez de regarder Git Large File Storage (LFS) . C'est nouveau, mais pourrait être la chose à regarder.

Comme je le vois, une discussion sur Hacker News mentionne quelques autres moyens de traiter des fichiers volumineux:

• git-annex (et par exemple l’ utiliser avec Amazon S3 )
• Extension Mercurual Largefiles

Nous ne contrôlons pas les versions réelles des fichiers de données. Nous ne voudrions pas, même si nous l'avons stocké au format CSV plutôt que sous une forme binaire. Comme l'a dit Riccardo M. , nous ne passerons pas notre temps à examiner les modifications, ligne par ligne, d'un ensemble de données de 10 millions de lignes.

Au lieu de cela, avec le code de traitement, je contrôle les métadonnées par la version:

• Date de modification
• Taille du fichier
• Nombre de lignes
• Noms de colonne

Cela me donne suffisamment d'informations pour savoir si un fichier de données a changé et une idée de ce qui a changé (par exemple, les lignes ajoutées / supprimées, les colonnes nouvelles / renommées), sans insister sur le VCS.

C'est un problème assez commun. J'ai eu cette douleur quand j'ai fait des projets de recherche pour une université et maintenant - dans des projets de science des données industrielles.

J'ai créé et récemment publié un outil open source pour résoudre ce problème - DVC .

Il combine essentiellement votre code dans Git et vos données sur votre disque local ou dans les clouds (stockage S3 et GCP). DVC surveille la dépendance entre les données et le code et construit le graphe de dépendance (DAG). Cela vous aide à rendre votre projet reproductible.

Le projet DVC pourrait être facilement partagé - synchronisez vos données sur un nuage (commande dvc sync), partagez votre référentiel Git et fournissez un accès à votre compartiment de données dans le nuage.

"apprenable en quelques heures" - est un bon point. Vous ne devriez pas avoir de problèmes avec DVC si vous connaissez Git. Vous devez vraiment apprendre que trois commandes:

1. dvc init- comme git init. Devrait être fait dans un dépôt Git existant.
2. dvc import- importer vos fichiers de données (sources). Fichier local ou URL.
3. dvc run- les étapes de votre flux de travail comme dvc run python mycode.py data/input.jpg data/output.csv. DVC déduit automatiquement la dépendance entre vos étapes, construit DAG et la conserve dans Git.
4. dvc repro- reproduire votre fichier de données. Exemple: vi mycode.py- changez le code, puis dvc repro data/output.csvreproduirez le fichier (et toutes les dépendances).

Vous devez apprendre quelques commandes DVC supplémentaires pour partager des données via le cloud et des compétences de base en S3 ou GCP.

Le didacticiel DVC est le meilleur point de départ - "Contrôle de version de données: apprentissage automatique itératif"

Je ne les ai pas utilisées mais il y a eu une discussion similaire dans un groupe financier

suggestions de logiciels de référentiel de données scidb , zfs, http://www.urbackup.org/

Vous pouvez consulter mon projet intitulé DOT: gestionnaire de référentiel Distrubuted Object Tracker.
C'est un VCS très simple pour les fichiers binaires à usage personnel (pas de collaboration).
Il utilise SHA1 pour la somme de contrôle et la déduplication par bloc. Synchronisation P2P complète.
Une caractéristique unique: un serveur TCP ponctuel pour tirer / pousser.
Il peut également utiliser SSH pour le transport.

Il n'est pas encore sorti, mais pourrait être un bon point de départ.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/

Vous pouvez essayer d'utiliser le hangar . C'est un acteur relativement nouveau dans le monde du contrôle de version de données, mais il fait un travail vraiment sympa en versionnant les tenseurs au lieu de l'attribut blob. La documentation doit être le meilleur endroit pour commencer. Étant donné que les données sont stockées en tant que tenseurs, vous devriez pouvoir les utiliser directement dans votre code ML (le hangar dispose désormais de chargeurs de données pour PyTorch et Tensorflow). Avec hangar, vous pouvez bénéficier de tous les avantages de git, tels que la création de branches sans frais, la fusion et le voyage dans le temps. Une fonctionnalité intéressante sur le clonage dans le hangar est que vous pouvez effectuer un clonage partiel . Autrement dit, si vous disposez de 10 To de données sur votre télécommande et que vous n’avez besoin que de 100 Mo pour le prototypage de votre modèle, vous ne pourrez récupérer que 100 Mo via un clonage partiel au lieu d’un clone complet.