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