El orquestador universal no existe: guía de campo para pipelines medallion
Un ingeniero de datos con seis años de experiencia sostiene que elegir orquestador por número de estrellas en GitHub es el origen de buena parte de los incidentes en arquitecturas medallion.
El orquestador universal no existe. Esa es la tesis de un ingeniero de datos que lleva seis años limpiando los destrozos de pipelines medallion mal orquestados, y su conclusión es incómoda: la herramienta importa menos que el modo de fallo que estés dispuesto a depurar. Su recetario tiene seis puntos y ninguno pasa por elegir el proyecto con más estrellas en GitHub.
Airflow, Step Functions o lo nativo
Con Airflow, el problema no es el scheduler sino lo que arrastra: dependencias de Python que chocan entre workers, un DAG que necesita pandas 1.5 mientras el de al lado pide 2.0, y una fragilidad de fondo que se come cerca del 40% del tiempo en gestionar el orquestador en lugar de los datos. Un grafo de tareas tampoco da atomicidad: si el merge de bronze a silver se rompe a mitad, alguien tiene que escribir la lógica de limpieza, y esa lógica también fallará. La cifra es suya, de su experiencia, no de un estudio.
Para quien tenga todo en AWS, con S3 por debajo y Glue o EMR ejecutando, defiende Step Functions. No administras un servidor, administras una máquina de estados, y la espera por callback permite lanzar un job de Spark largo y dejar la ejecución en pausa hasta que el job responda por API. El límite a tener en cuenta son 25.000 eventos por ejecución: un pipeline que itera 10.000 archivos se lo come y aparece el ExecutionLimitExceeded en mitad de un despliegue de viernes. O se trocean los datos o se asume.
Si el almacenamiento es Delta Lake, el argumento cambia. Databricks Workflows conoce el ciclo de vida del clúster y los commits de Delta, algo que un orquestador externo no ve. Eso evita el clúster huérfano, ese caso en el que la herramienta cree que el job terminó bien pero la máquina murió durante el VACUUM final.
El estado va en los datos, no en el orquestador
El error estructural que más veces ha visto es la cadena monolítica: un único DAG que ejecuta bronze, silver y gold en serie. Si falla el último paso, se reprocesa todo. Su propuesta son disparadores desacoplados: bronze termina, emite un evento de fichero llegado y eso arranca silver. Si silver falla, se corrige la lógica y se relanza silver sin tocar bronze.
Y el estado no vive en el orquestador. Guardar el último timestamp procesado en variables propias o en su base de datos es una bomba de relojería cuando toca un backfill. Mejor un watermark en una tabla del lago y dejar al orquestador tonto: la tarea pregunta a la tabla dónde se quedó. Así se puede sustituir Airflow por un Cron sin que los datos noten nada.
Queda la observabilidad. El check verde en la interfaz no dice gran cosa: un job puede terminar bien habiendo cargado vacío o corrompido una partición. La puerta de calidad, con dbt o Great Expectations como una tarea más del flujo, tiene que poder tumbar el paso antes de llegar a gold.
Nada de esto viene con benchmarks públicos ni con código de referencia más allá de un par de fragmentos de configuración: es experiencia de campo de alguien que se ha comido los incidentes. Lo que sí es comprobable es el coste de hacer lo contrario, y ese lo paga quien opera el pipeline a las tres de la mañana.
