A las 9:00 de un lunes, antes de acabar el primer café, alguien ya quiere saber si los datos del fin de semana llegaron bien. Ese alguien es, muchas veces, el ingeniero de datos (en las ofertas de empleo, Data Engineer): la persona que construye y vigila las tuberías por las que viajan los datos de una empresa. Para que veas cómo es de verdad, te cuento un lunes. Es un escenario ficticio: Lucía y la tienda Zapatea no existen, pero las tareas son las típicas del oficio.
## 9:00. Lo primero: ¿llegó lo de ayer?
Zapatea vende zapatillas por internet. Cada pedido se guarda como una fila (un registro: quién compró, qué y cuándo) en una tabla (como una hoja de cálculo con columnas fijas) de la base de datos de la web, el programa donde guarda su información. Por la noche, un pipeline (tubería de datos: un programa automático que copia datos de un sitio a otro) los lleva a un data warehouse (almacén de datos: una base de datos pensada para que los analistas, las personas que responden preguntas del negocio con datos, la consulten). Lucía no mira el pipeline con lupa. Hace una pregunta rápida al almacén: ¿cuántos pedidos hay por día?
1SELECT2 CAST(fecha AS DATE) AS dia,3 COUNT(*) AS pedidos4FROM pedidos5WHERE fecha >= CURRENT_DATE - 66 AND fecha < CURRENT_DATE7GROUP BY dia8ORDER BY dia;
SQL es el lenguaje para pedirle cosas a una base de datos. CAST(fecha AS DATE) se queda con el día, sin la hora. WHERE limita a los últimos seis días completos, hasta ayer. GROUP BY junta las filas de cada día y COUNT(*) las cuenta. Suponemos una tabla pedidos con una columna fecha.
El resultado es claro: los cinco días anteriores se parecen y el de ayer casi no tiene pedidos. Un domingo tranquilo explicaría una bajada, pero no un casi cero. Lucía sospecha que no es que no se vendiera, sino que no llegó lo vendido. Esta comprobación de cinco minutos es la parte más constante del oficio: antes de arreglar nada, mirar si algo está roto.
## 11:00. El fallo: una carga que se rompió por la noche
Un pipeline tiene pasos. En muchos pipelines el último es la carga (*load*): meter los datos en el almacén. Lucía abre el log (el registro donde el programa va apuntando lo que hace y lo que falla) y lo lee de abajo arriba. Encuentra el aviso a las 03:12: la carga se cortó a medias porque el almacén tuvo un fallo de conexión. La carga original no iba en una transacción (un bloque de pasos que se hace entero o no se hace): insertaba los pedidos por lotes, y por eso quedó a medias. No hay malicia ni misterio. Una tubería se atasca y listo.
Aquí está la trampa. Si Lucía simplemente vuelve a lanzar la carga, los pedidos que sí llegaron antes del corte entrarán dos veces. El almacén contaría ventas que no existen. Por eso un buen pipeline es idempotente: se puede ejecutar una vez o cinco y el resultado final es el mismo. La receta más sencilla tiene dos piezas que van juntas: borrar el día afectado en la copia de `pedidos` que vive en el almacén (no en la base de la web) y cargarlo entero. La tabla `pedidos_nuevos` se vuelve a generar completa, con el día entero, en cada intento. Esa pareja, borrar el día y cargar el día entero, es lo que hace al proceso idempotente.
1BEGIN;23DELETE FROM pedidos4WHERE CAST(fecha AS DATE) = DATE '2026-11-08';56INSERT INTO pedidos7SELECT * FROM pedidos_nuevos8WHERE CAST(fecha AS DATE) = DATE '2026-11-08';910COMMIT;
BEGIN ... COMMIT es una transacción: o se hace todo o no se hace nada, así que nunca queda el día a medias. DELETE borra el domingo en la copia de pedidos del almacén. INSERT lo vuelve a meter desde pedidos_nuevos, que suponemos regenerada entera con el día completo en cada intento. Funciona en bases como PostgreSQL.
Antes de borrar nada en un almacén de verdad, comprueba dos veces la fecha del DELETE y que tienes los datos nuevos a mano. Un DELETE sin su WHERE vacía la tabla entera. Es un error muy común.
## 14:00. Hablar con el analista, que también es trabajo
Después de comer, Pablo, un analista de datos (quien convierte los datos en respuestas y gráficos), le escribe: el panel de ventas (la pantalla de gráficos que mira el negocio) de ayer le sale vacío. Lucía ya lo ha arreglado, pero no le basta con decirlo. Le explica qué falló, qué datos estuvieron mal unas horas y a qué hora estará todo cuadrado. Un buen ingeniero de datos se parece más a un mecánico que explica la avería que a alguien que se esconde tras el código.
## 17:00. Cerrar el día sin dejar bombas de relojería
La tarde de Lucía es más tranquila. Revisa la última carga y deja anotado en un documento qué pasó. Después añade una alerta: un aviso automático que le escribe si un día tiene muy pocos pedidos. Así, la próxima vez que la carga se corte, se enterará a las 7:00 por un mensaje y no a las 11:00 por un analista. Esa es la mejor parte del oficio: cada fallo que arreglas bien es un fallo menos mañana.
## ¿Te encaja? Lo que te gustará y lo que te costará
Un lunes así tiene poco brillo y mucha satisfacción tranquila. Mira cómo se reparte según tu forma de ser.
| Momento | Te gustará si… | Te costará si… |
|---|---|---|
| Revisar lo de ayer | Comprobar te tranquiliza | Odias la rutina |
| Arreglar un fallo | Un misterio te divierte | No saber te bloquea |
| Hablar con analistas | Explicas sin prisa | Prefieres no hablar |
| Que todo funcione | Te basta con saberlo | Necesitas aplausos |
Prueba pequeña antes de decidir: practica consultas SQL como la de las 9:00 sobre datos de ejemplo y fíjate si te entretiene averiguar por qué un número no cuadra. Eso lo practicamos en profundidad en la plataforma con SQL y Python.
Ni todos los lunes son tan limpios (en empresas grandes habrá más reuniones y más herramientas), pero la esencia se repite: comprobar, arreglar, explicar y evitar que vuelva a pasar. Mi opinión: si te gusta que las cosas funcionen sin hacer ruido y te divierte encontrar por qué no lo hacen, este oficio te va a gustar. Si necesitas ver el resultado en un gráfico bonito, mira antes el de analista. Y para salir de dudas, practica unas consultas SQL de ejemplo y mira si te pica la curiosidad cuando un número no cuadra.