Batch vs Streaming en Data Engineering: cómo decidir en producción sin romper nada

Introducción

En Data Engineering, la pregunta no es si usar batch o streaming.

La pregunta correcta es: ¿qué problema estoy resolviendo y qué trade-offs puedo aceptar?

Batch vs streaming no es una diferencia conceptual. Es una decisión operativa que impacta costos, mantenimiento, confiabilidad y latencia.

Elegir mal no rompe el sistema el día 1. Lo rompe en producción.

Problema real en producción

Supuesto: tienes una plataforma que alimenta dashboards, alertas y modelos.

Aparecen pedidos típicos:

• “Queremos métricas en tiempo real”
• “El fraude debe detectarse en segundos”
• “El dashboard tarda horas”

La reacción más común:

“Pasemos todo a streaming”

Resultado en producción:

• Mayor complejidad sin necesidad real
• Costos constantes elevados
• Debugging difícil
• Fallos silenciosos

Conclusión: Batch y streaming no compiten. Se combinan según el caso de uso.

Diferencia real en producción

Batch

Procesamiento por intervalos, optimizado para:

• simplicidad operativa
• reproducibilidad
• bajo costo
• observabilidad clara

Casos reales:

• ETL incremental
• dashboards de negocio
• backfills

Streaming

Procesamiento continuo de eventos, optimizado para:

• baja latencia
• reacción inmediata
• procesamiento incremental

Casos reales:

• fraude
• tracking de usuarios
• alertas operativas

Diferencia clave

No es tiempo real vs no tiempo real.

• Batch: exactitud + simplicidad + costo
• Streaming: latencia + reactividad

Cuándo usar Batch

Usa batch cuando:

• la latencia puede ser minutos u horas
• necesitas reprocesamiento
• querés simplicidad operativa
• el costo es prioridad

Caso real

Pipeline de ventas:

• ejecución cada 1 hora
• carga incremental
• transformación en warehouse

Resultado:

• estable
• barato
• fácil de mantener

Cuándo usar Streaming

Usa streaming cuando:

• la latencia es crítica
• necesitas reaccionar automáticamente
• el dato pierde valor rápido
• hay alto volumen continuo

Caso real

Fraude:

• eventos en Kafka
• procesamiento en segundos
• trigger inmediato

Resultado:

• mayor complejidad
• alto valor de negocio

Trade-offs reales

Latencia

• Batch: minutos → horas
• Streaming: ms → segundos

Trade-off:

menor latencia = mayor complejidad + mayor costo

Costo

• Batch: bajo si está bien diseñado
• Streaming: infraestructura activa todo el tiempo

Complejidad

Batch:

• simple de debuggear

Streaming:

• offsets, ventanas, estado

Realidad:

streaming es más difícil de operar

Observabilidad

Batch:

• ejecuciones claras

Streaming:

• sistema continuo con métricas (lag, throughput)

Problema:

puede fallar sin señales claras

Confiabilidad

Batch:

• retries simples
• backfills fáciles

Streaming:

• duplicados
• eventos fuera de orden
• exactly-once complejo

Ejemplo práctico (paso a paso)

Problema

E-commerce necesita:

• dashboard de ventas
• detección de fraude

Diseño incorrecto

Todo en streaming:

• Kafka + Spark Streaming
• dashboards en tiempo real

Problema:

• alto costo
• complejidad innecesaria

Diseño correcto (híbrido)

1) Separar casos de uso

• dashboard → batch
• fraude → streaming

2) Pipeline batch

• fuente: DB
• ejecución cada 1 hora
• carga incremental
• destino: warehouse

Stack:

• Airflow + dbt + BigQuery

3) Pipeline streaming

• eventos de pago
• Kafka
• procesamiento en streaming
• salida: alertas

4) Enriquecimiento

• lookups a DB
• cache (Redis)

5) Observabilidad

Batch:

• éxito/error

Streaming:

• lag
• latencia
• dead letter queue

Resultado

• dashboard confiable y barato
• fraude en tiempo real
• sistema mantenible

Errores comunes

• “Todo debería ser real-time”
• subestimar complejidad de streaming
• no definir SLA
• no monitorear métricas
• mezclar múltiples casos en un pipeline
• no planificar reprocesos
• elegir tecnología antes del problema

Checklist de producción

Antes de decidir:

• ¿Cuál es la latencia máxima aceptable?
• ¿Necesito real-time o solo mayor frecuencia?
• ¿Cuánto cuesta operar 24/7?
• ¿Necesito reprocesar datos?
• ¿Reacción o análisis?
• ¿Volumen de eventos?
• ¿Tengo capacidad de operar streaming?
• ¿Cómo monitoreo el sistema?
• ¿Qué pasa si falla?
• ¿Cómo manejo duplicados?
• ¿Voy a necesitar backfills?

Conclusión

No hay respuesta única.

Regla práctica:

• empieza con batch
• agrega streaming cuando el negocio lo necesite

En producción:

el mejor sistema es el más simple que cumple el SLA

CTA

Antes de usar streaming, responde esto:

¿realmente necesitas esa latencia o estás siguiendo una moda?