Système de gestion des versions de données

 (dvc.org)
2 points par GN⁺ 2024-10-21 | 1 commentaires | Partager sur WhatsApp
  • Data Version Control est une famille d’outils fondée sur un modèle similaire à Git pour gérer les données comme du code, permettant aux équipes data, IA/ML et data science d’appliquer des pratiques d’ingénierie logicielle
  • lakeFS répond aux besoins des infrastructures IA/ML et data à grande échelle, avec une approche adaptée aux opérations IA complexes et aux environnements big data manipulant des stockages objet multimodaux et des data lakes à l’échelle du pétaoctet
  • Pour les petits projets de data science, l’extension Git DVC est adaptée, afin que les data scientists individuels puissent intégrer la gestion de versions de données dans leur workflow avec peu de surcharge
  • DVC est proposé en open source gratuit, avec également l’extension DVC for VS Code, et le dépôt GitHub affiche 15 713 étoiles
  • La communauté DVC a rejoint la famille lakeFS, et il est possible de consulter séparément la répartition des rôles entre lakeFS et DVC ainsi qu’une FAQ associée

Le rôle de Data Version Control

  • Data Version Control met en avant l’objectif de « gérer les données comme on gère le code »
  • Grâce à un modèle similaire à Git, il aide les équipes data, IA/ML et data science à utiliser les bonnes pratiques de l’ingénierie logicielle
  • Les cas d’usage se répartissent en deux grandes catégories
    • Les équipes infrastructure IA/ML et data
    • Les workflows locaux et les petits projets de data science

Public visé et point d’entrée selon le produit

  • lakeFS est une infrastructure de gestion des versions de données pour les équipes enterprise d’IA et de data engineering
    • Cible les opérations IA complexes et les environnements big data
    • Gère des stockages objet multimodaux et des data lakes à l’échelle du pétaoctet
    • Les liens de démarrage proposés sont Get started with lakeFS et Book a Demo
  • DVC est une extension Git pour les data scientists individuels
    • Vise une gestion de versions de données simple adaptée aux petits projets de data science
    • Peut s’intégrer à un workflow de data science avec un minimum de surcharge
    • Le lien de démarrage est Get started with DVC
  • L’extension DVC for VS Code permet aussi de l’utiliser dans VS Code
  • La communauté DVC a rejoint la famille lakeFS, avec comme ressources lakeFS and DVC et FAQs
  • Le dépôt GitHub de DVC est treeverse/dvc, et la page affiche 15 713 étoiles

À lire aussi

1 commentaires

 
GN⁺ 2024-10-21
Avis sur Hacker News

  • J’utilise DVC dans la plupart de mes projets depuis 5 ans, et son avantage, c’est qu’il fonctionne comme Git
    Si des scientifiques comprennent les branches, les commits et les diffs, alors ils peuvent aussi comprendre DVC. Son inconvénient, c’est justement qu’il fonctionne comme Git : en pratique, les scientifiques comprennent rarement bien les branches, les commits et les diffs, ou ne les utilisent pas vraiment. Le meilleur point, c’est qu’il force en pratique à suivre les Ten Simple Rules for Reproducible Computational Research. Dans les équipes où j’ai travaillé, la reproductibilité était un enjeu majeur

    • J’ai eu à peu près la même impression, et la résistance à l’apprentissage de Git est assez forte, ce qui se comprend dans une certaine mesure
      Les chercheurs savent ce qu’est Git et qu’il a de la valeur, mais estiment qu’il faut trop de temps pour l’apprendre et veulent avancer vite. C’est pour ce type de chercheurs que j’ai commencé à créer Calkit(https://github.com/calkit/calkit), un outil qui simplifie et intègre Git et DVC. J’aimerais les convaincre que travailler de manière reproductible est plus rapide à long terme et permet, au final, d’utiliser le travail plus directement pour faire progresser l’ensemble du domaine plus vite

  • Je suis mainteneur et auteur de DVC, et je suis ravi de le voir arriver en page d’accueil
    Je peux répondre aux questions sur DVC et sur son projet frère, DataChain https://github.com/iterative/datachain. DataChain est un outil de versioning des données basé sur des hypothèses un peu différentes, avec des transformations de données intégrées et sans copie de fichiers

    • Si les fichiers de données sont tous des fichiers texte, quelle est la différence entre DVC et Git pur ?
    • Je fais surtout du conseil comme data engineer et je ne suis pas spécialiste du MLOps, mais ce point m’intéresse
      J’ai 10 ans de fichiers Parquet provenant de plus de 300 topics Kafka, et je suis en train de migrer vers Apache Iceberg. Je ne prévois de faire du backfill qu’en cas de besoin, et ce serait bien de pouvoir suivre ce processus avec Git. Je me demande si cela convient bien à ce type d’usage. Une autre possibilité serait de suivre les évolutions de schéma mieux qu’aujourd’hui. Cela fait plus de 20 ans que je travaille dans ce domaine, et je pense que le anything-as-code s’adapte bien aux données

  • Ravi de voir DVC discuté ici
    En tant qu’outil, il a beaucoup simplifié le versioning des données et des modèles, et cela a été un vrai tournant pour beaucoup de monde dans l’univers MLOps. En particulier, c’est une manière ingénieuse de stocker de gros fichiers en les reliant directement à un dépôt Git dans n’importe quel object store, sans serveur d’application séparé comme git-lfs ni réécriture de Git. Chez DagsHub https://dagshub.com, nous intégrons directement DVC depuis longtemps pour permettre aux équipes de faire au même endroit la visualisation et le labeling des jeux de données, la gestion des modèles, l’exécution d’expériences collaboratives et le suivi du code, des données et des modèles. Si vous utilisez déjà DVC ou l’envisagez, il existe aussi l’option de l’employer comme composant d’une toolchain plus proche de l’end-to-end

  • Je me demande comment cela se compare à Oxen
    https://github.com/Oxen-AI/Oxen

    • Je suis mainteneur d’Oxen, et la raison initiale pour laquelle nous avons créé Oxen, c’est que DVC était assez lent et comportait beaucoup de fonctionnalités inutiles
      En interne, nous l’avons rendu rapide même sur de gros jeux de données en optimisant la structure en arbre de Merkle, les algorithmes de hachage, les protocoles réseau, etc. https://oxen.ai propose aussi un frontend plutôt réussi pour consulter et interroger les données
    • Si on pouvait l’utiliser avec GitHub, je pense que je migrerais directement depuis DVC
    • Je découvre Oxen, mais cela semble être une alternative très intéressante, et j’aimerais bien avoir le retour de quelqu’un qui a utilisé les deux
      À première vue, DVC semble conçu pour être utilisé avec Git, avec DVC qui gère des dossiers arbitraires dans un dépôt Git, tandis qu’Oxen paraît plus proche d’une alternative de dépôt de données séparé. Oxen semble aussi davantage intégré aux dataframes, aux données tabulaires et aux données d’entraînement et d’inférence IA, ce qui comble des manques de DVC. En revanche, DVC intègre un véritable moteur de pipelines DAG, l’import/export et des backends interchangeables

  • J’ai du mal à voir concrètement comment cela interagit avec les données
    Je stocke des tables Delta sur ADLS, et si je ne peux pas rapatrier les données de production en local, est-ce que cela reste utilisable ? Si pour revenir à une version passée il suffit de regarder les logs Delta, je me demande aussi quelle serait la raison d’utiliser DVC

    • D’après mon usage, DVC est proche de git LFS avec prise en charge de plusieurs backends, et on peut aussi le voir comme un git-annex plus simple
      Avec en plus des fonctionnalités spécialisées pour le MLOps. C’est pratique pour versionner l’entraînement de modèles quand les données sur S3 changent

  • Nous avons aussi évalué DVC, mais pour certains cas d’usage, le paradigme Git n’était pas très utile
    Il s’agissait de fichiers vidéo gigantesques qui changeaient très peu, et il fallait une copie des données côté source, puis une autre sur chaque système exécutant l’entraînement. Nous avons finalement opté pour des fichiers et dossiers sur un NAS, et cela fonctionnait suffisamment bien. Une approche hybride où seul le métadonnées du jeu de données serait géré avec DVC, puis versionné, semble possible. Cela dit, c’était il y a quelques années, et je me demande s’il existe aujourd’hui davantage de solutions de versioning des données on-premise. La dernière fois que j’ai regardé, la plupart semblaient surtout orientées cloud

  • Je me demande quels sont les avantages de DVC par rapport à Apache Iceberg
    Si quelqu’un a utilisé les deux, j’aimerais bien connaître son avis

    • Si c’est ce point qui vous intéresse, il faut aussi regarder Icechunk, open source depuis cette semaine
      C’est similaire à Apache Iceberg, mais conçu pour des données multidimensionnelles comme Zarr. https://earthmover.io/blog/icechunk et https://news.ycombinator.com/item?id=41850352
    • Je ne vois pas vraiment d’avantage net, j’ai plutôt l’impression qu’on utilise un outil familier là où il n’est pas adapté
      Iceberg est peut-être mieux adapté à des modèles où les changements sont moins fréquents que dans cette approche
    • Je n’ai pas encore les idées très claires, mais si je devais essayer de l’expliquer, un bon exemple des données blob dont il est question ici serait un ensemble de très longs fichiers vidéo en 1080p
      En résumé, il vaut mieux mettre les données blob non structurées dans DVC, et les données structurées dans Iceberg. L’avantage de DVC par rapport à Iceberg, c’est qu’il n’est pas nécessaire de forcer les données blob dans un format tabulaire, ni de subir les étapes de traitement pénibles qui vont avec. En pratique, il n’y a même pas besoin d’exécuter une étape de traitement pour extraire les données blob depuis des fichiers Parquet : on peut simplement télécharger chaque fichier tel quel avec une commande comme dvc pull. Après avoir modifié des fichiers en local, on peut faire un commit en gros avec trois commandes, sans avoir besoin d’un pipeline d’ingestion qui force les données blob à entrer dans des tables. Comme c’est totalement sans schéma, il suffit de les mettre dans le dépôt et de les valider sans se soucier des types. On peut revenir en arrière sur tout l’historique des commits, et pas seulement jusqu’au dernier vacuum/checkpoint. Forcer des données blob dans un format de données tabulaire relève presque de la recette du cauchemar, alors que mettre des blobs dans un dépôt de type Git est bien plus rapide et simple. C’est particulièrement vrai si l’on a besoin d’un historique complet des versions ou de branches pour différents résultats : appliquer, selon les branches, différents filtres ffmpeg à de longs fichiers vidéo 1080p, puis permettre aux gens d’accéder à tous les résultats et à tout l’historique, serait cauchemardesque avec Iceberg, mais facile avec DVC. Au final, comme tout est versionné, on a l’impression de construire un data lake qui ne se transforme pas en marécage de données

  • J’ai eu beaucoup de problèmes en l’utilisant sur un dataset composé d’un grand nombre de fichiers jpg
    À chaque dvc status, l’indexation qui vérifiait tous les fichiers prenait plusieurs minutes, et le cache ne fonctionnait pas non plus. J’ai malheureusement dû abandonner

    • Oui, les performances sont assez mauvaises, et le cache peut causer beaucoup de maux de tête
      C’est particulièrement vrai si l’on utilise un système de fichiers qui ne prend pas en charge les reflinks. Pour de gros datasets shardés comme WebDataset, d’autres solutions sont préférables, surtout si le pipeline de machine learning peut faire du streaming directement depuis un object storage

  • J’ai aussi entendu parler de lakeFS comme outil de gestion de versions de données au-dessus du stockage objet S3
    Je me demande si DVC peut être considéré comme un concurrent dans ce domaine