Por Andrew Tan
Estaba en una conferencia el año pasado cuando un arquitecto de datos — Fortune 500, gran equipo, presupuesto serio — me apartó y me contó una historia que he escuchado demasiadas veces.
Pasaron 14 meses migrando a Kafka. Contrataron un nuevo equipo. Implementaron nueva infraestructura. Crearon todo un nuevo sistema de guardias. Todo el paquete.
Seis meses después del lanzamiento, movieron silenciosamente la mitad de los pipelines de vuelta a batch.
Kafka no se rompió. Funcionó bien. El problema era más tonto que eso: nadie usaba los datos en tiempo real. Los paneles de control aún se revisaban a las 9 AM. Los informes seguían ejecutándose semanalmente. Los modelos de Machine Learning aún se reentrenaban durante la noche. Habían construido un coche de Fórmula 1 para ir al supermercado.
La Conferencia que Inició Mil Migraciones
Así es como suele comenzar. Alguien del equipo ve una charla en una conferencia — probablemente a 2x de velocidad en YouTube — donde un ingeniero de FAANG describe su pipeline en tiempo real. Miles de millones de eventos por segundo. Latencia de submilisegundos. Paneles de control actualizándose como en Matrix.
Ese ingeniero regresa a la oficina inspirado. "Deberíamos hacer esto." El equipo asiente. Al CTO le encanta la palabra "tiempo real" en la hoja de ruta trimestral. Nace una épica en Jira.
Lo que nadie pregunta: ¿alguien en este edificio realmente necesita datos más rápido de lo que los está recibiendo hoy?
No "sería agradable". No "suena más moderno". ¿Una persona específica, tomando una decisión específica, obtiene resultados mediblemente peores porque los datos tienen una hora de antigüedad en lugar de un segundo?
Nueve de cada diez veces, la respuesta honesta es no. Y la única vez que es sí, suele ser un solo pipeline — no toda la plataforma.
La Lista de Compras
Antes de migrar cualquier cosa, haz una lista. Hablo en serio — abre una hoja de cálculo. Para cada pipeline, responde tres preguntas:
¿Quién consume estos datos? Un nombre. Un equipo. Un sistema. Si no puedes nombrar al consumidor, el pipeline podría no necesitar existir en absoluto, y mucho menos en tiempo real.
¿Qué hacen con él y cuándo? Si la respuesta es "revisan un panel de control cada mañana" o "alimenta un informe los viernes", el streaming no cambiará el resultado. Solo estás haciendo la plomería más cara para la misma agua.
¿Qué se rompe si estos datos llegan con 1 hora de retraso? ¿1 día de retraso? Esta es la única pregunta que realmente separa batch de streaming. Si la respuesta a ambas es "nada, realmente", tienes una carga de trabajo batch disfrazada de streaming.
La mayoría de los equipos descubren que el 80% de sus pipelines están perfectamente bien como batch. El 20% restante es donde las cosas se ponen interesantes.
Donde la Velocidad Realmente Importa
Algunos datos realmente se echan a perder. Como la leche, no el vino.
Detección de fraude es el obvio. Una transacción con tarjeta de crédito marcada cinco minutos después del hecho no es detección de fraude — es notificación de fraude. El dinero ya se ha ido. Si tu pipeline de fraude se ejecuta en batch, estás escribiendo cartas de disculpa en lugar de bloqueando puertas.
Nuestra solución de detección de fraude maneja puntuación en tiempo real con latencia de menos de 100 ms.
Alertas operativas — si tu sensor IoT te dice que una turbina se está sobrecalentando, esa información tiene una vida útil medida en segundos. Un trabajo batch por hora aquí no solo es lento. Es negligente.
Precios e inventario en mercados competitivos. Si tu competidor actualiza precios cada 30 segundos y tú actualizas cada 6 horas, no estás compitiendo. Estás siendo espectador.
Flujos de eventos multi-consumidor donde la economía se compone. Un tema de Kafka alimentando tres sistemas descendentes puede ser más barato que tres trabajos batch separados extrayendo de la misma base de datos. El streaming se gana su lugar aquí no por la velocidad, sino por la elegancia arquitectónica.
El patrón: en cada caso, hay un costo específico y medible por el retraso. No una sensación vaga. Un número.
Los Costos que Nadie Pone en la Épica de Jira
La infraestructura de streaming tiene un modelo de precios que se ve genial en la diapositiva del proveedor y terrible en los resultados reales del Q3.
Funciona 24/7. Tu trabajo batch funciona durante 4 horas y duerme. Tu trabajo de streaming funciona todo el día, toda la noche, fines de semana, festivos. Incluso si el volumen total de datos es idéntico, la factura de computación no lo es. Un equipo que conozco pasó de una configuración batch de $2,000/mes a una de streaming de $11,000/mes — procesando los mismos datos, entregándolos al mismo lugar, consumidos al mismo ritmo.
La depuración pasa de arqueología a física cuántica. Cuando un trabajo batch falla, obtienes un rastro de pila, un registro malo y una ruta clara de reejecución. Cuando un trabajo de streaming produce una salida incorrecta, podría no "fallar" en absoluto. Simplemente alimenta silenciosamente basura hacia abajo hasta que alguien nota que el panel de ingresos se ve raro tres días después.
Los cambios de esquema se convierten en una negociación diplomática. En batch, versionas tu código, pruebas con datos históricos y publicas. En streaming, cambiar un campo significa coordinar cada productor y consumidor simultáneamente en un sistema en vivo. Si te equivocas en el orden, estarás depurando corrupción de datos a las 2 AM.
El impuesto de guardia es real. Retraso del consumidor, sesgo de partición, fallos de broker — estos no son casos raros, son martes. Si tu equipo ya está estirado, el streaming no resuelve el problema. Lo multiplica.
Un Marco que Realmente Ayuda
Esto es lo que recomendaría. Toma alrededor de dos horas con las personas adecuadas en la sala.
Paso 1: Nombra las decisiones. Para cada pipeline, identifica la decisión de negocio específica que soporta. No "analítica" — la decisión real. "Aprobar o rechazar esta transacción." "Reordenar este SKU." "Alertar al equipo de mantenimiento." Si no puedes nombrarla, batch está bien.
Paso 2: Cronometra las decisiones. ¿Con qué frecuencia se toma esa decisión? ¿Cada segundo? ¿Cada hora? ¿Cada lunes? Ajusta la cadencia del pipeline a la cadencia de la decisión. Entrega en sub-segundos para una decisión diaria es un desperdicio.
Paso 3: Valora el retraso. ¿Cuánto cuesta un retraso de una hora, en dólares? Esta es la pregunta más difícil y más importante. Si la respuesta es "no sabemos" o "probablemente nada", no tienes un caso de uso de streaming. Tienes un deseo de streaming.
Paso 4: Comienza con uno. Elige el pipeline con el costo de retraso más claro. Migra. Ejecútalo junto con la versión batch durante un ciclo completo. Compara. Arregla lo que se rompa. Luego decide si expandir.
Los equipos que hacen esto bien suelen terminar con 2–3 pipelines de streaming y 15 de batch. Los equipos que se saltan este proceso terminan con 18 pipelines de streaming, un equipo de operaciones quemado y una migración silenciosa de vuelta a batch seis meses después.
No es Ni Uno Ni Otro
Aquí está lo que la mayoría de los proveedores de streaming no te dirán: las mejores arquitecturas de datos son aburridas. No son todo-streaming o todo-batch. Son una mezcla, elegida pipeline por pipeline, basada en lo que los datos realmente necesitan hacer.
Batch para informes. Batch para entrenamiento de Machine Learning. Batch para cualquier cosa donde "diario" sea lo suficientemente rápido y la simplicidad te ahorre $8,000 al mes en costos de operaciones.
Streaming para fraude. Streaming para alertas operativas. Streaming para los pocos pipelines donde el retraso tiene un signo de dólar adjunto.
Esto es exactamente por qué construimos layline.io de la manera en que lo hicimos. Maneja tanto batch como streaming en la misma plataforma — mismos Workflows, mismas herramientas, mismo equipo. No tienes que elegir un mundo y abandonar el otro. Comienzas con lo que tienes, agregas tiempo real donde se justifica, y mantienes batch donde tiene sentido. Sin reemplazo total. Sin ni uno ni otro.
El diagrama de arquitectura no ganará ninguna charla de conferencia. Pero el equipo se va a casa a las 5 PM y la rotación de guardia realmente duerme toda la noche.
Ese es el tipo de aburrimiento que escala.
Si estás evaluando qué pipelines pertenecen al tiempo real y cuáles están perfectamente bien como batch, layline.io te permite ejecutar ambos en una sola plataforma — para que puedas validar el caso de negocio antes de comprometer infraestructura. Habla con nosotros sobre tu arquitectura específica.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja tanto cargas de trabajo batch como en tiempo real a escala.
