Ya tienes Airflow en funcionamiento. Tu equipo lo conoce. Los DAGs funcionan. Entonces, ¿por qué de repente escuchas "necesitamos en tiempo real" y qué haces realmente al respecto?
La petición que no desaparece
Viene primero del lado del negocio. Usualmente a través de Slack: "¿Podemos actualizar ese tablero más de una vez al día?" Luego del producto: "El equipo de fraude quiere saber sobre los problemas en segundos, no en horas." Luego de tu CTO en la próxima reunión de planificación: "¿Por qué seguimos ejecutando en lotes cuando nuestros competidores están en tiempo real?"
Eres la persona de Airflow. Has construido una operación por lotes sólida. Tus DAGs se ejecutan según lo programado. Tu equipo puede depurarlos. Tienes los manuales de operación. Y ahora todos te piden que te conviertas en un ingeniero de streaming de la noche a la mañana.
Esta guía es para ese momento. No es el argumento de por qué el tiempo real importa — probablemente ya lo has aceptado. Se trata de lo que realmente haces con tu configuración actual de Airflow cuando llega la petición de tiempo real.
Donde Airflow alcanza su límite
Airflow es un orquestador de workflows. Ejecuta tareas en horarios o desencadenantes. Eso es extremadamente útil — y la herramienta adecuada para muchas de ellas. Pero hay casos de uso genuinos donde comienza a mostrar límites.
La latencia es la obvia. Si tu programación más corta es de 15 minutos, todo lo que está aguas abajo espera un mínimo de 15 minutos. Para algunos workflows — informes diarios, sincronizaciones masivas de API, pipelines de entrenamiento de ML — eso está perfectamente bien. Para otros — alertas de fraude, actualizaciones de inventario, notificaciones de usuarios — 15 minutos es una eternidad.
Los desencadenantes de alta frecuencia se vuelven costosos. Programar una tarea cada pocos segundos se desmorona cuando necesitas reaccionar a miles de eventos por segundo. Terminas con tareas de sensor sondeando condiciones, lo cual no es para lo que Airflow fue diseñado.
El estado entre eventos es incómodo. Las tareas de Airflow son sin estado y de corta duración. Si necesitas mantener el estado a través de millones de eventos individuales — rastrear ventanas de sesión, construir agregaciones en tiempo real, manejar llegadas fuera de orden — estás luchando contra el paradigma.
Nada de esto es una crítica a Airflow. Se trata de saber cuándo buscar una herramienta diferente.
Las cuatro opciones realistas
Cuando los equipos preguntan "¿deberíamos movernos a streaming?", la pregunta real es usualmente "¿cuál es el camino de menor costo hacia la capacidad en tiempo real?" Aquí están los cuatro caminos que los equipos realmente toman:
1. Mantener todo en Airflow, pero programar con más frecuencia. Para algunos equipos, ejecutar DAGs cada 5 minutos es suficiente. Si "en tiempo real" significa "dentro de unos minutos", la programación a nivel de cron puede llevarte allí sin agregar ninguna nueva infraestructura. No asumas que necesitas Kafka para reaccionar más rápido — verifica si tu herramienta actual ya puede hacerlo.
2. Agregar una capa de streaming junto a Airflow. Este es el camino más común para equipos maduros. Mantienes Airflow para workflows por lotes, árboles de dependencia complejos y cualquier cosa con pasos de intervención humana. Agregas una plataforma de streaming para cargas de trabajo impulsadas por eventos y de baja latencia. Coexisten.
3. Migrar pipelines específicos completamente a streaming. A veces un workflow que se ejecuta en Airflow no debería estar en Airflow en absoluto — era simplemente la única herramienta disponible cuando se construyó. Para pipelines de alto volumen e impulsados por eventos, una migración completa a infraestructura de streaming tiene sentido.
4. Reemplazar Airflow completamente. Rara vez es la decisión correcta, pero sucede cuando una organización se compromete completamente con una arquitectura impulsada por eventos y quiere un sistema manejando todo. El costo de migración es alto y el riesgo es real.
La mayoría de los equipos terminan haciendo la opción 2 o 3 para pipelines específicos. Esa es la realidad práctica.
Cómo evaluar lo que realmente tienes
Antes de planear cualquier cosa, mapea la carga de trabajo real. No en teoría — en práctica.
Encuentra los pipelines sensibles a la latencia. ¿Qué DAGs alimentan sistemas aguas abajo con los que interactúan directamente clientes o usuarios? ¿Cuáles sirven datos que cambian resultados de negocio si tienen 5 minutos de antigüedad versus 5 segundos? Empieza ahí.
Cuenta las transferencias. Observa los pipelines donde los datos se mueven a través de múltiples DAGs en secuencia. Cada transferencia agrega latencia y superficie de falla. El streaming puede a menudo colapsar múltiples pasos por lotes en un flujo continuo.
Habla con los consumidores. No con los líderes de ingeniería — con los usuarios de negocio reales. Pregúntales qué significa "en tiempo real" para ellos. A menudo encontrarás que "en tiempo real" para el negocio es "dentro de una hora" para ellos, y eso cambia la prioridad completamente.
Evalúa tu capacidad operativa. El streaming introduce diferentes modos de falla: retraso del consumidor, sesgo de partición, uso de disco del broker. Si tu equipo ya está al límite manteniendo pipelines por lotes, agregar streaming sin espacio de maniobra creará problemas.
Una migración que no rompe todo
La peor manera de migrar es tratarlo como una reescritura. Arrancar el DAG, construir la versión de streaming, esperar que funcione en producción.
El camino práctico es incremental.
Paso 1: Modo sombra. Elige un pipeline por lotes con sensibilidad real a la latencia. Construye la versión de streaming junto a él. Dirige la salida de streaming a un consumidor de prueba o de staging, no a producción. Déjalos correr en paralelo por al menos un ciclo completo.
Paso 2: Validar. ¿El pipeline de streaming produce los mismos resultados que la versión por lotes? Para agregaciones, esto significa comparar números. Para el enrutamiento de eventos, esto significa verificar que cada evento esperado llegó al destino esperado. No te saltes este paso.
Paso 3: Período de escritura dual. Dirige un consumidor de producción no crítico a la salida de streaming mientras mantienes la salida por lotes como la fuente principal. Monitorea tasas de error, distribuciones de latencia y retraso del consumidor. Arregla lo que se rompa.
Paso 4: Cambio. Después de un período de escritura dual exitoso, haz que la salida de streaming sea la principal. Mantén el pipeline por lotes en espera por un período definido — una semana, dos semanas — antes de desmantelarlo.
Paso 5: Repetir. Aplica las lecciones. Cada migración es más rápida que la anterior.
El período híbrido no es opcional — es cómo mantienes la confianza en los datos mientras validas el nuevo sistema.
¿Qué pasa con los DAGs de Airflow que ya has construido?
Esta es la pregunta que nadie responde bien. La realidad: tus DAGs existentes representan conocimiento acumulado sobre tus datos y workflows. No los deseches.
Algunos DAGs deberían migrar a streaming. Otros deberían permanecer por lotes — porque el workflow es genuinamente orientado a lotes, el requisito de latencia es real pero manejable en intervalos horarios, o la lógica de transformación es lo suficientemente compleja como para que reconstruirla no valga el costo de ingeniería.
Un heurístico útil: si el pipeline existe principalmente para mover datos de A a B en un horario, podría ser un candidato para streaming. Si existe para orquestar transformaciones de múltiples pasos con lógica condicional y puertas de aprobación humana, Airflow probablemente sigue siendo el hogar adecuado.
El objetivo no es reemplazar Airflow. Es agregar streaming donde realmente vale la pena — y dejar que cada herramienta haga lo que realmente es buena haciendo.
Cómo se ve cuando funciona
Cuando la migración funciona, el negocio lo nota — no la infraestructura.
Un analista de fraude que solía revisar transacciones marcadas seis horas después de que ocurrieran ahora las revisa en menos de un minuto. Un gerente de producto que revisaba el tablero cada mañana para ver los números de ayer ahora ve actualizaciones a medida que ocurren los eventos. Estos son los resultados que vale la pena optimizar.
Los equipos de infraestructura también lo notan, pero de una manera diferente: menos alertas de emergencia sobre fallos de trabajos por lotes, más tiempo en trabajo de mejora, tableros de observabilidad que muestran exactamente dónde están fluyendo los datos y dónde se están acumulando.
Decisiones más rápidas. Menos supervisión manual. Más tiempo construyendo cosas que importan.
Antes de comenzar
Aclara algunas cosas antes de escribir la primera línea de lógica de streaming:
¿Cuál es el costo real de la latencia en tu workflow más importante? No una suposición — números reales. Si el pipeline de fraude tarda 6 horas en lugar de 6 segundos, ¿cuál es el impacto financiero? Esa es tu señal de priorización.
¿Cuál es tu plan de reversión? Si el pipeline de streaming falla a las 2 AM, ¿qué sucede? ¿Reversión automática a por lotes? ¿Intervención manual? ¿Escalamiento en PagerDuty? Define esto antes de lanzar, no después.
¿Cuál es la curva de aprendizaje del equipo? Necesitarás aprender nuevos conceptos: grupos de consumidores, claves de partición, gestión de offsets, políticas de watermark. Asegúrate de que tu equipo tenga tiempo asignado para entender estos — no solo implementarlos.
Y si la respuesta honesta es que tu equipo no tiene la capacidad para operar un sistema de streaming junto a los pipelines de Airflow existentes en este momento — está bien. Dilo. La urgencia del streaming desde el negocio es a menudo menor de lo que el negocio piensa, y comprometer en exceso a tu equipo a una migración que no puedes soportar es peor que decir no.
El camino práctico hacia adelante
Los equipos que hacen esto bien comparten un rasgo: no intentan hervir el océano.
Eligen un pipeline de alto valor y sensible a la latencia. Lo construyen en streaming junto a la versión por lotes existente. Validan rigurosamente. Cambian cuando están seguros. Luego hacen el siguiente.
Airflow se queda. Maneja lo que es bueno haciendo. Streaming se agrega donde el valor de la latencia es real y medible. El resultado es una arquitectura que utiliza la herramienta adecuada para cada carga de trabajo — no una migración de gran explosión que apuesta todo a una reescritura de un solo fin de semana.
Comienza con un pipeline. Hazlo bien. Aprende lo que no sabes. Luego escala desde ahí.
Si estás evaluando plataformas para la capa de streaming, layline.io ofrece un visual workflow designer que te permite prototipar y desplegar pipelines de streaming sin requerir experiencia en sistemas distribuidos. La Community Edition es gratuita para probar — no se requiere tarjeta de crédito.
