Gestion des versions de vos jeux de données avec Data Version Control (DVC) et Git
By JOUET Grégor
3 sept. 2020
- Catégories
- Data Science
- DevOps & SRE
- Tags
- DevOps
- Infrastructure
- Exploitation
- Git
- GitOps
- SCM [plus][moins]
Ne ratez pas nos articles sur l'open source, le big data et les systèmes distribués, fréquence faible d’un email tous les deux mois.
L’utilisation d’un système de contrôle de version tel que Git pour le code source est une bonne pratique et une norme de l’industrie. Étant donné que les projets se concentrent de plus en plus sur les données, ne devrions-nous pas avoir une approche similaire telle que la gestion des versions des données ?
Le projet Data Version Control (DVC) vise à intégrer Git dans des projets qui utilisent beaucoup de données. Vous trouvez souvent dans de tels projets un lien quelconque pour télécharger les données et parfois Git LFS est utilisé. Cependant, cela présente un inconvénient majeur : les données elles-mêmes ne sont pas suivies par git.
Ce qui signifie qu’un autre outil est nécessaire pour suivre les modifications apportées aux données, et le plus souvent, cet outil est une feuille de calcul.
Les projets à forte intensité de données, tels que les projets d’apprentissage en profondeur, reposent fortement sur la qualité du jeu de données pour produire de bons résultats. Il est juste de dire que les données sont souvent plus importantes que le modèle qui les traite. Avoir un moyen de suivre la version et les modifications apportées à vos données et de les échanger avec vos collègues d’une manière qui n’implique pas un .tar.gz
semble être une bonne idée. Et étant donné que Git est le système de versionnage le plus utilisé, coupler Git avec le système Data Version Control semble être une idée encore meilleure.
De cette façon, lorsque la version de notre jeux de données est suivie, nous pouvons utiliser plus tard MLflow pour lier la précision d’un modèle à la version du jeux de données que nous avons utilisé.
Utilisation de DVC
L’utilisation de DVC est très similaire à celui de Git. Les commandes se ressemblent. DVC vous permet de choisir des fichiers dans votre dépôt Git et de les pousser sur un stockage distant. Cela peut être S3, HDFS, SSH… Tous conviennent mieux aux fichiers volumineux que Git. Pour installer DVC, utilisez simplement pip
avec la commande sudo pip install dvc
.
Un référentiel DVC doit d’abord être suivi par un outil scm, l’outil SCM suivra les fichiers d’index depuis DVC, ce qui indiquera où obtenir les fichiers réels qui sont trop gros pour être placés directement sur Git. Pour rappel, SCM signifie Source Control Management. C’est une famille d’outils dont font parti Git, SVN ou encore Mercurial. Si vous n’utilisez que Git, vous pouvez remplacer le terme SCM par Git.
Alors tout d’abord, initialisez un dépôt Git, comme d’habitude : git init
.
Ensuite, initialisez un dépôt DVC dans le même dossier : dvc init
.
De cette façon, votre dossier est suivi par Git et DVC. Vous pouvez toujours utiliser Git pour suivre les modifications apportées à votre projet comme d’habitude. Mais avec DVC, le fichier que vous choisissez est supprimé de Git et ajouté au .gitignore
et géré par dvc.
DVC créera un
contenant des informations sur votre fichier. Par exemple, si vous avez un fichier dataset
, dataset.dvc
ressemblera à :
md5: a33606741514b870f609eb1510d8c6cf
outs:
- md5: b2455b259b1c3b5d86eac7dfbb3bbe6d
path: dataset
cache: true
metric: false
persist: false
Ce fichier décrit un fichier appelé dataset
qui est présent sur le serveur distant (ou le cache local DVC) et disponible pour un checkout (comme dans Git). Le hachage md5 est utilisé pour le contrôle de version et pour indiquer quelle version du fichier doit être extraite et utilisée dans le projet.
Les fichiers .dvc
doivent être validés sur le SCM car DVC n’est pas un outil SCM : DVC a des commits mais ils ne sont pas liés entre eux. Les commits n’ont pas de parent, ceci est géré par le logiciel SCM. Dans l’exemple ci-dessus, le hachage md5 n’est lié à aucun autre hachage DVC. Ils sont indépendants et suivis par le logiciel SCM.
Les commandes pour commiter, pousser (push) et extraire (pull) avec un stockage distant comme S3 ou HDFS sont très simples :
- Utilisez
dvc add
pour traquer un fichier avec DVC (et l’ajouter automatiquement au .gitignore), ce qui créera le fichier.dvc
associé. - Utilisez
dvc commit
pour commiter les modifications dans le cache local DVC. - Utilisez
dvc pull/push
pour recevoir et récupérer (checkout) ou pour envoyer le fichier sur le stockage distant.
Ainsi, lors du clonage d’un projet de Data Science, utilisez simplement la séquence suivante pour cloner le projet et obtenir les fichiers volumineux associés :
git clone <url> project
cd project
dvc pull
Utilisez cette séquence pour traquer et envoyer le fichier dataset.zip
dans dvc.
dvc add dataset.zip
dvc commit
git add dataset.zip.dvc .gitignore
git commit -m "[DVC] Move dataset to dvc"
dvc push
git push
Using DVC with MLflow
DVC peut être utilisé avec d’autres outils de Data Science pour en tirer le meilleur parti. L’un de ces outils est MLflow, qui est utilisé pour suivre l’efficacité des modèles de Machine Learning.
MLflow peut être utilisé avec de nombreux frameworks de Data Science : Tensorflow, Pytorch, Spark, … Ce qui est intéressant, c’est que les exécutions de MLflow peuvent être balisées (tag) avec le hachage des commits Git. Auparavant, seul le code passait sur Git et les informations associés aux data sets se trouvaient généralement dans des fichiers Excel, transmis de départements en départements. Désormais, avec DVC, le jeux de données est intégré dans Git. Vous pouvez garder une trace des modifications qui y sont apportées dans les messages de validation Git et avoir une branche dédiée au suivi des jeux de données. De plus, vous pouvez voir l’influence de chaque modification sur les performances du modèle avec MLflow. Parce que DVC est entièrement dissocié du code projet, il est très facile de l’ajouter à un projet existant.
Nous utilisons MLflow ici comme exemple, mais tout autre framework utilisant un outil SCM fonctionnera également.
Mise en garde sur le stockage DVC
Le principal problème avec DVC est la configuration initiale du stockage distant, en particulier avec HDFS qui nécessite un peu de configuration pour avoir un client opérationnel. L’un des moyens les plus simples de configurer DVC consiste à utiliser un bucket S3.
dvc remote add myremote s3://bucket/path
Mais DVC peut également être utilisé avec de nombreux stockages distants comme GoogleDrive :
dvc remote add myremote gdrive://root/my-dvc-root
dvc remote modify myremote gdrive_client_id my_gdrive_client_id
dvc remote modify myremote gdrive_client_secret gdrive_client_secret
Plus d’informations sur l’ajout de stockage distant sont disponibles sur leur site Web.
Sachez également que DVC a un stockage local pour les fichiers qui sont suivis. Les fichiers suivis par DVC peuvent être liés (hard link) au cache. Soyez conscient de cela si vous décidez de supprimer DVC de votre projet. Plus d’informations sur la structure du cache DVC sont disponibles sur leur site Web.