DEV Community: Agustín José Mazzeo

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

Agustín José Mazzeo — Wed, 12 Aug 2026 22:25:43 +0000

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?

What does a Data Engineer do in Production (No Hype)

Agustín José Mazzeo — Fri, 29 May 2026 02:10:46 +0000

What Does a Data Engineer Do in Production (No Hype)

If you learned Data Engineering with notebooks and clean datasets, this article is for you. In production there are no clean datasets: there are systems that change, pipelines that fail, and data that has to be correct every single day.

TL;DR

A Data Engineer in production:

Builds and maintains reliable pipelines
Ensures data quality (doesn’t “wait” for good data)
Designs for consumption (BI, ML, APIs)
Operates: monitors, debugs, and reprocesses
Makes real trade-off decisions: cost, performance, risk

Problem

In theory:

“Extract data, transform it, and load it into a data warehouse”

In production:

Data arrives incomplete or late
APIs fail or change schemas
“OK” jobs can still produce incorrect data
Dashboards depend on you

👉 Result: the job is not just building, it’s operating living data systems

Explanation

A Data Engineer builds and operates systems that turn chaotic data into reliable data for the business.

It’s not just ETL.

It’s:

pipeline design
data quality enforcement
continuous operations
architectural decision-making

Once you understand the problem, the work breaks down into these layers:

1. Ingestion (unstable sources)

What it involves:

Integrating APIs, databases, events
Handling errors and retries
Detecting schema changes

Example:


expected = {"order_id", "user_id", "amount"}

for col in expected:

    if col not in df.columns:

        df[col] = None

👉 Defensive design, not perfect data

2. Transformation

What it involves:

Cleaning and deduplication
Business logic
Performance

Example:


SELECT *

FROM (

  SELECT *,

         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn

  FROM raw_users

)

WHERE rn = 1;

👉 Key decision: correctness vs performance

3. Modeling

What it involves:

Designing for BI or ML

Example:

Dashboard → aggregated table
ML → detailed events

👉 Depends on consumption

4. Consumption

Consumers:

BI
ML
APIs

👉 Changing schema breaks things → you need contracts

5. Operation (the most important part)

What it involves:

Alerts
Debugging
Reprocessing

👉 This is where the real work happens

Practical Example

E-commerce pipeline:

Source


orders = fetch_api("/orders")

events = read_stream("user_events")

Raw


INSERT INTO raw_orders

SELECT *

FROM api_orders;

Curated


SELECT

  order_id,

  user_id,

  order_date,

  total_amount

FROM raw_orders

WHERE order_id IS NOT NULL;

Serving


SELECT

  order_date,

  SUM(total_amount) AS revenue

FROM curated_orders

GROUP BY order_date;

Consumption

Dashboard
ML

👉 The pipeline ends when someone actually uses the data

Common Mistakes

Assuming data is correct
Not storing raw data
Not validating outputs
Breaking contracts
Not handling failures

Checklist

Can I reprocess data?
Do I store raw data?
Do I have validations?
Is it idempotent?
Do I know who consumes it?
Do I have alerts?
Are costs controlled?
Are logs useful?

Conclusion

Being a Data Engineer in production is not writing SQL.

It is:

building resilient systems
anticipating failures
balancing trade-offs

👉 Your real value is making sure data always works

CTA

If you’re learning Data Engineering: start with real pipelines, not theory.

👉 Next step: understand Batch vs Streaming in production

Qué hace un Data Engineer en producción (sin humo)

Agustín José Mazzeo — Thu, 28 May 2026 19:17:32 +0000

Qué hace un Data Engineer en producción (sin humo)

Si aprendiste Data Engineering con notebooks y datasets limpios, este artículo es para vos. En producción no hay datasets prolijos: hay sistemas que cambian, pipelines que fallan y datos que tienen que estar bien todos los días.

TL;DR

Un Data Engineer en producción:

Construye y mantiene pipelines confiables
Asegura calidad de datos (no “espera” que llegue bien)
Diseña pensando en consumo (BI, ML, APIs)
Opera: monitorea, debuggea y reprocesa
Toma decisiones con trade-offs reales: costo, performance, riesgo

Problema

En teoría:

“Extraer datos, transformarlos y cargarlos en un data warehouse”

En producción:

Los datos llegan incompletos o tarde
Las APIs fallan o cambian el esquema
Jobs “OK” pueden producir datos incorrectos
Dashboards dependen de vos

👉 Resultado: el trabajo no es solo construir, es operar sistemas de datos vivos

Explicación

Un Data Engineer construye y opera sistemas que convierten datos caóticos en datos confiables para el negocio.

No es solo ETL.

Es:

diseño de pipelines
aseguramiento de calidad
operación continua
decisiones de arquitectura

Una vez que entendés el problema, el trabajo se divide en estas capas:

1. Ingesta (fuentes inestables)

Qué implica:

Integrar APIs, bases, eventos
Manejar errores y reintentos
Detectar cambios de esquema

Ejemplo:

expected = {"order_id", "user_id", "amount"}
for col in expected:
    if col not in df.columns:
        df[col] = None

👉 Diseño defensivo, no datos perfectos

2. Transformación

Qué implica:

Limpieza y deduplicación
Lógica de negocio
Performance

Ejemplo:

SELECT *
FROM (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn
  FROM raw_users
)
WHERE rn = 1;

👉 Decisión clave: correctitud vs performance

3. Modelado

Qué implica:

Diseñar para BI o ML

Ejemplo:

Dashboard → tabla agregada
ML → eventos detallados

👉 Depende del consumo

4. Consumo

Consumidores:

BI
ML
APIs

👉 Cambiar schema rompe cosas → necesitas contratos

5. Operación (lo más importante)

Qué implica:

Alertas
Debug
Reprocesos

👉 Aquí está el trabajo real

Ejemplo práctico

Pipeline de e-commerce:

Source

orders = fetch_api("/orders")
events = read_stream("user_events")

Raw

INSERT INTO raw_orders
SELECT *
FROM api_orders;

Curated

SELECT
  order_id,
  user_id,
  order_date,
  total_amount
FROM raw_orders
WHERE order_id IS NOT NULL;

Serving

SELECT
  order_date,
  SUM(total_amount) AS revenue
FROM curated_orders
GROUP BY order_date;

Consumo

Dashboard
ML

👉 El pipeline termina cuando alguien usa los datos

Errores comunes

Asumir datos correctos
No guardar raw
No validar resultados
Romper contratos
No manejar fallas

Checklist

¿Puedo reprocesar datos?
¿Guardo raw?
¿Tengo validaciones?
¿Es idempotente?
¿Sé quién consume?
¿Tengo alertas?
¿Costo controlado?
¿Logs útiles?

Conclusión

Ser Data Engineer en producción no es escribir SQL.

Es:

construir sistemas resilientes
anticipar fallas
balancear trade-offs

👉 Tu valor real es que los datos funcionen siempre

CTA

Si estás aprendiendo Data Engineering: empezá por pipelines reales, no por teoría.

👉 Siguiente paso: entender Batch vs Streaming en producción