Outils et protocole pour la science des données reproductibles à l'aide de Python

Je travaille sur un projet de science des données utilisant Python. Le projet comporte plusieurs étapes. Chaque étape consiste à prendre un ensemble de données, à utiliser des scripts Python, des données auxiliaires, une configuration et des paramètres, et à créer un autre ensemble de données. Je stocke le code dans git, cette partie est donc couverte. J'aimerais entendre parler de:

1. Outils pour le contrôle de version de données.
2. Outils permettant de reproduire des étapes et des expériences.
3. Protocole et structure de répertoire suggérée pour un tel projet.
4. Outils de génération / exécution automatisés.

Le thème de la recherche reproductible (RR) est très populaire aujourd'hui et, par conséquent, est énorme , mais j'espère que ma réponse sera assez complet comme une réponse et fournira suffisamment d' informations pour d' autres recherches , si vous décidez de le faire.

Bien que des outils spécifiques à Python pour RR existent certainement, je pense qu'il est plus logique de se concentrer sur des outils plus universels (vous ne savez jamais avec certitude quels langages de programmation et environnements informatiques vous utiliserez à l'avenir). Cela dit, examinons quels outils sont disponibles dans votre liste.

1) Outils pour le contrôle de version de données . À moins que vous ne envisagiez de travailler avec des données très volumineuses , j’imagine qu’il serait logique d’utiliser la même gitsolution que celle que vous utilisez pour le contrôle de version du code source. L'infrastructure est déjà là. Même si vos fichiers sont gros et binaires, ce conseil peut être utile: https://stackoverflow.com/questions/540535/managing-large-binary-files-with-git .

2) Outils de gestion des flux de travail et des expériences de RR . Voici une liste des outils les plus populaires dans cette catégorie, au meilleur de ma connaissance (par ordre décroissant de popularité):

• Taverna Workflow Management System ( http://www.taverna.org.uk ) - ensemble d'outils très solides, bien qu'un peu trop complexes. L'outil principal est un logiciel de bureau basé sur Java. Cependant, il est compatible avec le portail de référentiel de flux de travail en ligne myExperiment ( http://www.myexperiment.org ), dans lequel l'utilisateur peut stocker et partager ses flux de travail RR. Le portail RR basé sur le Web, entièrement compatible avec Taverna s'appelle Taverna Online , mais il est développé et maintenu par une organisation totalement différente en Russie (appelée ici OnlineHPC : http://onlinehpc.com ).

• Le projet Kepler ( https://kepler-project.org )

• VisTrails ( http://vistrails.org )

• Madagascar ( http://www.reproducibility.org )

Exemple . Voici un article intéressant sur les flux de travail scientifiques avec un exemple de la conception de flux de travail et de l'analyse de données réelles , basés sur l'utilisation de projets Kepler et myExperiment : http://f1000research.com/articles/3-110/v1 .

Il existe de nombreux outils RR qui implémentent le paradigme de la programmation alphabétisée , illustrés par LaTeXla famille de logiciels. Les outils d'aide à la création et à la présentation de rapports constituent également une grande catégorie, Sweaveet knitrsont probablement les plus connus. Sweaveest un outil, axé sur R, mais il peut être intégré à des projets basés sur Python, avec toutefois des efforts supplémentaires ( https://stackoverflow.com/questions/2161152/sweave-for-python ). Je pense que cela knitrpourrait être une meilleure option, car elle est moderne, supportée par des outils populaires (tels que RStudio) et indépendante de la langue ( http://yihui.name/knitr/demo/engines ).

3) Protocole et structure de répertoire suggérée . Si j'ai bien compris ce que vous avez sous-entendu en utilisant le terme protocole ( workflow ), je pense généralement que le workflow d'analyse de données RR standard comprend les phases suivantes: collecte des données => préparation des données (nettoyage, transformation, fusion, échantillonnage) => analyse des données => présentation des résultats (production de rapports et / ou de présentations). Néanmoins, chaque flux de travail est spécifique à un projet et, par conséquent, certaines tâches spécifiques peuvent nécessiter l'ajout d'étapes supplémentaires.

Pour un exemple de structure de répertoires, vous pouvez consulter la documentation du package R ProjectTemplate( http://projecttemplate.net ), afin d'automatiser les flux de travail et les projets d'analyse de données:

4) Outils de construction / exécution automatisés . Étant donné que ma réponse est axée sur les outils RR universels (indépendants de la langue), les outils les plus populaires sont make. Lisez l'article suivant pour quelques raisons d'utiliser makel'outil d'automatisation de flux de travaux RR préféré: http://bost.ocks.org/mike/make . Il existe certainement d'autres outils similaires , qui améliorent certains aspects de make, ou ajoutent des fonctionnalités supplémentaires. Par exemple: ant(officiellement, Apache Ant: http://ant.apache.org ), Maven("nouvelle génération ant": http://maven.apache.org ), rake( https://github.com/ruby/rake ) , Makepp( http://makepp.sourceforge.net) Pour une liste complète de ces outils, voir Wikipedia: http://fr.wikipedia.org/wiki/List_of_build_automation_software .

Depuis que j'ai commencé mes recherches dans le monde universitaire, je cherchais constamment un flux de travail satisfaisant. Je pense que j'ai finalement trouvé quelque chose qui me rend heureux:

1) Mettez tout sous contrôle de version, par exemple Git:

J'utilise GitHub pour les projets de recherche liés aux loisirs, tandis que j'utilise le serveur privé GitLab fourni par notre université pour les recherches au travail. Je garde aussi mes jeux de données là-bas.

2) Je fais la plupart de mes analyses avec la documentation sur les notebooks IPython. Il est très organisé (pour moi) d'avoir le code, les graphiques, et la discussion / conclusion dans un seul document. Si j'exécute des scripts plus volumineux, je les mettrais généralement dans des fichiers script séparés .py, mais je les exécuterais quand même. depuis le bloc-notes IPython via la magie% run pour ajouter des informations sur l’objet, le résultat et d’autres paramètres.

J'ai écrit une petite extension Cell-Magic pour les cahiers IPython et IPython, appelée "filigrane", que j'utilise pour créer facilement des horodatages et garder une trace des différentes versions de paquetages que j'ai utilisées, ainsi que des hashs Git.

Par exemple

%watermark

29/06/2014 01:19:10

CPython 3.4.1
IPython 2.1.0

compiler   : GCC 4.2.1 (Apple Inc. build 5577)
system     : Darwin
release    : 13.2.0
machine    : x86_64
processor  : i386
CPU cores  : 2
interpreter: 64bit

%watermark -d -t

29/06/2014 01:19:11 

%watermark -v -m -p numpy,scipy

CPython 3.4.1
IPython 2.1.0

numpy 1.8.1
scipy 0.14.0

compiler   : GCC 4.2.1 (Apple Inc. build 5577)
system     : Darwin
release    : 13.2.0
machine    : x86_64
processor  : i386
CPU cores  : 2
interpreter: 64bit

Pour plus d'informations, voir la documentation ici .

Le meilleur outil de reproductibilité consiste à consigner vos actions dans un journal:

experiment/input ; expected ; observation/output ; current hypothesis and if supported or rejected
exp1 ; expected1 ; obs1 ; some fancy hypothesis, supported

Cela peut être écrit sur un papier, mais si vos expériences s’inscrivent dans un cadre informatique, vous pouvez utiliser des outils informatiques pour automatiser en partie ou en totalité ce processus de journalisation (notamment en vous aidant à suivre les jeux de données en entrée Les figures).

IPython / Jupyter Notebook est un excellent outil de reproductibilité pour Python avec une courbe d’apprentissage faible (n'oubliez pas les magies % logon et% logstart ). Astuce: pour vous assurer que votre ordinateur est reproductible, redémarrez le noyau et essayez d’exécuter toutes les cellules de haut en bas (bouton Exécuter toutes les cellules): si cela fonctionne, enregistrez tout dans un fichier d’archive ("gel"), sinon, notamment Si vous devez exécuter des cellules de manière non linéaire, non séquentielle et non évidente pour éviter les erreurs, vous devez retravailler un peu.

Un autre excellent outil très récent (2015) est recipy , qui ressemble beaucoup à sumatra (voir ci-dessous), mais spécialement conçu pour Python. Je ne sais pas si cela fonctionne avec les ordinateurs portables Jupyter, mais je sais que l'auteur les utilise fréquemment, donc je suppose que si ce n'est pas actuellement pris en charge, ce le sera dans le futur.

Git est également génial et n'est pas lié à Python. Il vous aidera non seulement à garder un historique de toutes vos expériences, le code, les ensembles de données, chiffres, etc. , mais aussi vous fournir des outils pour maintenir ( git pickaxe ), collaborer ( blâme ) et debug ( git - bisect ) à l' aide d' un scientifique méthode de débogage (appelée débogage delta ). Voici l'histoire d'un chercheur fictif qui tente de créer son propre système de journalisation d'expériences, jusqu'à ce qu'il devienne un fac-similé de Git.

Un autre outil de travail général avec une langue (avec une API Python sur pypi ) est de Sumatra , qui est spécialement conçu pour vous aider à faire réplicables la recherche ( réplicables vise à produire les mêmes résultats étant donné le code exact même et logiciels, alors que la reproductibilité vise à produire le mêmes résultats, quel que soit le support utilisé, ce qui est beaucoup plus difficile, prend du temps et ne peut pas être automatisé).

Voici comment Sumatra fonctionne: pour chaque expérience que vous menez à travers Sumatra, ce logiciel agira comme un "état de sauvegarde", que l’on trouve souvent dans les jeux vidéo. Plus précisément, vous économiserez:

• tous les paramètres que vous avez fournis;
• l'état exact du code source de l'ensemble de votre application expérimentale et de vos fichiers de configuration;
• les résultats / tracés / résultats ainsi que tout fichier généré par votre application expérimentale.

Il construira ensuite une base de données avec l'horodatage et d'autres métadonnées pour chacune de vos expériences, que vous pourrez analyser ultérieurement à l'aide de l'interface WebGUI. Sumatra ayant enregistré l’état complet de votre application pour une expérience spécifique à un moment donné, vous pouvez restaurer le code qui a produit un résultat spécifique à tout moment. Vous disposez ainsi d’une recherche reproductible à faible coût (sauf pour le stockage si vous travaillez sur d’énormes jeux de données, mais vous pouvez configurer des exceptions si vous ne voulez pas tout sauvegarder à chaque fois).

GNOME Zeitgeist (auparavant codé en Python mais maintenant porté en vala) est un autre outil formidable , un système de journalisation des actions très complet, qui enregistre tout ce que vous faites et qui peut utiliser l’apprentissage automatique pour résumer sur une période donnée les relations entre les éléments. sur la similarité et les schémas d'utilisation, par exemple en répondant à des questions du type "Qu'est-ce qui était le plus pertinent pour moi pendant que je travaillais sur le projet X pendant un mois l'année dernière?" . Fait intéressant, Zim Desktop Wiki , une application de prise de notes similaire à Evernote, possède un plugin pour travailler avec Zeitgeist.

En fin de compte, vous pouvez utiliser Git ou Sumatra ou tout autre logiciel de votre choix. Ils vous fourniront à peu près le même pouvoir de réplication, mais Sumatra est spécialement conçu pour la recherche scientifique. Il fournit donc quelques outils sophistiqués, tels qu'une interface graphique Web, vos résultats, alors que Git est plus adapté à la maintenance du code (mais il a des outils de débogage comme git-bisect, donc si vos expériences impliquent des codes, ce sera peut-être mieux). Ou bien sûr, vous pouvez utiliser les deux!

/ EDIT: dsign a touché un point très important ici: la réplicabilité de votre configuration est aussi importante que la réplicabilité de votre application. En d'autres termes, vous devez au moins fournir une liste complète des bibliothèques et des compilateurs que vous avez utilisés, avec leurs versions exactes et les détails de votre plate - forme .

Personnellement, dans l'informatique scientifique avec Python, j'ai trouvé qu'il était trop pénible d'empaqueter une application avec les bibliothèques. C'est pourquoi je viens maintenant d'utiliser un package python scientifique tout-en-un tel qu'Anaconda (avec l'excellent gestionnaire de paquets conda ), et juste conseiller aux utilisateurs d'utiliser le même paquet. Une autre solution pourrait consister à fournir un script pour générer automatiquement un fichier virtualenv ou à tout emballer à l’aide de l’ application commerciale Docker citée par dsign ou par le Vagrant opensource (avec par exemple pylearn2-in-a-box qui utilise Vagrant pour produire un fichier facilement distribuable). paquet d'environnement virtuel).

Enfin, pour réellement disposer d'un environnement de travail complet à chaque fois que vous en avez besoin, vous pouvez créer une machine virtuelle (voir VirtualBox). Vous pouvez même enregistrer l'état de la machine (capture instantanée) avec votre expérience prête à être exécutée à l'intérieur. Ensuite, vous pouvez simplement partager cette machine virtuelle avec tout ce qui est inclus afin que tout le monde puisse répliquer votre expérience avec votre configuration exacte. C’est probablement le meilleur moyen de reproduire une expérience logicielle. Les conteneurs peuvent constituer une alternative plus légère, mais ils n'incluent pas l'environnement complet, de sorte que la fidélité de la réplication sera moins robuste.

/ EDIT2: Voici une superbe vidéo résumant (pour le débogage mais qui peut aussi s’appliquer à la recherche) ce qui est fondamental pour faire une recherche reproductible: enregistrer vos expériences et les étapes de la méthode scientifique, une sorte d ’ " expérimentation explicite " .

Assurez-vous de vérifier docker ! Et en général, toutes les autres bonnes choses que le génie logiciel a créées au cours des décennies pour assurer l’isolation et la reproductibilité.

Je voudrais souligner qu'il ne suffit pas d'avoir simplement des flux de travail reproductibles, mais aussi facile à reproduire des flux de travail. Laissez-moi montrer ce que je veux dire. Supposons que votre projet utilise Python, une base de données X et Scipy. Vous utiliserez sûrement une bibliothèque spécifique pour vous connecter à votre base de données à partir de Python, et Scipy utilisera à son tour des routines algébriques clairsemées. Ceci est bien sûr une configuration très simple, mais pas tout à fait simple à installer, jeu de mots. Si quelqu'un veut exécuter vos scripts, il devra installer toutes les dépendances. Ou pire, elle pourrait avoir des versions incompatibles déjà installées. Réparer ces choses prend du temps. Cela vous prendra également du temps si, à un moment donné, vous devez déplacer vos calculs vers un cluster, vers un autre cluster ou vers certains serveurs de cloud.

Voici où je trouve le docker utile. Docker est un moyen de formaliser et de compiler des recettes pour des environnements binaires. Vous pouvez écrire ce qui suit dans un fichier docker (j'utilise ici un anglais simple à la place de la syntaxe Dockerfile):

• Commencez avec un environnement binaire de base, comme celui d'Ubuntu
• Installez libsparse-dev
• (Pip) Installez Numpy et Scipy
• Installer X
• Installez libX-dev
• (Pip) Installez python-X
• Installer IPython-Notebook
• Copiez mes scripts / cahiers python dans mon environnement binaire, ces fichiers de données et ces configurations pour effectuer d’autres tâches diverses. Pour garantir la reproductibilité, copiez-les à partir d'une URL nommée au lieu d'un fichier local.
• Peut-être exécuter IPython-Notebook.

Certaines lignes installeront des choses en Python à l’aide de pip, ce dernier pouvant effectuer un travail très propre en sélectionnant des versions de paquetages spécifiques. Vérifiez aussi!

Et c'est tout. Si, après avoir créé votre fichier Dockerfile, il peut être créé, il peut être créé n'importe où, par n'importe qui (à condition qu'il ait également accès aux fichiers spécifiques à votre projet, par exemple parce que vous les avez placés dans une URL publique référencée à partir du fichier Dockerfile). Dans le meilleur des cas, vous pouvez télécharger l'environnement résultant (appelé "image") sur un serveur public ou privé (appelé "registre") pour que d'autres personnes l'utilisent. Ainsi, lorsque vous publiez votre flux de travail, vous disposez à la fois d'une recette entièrement reproductible sous la forme d'un fichier Docker, et d'un moyen simple pour vous ou d'autres personnes de reproduire ce que vous faites:

docker run dockerregistery.thewheezylab.org/nowyouwillbelieveme

Ou s'ils veulent fouiller dans vos scripts, etc.:

docker run -i -t dockerregistery.thewheezylab.org/nowyouwillbelieveme /bin/bash

Malheureusement, je n'ai pas assez de points de réputation pour répondre au message de Plank, je dois donc répondre à tout le fil - désolé pour cela.

En fait, je suis le développeur du référentiel de connaissances collectives open source mentionné ci-dessus. Il tente de simplifier le partage des artefacts et des workflows expérimentaux en tant que composants Python réutilisables et reproductibles avec API JSON unifiée et méta JSON partagés via GitHub. Ils peuvent également être connectés à l'analyse prédictive avec la même API JSON unifiée.

Nous venons de publier la nouvelle version V1.8.1 et avons fourni une documentation complète. Nous espérons donc que les concepts seront plus faciles à comprendre: http://github.com/ctuning/ck/wiki

Nous avons maintenant de nombreux projets académiques et industriels basés sur ce cadre, vous pouvez donc en vérifier un: l'optimisation du programme de crowdsourcing sur des appareils mobiles fournis par des volontaires de manière reproductible: http://cknowledge.org/repo

Nous suivons également diverses ressources liées à la science reproductible ici: https://github.com/ctuning/ck/wiki/Enabling-open-science

Bien que mon objectif principal soit de rendre les recherches sur les systèmes informatiques reproductibles, j’ai eu des discussions intéressantes avec des collègues d’autres domaines et il me semble que leurs problèmes sont très similaires. Je serai donc très heureux si notre cadre peut être d'une quelconque aide pour les autres communautés! Si vous avez des questions ou des suggestions, n'hésitez pas à nous contacter!

Il existe un cours entier consacré à la recherche reproductible. https://www.coursera.org/learn/reproducible-research Ce cours est basé sur R, mais l'idée sous-jacente peut être apprise.

Un moyen simple est d’avoir un cahier Ipython et d’enregistrer en permanence chaque tâche fastidieuse, qu’il s’agisse de nettoyer les données, d’analyser l’exploration ou de construire le modèle.

Je suis récemment tombé sur l'outil suivant - http://github.com/ctuning/ck . Il est déjà écrit en Python et semble inclure ce dont vous avez besoin (mon collègue l’utilise dans le projet pilote pour automatiser la reconnaissance d’image).

Avantages:

1. très petit, portable et personnalisable
2. comprend un serveur Web pour diffuser les expériences et les traiter à l'aide de l'analyse prédictive
3. a un bon exemple d'utilisation pour externaliser et reproduire l'optimisation du compilateur - http://cknowledge.org/repo

Les inconvénients:

1. un peu bas niveau - vous devez implémenter votre propre flux de travail à partir de composants Python partagés via GitHub à l'aide de l'API JSON ou d'une ligne de commande
2. la documentation est quelque peu complexe - j'espère vraiment qu'ils trouveront le temps de la mettre à jour rapidement.

J'ai créé et récemment publié un outil open source http://dvc.org ou DVC qui fait exactement ce que vous essayez d'atteindre:

1. [Outils pour le contrôle de version de données.] DVC fonctionne sur Git, ajoute un contrôle de version de fichier de données (les fichiers sont stockés en dehors de Git) et suit les dépendances entre le code et les fichiers de données. DVC dérive automatiquement le graphe de dépendance (DAG) pour le code et les données.
2. [Outils permettant de reproduire des étapes et des expériences.] dvc repro data/scores.csvReproduit toutes les étapes requises concernant le DAG.
3. [Protocole et structure de répertoires suggérée pour un tel projet.] DVC nécessitait un répertoire de données ( datapar défaut) dans lequel vous supposiez stocker tous les fichiers de données. Cependant, DVC déplace de manière transparente le contenu réel vers le .cacherépertoire et crée les liens symboliques (oui, je l’ai également fait fonctionner sous Windows). Le .cacherépertoire n'est pas synchronisé avec Git, mais il peut être synchronisé via le cloud (S3 ou GCP) par commande dvc sync data/scores.csv(il synchronise le fichier de données correspondant à partir du cache .cache/scores.csv_29de545).
4. [Outils de génération / exécution automatisés.] Voir ci-dessus.

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

AVERTISSEMENT: Je travaille pour une société, Datmo , qui crée un outil open source pour le faire.

La meilleure pratique pour la reproductibilité est la suivante:

1) Commencez par conteneuriser votre environnement dans un environnement Docker en créant un fichier Docker et en veillant à ce que toutes les dépendances soient couvertes dans ce fichier. J'ai trouvé que cette ressource était la meilleure ( https://arxiv.org/pdf/1410.0846.pdf )

2) Une fois que vous avez cela choisi, vous devrez décider où vous pouvez suivre toutes les métriques et configurations de performances (afin de pouvoir les revoir pour de futures expérimentations).

3) Enfin, rédigez de la documentation pour qu'un nouvel expérimentateur / développeur puisse revoir votre code, le répliquer avec l'environnement et voir où vous avez conservé vos configurations et vos métriques de performance.