Orquestación y transformación sin montar un equipo de datos

El primer pipeline de datos es un script programado. Funciona. El segundo depende del primero, así que alguien añade una espera. El tercero falla a medias y deja una tabla cargada por la mitad, y el arreglo es un vaciado manual. Para el décimo hay un directorio de scripts, un orden sin documentar, y una persona que sabe cuáles se pueden reejecutar sin peligro.

Ese es el punto en el que un orquestador se gana su sitio, y el punto en el que la mayoría de los equipos instalan uno y lo usan mal de inmediato.

Airflow coordina, no procesa

El error más común con diferencia es hacer el trabajo dentro del orquestador. Una tarea que trae diez millones de filas a la memoria del planificador, las transforma en Python y las vuelve a escribir convierte al orquestador en cuello de botella, en riesgo de memoria y en punto único de fallo.

El trabajo del orquestador es decir qué se ejecuta, en qué orden, bajo qué condiciones, y dejar constancia de lo ocurrido. El trabajo pertenece a donde está el dato: una consulta ejecutada en el almacén, un trabajo enviado a un clúster de procesamiento, un contenedor corriendo en otro sitio.

La prueba práctica: si una tarea no se puede matar y reiniciar sin peligro, está haciendo demasiado.

Idempotencia y el intervalo

La propiedad que hace operable un pipeline es que reejecutar un periodo produzca el mismo resultado que ejecutarlo una vez. Sin ella, cada fallo se convierte en una investigación manual sobre qué se escribió parcialmente.

Dos hábitos dan casi todo esto. Procesa un intervalo acotado en vez de "todo desde la última vez", para que una ejecución quede definida por la ventana que cubre y pueda repetirse. Y escribe con semántica de reemplazo para esa ventana, borrando y reinsertando la partición en vez de añadir, para que una reejecución sobrescriba en lugar de duplicar.

Rellenar el histórico es el mismo mecanismo apuntado al pasado, y un pipeline construido así rellena trivialmente mientras que uno construido sobre añadidos no.

Las dependencias entre tareas no son dependencias entre datos

Un orquestador sabe que la tarea B corre después de la A. No sabe que B lee una tabla que A escribe. Cuando alguien añade una tarea C que también escribe esa tabla, el grafo se ve bien y el dato está mal.

Dos cosas ayudan. Expresa la dependencia sobre el dato donde la herramienta lo permita, con planificación consciente de conjuntos de datos para que un trabajo aguas abajo se dispare cuando su entrada se actualiza y no a una hora fija. Y mantén el grafo de dependencias de transformación en la herramienta de transformación, que es para lo que sirve dbt, en vez de expresar cada dependencia de modelo como una tarea del orquestador.

La forma que funciona: el orquestador ejecuta un número pequeño de pasos gruesos, uno de los cuales es "ejecuta las transformaciones", y la herramienta de transformación resuelve ella misma el grafo fino.

dbt, y la parte que más importa

dbt convierte la transformación en SQL versionado con un grafo de dependencias, y su funcionalidad más valiosa no es la plantilla. Son las pruebas.

Un puñado de aserciones por modelo caza los fallos que de otro modo aparecen como un número equivocado en una presentación de consejo: esta columna nunca es nula, esta clave es única, esta clave foránea existe en la tabla padre, esta columna categórica solo contiene estos valores. Las comprobaciones de frescura sobre las fuentes cazan al sistema origen que dejó de entregar.

Ese es el programa entero de calidad de datos para la mayoría de las organizaciones, y cuesta unas pocas líneas por modelo. Los equipos que se lo saltan son los que descubren que un pipeline lleva seis semanas equivocado en silencio.

Otras dos propiedades que merece tener: el linaje generado desde el grafo, para poder responder qué se rompe si cambia esta columna, y documentación que vive junto al modelo en vez de en un wiki.

La materialización es donde viven las decisiones de coste. Una vista no cuesta nada de almacenar y se recalcula en cada consulta. Una tabla cuesta almacenamiento y es rápida de leer. Los modelos incrementales procesan solo filas nuevas y son la respuesta correcta para tablas de hechos grandes, a cambio de más complejidad y de la necesidad de reconstruir por completo de vez en cuando. Elige por modelo, y recuerda que un modelo pesado reconstruido cada hora contra un almacén con precio por byte escaneado es exactamente el fallo de facturas de BigQuery que se triplican.

La extracción, y la parte que no hay que construir

Sacar datos de los sistemas origen es la parte menos interesante y más tediosa de esto, y es donde los equipos queman meses escribiendo conectores para sistemas cuyas APIs cambian.

Los servicios gestionados de extracción y los ecosistemas libres de conectores existen precisamente para esto. Úsalos para las fuentes estándar: el CRM, la pasarela de pago, las plataformas de publicidad, la réplica de la base de datos de producción. Escribe extracción propia solo para los sistemas genuinamente propietarios donde no exista nada.

El patrón que ha ganado es extraer y cargar primero, transformar después dentro del almacén. Aterriza el dato crudo, consérvalo, y dale forma en SQL, donde es comprobable y reejecutable. La alternativa, transformar en vuelo, significa que un cambio de lógica exige reextraer de una fuente que puede no dejarte.

Cuándo no necesitas Airflow

Esta es la parte que el ecosistema de herramientas no cuenta. Airflow es un sistema distribuido con un planificador, una base de datos de metadatos, workers y un camino de actualización. Ejecutarlo tú es un compromiso operativo real, y ni siquiera las versiones gestionadas son gratis.

Con cinco pipelines y sin dependencias complejas, un trabajo programado en la plataforma que ya tienes más la resolución de dependencias del propio dbt lo cubre. Los planificadores nativos de la nube, un servicio de flujos de trabajo, o sencillamente una tarea programada en un contenedor con buen alertado son todos razonables, y todos son menos cosa que operar.

Los orquestadores más ligeros son un término medio genuino con mejor experiencia de desarrollo local y menos maquinaria. Y las ofertas gestionadas de Airflow en cada nube valen la prima sobre autoalojarlo para casi todo el mundo, porque el trabajo operativo es la parte sin valor diferencial.

Adopta un orquestador pesado cuando tengas suficientes pipelines, suficientes dependencias entre equipos o suficiente complejidad de relleno histórico como para que la coordinación sea el problema real. Antes no.

Lo que se olvida

• La hora del planificador no es la hora del dato. Una ejecución programada a medianoche procesa el intervalo anterior. Equivocarse aquí produce errores de un día que se encuentran semanas después.
• Husos horarios y cambio de hora. Programa en un desplazamiento fijo y maneja la conversión explícitamente.
• Alerta sobre la frescura, no solo sobre el fallo. Un pipeline que termina bien mientras su fuente ha dejado de actualizarse es el peor fallo, porque nada se pone en rojo.
• Credenciales en el orquestador. Tiene acceso a todos los sistemas que toca, lo que lo convierte en un objetivo de alto valor y lo mete de lleno en el ámbito de un Secret de Kubernetes es base64 y del manejo de secretos en general.
• Por aquí pasan datos personales. La copia en el almacén está sujeta a las mismas obligaciones de conservación y supresión que la fuente, que es una de las filas que la gente olvida en el RGPD como controles de ingeniería.
• El coste por ejecución es invisible por defecto. Un modelo reconstruido cada hora en vez de cada día es un aumento de coste de veinticuatro veces del que ninguna alerta te va a avisar.

Qué hacer esta semana

Coge tu panel más importante, rastrea hacia atrás hasta las tablas que lo alimentan, y comprueba si alguna tiene una prueba que afirme lo obvio: que la clave primaria es única y que el dato de ayer llegó. Si no, añade esas dos pruebas. Llevan diez minutos y son la diferencia entre encontrar un problema el día que ocurre y encontrarlo en una revisión trimestral. Arrancamos la línea de datos de un proyecto cloud con exactamente esa comprobación.