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

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? Top comments (0)