El pedido que siempre aparece
"Necesitamos los datos en tiempo real."
Esa frase aparece en casi todos los proyectos de datos. Y casi siempre significa algo distinto de lo que parece.
Cuando alguien de negocio pide "tiempo real", rara vez está pensando en milisegundos. Generalmente quiere ver los datos del día, o de la última hora, o de los últimos quince minutos. Eso no es streaming de ingeniería. Es batch con ventanas más cortas.
Antes de elegir una arquitectura, hay que traducir el pedido a una latencia concreta. Y después evaluar si esa latencia justifica la complejidad que trae.
Tres estrategias, tres perfiles de costo
Batch tradicional: procesás los datos una vez al día, o cada algunas horas. Es la estrategia más simple de operar. Las herramientas de transformación como dbt están pensadas para esto. Tenés tiempo para aplicar lógica de negocio compleja, validar, y cerrar el período.
Micro-batch: procesás en ventanas cortas, cada cinco o quince minutos. Seguís en territorio batch (no es streaming), pero con frecuencia alta. Esto funciona para muchos casos de "casi tiempo real" sin la complejidad de un sistema de streaming.
Streaming: procesás eventos a medida que llegan, en segundos o milisegundos. Acá sí estás en otro juego. Necesitás infraestructura distinta, patrones distintos, y conviene que la lógica de negocio sea acotada.
El costo oculto del streaming
Cuando hay lógica de negocio en el medio, el streaming se complica.
Si tu transformación es "tomar el evento y guardarlo", streaming funciona bien. Pero si necesitás cruzar con otras tablas, aplicar reglas de negocio o calcular métricas agregadas, streaming puede hacerlo, aunque con estado, ventanas, eventos tardíos y más complejidad operativa.
Las herramientas de transformación más usadas están pensadas para batch. Bajarles la ventana de ejecución no las convierte en streaming. Siguen siendo batch, solo que más frecuente.
El patrón lambda y sus riesgos
Una solución que aparece seguido es combinar ambos caminos: un flujo de streaming para tener datos "casi vivos", y un cierre batch para consolidar.
Esto puede funcionar, pero tiene un riesgo grande: si la lógica de negocio está duplicada en los dos caminos, vas a tener dos versiones de la verdad. El número del streaming no va a coincidir con el del batch, y vas a pasar más tiempo explicando diferencias que generando valor.
Si vas por este camino, la disciplina de consolidación es crítica. Tiene que haber un momento donde el batch "gana" y el streaming se descarta o se reconcilia.
Cómo decidir
La pregunta no es "¿queremos tiempo real?" sino "¿qué latencia necesitamos y qué estamos dispuestos a pagar por ella?"
Si la respuesta es "los datos del día anterior están bien", batch tradicional. Es lo más simple y lo más robusto.
Si la respuesta es "necesitamos ver lo que pasó en la última hora", micro-batch. Podés bajar la ventana de ejecución sin cambiar de paradigma.
Si la respuesta es "necesitamos reaccionar en segundos a eventos individuales", ahí sí streaming. Pero con la conciencia de que la lógica de negocio debería estar acotada, y que estás entrando en territorio operativamente más complejo.
Separar operación de analítica
Una distinción útil: las métricas operativas y las métricas analíticas no tienen por qué vivir en el mismo sistema.
Si necesitás un dashboard que muestre cuántos pedidos entraron en los últimos cinco minutos, eso puede ser un sistema operativo separado, con datos crudos y lógica mínima.
La analítica con lógica de negocio, cruces y métricas calculadas puede seguir siendo batch. No todo tiene que ir al mismo lugar ni con la misma latencia.
En resumen
La latencia que necesita el negocio define la estrategia de procesamiento. Batch es simple y robusto. Micro-batch te da frecuencia sin cambiar de paradigma. Streaming es para reaccionar en segundos, pero con lógica acotada.
Combinar caminos es posible, pero duplicar lógica de negocio en dos rutas es la forma más rápida de tener dos verdades distintas.
Antes de elegir, traducí "tiempo real" a una latencia concreta. Y después evaluá si esa latencia justifica la complejidad.