Cloud Composer: orquestación de workflows con Airflow gestionado

Tener un pipeline de Dataflow que funciona y una tabla de BigQuery bien diseñada no sirve de mucho si nadie decide cuándo y en qué orden se ejecutan. Ese es el trabajo de un orquestador, y en Google Cloud ese orquestador se llama Cloud Composer.

Airflow gestionado, sin gestionar tú la infraestructura

Cloud Composer es la versión gestionada de Apache Airflow sobre Google Cloud. Airflow es un proyecto open source pensado precisamente para esto: definir workflows como código, programarlos y monitorizar su ejecución. La diferencia entre instalar Airflow tú mismo y usar Composer es que Google se encarga de desplegarlo sobre Google Kubernetes Engine (GKE) y de mantener en marcha sus piezas internas —el scheduler, el servidor web, la cola de tareas— sin que tengas que tocar un solo nodo.

Cada instancia de Composer se llama entorno. Al crear uno, Google aprovisiona automáticamente, entre otras cosas, un clúster de GKE que ejecuta los componentes de Airflow, un bucket de Cloud Storage donde se guardan los DAGs y los logs, y una cuenta de servicio dedicada con la que el entorno se autentica frente a otros servicios de Google Cloud.

¿Qué es exactamente un DAG?

Un DAG (Directed Acyclic Graph, grafo acíclico dirigido) es, en términos de Airflow, una colección de tareas organizadas que quieres programar y ejecutar en un orden concreto. Se define en un archivo Python normal: cada tarea es un nodo, y las dependencias entre tareas son las flechas del grafo. «Acíclico» significa que el flujo no puede volver sobre sus propios pasos: siempre avanza hacia delante, lo cual evita bucles infinitos de dependencias.

Un DAG sencillo: de Dataflow a BigQuery

Imagina un flujo típico de ingesta diaria: primero se lanza un job de Dataflow que transforma los eventos del día, después se valida que el resultado exista en Cloud Storage y, por último, se carga en una tabla de BigQuery para que el equipo de analítica pueda consultarla. Representado como un DAG, quedaría más o menos así:

Cada uno de esos pasos es un operator de Airflow (hay operadores específicos para lanzar jobs de Dataflow, esperar archivos en Cloud Storage o cargar datos en BigQuery), y Composer se encarga de programar el DAG completo —por ejemplo, todos los días a una hora fija— y de reintentar automáticamente la tarea que falle, según la configuración que le indiques.

Merece la pena aclarar una cosa: Google ha comunicado que Cloud Composer está evolucionando de nombre hacia Managed Service for Apache Airflow, aunque el concepto de fondo —Airflow gestionado, con entornos y DAGs— se mantiene igual.

Reintentos, alertas y algo de tranquilidad

Cada tarea de un DAG se puede configurar con su propia política de reintentos: cuántas veces se vuelve a intentar si falla, cuánto tiempo esperar entre intento e intento, y a quién avisar si finalmente no se recupera. En un flujo como el del ejemplo anterior, esto importa especialmente en la tarea que espera a Dataflow: si el job tarda más de lo habitual por un pico de volumen, el sensor puede esperar dentro de una ventana razonable en lugar de marcar el DAG entero como fallido a la primera. Esa capacidad de definir tolerancia a fallos declarativamente, dentro del propio código del DAG, es una de las razones por las que Airflow se ha convertido en el estándar de facto para orquestar flujos de datos.

Orquestar bien no es solo cuestión de definir el orden de las tareas, también es cuestión de permisos: para que ese DAG pueda lanzar un job de Dataflow y luego escribir en BigQuery, el entorno necesita una identidad con los permisos justos y ni uno más.