A blog about data, information and Tech by Mario Alberich

        

Luigi, a posteriori

Durante los dos últimos años mi actividad se ha ido centrando progresivamente en tareas relacionadas con el tratamiento de datos, y más especialmente con tareas de data engineering. Este cambio también ha supuesto un cambio en mi lenguaje de programación, que ahora es Python la mayor parte del tiempo.

Y entre las utilidades y herramientas que he usado, Luigi ha sido un agradable descubrimiento.

¿Para qué una data pipeline

En resumen, para poder ejecutar operaciones sobre datos que pueden tener una o varias de estas características:

  • se repetirán de forma periódica,
  • están conformadas por distintas fases de proceso, que presentan dependencias más o menos complejas entre ellas,
  • provienen de varias fuentes (ficheros, bases de datos, ubicados en servidores remotos,...),
  • se procesan en distintos contextos.

El motivo para utilizar una herramienta para desarrollar una data pipeline es porque es necesario gestionar los errores, las dependencias, el acceso a los datos y en conjunto todo el flujo del proceso. Pero también porque al utilizar un lenguaje como Python, automáticamente se tiene a disposición todas las herramientas y paquetes de ese lenguaje.

Escogiendo la herramienta más adecuada

Darwin afirmaba que sobrevive el que mejor se adapta, y eso no es necesariamente el más fuerte. Poco más o menos sucede al escoger una herramienta como como esta: hay que analizar los pros y contras de cada una y ver la que mejor se adapta.

En mi caso, la herramienta que buscaba requería:

  • Basada en python, para poder usar de forma integrada herramientas como Pandas y Numpy.
  • Estructurar las tareas por dependencias, y poder reutilizarlas en distintas tareas.
  • Fácil de mantener, en tanto que las dependencias y la estructura sea definible en el propio código.
  • Potencial integración/conexión con Spark.

Pero por ejemplo, no necesitaba:

  • Funciones sofisticadas en cuanto a la planificación de ejecuciones (scheduling): con el crontab era suficiente.
  • Una interfaz web para consultar/gestionar las operaciones en ejecución.
  • Tratamiento de datos en streaming.

Al final, la mayor parte del proceso se centraba en tareas ETL básicas basadas en el filtrado y la agregación de contenidos, con una periodicidad definida. Y aunque el volumen de los datos podía llegar a algunos GB en memoria, prácticamente en ningún caso era necesario era usar un sistema distribuído para realizar los cálculos.

La experiencia de usar Luigi

No creo que pudiera estar más contento, aunque ninguna herramienta es ideal. Luigi al menos en mi caso requiere un poco de preparación para por ejemplo poder definir una configuración de una forma un poco más replicable y mantenible, o bien definir una política adecuada para guardar los datos extraídos.

Y aunque Luigi tiene funcionalidades básicas para el mocking de datos, probablemente requiera funcionalidades más sofisticadas para simular la conexión a servicios externos, la integración/combinación con herramientas automáticas para generar fixtures, etc.

© 2007 and beyond Mario Alberich, licensed under CC-BY-SA unless stated otherwise.