Cree herramientas en proyectos de aprendizaje automático, una descripción general

Me preguntaba sobre la estructura del proyecto de aprendizaje automático / ciencia de datos / flujo de trabajo y estaba leyendo diferentes opiniones sobre el tema. Y cuando las personas comienzan a hablar sobre el flujo de trabajo, quieren que sus flujos de trabajo sean reproducibles. Hay muchas publicaciones que sugieren usar make para mantener el flujo de trabajo reproducible. Aunque make es muy estable y ampliamente utilizado, personalmente me gustan las soluciones multiplataforma. Después de todo, es 2019, no 1977. Se puede argumentar que hacerse es multiplataforma, pero en realidad tendrá problemas y pasará tiempo arreglando su herramienta en lugar de hacer el trabajo real. Así que decidí echar un vistazo y ver qué otras herramientas están disponibles. Sí, decidí dedicar algo de tiempo a las herramientas.


Esta publicación es más una invitación a un diálogo que un tutorial. Quizás tu solución sea perfecta. Si es así, será interesante escucharlo.

En esta publicación usaré un pequeño proyecto de Python y haré las mismas tareas de automatización con diferentes sistemas:

• CMake
• Pybuilder
• pynt
• Adoquín
• doit
• Luigi

Habrá una tabla de comparación al final de la publicación.

La mayoría de las herramientas que analizaré se conocen como software de automatización de compilación o sistemas de compilación . Hay miles de ellos en todos los sabores, tamaños y complejidades. La idea es la misma: el desarrollador define reglas para producir algunos resultados de manera automatizada y consistente. Por ejemplo, un resultado podría ser una imagen con un gráfico. Para hacer esta imagen, uno necesitaría descargar los datos, limpiar los datos y hacer algunas manipulaciones de datos (ejemplo clásico, realmente). Puede comenzar con un par de scripts de shell que harán el trabajo. Una vez que regrese al proyecto un año después, será difícil recordar todos los pasos y el orden que debe seguir para crear esa imagen. La solución obvia es documentar todos los pasos. Buenas noticias! Los sistemas de construcción le permiten documentar los pasos en forma de programa de computadora. Algunos sistemas de compilación son como sus scripts de shell, pero con campanas y silbatos adicionales.

La base de esta publicación es una serie de publicaciones de Mateusz Bednarski sobre flujo de trabajo automatizado para un proyecto de aprendizaje automático. Mateusz explica sus puntos de vista y proporciona recetas para usar make . Te animo a que vayas y revises sus publicaciones primero. Usaré principalmente su código, pero con diferentes sistemas de compilación.

Si desea obtener más información sobre make , a continuación encontrará referencias para un par de publicaciones. Brooke Kennedy ofrece una descripción general de alto nivel en 5 sencillos pasos para hacer que su proyecto de ciencia de datos sea reproducible. Zachary Jones brinda más detalles sobre la sintaxis y las capacidades junto con los enlaces a otras publicaciones. David Stevens escribe una publicación muy publicitaria sobre por qué absolutamente tienes que comenzar a usar make inmediato. Proporciona buenos ejemplos que comparan la manera antigua y la nueva . Samuel Lampa , por otro lado, escribe sobre por qué usar make es una mala idea.

Mi selección de sistemas de compilación no es exhaustiva ni imparcial. Si desea hacer su lista, Wikipedia podría ser un buen punto de partida. Como se indicó anteriormente, cubriré CMake , PyBuilder , pynt , Paver , doit y Luigi . La mayoría de las herramientas en esta lista están basadas en Python y tiene sentido ya que el proyecto está en Python. Esta publicación no cubrirá cómo instalar las herramientas. Supongo que eres bastante competente en Python.

Estoy principalmente interesado en probar esta funcionalidad:

1. Especificar un par de objetivos con dependencias. Quiero ver cómo hacerlo y lo fácil que es.
2. Verificando si son posibles las construcciones incrementales. Esto significa que el sistema de compilación no reconstruirá lo que no ha cambiado desde la última ejecución, es decir, no necesita volver a descargar sus datos sin procesar. Otra cosa que buscaré es compilaciones incrementales cuando cambie la dependencia. Imagina que tenemos un gráfico de dependencias A -> B -> C ¿Se reconstruirá el objetivo C si B cambia? Si a?
3. Verificando si la reconstrucción se activará si se cambia el código fuente, es decir, si cambiamos el parámetro del gráfico generado, la próxima vez que construyamos la imagen debe reconstruirse.
4. Verificando las formas de limpiar los artefactos de compilación, es decir, eliminar los archivos que se crearon durante la compilación y volver al código fuente limpio.

No usaré todos los objetivos de compilación de la publicación de Mateusz, solo tres de ellos para ilustrar los principios.

Todo el código está disponible en GitHub .

CMake

CMake es un generador de scripts de compilación, que genera archivos de entrada para varios sistemas de compilación. Y su nombre significa marca multiplataforma. CMake es una herramienta de ingeniería de software. Su principal preocupación es la construcción de ejecutables y bibliotecas. Entonces CMake sabe cómo construir objetivos a partir del código fuente en los idiomas compatibles. CMake se ejecuta en dos pasos: configuración y generación. Durante la configuración, es posible configurar la compilación futura según las necesidades. Por ejemplo, las variables proporcionadas por el usuario se dan durante este paso. La generación normalmente es sencilla y produce archivos con los que los sistemas de compilación pueden trabajar. Con CMake, aún puede usar make , pero en lugar de escribir makefile directamente, escribe un archivo CMake, que generará el makefile por usted.

Otro concepto importante es que CMake fomenta las compilaciones fuera de la fuente . Las compilaciones fuera de la fuente mantienen el código fuente alejado de cualquier artefacto que produzca. Esto tiene mucho sentido para los ejecutables donde la base de código de fuente única puede compilarse bajo diferentes arquitecturas de CPU y sistemas operativos. Sin embargo, este enfoque puede contradecir la forma en que trabajan muchos científicos de datos. Me parece que la comunidad de ciencia de datos tiende a tener un alto acoplamiento de datos, código y resultados.

Veamos qué necesitamos para lograr nuestros objetivos con CMake. Hay dos posibilidades para definir cosas personalizadas en CMake: objetivos personalizados y comandos personalizados. Desafortunadamente, necesitaremos usar ambos, lo que da como resultado una mayor tipificación en comparación con el archivo MAKE vanila. Se considera que un objetivo personalizado siempre está desactualizado, es decir, si hay un objetivo para descargar datos sin procesar, CMake siempre lo volverá a descargar. Una combinación de comando personalizado con objetivo personalizado permite mantener los objetivos actualizados.

Para nuestro proyecto crearemos un archivo llamado CMakeLists.txt y lo colocaremos en la raíz del proyecto. Veamos el contenido:

 cmake_minimum_required(VERSION 3.14.0 FATAL_ERROR) project(Cmake_in_ml VERSION 0.1.0 LANGUAGES NONE) 

Esta parte es básica. La segunda línea define el nombre de su proyecto, versión y especifica que no usaremos ningún soporte de lenguaje incorporado (llamaremos scripts Python).

Nuestro primer objetivo descargará el conjunto de datos IRIS:

 SET(IRIS_URL "https://archive.ics.uci.edu/ml/machine-learning-databases/iris/iris.data" CACHE STRING "URL to the IRIS data") set(IRIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/data/raw) set(IRIS_FILE ${IRIS_DIR}/iris.csv) ADD_CUSTOM_COMMAND(OUTPUT ${IRIS_FILE} COMMAND ${CMAKE_COMMAND} -E echo "Downloading IRIS." COMMAND python src/data/download.py ${IRIS_URL} ${IRIS_FILE} COMMAND ${CMAKE_COMMAND} -E echo "Done. Checkout ${IRIS_FILE}." WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} ) ADD_CUSTOM_TARGET(rawdata ALL DEPENDS ${IRIS_FILE}) 

La primera línea define el parámetro IRIS_URL , que se expone al usuario durante el paso de configuración. Si usa CMake GUI, puede establecer esta variable a través de la GUI:



A continuación, definimos variables con la ubicación descargada del conjunto de datos IRIS. Luego agregamos un comando personalizado, que producirá IRIS_FILE como su salida. Al final, definimos un rawdata destino personalizado que depende de IRIS_FILE lo que significa que para construir rawdata IRIS_FILE debe construir rawdata . La opción ALL del objetivo personalizado dice que los datos rawdata serán uno de los objetivos predeterminados para construir. Tenga en cuenta que uso CMAKE_CURRENT_SOURCE_DIR para mantener los datos descargados en la carpeta de origen y no en la carpeta de compilación. Esto es solo para que sea lo mismo que Mateusz.

Muy bien, veamos cómo podemos usarlo. Actualmente lo estoy ejecutando en Windows con el compilador MinGW instalado. Es posible que deba ajustar la configuración del generador según sus necesidades (ejecute cmake --help para ver la lista de generadores disponibles). Encienda la terminal y vaya a la carpeta principal del código fuente, luego:

 mkdir overcome-the-chaos-build cd overcome-the-chaos-build cmake -G "MinGW Makefiles" ../overcome-the-chaos 

Con CMake moderno podemos construir el proyecto directamente desde CMake. Este comando invocará el comando build all :

 cmake --build . 

También podemos ver la lista de objetivos disponibles:

 cmake --build . --target help 

Y podemos eliminar el archivo descargado por:

 cmake --build . --target clean 

Vea que no necesitamos crear el objetivo limpio manualmente.

Ahora pasemos al siguiente objetivo: datos IRIS preprocesados. Mateusz crea dos archivos desde una sola función: processed.pickle y processed.xlsx . Puede ver cómo se va con la limpieza de este archivo de Excel utilizando rm con comodín. Creo que este no es un muy buen enfoque. En CMake, tenemos dos opciones de cómo tratarlo. La primera opción es usar la propiedad de directorio ADDITIONAL_MAKE_CLEAN_FILES . El código será:

 SET(PROCESSED_FILE ${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.pickle) ADD_CUSTOM_COMMAND(OUTPUT ${PROCESSED_FILE} COMMAND python src/data/preprocess.py ${IRIS_FILE} ${PROCESSED_FILE} --excel data/processed/processed.xlsx WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS rawdata ${IRIS_FILE} ) ADD_CUSTOM_TARGET(preprocess DEPENDS ${PROCESSED_FILE}) # Additional files to clean set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.xlsx ) 

La segunda opción es especificar una lista de archivos como salida de comando personalizada:

 LIST(APPEND PROCESSED_FILE "${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.pickle" "${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.xlsx" ) ADD_CUSTOM_COMMAND(OUTPUT ${PROCESSED_FILE} COMMAND python src/data/preprocess.py ${IRIS_FILE} data/processed/processed.pickle --excel data/processed/processed.xlsx WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS rawdata ${IRIS_FILE} src/data/preprocess.py ) ADD_CUSTOM_TARGET(preprocess DEPENDS ${PROCESSED_FILE}) 

Vea que en este caso creé la lista, pero no la utilicé dentro del comando personalizado. No conozco una manera de hacer referencia a los argumentos de salida del comando personalizado dentro de él.

Otra cosa interesante a tener en cuenta es que el uso de depends en este comando personalizado. Establecemos la dependencia no solo de un objetivo personalizado, sino también su salida y el script de Python. Si no agregamos dependencia a IRIS_FILE , la modificación manual de iris.csv no dará como resultado la reconstrucción del objetivo IRIS_FILE al IRIS_FILE . Bueno, no debes modificar los archivos en tu directorio de compilación manualmente en primer lugar. Solo dejándote saber. Más detalles en la publicación de Sam Thursday . La dependencia del script python es necesaria para reconstruir el destino si el script python cambia.

Y finalmente el tercer objetivo:

 SET(EXPLORATORY_IMG ${CMAKE_CURRENT_SOURCE_DIR}/reports/figures/exploratory.png) ADD_CUSTOM_COMMAND(OUTPUT ${EXPLORATORY_IMG} COMMAND python src/visualization/exploratory.py ${PROCESSED_FILE} ${EXPLORATORY_IMG} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS ${PROCESSED_FILE} src/visualization/exploratory.py ) ADD_CUSTOM_TARGET(exploratory DEPENDS ${EXPLORATORY_IMG}) 

Este objetivo es básicamente el mismo que el segundo.

Para terminar. CMake parece desordenado y más difícil que Make. De hecho, mucha gente critica a CMake por su sintaxis. En mi experiencia, la comprensión llegará y es absolutamente posible dar sentido incluso a los archivos CMake muy complicados.

Todavía se pegará mucho, ya que deberá pasar las variables correctas. No veo una manera fácil de hacer referencia a la salida de un comando personalizado en otro. Parece que es posible hacerlo a través de objetivos personalizados.

Pybuilder

La parte de PyBuilder es muy corta. Utilicé Python 3.7 en mi proyecto y la versión actual de PyBuilder 0.11.17 no lo admite. La solución propuesta es usar la versión de desarrollo. Sin embargo, esa versión está limitada a pip v9. Pip es v19.3 en el momento de la escritura. Bummer Después de jugar un poco con eso, no me funcionó en absoluto. La evaluación de PyBuilder fue de corta duración.

pynt

Pynt está basado en Python, lo que significa que podemos usar las funciones de Python directamente. No es necesario ajustarlos con un clic y proporcionar una interfaz de línea de comandos. Sin embargo, pynt también es capaz de ejecutar comandos de shell. Usaré las funciones de Python.

Los comandos de compilación se dan en un archivo build.py . Los objetivos / tareas se crean con decoradores de funciones. Las dependencias de tareas se proporcionan a través del mismo decorador.

Como me gustaría usar las funciones de Python, necesito importarlas en el script de compilación. Pynt no incluye el directorio actual como script de Python, por lo que escribir algo así:

 from src.data.download import pydownload_file 

No funcionará. Tenemos que hacer:

 import os import sys sys.path.append(os.path.join(os.path.dirname(__file__), '.')) from src.data.download import pydownload_file 

Mi archivo build.py inicial era así:

 #!/usr/bin/python import os import sys sys.path.append(os.path.join(os.path.dirname(__file__), '.')) from pynt import task from path import Path import glob from src.data.download import pydownload_file from src.data.preprocess import pypreprocess iris_file = 'data/raw/iris.csv' processed_file = 'data/processed/processed.pickle' @task() def rawdata(): '''Download IRIS dataset''' pydownload_file('https://archive.ics.uci.edu/ml/machine-learning-databases/iris/iris.data', iris_file) @task() def clean(): '''Clean all build artifacts''' patterns = ['data/raw/*.csv', 'data/processed/*.pickle', 'data/processed/*.xlsx', 'reports/figures/*.png'] for pat in patterns: for fl in glob.glob(pat): Path(fl).remove() @task(rawdata) def preprocess(): '''Preprocess IRIS dataset''' pypreprocess(iris_file, processed_file, 'data/processed/processed.xlsx') 

Y el objetivo del preprocess no funcionó. Constantemente se quejaba de los argumentos de entrada de la función pypreprocess . Parece que Pynt no maneja muy bien los argumentos de funciones opcionales. Tuve que eliminar el argumento para hacer el archivo de Excel. Tenga esto en cuenta si su proyecto tiene funciones con argumentos opcionales.

Podemos ejecutar pynt desde la carpeta del proyecto y enumerar todos los objetivos disponibles:

 pynt -l 

Hagamos la distribución por pares:

 pynt exploratory 

Si ahora ejecutamos el mismo comando nuevamente (es decir, pynt exploratory ) habrá una reconstrucción completa. Pynt no hizo un seguimiento de que nada ha cambiado.

Adoquín

Pavimentadora se ve casi exactamente como Pynt. Es ligeramente diferente en una forma en que uno define dependencias entre objetivos (otro decorador @needs ). Paver realiza una reconstrucción completa cada vez y no funciona bien con funciones que tienen argumentos opcionales. Las instrucciones de compilación se encuentran en el archivo pavement.py .

doit

Doit parece un intento de crear una verdadera herramienta de automatización de compilación en python. Puede ejecutar código python y comandos de shell. Se ve bastante prometedor. Lo que parece perderse (en el contexto de nuestros objetivos específicos) es la capacidad de manejar las dependencias entre objetivos. Digamos que queremos hacer una pequeña tubería donde la salida del objetivo A se usa como entrada del objetivo B. Y digamos que estamos usando archivos como salidas, por lo que el objetivo A crea un archivo llamado outA .



Para hacer esta canalización, necesitaremos especificar el archivo outA dos veces en el objetivo A (como resultado de un objetivo, pero también devolver su nombre como parte de la ejecución del objetivo). Luego, tendremos que especificarlo como entrada para el objetivo B. Por lo tanto, hay 3 lugares en total en los que necesitamos proporcionar información sobre la outA archivo outA E incluso después de hacerlo, la modificación del archivo outA no conducirá a la reconstrucción automática del objetivo B. Esto significa que si le pedimos a Doit que construya el objetivo B, solo verificará si el objetivo B está actualizado sin verificar ninguna de las dependencias Para superar esto, necesitaremos especificar outA 4 veces, también como dependencia de archivo del objetivo B. Veo esto como un inconveniente. Tanto Make como CMake pueden manejar tales situaciones correctamente.

Las dependencias en doit se basan en archivos y se expresan como cadenas. Esto significa que las dependencias ./myfile.txt y myfile.txt se consideran diferentes. Como escribí anteriormente, me parece un poco extraño la forma de pasar información de un objetivo a otro (cuando se usan objetivos de Python). El objetivo tiene una lista de artefactos que va a producir, pero otro objetivo no puede usarlo. En cambio, la función python, que constituye el objetivo, debe devolver un diccionario, al que se puede acceder desde otro objetivo. Veámoslo en un ejemplo:

 def task_preprocess(): """Preprocess IRIS dataset""" pickle_file = 'data/processed/processed.pickle' excel_file = 'data/processed/processed.xlsx' return { 'file_dep': ['src/data/preprocess.py'], 'targets': [pickle_file, excel_file], 'actions': [doit_pypreprocess], 'getargs': {'input_file': ('rawdata', 'filename')}, 'clean': True, } 

Aquí el preprocess objetivo depende de los datos sin rawdata . La dependencia se proporciona a través de la propiedad getargs . Dice que el argumento input_file de la función doit_pypreprocess es el filename de filename de salida de los datos rawdata destino. Eche un vistazo al ejemplo completo en el archivo dodo.py.

Puede valer la pena leer las historias de éxito del uso de doit. Definitivamente tiene características agradables como la capacidad de proporcionar una verificación de objetivos actualizada personalizada.

Luigi

Luigi se mantiene alejado de otras herramientas, ya que es un sistema para construir tuberías complejas. Apareció en mi radar después de que un colega me dijo que intentó hacer Make, que nunca pudo usarlo en Windows / Linux y se mudó a Luigi.

Luigi apunta a sistemas listos para la producción. Viene con un servidor, que se puede utilizar para visualizar sus tareas o para obtener un historial de ejecuciones de tareas. El servidor se llama un programador central . Un planificador local está disponible para fines de depuración.

Luigi también es diferente de otros sistemas en la forma en que se crean las tareas. Lugi no actúa en algún archivo predefinido (como dodo.py , dodo.py o makefile). Más bien, uno tiene que pasar un nombre de módulo de Python. Entonces, si intentamos usarlo de manera similar a otras herramientas (colocar un archivo con tareas en la raíz del proyecto), no funcionará. Tenemos que instalar nuestro proyecto o modificar la variable de entorno PYTHONPATH agregando la ruta al proyecto.

Lo bueno de luigi es la forma de especificar dependencias entre tareas. Cada tarea es una clase. La output método le dice a Luigi dónde terminarán los resultados de la tarea. Los resultados pueden ser un solo elemento o una lista. El método requires especifica dependencias de tareas (otras tareas; aunque es posible hacer una dependencia de sí mismo). Y ya está. Lo que se especifica como output en la tarea A se pasará como entrada a la tarea B si la tarea B se basa en la tarea A.


A Luigi no le importan las modificaciones de archivos. Se preocupa por la existencia de archivos. Por lo tanto, no es posible activar reconstrucciones cuando cambia el código fuente. Luigi no tiene una funcionalidad limpia incorporada.

Las tareas de Luigi para este proyecto están disponibles en el archivo luigitasks.py . Los ejecuto desde la terminal:

 luigi --local-scheduler --module luigitasks Exploratory 

Comparación

La siguiente tabla resume cómo funcionan los diferentes sistemas con respecto a nuestros objetivos específicos.