El problema: "mi script funciona... cuando lo ejecuto yo"

### La historia que todo ingeniero de datos ha vivido

Imagina esto: llevas tres meses construyendo un pipeline precioso. Lee datos de una API, los limpia con Pandas, los transforma con PySpark, los guarda en Parquet particionado por fecha y actualiza una tabla en el warehouse. Funciona perfecto. Lo ejecutas cada mañana a las 7:30 antes de tu café y los datos están listos para cuando el equipo de negocio llega a las 9. Te sientes orgulloso. El CEO te felicita en la reunión semanal.

Entonces te vas de vacaciones dos semanas a la playa. El lunes a las 10AM tu teléfono explota: "¿dónde están los datos de hoy?". El martes: "llevamos dos días sin dashboard". El miércoles el CTO te llama directamente. Tu pipeline perfecto tenía un único punto de fallo: TÚ. Tu dedo pulsando Enter cada mañana era parte de la infraestructura de la empresa, y nadie se había dado cuenta hasta que ese dedo se fue a tomar mojitos.

Esta historia no es ficción. Es el pan de cada día en empresas que crecen rápido. El script empieza como un experimento, funciona, se promueve a "producción" (que realmente significa "lo ejecuto yo todos los días") y eventualmente falla de la peor forma posible: silenciosamente, cuando nadie está mirando.

### Los cinco problemas de la ejecución manual

Vamos a diseccionar por qué ejecutar pipelines a mano es una estrategia que escala exactamente hasta el tamaño de tu memoria y tu disciplina personal — es decir, no escala.

1. 01.Dependencia humana: si te pones enfermo, te vas de vacaciones o simplemente se te olvida, el pipeline no corre. No hay plan B.
2. 02.Sin horario garantizado: "lo lanzo cada mañana" no es un SLA. Algunos días lo lanzas a las 7, otros a las 9, otros se te olvida hasta las 11. El equipo de negocio nunca sabe cuándo los datos estarán listos.
3. 03.Sin gestión de errores: Juan lo lanza a las 8, se va a una reunión y vuelve a las 11. El script murió en el minuto tres porque el SFTP no respondía — tres horas de datos que el equipo de BI ya ha usado para presentar números que no existen. Y cuando un día Juan no esté y alguien ponga un cron para taparlo, el fallo pasará a las 3AM y nadie lo verá hasta el día siguiente.
4. 04.Sin reintentos automáticos: la API origen devolvió un timeout. Si estuvieras delante, lo relanzarías. Pero estás durmiendo. Y mañana tendrás que recuperar dos días de datos.
5. 05.Sin trazabilidad: ¿cuándo se ejecutó por última vez? ¿tardó lo normal o fue más lento? ¿procesó los 2 millones de registros o se quedó en 500.000? Sin logs centralizados ni historial, estás ciego.

### ¿Qué es orquestar?

Orquestar es coordinar la ejecución automática de tareas interdependientes. La analogía perfecta es un director de orquesta: no toca ningún instrumento, pero decide cuándo entra cada sección, en qué orden, a qué tempo, y qué hacer si un músico se equivoca (¿paramos todo? ¿seguimos sin él?). Un orquestador de datos hace exactamente eso con tus scripts.

Cuando dices "mi pipeline tiene tres pasos: ingestar, transformar y cargar", lo que necesitas es algo que diga: primero ejecuta ingestar. Si sale bien, ejecuta transformar. Si transformar sale bien, ejecuta cargar. Si cualquier paso falla, reintenta 3 veces. Si sigue fallando, envía un email al equipo y para. Y que esto ocurra todos los días a las 6AM sin que ningún humano pulse nada.

### El concepto más importante: idempotencia

Antes de hablar de herramientas concretas, necesitas grabar a fuego un concepto que separará tus pipelines "de juguete" de los de producción: la idempotencia. Una operación es idempotente cuando puedes ejecutarla varias veces y el resultado es el mismo que ejecutarla una sola vez.

La analogía perfecta: pedir un café en una cafetería. Si por un glitch del sistema tu pedido se envía dos veces, NO quieres recibir dos cafés y que te cobren doble. Quieres que el sistema detecte "ah, este pedido ya lo procesé" y te entregue un solo café. Eso es idempotencia.

¿Por qué importa en pipelines? Porque los orquestadores reintentan cosas. Si tu paso "cargar datos" falla a mitad y se reintenta, necesitas que la segunda ejecución no duplique los datos que ya se cargaron en la primera mitad. Necesitas que puedas reejecutar el pipeline entero y obtener el mismo resultado que si solo se ejecutara una vez.

1from sqlalchemy import text
2
3# ❌ NO idempotente: cada ejecución AÑADE filas
4def cargar_datos(df, tabla):
5    df.to_sql(tabla, con=engine, if_exists='append')
6    # Si se ejecuta 2 veces: datos duplicados!
7
8# ✅ Idempotente: cada ejecución REEMPLAZA la partición del día
9def cargar_datos_idempotente(df, tabla, fecha):
10    with engine.begin() as conn:
11        # Borra los datos de ese día (si existen), en transacción
12        conn.execute(
13            text(f"DELETE FROM {tabla} WHERE fecha = :fecha"),
14            {"fecha": fecha}
15        )
16        # Inserta dentro de la MISMA transacción
17        df.to_sql(tabla, con=conn, if_exists='append', index=False)
18    # Si falla el INSERT, el DELETE se revierte automáticamente
19    # Si se ejecuta 2 veces: mismo resultado

¿Y por qué la idempotencia importa tanto? No solo por los reintentos — esos son el motivo menor. El motivo mayor es el backfill: con un pipeline idempotente puedes reprocesar el pasado. Descubres un bug que llevaba un mes corrompiendo datos, relanzas los treinta días, y la tabla queda limpia. Sin idempotencia, relanzar duplica o corrompe. Con ella, relanzar es la solución.

El DELETE + INSERT por fecha que acabas de ver es un patrón de idempotencia, pero no el único. El otro es el upsert por clave: INSERT ... ON CONFLICT (id) DO UPDATE en PostgreSQL (MERGE en el estándar SQL). La regla para elegir: DELETE + INSERT cuando reprocesas una partición entera (un día, un país, un fichero). Upsert cuando llegan registros sueltos que pueden repetirse — por ejemplo, una Lambda que se ejecuta dos veces por el mismo evento.

### Las tres familias de orquestadores

A lo largo de los años, la industria ha creado tres grandes familias de herramientas para orquestar pipelines. Cada una nació en un contexto diferente y resuelve el problema con una filosofía distinta:

1. 01.Cron (1979): el abuelo. Un programador de tareas del sistema operativo. Le dices "ejecuta este script todos los días a las 6AM" y lo hace. Sin reintentos, sin dependencias entre tareas, sin interfaz visual. Primitivo pero ubicuo.
2. 02.Máquinas de estado / Step Functions (2016): piensas en tu pipeline como un diagrama de flujo. "Si este paso sale bien, ve al siguiente. Si falla, ve a la rama de error". Visual, intuitivo, serverless. AWS Step Functions es el referente.
3. 03.DAGs / Airflow (2014): piensas en tu pipeline como un grafo dirigido acíclico (DAG). Defines tareas y sus dependencias, y el scheduler se encarga de ejecutarlas en el orden correcto. Potente, flexible, el estándar de la industria.

En esta skill vamos a recorrer las tres, de la más simple a la más compleja. Empezaremos con Step Functions porque su modelo mental (máquina de estados = diagrama de flujo) es el más intuitivo para entender QUÉ es orquestación. Luego instalaremos Airflow para ver el estándar que encontrarás en la mayoría de empresas. Y terminaremos comparando cuándo usar cada una.

### El mapa de esta skill

1. 01.Lección 1 (esta): entender el DOLOR y los conceptos fundamentales
2. 02.Lección 2: instalar LocalStack para emular Step Functions en tu máquina
3. 03.Lección 3: crear máquinas de estado con Step Functions
4. 04.Lección 4: construir un workflow completo (ingesta → transformación → carga)
5. 05.Lección 5: gestionar errores, reintentos y bifurcaciones
6. 06.Lección 6: instalar Apache Airflow con Docker
7. 07.Lección 7: crear DAGs, usar operators y configurar scheduling
8. 08.Lección 8: comparativa final — cuándo usar qué herramienta