Flux de travail de reproductibilité au-delà des conteneurs : versionnement des données et suivi de la provenance

Points à retenir clés

• Les conteneurs résolvent un problème. Ils gelent l’environnement logiciel, mais ils ne suivent pas ce qui a changé dans vos données ni l’évolution de votre analyse.
• Le versionnement des données ajoute une couche manquante. Des outils tels que DVC et DataLad apportent un contrôle de version de style Git aux jeux de données, ce qui facilite la reproduction des résultats avec des entrées exactes, des fichiers de paramètres et des sorties sélectionnées.
• La provenance est la piste d’audit. Il enregistre toutes les transformations qui sont arrivées à vos données, des fichiers bruts aux chiffres finaux.
• Les conteneurs, la gestion des versions de données et le suivi de provenance sont complémentaires. Ensemble, ils couvrent le code, l’environnement, les données et la lignée.

Ce qu’il faut savoir d’abord

Des conteneurs comme Docker et Singularity sont devenus une partie quasi obligatoire de la recherche reproductible. Ils résolvent un problème réel : si vous envoyez une image Docker à quelqu’un, cette personne devrait pouvoir exécuter le code et obtenir les mêmes résultats sur une autre machine.

C’est pourquoi les revues et les réviseurs demandent de plus en plus des images de conteneurs à côté des articles. Mais les conteneurs laissent deux lacunes critiques ouvertes.

Premièrement, les conteneurs ne suivent pas les modifications apportées à vos données. Un ensemble de données évolue au fil du temps au fur et à mesure que vous nettoyez, filtrez et retraitez. Lorsque vous reproduisez un résultat six mois plus tard, vous devez savoir quelle version des données produite ce chiffre. Les conteneurs n’enregistrent pas cela par défaut.

Deuxièmement, les conteneurs ne capturent pas la lignée. Si un script d’analyse est erroné, un paramètre a été modifié accidentellement ou une étape de prétraitement a été appliquée de manière incohérente, il se peut qu’il n’y ait pas d’enregistrement automatisé de ce qui s’est passé. Il vous reste à compter sur la mémoire, les notes manuelles ou la chance.

Cet article explique comment les workflows scientifiques modernes résolvent ces lacunes grâce à la gestion des versions des données et au suivi de la provenance. Le contrôle des données permet de suivre les changements de l’ensemble de données au fil du temps. Le suivi de la provenance enregistre chaque transformation appliquée aux données.

Les conteneurs ne suffisent pas

Avant de discuter de la gestion des données, il est utile de comprendre ce que font et ne font pas les conteneurs.

Un conteneur capture :

• Le système d’exploitation, généralement une distribution Linux.
• Packages installés et leurs versions.
• Vos fichiers de code et de configuration.
• La commande utilisée pour exécuter l’analyse.

Un conteneur ne capture pas automatiquement :

• Les fichiers exacts utilisés comme entrées, à moins qu’ils ne soient intégrés à l’image.
• Paramètres d’exécution, à moins qu’ils ne soient explicitement enregistrés.
• Sorties intermédiaires générées lors d’un pipeline.
• L’ordre et la logique des transformations appliquées aux données.

La conséquence pratique est simple. Vous pouvez exécuter un conteneur sur une autre machine et obtenir la même sortie uniquement si les entrées et le contexte d’exécution sont également contrôlés. Si vous souhaitez reproduire une analyse spécifique d’il y a des mois, en particulier une analyse avec plusieurs étapes et un ensemble de données changeant, vous avez besoin de plus qu’un conteneur.

Envisagez un scénario commun. Vous entraînez une simulation de champ de phase sur des images de microstructure expérimentales. Les images sont nettoyées pendant le prétraitement, puis divisées en ensembles de formation et de validation. Six mois plus tard, quelqu’un vous demande de reproduire la simulation.

Vous ouvrez le conteneur, exécutez la commande et obtenez le mauvais résultat. La raison peut être que l’ensemble de données a été réorganisé, que de nouveaux échantillons ont été ajoutés ou que le point d’entrée a utilisé quel que soit le fichier dans un répertoire. Sans entrées versionnées et sans piste d’audit, le conteneur seul ne peut pas prouver ce qui s’est passé.

C’est là que le versionnement des données et le suivi de provenance deviennent nécessaires.

Qu’est-ce que le versionnage des données ?

Le versionnement des données apporte la même idée qui rend Git utile pour le code dans le monde des ensembles de données. Au lieu de suivre directement chaque fichier binaire volumineux, il crée des instantanés légers ou des pointeurs vers des états spécifiques de données à des moments spécifiques.

L’idée de base est simple :

1. Vous modifiez le jeu de données, comme l’ajout de fichiers, la modification ou la réorganisation de dossiers.
2. Vous validez un snapshot qui enregistre ce qui a changé et où vivent les données actuelles.
3. Plus tard, vous pouvez vérifier ce snapshot pour restaurer l’état exact des données qui a produit un résultat spécifique.

Les deux principaux outils de l’écosystème scientifique Python sont DVC et DataLad.

DVC : contrôle de version de données

DVC est un outil de gestion des données largement adopté pour les flux de travail basés sur Python. Il fonctionne en générant de petits fichiers de métadonnées qui suivent les emplacements de données et les sommes de contrôle tandis que les données réelles se trouvent dans le stockage à distance, tels que les buckets cloud, les disques locaux ou les réseaux partagés.

Plusieurs fonctionnalités DVC comptent pour les flux de travail scientifiques :

• Définition du pipeline dvc.yaml Les fichiers vous permettent de décrire le pipeline d’analyse, y compris les entrées, les sorties, les étapes de traitement et les dépendances.
• Suivi des expériences. dvc exp run crée des espaces de noms d’expérience isolés afin que vous puissiez tester les configurations de paramètres sans encombrer l’historique des Git.
• Stockage à distance. DVC peut transférer des données sur des télécommandes configurées telles que S3, Google Cloud Storage, Azure, SSH Servers ou des systèmes de fichiers partagés.
• Voyage dans le temps. Vous pouvez extraire un commit git, exécuter dvc pull et dvc checkout et restaurer l’état des données à partir de ce point.

Un flux de travail scientifique typique peut ressembler à ceci :

# Initialize DVC in your project
dvc init

# Add your dataset
dvc add data/raw_microstructures/

# Commit only the lightweight metadata
git add data/raw_microstructures.dvc
git commit -m "Initial microstructure dataset"

# Define a processing pipeline
dvc run -d data/raw_microstructures.dvc -o data/cleaned/ 
    python src/preprocess.py

# Run experiments
dvc exp run --set-param preprocessing.threshold=0.5

datalad

Datalad est conçu pour les ensembles de données scientifiques et utilise Git-Annex sous le capot. Il est particulièrement utile pour les grands ensembles de données qui peuvent couvrir de nombreux fichiers, tels que des simulations, des mesures expérimentales, des données d’imagerie ou des collections de recherche institutionnelle.

DataLad offre plusieurs avantages spécifiques à des données scientifiques :

• Conception centrée sur l’ensemble de données. Datalad traite chaque répertoire comme un jeu de données avec un historique de versions.
• Récupération de données sur demande. Au lieu de tout tirer, DataLad peut récupérer des fichiers ou des sous-répertoires spécifiques en cas de besoin.
• Réplication intégrée. Datalad peut gérer les dépôts de sœurs dans toutes les institutions pour des raisons de redondance et de conformité.
• Intégration HPC. Les extensions peuvent prendre en charge les systèmes de planification par lots tels que Slurm et PBS.

Un workflow de base de DataLad ressemble à ceci :

# Initialize a dataset
datalad create -s my-dataset

# Add data using git-annex under the hood
datalad add data/raw_images/

# Record a provenance-rich commit
datalad save -m "Add raw imaging data, batch 2024-01"

# Clone to another machine and fetch data on demand
datalad clone my-dataset
datalad get data/processed_results/

Quand utiliser lequel

DVC est souvent mieux pour les équipes travaillant dans des environnements de science des données Python qui nécessitent un suivi des pipelines et une gestion des expériences. Il s’intègre naturellement à des outils tels que Scikit-Learn, PyTorch et d’autres flux de travail Python.

DataLad est souvent meilleur pour les projets de conservation des données à long terme, en particulier lorsque les ensembles de données sont volumineux, répartis entre les institutions ou devraient survivre pendant de nombreuses années.

Ils ne s’excluent pas mutuellement. Les deux utilisent Git dans le cadre de leur dorsale de contrôle de version, et les deux peuvent être combinés avec des environnements d’exécution conteneurisés.

Qu’est-ce que le suivi de provenance ?

La provenance est l’enregistrement systématique de la provenance des données et de ce qui leur est arrivé. Dans les flux de travail scientifiques, Provenance répond à des questions pratiques :

• Quelle version des données d’entrée a été utilisée ?
• Quels paramètres ont été appliqués lors du traitement ?
• Quels fichiers intermédiaires ont été générés ?
• Quelles versions de logiciels étaient actives lors de la production de la sortie ?
• Qui a exécuté le flux de travail et quand ?

Deux types de provenance dans les flux de travail scientifiques.

La provenance prospective décrit ce qui va se passer. Il s’agit de la spécification de flux de travail planifié : la recette de la façon dont les données doivent passer à travers l’analyse. Des outils tels que CWL et WDL utilisent des formats déclaratifs pour spécifier ce qui devrait se produire lors de l’exécution d’un workflow.

La provenance rétrospective décrit ce qui s’est réellement passé. Il enregistre les journaux d’exécution, les instantanés d’environnement, les sommes de contrôle des données et les fichiers d’exécution exacts. Il s’agit de la piste d’audit qui prend en charge la reproductibilité.

RO-crate : artefacts de recherche sur l’emballage avec provenance

RO-Crate est un standard pour l’emballage des résultats de recherche, des fichiers de données, des définitions de flux de travail, des paramètres et des enregistrements dans une archive lisible par machine.

Une archive RO-Crate est généralement un répertoire ou un fichier ZIP qui contient :

• Fichiers de données et sorties d’analyse.
• Un fichier ro-crate-metadata.json avec des métadonnées JSON-LD.
• Définitions de workflow telles que CWL, NextFlow ou SnakeMake.
• Journaux d’exécution et captures d’environnement.

RO-crate est utile car il est léger et portable. Vous n’avez pas besoin d’une base de données ou d’un service spécial pour l’inspecter. Toute personne disposant des fichiers peut lire les métadonnées et comprendre la provenance.

Le format prend en charge à la fois la provenance prospective, qui décrit ce que le flux de travail prévoit de faire, et la provenance rétrospective, qui enregistre ce qui fonctionnait réellement.

RO-crate gagne du terrain dans le calcul scientifique. Des plates-formes telles que Galaxy, WorkflowHub et Zenodo prennent en charge les exportations de RO-crate, ce qui le rend utile pour les artefacts de recherche prêts à l’emploi.

Mettre le tout en place : un modèle de flux de travail pratique

Les conteneurs, la gestion des versions de données et le suivi de provenance fonctionnent mieux lorsqu’ils sont utilisés ensemble. Chacun couvre une couche de reproductibilité différente.

Étape 1 : Versez vos données avec DVC ou DataLad

Commencez par mettre à jour les entrées brutes. Utilisez dvc add ou datalad add pour chaque jeu de données qui alimente l’analyse. Validez les fichiers de métadonnées DVC ou Git-annex à Git à côté du code.

Étape 2 : Définissez votre pipeline

Si vous utilisez DVC, écrivez un fichier dvc.yaml qui décrit chaque étape de traitement comme une étape. Si vous utilisez Datalad, utilisez des scripts documentés, des fichiers de paramètres cohérents et des référentiels de sœurs si nécessaire.

Étape 3 : Contenez l’exécution

Enveloppez les scripts d’analyse dans un conteneur qui peut s’exécuter sur des machines. Le conteneur maintient la cohérence des packages Python, des bibliothèques C++ et des fichiers binaires. Il ne remplace pas les entrées versionnées.

Étape 4 : Capturez la provenance avec RO-crate ou CWLProv.

À la fin de chaque exécution de workflow, les artefacts d’empaqueter dans une archive RO-Crate. Cela vous donne :

• Un seul répertoire ou fichier ZIP contenant des données, du code, des journaux et des métadonnées.
• Provenance lisible par machine liée à des ensembles de données.
• Identifiants persistants lorsqu’ils sont déposés dans des référentiels tels que Zenodo ou FigShare.

Le flux de travail en pratique

Your Project Directory
├── .git/                     # Code and metadata
├── .dvc/                     # DVC pipeline state
├── src/                      # Analysis scripts
├── data/                     # Versioned datasets
├── results/                  # Output data
├── dvc.yaml                  # Pipeline definition
├── params.yaml               # Parameter file
└── Dockerfile                # Container definition

L’exécution du workflow peut ressembler à ceci :

# Restore exact data state
dvc checkout

# Run with pinned container
docker run -v $(pwd):/workspace my-analysis:1.2 python src/run.py

# Package results with provenance
ro-crate add data/results.csv params.yaml results/

erreurs courantes

Ce sont des pièges courants lorsque les chercheurs adoptent le contrôle de version des données et le suivi de la provenance.

1. Suivi de chaque fichier intermédiaire

La gestion des versions de chaque fichier intermédiaire est généralement inutile et peut devenir nuisible. Il gonfle le stockage et les métadonnées sans améliorer la reproductibilité.

Piste uniquement :

• Les entrées brutes, qui sont les fichiers d’origine acquises.
• Données prétraitées, qui est la version sélectionnée réellement utilisée pour l’analyse.
• Fichiers de sortie finaux, tels que les chiffres, les tableaux et les sorties de simulation publiées.

Ne versionnez pas chaque fichier CSV ou Scratch temporaire, sauf s’il est nécessaire de reproduire le résultat final.

2. Oublier les fichiers de paramètres de version

Si les paramètres sont passés uniquement en tant qu’arguments de ligne de commande, ils peuvent ne pas être récupérables à partir de Git seul. Les fichiers de paramètres sont tout aussi importants que les fichiers de données.

Versionnez-les explicitement :

dvc add configs/params.yaml
git add configs/params.yaml.dvc

3. En supposant que les conteneurs résolvent tout

Les conteneurs sont précieux, mais ils ne sont qu’une seule couche. Un conteneur sans entrées et provenance versionnée ne suffit pas pour prouver comment un résultat spécifique a été produit.

Considérez les conteneurs comme la couche d’environnement. Vous avez toujours besoin d’un versionnement des données pour les entrées et le suivi de provenance pour l’historique du flux de travail.

4. Ignorer la configuration du stockage à distance

DVC et DataLad fonctionnent mieux lorsque le stockage à distance est configuré tôt. Sans télécommande, les fichiers de métadonnées peuvent pointer vers des chemins locaux qui disparaissent lorsque vous passez à un cluster ou à un environnement cloud.

Configurez les télécommandes au début du projet, et non lors d’une période de crise.

Choisir le bon outil pour votre projet

Le paysage des outils est diversifié. Utilisez ce cadre de décision comme point de départ.

Vous pouvez également combiner des outils. Par exemple, utilisez DVC pour le versionnement des données, Docker pour la reproductibilité de l’environnement et RO-Crate pour regrouper le flux de travail final pour publication.

Que faire ensuite

Si vous lancez un nouveau projet, le chemin est simple :

1. Initialisez un référentiel Git pour le code.
2. Ajoutez DVC avec dvc init et les jeux de données brutes de version.
3. Écrivez des scripts d’analyse sous forme de fichiers Python ou de scripts bash.
4. Containez le workflow avec Docker ou Singularity.
5. Résultats du package avec RO-crate à chaque étape majeure.

Si vous travaillez sur un projet existant, commencez petit :

1. Ajoutez DVC aux ensembles de données de référentiel et de clé de version.
2. Écrivez un fichier dvc.yaml qui décrit le pipeline.
3. Containerisez l’étape d’exécution principale.
4. Créez une archive RO-crate pour le résultat le plus important.

Cette approche incrémentale vous permet d’ajouter des couches de reproductibilité sans réécrire l’ensemble du projet.

Guides connexes

• Version et intégrité dans les logiciels de recherche — un aperçu plus large du contrôle des versions, de la reproductibilité et de la traçabilité des flux de travail pour les équipes de logiciels de recherche.
• débogage de Python pour le code scientifique – des modèles de débogage qui fonctionnent avec des flux de travail reproductibles.

Cet article couvre le versionnement des données et le suivi de la provenance en tant qu’outils pratiques pour des flux de travail scientifiques reproductibles. DVC, Datalad et Ro-Crate sont activement maintenus et largement utilisés dans l’écosystème scientifique Python. Pour connaître les derniers détails de la configuration, reportez-vous toujours à la documentation officielle de chaque outil.