Herramientas y protocolo para la ciencia de datos reproducibles usando Python

Estoy trabajando en un proyecto de ciencia de datos usando Python. El proyecto tiene varias etapas. Cada etapa consiste en tomar un conjunto de datos, usar scripts de Python, datos auxiliares, configuración y parámetros, y crear otro conjunto de datos. Guardo el código en git, para que esa parte quede cubierta. Me gustaría saber sobre:

1. Herramientas para el control de versiones de datos.
2. Herramientas que permiten reproducir etapas y experimentos.
3. Protocolo y estructura de directorio sugerida para tal proyecto.
4. Herramientas automatizadas de compilación / ejecución.

El tema de la investigación reproducible (RR) es muy popular hoy y, en consecuencia, es enorme , pero espero que mi respuesta sea lo suficientemente completa como respuesta y proporcione suficiente información para futuras investigaciones , en caso de que decida hacerlo.

Si bien existen herramientas específicas de Python para RR, creo que tiene más sentido centrarse en herramientas más universales (nunca se sabe con seguridad con qué lenguajes de programación y entornos informáticos trabajará en el futuro). Dicho esto, echemos un vistazo a las herramientas disponibles según su lista.

1) Herramientas para el control de versiones de datos . A menos que planee trabajar con (muy) grandes datos , supongo que tendría sentido usar el mismo git, que usa para el control de la versión del código fuente. La infraestructura ya está ahí. Incluso si sus archivos son binarios y grandes, este consejo puede ser útil: https://stackoverflow.com/questions/540535/managing-large-binary-files-with-git .

2) Herramientas para gestionar flujos de trabajo y experimentos RR . Aquí hay una lista de las herramientas más populares en esta categoría, que yo sepa (en el orden descendente de popularidad):

• Taverna Workflow Management System ( http://www.taverna.org.uk ): conjunto de herramientas muy sólido, aunque demasiado complejo. La herramienta principal es un software de escritorio basado en Java. Sin embargo, es compatible con el portal de repositorio de flujo de trabajo en línea myExperiment ( http://www.myexperiment.org ), donde el usuario puede almacenar y compartir sus flujos de trabajo RR. El portal RR basado en la web, totalmente compatible con Taverna se llama Taverna Online , pero está siendo desarrollado y mantenido por una organización totalmente diferente en Rusia (denominado OnlineHPC : http://onlinehpc.com ).

• El Proyecto Kepler ( https://kepler-project.org )

• VisTrails ( http://vistrails.org )

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

Ejemplo . Aquí hay un artículo interesante sobre flujos de trabajo científicos con un ejemplo del diseño real del flujo de trabajo y el análisis de datos, basado en el uso de proyectos Kepler y myExperiment : http://f1000research.com/articles/3-110/v1 .

Existen muchas herramientas RR que implementan el paradigma de programación alfabetizada , ejemplificado por LaTeXla familia de software. Las herramientas que ayudan en la generación y presentación de informes también son una gran categoría, donde Sweavey knitrprobablemente sean las más conocidas. Sweavees una herramienta, enfocada en R, pero se puede integrar con proyectos basados ​​en Python, aunque con un esfuerzo adicional ( https://stackoverflow.com/questions/2161152/sweave-for-python ). Creo que esa knitrpodría ser una mejor opción, ya que es moderna, tiene un amplio soporte de herramientas populares (como RStudio) y es neutral en cuanto al idioma ( http://yihui.name/knitr/demo/engines ).

3) Protocolo y estructura de directorios sugerida . Si entendí correctamente lo que usted implica al usar el protocolo de término ( flujo de trabajo ), en general creo que el flujo de trabajo de análisis de datos RR estándar consta de las siguientes fases secuenciales: recopilación de datos => preparación de datos (limpieza, transformación, fusión, muestreo) => análisis de datos => presentación de resultados (generación de informes y / o presentaciones). Sin embargo, cada flujo de trabajo es específico del proyecto y, por lo tanto, algunas tareas específicas pueden requerir agregar pasos adicionales.

Para obtener una estructura de directorio de muestra, puede consultar la documentación del paquete R ProjectTemplate( http://projecttemplate.net ), como un intento de automatizar los flujos de trabajo y proyectos de análisis de datos:

4) Herramientas automatizadas de compilación / ejecución . Como mi respuesta se centra en las herramientas RR universales (sin lenguaje), las herramientas más populares son make. Lea el siguiente artículo para conocer algunos motivos para utilizarlo makecomo la herramienta de automatización de flujo de trabajo RR preferida: http://bost.ocks.org/mike/make . Ciertamente, hay otras herramientas similares que mejoran algunos aspectos makeo agregan algunas características adicionales. Por ejemplo: ant(oficialmente, Apache Ant: http://ant.apache.org ), Maven("próxima generación ant": http://maven.apache.org ), rake( https://github.com/ruby/rake ) , Makepp( http://makepp.sourceforge.net) Para obtener una lista completa de tales herramientas, consulte Wikipedia: http://en.wikipedia.org/wiki/List_of_build_automation_software .

Desde que comencé a investigar en la academia, buscaba constantemente un flujo de trabajo satisfactorio. Creo que finalmente encontré algo con lo que estoy feliz:

1) Ponga todo bajo control de versión, por ejemplo, Git:

Para proyectos de investigación de pasatiempos utilizo GitHub, para investigación en el trabajo utilizo el servidor privado GitLab que proporciona nuestra universidad. También mantengo mis conjuntos de datos allí.

2) Realizo la mayoría de mis análisis junto con la documentación en los portátiles IPython. Es muy organizado (para mí) tener el código, las tramas y la discusión / conclusión todo en un solo documento. desde el cuaderno de IPython a través de% run magic para agregar información sobre el propósito, el resultado y otros parámetros.

He escrito una pequeña extensión de magia de celdas para las notebooks IPython e IPython, llamada "marca de agua" que utilizo para crear convenientemente marcas de tiempo y realizar un seguimiento de las diferentes versiones de paquetes que utilicé y también los hash de Git

Por ejemplo

%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

Para obtener más información, consulte la documentación aquí .

La mejor herramienta de reproducibilidad es hacer un registro de sus acciones, algo como esto:

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

Esto puede escribirse en un papel, pero, si sus experimentos se ajustan a un marco computacional, puede usar herramientas computacionales para automatizar parcial o completamente ese proceso de registro (particularmente ayudándole a rastrear los conjuntos de datos de entrada que pueden ser enormes, y la salida cifras).

Por supuesto, una gran herramienta de reproducibilidad para Python con una curva de aprendizaje baja es IPython / Jupyter Notebook (no olvide las magias % logon y% logstart ). Consejo: para asegurarse de que su computadora portátil es reproducible, reinicie el núcleo e intente ejecutar todas las celdas de arriba a abajo (botón Ejecutar todas las celdas): si funciona, guarde todo en un archivo ("congelación"), de lo contrario, notablemente Si necesita ejecutar celdas de forma no lineal, no secuencial y no obvia para evitar errores, debe volver a trabajar un poco.

Otra gran herramienta que es muy reciente (2015) es recipy , que es muy similar a sumatra (ver más abajo), pero hecha específicamente para Python. No sé si funciona con los Cuadernos Jupyter, pero sé que el autor los usa con frecuencia, así que supongo que si no es compatible actualmente, lo será en el futuro.

Git también es increíble, y no está vinculado a Python. Le ayudará no solo a mantener un historial de todos sus experimentos, códigos, conjuntos de datos, figuras, etc., sino que también le proporcionará herramientas para mantener ( git pickaxe ), colaborar ( culpar ) y depurar ( git - bisect ) utilizando un científico método de depuración (llamado depuración delta ). Aquí hay una historia de un investigador ficticio que intenta hacer su propio sistema de registro de experimentos, hasta que termina siendo un facsímil de Git.

Otra herramienta general se trabaja con cualquier idioma (con un API Python en PyPI ) es de Sumatra , que está diseñado específicamente para ayudarle a hacer replicable investigación ( replicables tiene como objetivo producir los mismos resultados dado el mismo código y software, mientras reproducibilidad tiene como objetivo producir la Los mismos resultados dados en cualquier medio, que es mucho más difícil y lento y no automatizable).

Así es como funciona Sumatra: para cada experimento que realice a través de Sumatra, este software actuará como un "estado de guardar juego" que a menudo se encuentra en los videojuegos. Más precisamente, ahorrará:

• todos los parámetros que proporcionaste;
• el estado exacto del código fuente de toda su aplicación experimental y archivos de configuración;
• la salida / gráficos / resultados y también cualquier archivo producido por su aplicación experimental.

Luego construirá una base de datos con la marca de tiempo y otros metadatos para cada uno de sus experimentos, que luego puede rastrear usando la webGUI. Dado que Sumatra guardó el estado completo de su aplicación para un experimento específico en un punto específico en el tiempo, puede restaurar el código que produjo un resultado específico en cualquier momento que desee, por lo que tiene una investigación replicable a bajo costo (excepto para el almacenamiento si trabaja en grandes conjuntos de datos, pero puede configurar excepciones si no desea guardar todo cada vez).

Otra herramienta increíble es el Zeitgeist de GNOME (anteriormente codificado en Python pero ahora portado a Vala), un sistema de diario de acción que abarca todo el compás, que registra todo lo que haces y puede usar el aprendizaje automático para resumir durante un período de tiempo que deseas la relación entre elementos sobre patrones de similitud y uso, por ejemplo, responder preguntas como "¿Qué fue lo más relevante para mí, mientras trabajaba en el proyecto X, durante un mes el año pasado?" . Curiosamente, Zim Desktop Wiki , una aplicación para tomar notas similar a Evernote, tiene un complemento para trabajar con Zeitgeist.

Al final, puede usar Git o Sumatra o cualquier otro software que desee, le proporcionarán aproximadamente el mismo poder de replicación, pero Sumatra está específicamente diseñado para la investigación científica, por lo que proporciona algunas herramientas sofisticadas como una GUI web para rastrear sus resultados, mientras que Git se adapta más al mantenimiento del código (pero tiene herramientas de depuración como git-bisect, por lo que si sus experimentos involucran códigos, en realidad puede ser mejor). ¡O, por supuesto, puedes usar ambos!

/ EDITAR: dsign tocó un punto muy importante aquí: la replicabilidad de su configuración es tan importante como la replicabilidad de su aplicación. En otras palabras, al menos debe proporcionar una lista completa de las bibliotecas y compiladores que utilizó junto con sus versiones exactas y los detalles de su plataforma .

Personalmente, en informática científica con Python, descubrí que empaquetar una aplicación junto con las bibliotecas es demasiado doloroso, por lo que ahora solo uso un paquete Python científico todo en uno como Anaconda (con el gran administrador de paquetes conda ), y solo aconseje a los usuarios que usen el mismo paquete. Otra solución podría ser proporcionar un script para generar automáticamente un virtualenv , o empaquetar todo utilizando la aplicación comercial Docker como se cita por dsign o el Vagrant de código abierto (por ejemplo, pylearn2-in-a-box que usa Vagrant para producir un redistribuible fácilmente paquete de entorno virtual).

Finalmente, para asegurarse realmente de tener un entorno de trabajo completo cada vez que lo necesite, puede hacer una máquina virtual (consulte VirtualBox) e incluso puede guardar el estado de la máquina (instantánea) con su experimento listo para ejecutarse en su interior. Luego puede compartir esta máquina virtual con todo lo incluido para que cualquiera pueda replicar su experimento con su configuración exacta. Esta es probablemente la mejor manera de replicar un experimento basado en software. Los contenedores pueden ser una alternativa más liviana, pero no incluyen todo el entorno, por lo que la fidelidad de replicación será menos robusta.

/ EDIT2: Aquí hay un gran video que resume (para la depuración, pero esto también se puede aplicar a la investigación) lo que es fundamental para hacer una investigación reproducible: registrar sus experimentos y otros pasos del método científico, una especie de "experimentación explícita" .

¡Asegúrate de ver la ventana acoplable ! Y, en general, todas las otras cosas buenas que la ingeniería de software ha creado a lo largo de décadas para garantizar el aislamiento y la reproducibilidad.

Me gustaría enfatizar que no es suficiente tener solo flujos de trabajo reproducibles, sino también flujos de trabajo fáciles de reproducir. Déjame mostrarte lo que quiero decir. Suponga que su proyecto usa Python, una base de datos X y Scipy. Seguramente usará una biblioteca específica para conectarse a su base de datos desde Python, y Scipy utilizará algunas rutinas algebraicas dispersas. Esto es, por supuesto, una configuración muy simple, pero no del todo simple, juego de palabras. Si alguien quiere ejecutar sus scripts, tendrá que instalar todas las dependencias. O peor, podría tener versiones incompatibles ya instaladas. Arreglar esas cosas lleva tiempo. También le llevará tiempo si en algún momento necesita mover sus cálculos a un clúster, a un clúster diferente o a algunos servidores en la nube.

Aquí es donde encuentro útil Docker. Docker es una forma de formalizar y compilar recetas para entornos binarios. Puede escribir lo siguiente en un dockerfile (estoy usando aquí inglés simple en lugar de la sintaxis de Dockerfile):

• Comience con un entorno binario básico, como el de Ubuntu
• Instalar libsparse-dev
• (Pip) Instalar numpy y scipy
• Instalar X
• Instalar libX-dev
• (Pip) Instalar python-X
• Instalar IPython-Notebook
• Copio mis scripts / cuadernos de Python a mi entorno binario, estos archivos de datos y estas configuraciones para hacer otras cosas misceláneas. Para garantizar la reproducibilidad, cópielos desde una URL con nombre en lugar de un archivo local.
• Tal vez ejecute IPython-Notebook.

Algunas de las líneas instalarán cosas en Python usando pip, ya que pip puede hacer un trabajo muy limpio al seleccionar versiones específicas de paquetes. ¡Compruébalo también!

Y eso es. Si después de crear su Dockerfile se puede construir, cualquiera puede hacerlo en cualquier lugar (siempre que también tengan acceso a sus archivos específicos del proyecto, por ejemplo, porque los puso en una URL pública a la que se hace referencia desde el Dockerfile). Lo mejor es que puede cargar el entorno resultante (denominado "imagen") en un servidor público o privado (denominado "registro") para que lo utilicen otras personas. Entonces, cuando publica su flujo de trabajo, tiene una receta totalmente reproducible en forma de Dockerfile y una manera fácil para que usted u otras personas reproduzcan lo que hace:

docker run dockerregistery.thewheezylab.org/nowyouwillbelieveme

O si quieren hurgar en sus guiones y demás:

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

Desafortunadamente, no tengo suficientes puntos de reputación para responder a la publicación de Plank, así que tengo que responder a todo el hilo, lo siento.

De hecho, soy el desarrollador del marco de conocimiento colectivo de código abierto mencionado anteriormente. Intenta simplificar el intercambio de artefactos y flujos de trabajo experimentales como componentes Python reutilizables y reproducibles con API unificada JSON y meta JSON compartido a través de GitHub. También se pueden conectar a análisis predictivos con la misma API unificada de JSON.

Acabamos de lanzar la nueva versión V1.8.1 y proporcionamos una extensa documentación, así que espero que ahora sea más fácil entender los conceptos: http://github.com/ctuning/ck/wiki

Ahora tenemos muchos proyectos académicos e industriales basados ​​en este marco, por lo que puede consultar uno de ellos: optimización del programa de crowdsourcing en dispositivos móviles proporcionados por voluntarios de forma reproducible: http://cknowledge.org/repo

También hacemos un seguimiento de varios recursos relacionados con la ciencia reproducible aquí: https://github.com/ctuning/ck/wiki/Enabling-open-science

Aunque me estoy centrando principalmente en hacer que la investigación de los sistemas informáticos sea reproducible, tuve conversaciones interesantes con colegas de otros dominios y parece que tienen problemas muy similares. Por lo tanto, ¡estaré muy feliz si nuestro marco puede ser de alguna ayuda para otras comunidades! Si tiene alguna pregunta o sugerencia, ¡no dude en ponerse en contacto!

Hay un curso completo dedicado a la investigación reproducible. https://www.coursera.org/learn/reproducible-research Este curso se basa en R, pero la idea subyacente se puede aprender.

Una manera simple es tener una computadora portátil Ipython y guardar todo el trabajo sucio que haga, ya sea limpiar los datos, realizar análisis exploratorios o construir el modelo.

Recientemente me encontré con la siguiente herramienta: http://github.com/ctuning/ck . Ya está escrito en Python y parece incluir lo que necesita (mi colega lo está utilizando en el proyecto piloto para automatizar el reconocimiento de imágenes).

Pros:

1. muy pequeño, portátil y personalizable
2. incluye servidor web para distribuir experimentos y procesarlos usando análisis predictivos
3. tiene un ejemplo de uso genial para crowdsource y reproducir la optimización del compilador - http://cknowledge.org/repo

Contras:

1. un poco bajo nivel: necesita implementar su propio flujo de trabajo desde los componentes de Python compartidos a través de GitHub usando la API JSON o la línea de comandos
2. la documentación es algo compleja, realmente espero que encuentren tiempo para actualizarla pronto.

Creé y lancé recientemente una herramienta de código abierto http://dvc.org o DVC que hace exactamente lo que está intentando alcanzar:

1. [Herramientas para el control de la versión de datos.] DVC funciona sobre Git, agrega el control de la versión del archivo de datos (los archivos se almacenan fuera de Git) y rastrea las dependencias entre el código y los archivos de datos. DVC deriva automáticamente el gráfico de dependencia (DAG) para el código y los datos.
2. [Herramientas que permiten reproducir etapas y experimentos.] dvc repro data/scores.csvReproduce todos los pasos necesarios con respecto a DAG.
3. [Protocolo y estructura de directorio sugerida para tal proyecto.] DVC requería un directorio de datos ( datapor defecto) donde se suponía que debía almacenar todos los archivos de datos. Sin embargo, DVC transparente mueve el contenido real de .cachedirectorio y crea los enlaces simbólicos (sí, lo hice para el trabajo en Windows también). El .cachedirectorio no está sincronizado con Git, pero podría sincronizarse a través de la nube (S3 o GCP) mediante un comando dvc sync data/scores.csv(sincroniza el archivo de datos correspondiente de la memoria caché como .cache/scores.csv_29de545)
4. [Herramientas automatizadas de compilación / ejecución.] Ver más arriba

El tutorial de DVC es un buen punto de partida: "Control de versión de datos: aprendizaje automático iterativo" .

DESCARGO DE RESPONSABILIDAD: Trabajo en una empresa, Datmo , que crea una herramienta de código abierto para hacer esto.

La mejor práctica para la reproducibilidad es la siguiente:

1) Primero contenga su entorno en un entorno Docker creando un Dockerfile y asegurándose de que todas las dependencias estén cubiertas en ese archivo. Encontré que este recurso es el mejor ( https://arxiv.org/pdf/1410.0846.pdf )

2) Una vez que tenga eso, querrá decidir dónde puede realizar un seguimiento de todas las métricas y configuraciones de rendimiento (para que pueda volver a visitarlo para futuras experimentaciones)

3) Finalmente, escriba alguna documentación para que un nuevo experimentador / desarrollador pueda volver a visitar su código, replicarlo con el entorno y ver dónde ha guardado sus configuraciones y métricas de rendimiento.