El Titán de Data: Nuestro camino hacia ETLasS
Un poco de historia
Hace dos años comencé a trabajar en el área Data Engineering de Ualá. A mi llegada, el equipo estaba justo en medio del armado del datalake que, para ese entonces, se estaba montando en la nube. Yo venía con una experiencia de trabajo de 6 años en BI, pero haciendo ingeniería de datos a pequeña escala (que lejos quedaron esos días de usar SSIS), y esto significaba un salto de fe en la dirección que creía que quería para mi desarrollo profesional.
En noviembre del 2021, con casi dos años del proyecto en marcha, y con un equipo completamente distinto, definimos migrar la plataforma de datos que teníamos hacia otro proveedor. Esto nos llevó a definir una herramienta de orquestación de procesos que solucionase uno de nuestros grandes problemas, el desarrollo y mantenimiento de pipelines de datos.
Estandarizar el desarrollo y solucionar los problemas de consistencia e integridad que teníamos era clave para poder escalar y hacer crecer nuestros procesos.
La decisión fue apalancarnos en Composer, el servicio de Airflow autoadministrado que provee GCP. De esta forma, comenzamos a desarrollar nuestros jobs como DAGs (Directed Acyclic Graph), scripts de Python con la definición de las tareas que requiere un Job.
Buscando eficientizar su creación, generamos una serie de templates y scripts automatizados para facilitar y estandarizar el desarrollo, lo que nos permitió reducir en gran medida nuestro time-to-market, pero queríamos ir por más.
¿Cómo estandarizar el desarrollo?
Investigando en el mercado y la comunidad de Data Engineering vimos una tendencia en el desarrollo de soluciones que permitan la construcción de DAGs a partir de un archivo de configuración. Esto no solo disminuye ampliamente el tiempo de desarrollo, sino que también permite la estandarización del código.
Decidimos utilizar Python como el lenguaje de programación principal para el desarrollo de la aplicación que terminaríamos bautizando como DagBuilder.
Comenzamos con una aplicación muy simple por línea de comando (CLI). En pocas palabras, un generador de snippets para crear DAGs a partir de un tipo de ingesta y una serie de configuraciones particulares.
La aplicación contaba con dos simples comandos:
- Validate: para comprobar la integridad de un archivo yaml y que el mismo contase con todos los parámetros obligatorios del tipo de DAG que se quisiera crear.
- Build: que en primer lugar ejecutara esa validación (en caso de que el usuario no validase previamente el archivo), y luego, si la misma era correcta, construyera los archivos necesarios.
Esto nos permitió entregar al equipo una experiencia de desarrollo mucho más sencilla y rápida, pero, sin embargo, tenía una gran falencia: la CLI se encontraba en el repositorio de GitHub, por lo cual era necesario tener acceso, que esté actualizado, y además solo podía ejecutarse de manera local.
Construyendo una API
Para disponibilizar la solución de la manera más amigable, pero eficiente a la vez, el next-step lógico era crear una API.
Comenzamos tomando todo el código de la CLI y lo transformamos en una librería propia de Python. Luego, utilizando FastAPI comenzamos a esbozar los distintos endpoints que debía tener la aplicación. Hecho el desarrollo, solo restaba dockerizar la API y apoyarnos en los servicios de la nube de Google para poder consumirla desde cualquier navegador (siempre y cuando el usuario tuviera los permisos necesarios.)
Esto significó un antes y un después, no solo en la manera en la que desarrollamos soluciones dentro del equipo, sino también en el servicio que brindamos.
Cumplido el principal objetivo, nos impulsamos hacia un desafío un poco más grande, generar una herramienta de self service para que cualquier usuario de Ualá, con o sin conocimientos técnicos previos, pudiese generar su propio ETL (proceso de carga/extracción/transformación de datos).
ETLasS para todos
Para agregar flexibilidad y mayor libertad a la herramienta debíamos modificar nuestro principio base, es decir, que solo pudiesen crearse DAGs a partir de ciertos templates.
Nos embarcamos en la tarea de redefinir la lógica en la que construíamos los DAGs dentro de la aplicación. Lograr generar un Job dinámico era la cuestión, posibilitando que la construcción no estuviera ligada a una lista u orden de tareas específicas, sino que el usuario fuese libre de armar el proceso tal cual lo necesitase.
Pero no podíamos quedarnos tan solo con la creación del Job si queríamos brindar una experiencia lo más completa posible para el usuario.
Así nació Chronos, una aplicación que nos permite unir los dos mundos: usuarios finales de negocio con soluciones más técnicas. Tratando de abarcar la mayor funcionalidad posible, incluimos además de un método para generar Jobs dinámicos, una lista de las posibles acciones de edición o monitoreo que podría llegar a necesitar un usuario, desde la posibilidad de editar, activar, desactivar o eliminar Jobs, hasta poder ver un detalle de las ejecuciones históricas o ejecutar manualmente un Job.
Sin embargo, seguíamos limitados a la forma de acceso y a la experiencia de usuario que proveíamos. Es por ello que nos aventuramos en la creación de un portal, que llamamos Data Ally, desde el cual pudiésemos ofrecer todos los servicios que desarrolláramos de una manera organizada y sencilla.
El camino recorrido fue muy largo y lleno de imprevistos, pero el resultado final más que compensa todo lo trabajado.
Logramos crear un único lugar para todas las necesidades de Data de Ualá, y le dimos la libertad al usuario de poder calendarizar sus propios Jobs. Con esto comienza una nueva etapa, tanto en los desarrollos internos, como así también en la manera en la que los equipos del negocio encaran sus procesos de datos.
Como siempre, lo mejor está por venir.
Dos años después de todo este recorrido, puedo decir que ese saltó de fe que comenté al principio fue en la dirección correcta. Si bien el camino fue muy desafiante, todo lo conseguido valió la pena.
Para cerrar, quiero decir que si bien yo transcribí la experiencia en este artículo, nada de todo esto habría sido posible sin el equipo que me acompaña día a día. Quienes fueron parte de este recorrido fueron:
Santiago Menendez que no solo fue quién me dio una mano gigante transformando la primera iteración del DagBuiler en una librería de Python, sino que también se cargó encima la tarea de diseñar todo el frontend del Portal sin nunca haber tocado un framework de diseño.
Juan Spinelli, mi mano derecha, creando todo el proceso de CI/CD, llevando en sus hombros toda la administración de la infra que tuvimos que crear para que esto fuera una realidad.
Guereta Martin que fue clave para administrar toda la permisería (gestión de permisos) del proyecto de GCP, y Santiagokhazki que también fue una pieza integral en el desarrollo del front y el back.
Finalmente, también agradecer a Cefranlly Perez Cantillo con quien comenzamos el proyecto del DagBuilder y siempre me impulsó a romper mis barreras y crecer como profesional, y a Rodrigo Marini que pone todos los días su confianza en nuestro equipo para llevar adelante soluciones como esta.
