El módulo 1 dejó la tesis; este deja el mapa. Todo pipeline de datos — del script humilde al lakehouse corporativo — tiene la misma anatomía de cinco etapas, y aprenderla primero tiene una recompensa concreta: cada herramienta que veas en el resto del curso (Kafka, dbt, Airflow, Iceberg) deja de ser una sigla suelta y pasa a ser “la pieza de la etapa 3”. El mapa convierte el zoológico en organigrama.

La tesis del módulo

Cinco etapas, cinco decisiones: de las fuentes se decide qué extraer y cómo detectar cambios; de la ingesta, el ritmo (batch o streaming); del almacenamiento, el formato y las capas; de la transformación, dónde y con qué reglas; del servicio, a quién y con qué frescura. Y un principio rector cruza todo: el dato crudo se guarda intacto y para siempre que se pueda — porque toda transformación se puede rehacer, pero lo que la fuente ya no tiene no se recupera de ninguna parte.

Las cinco etapas

   LA ANATOMÍA DE TODO PIPELINE

  1. FUENTES  (OLTP, APIs, archivos, eventos)
     │  ¿qué extraer y cómo detectar cambios?
     ▼
  2. INGESTA  (batch / streaming / CDC)
     │  ¿a qué ritmo?
     ▼
  3. ALMACENAMIENTO  (bronce → plata → oro)
     │  ¿formato y capas?
     ▼
  4. TRANSFORMACIÓN  (limpiar, unir, agregar)
     │  ¿dónde y con qué?
     ▼
  5. SERVICIO  (BI, dataset, índice RAG, features)
        ¿a quién y qué tan fresco?

1. Fuentes. Donde el dato nace, y donde tú no mandas: los sistemas transaccionales (OLTP: las bases operativas que procesan las transacciones del negocio — el CRM, el ERP, la app), las APIs de terceros, los archivos que alguien deposita, los flujos de eventos. La decisión de esta etapa es doble: qué extraer, y cómo detectar lo que cambió — porque re-extraer todo cada vez muere con el volumen. Las respuestas (extracción incremental, CDC) son el módulo 3.

2. Ingesta. El movimiento desde la fuente hacia tu territorio. La decisión es el ritmo: batch (por lotes, cada cierto tiempo — el correo de anoche procesado a las 2 AM) o streaming (evento a evento, en segundos — el pago que dispara la verificación al instante). La regla que el módulo 3 argumentará: batch por defecto, streaming cuando el caso de uso — no el entusiasmo — exige frescura de segundos.

3. Almacenamiento. Donde el dato aterriza, en capas de refinamiento progresivo. La convención de la industria las llama medallón: bronce (el crudo, tal cual llegó), plata (limpio y conformado), oro (agregado y listo para consumir). La decisión es el formato y la casa — archivos columnar en un lake, tablas en un warehouse, o el híbrido lakehouse — y es el módulo 4 entero.

4. Transformación. Convertir crudo en útil: limpiar tipos, deduplicar, unir fuentes, aplicar reglas de negocio, agregar. Las decisiones — ¿transformo antes o después de cargar (ETL vs. ELT)? ¿con qué herramienta y qué disciplina? — son el módulo 5, y su vigilancia (¿la transformación produjo basura?) el 7.

5. Servicio. La etapa que justifica todas las anteriores: entregar el dato a sus consumidores — el dashboard del analista, el dataset del entrenamiento, el índice del RAG, el feature store del modelo en producción — cada uno con su SLA de frescura (¿de hace cuánto puede ser el dato? — un reporte mensual tolera días; una feature de fraude, milisegundos). Los módulos 8-11 son, en el fondo, cuatro variantes de esta etapa para consumidores de IA.

El principio rector: el crudo es sagrado

La decisión de diseño más barata de tomar temprano y más cara de lamentar tarde: la capa bronce guarda el dato exactamente como llegó — sin limpiar, sin “arreglar”, sin filtrar — y las transformaciones producen capas nuevas. Tres razones, en orden de dolor:

Las transformaciones tienen bugs. El día que descubras que la limpieza de teléfonos borraba los números extranjeros, re-corres la transformación sobre el bronce y recuperas todo. Si limpiaste “en el aire” (transformando durante la ingesta, sin guardar el crudo), esos datos no existen más.
Los requisitos cambian. El campo que hoy “no sirve” es el que el caso de uso de 2027 necesita. El bronce barato de hoy (módulo 4: el almacenamiento de objetos cuesta centavos) es la opcionalidad de mañana.
La fuente olvida. Muchas fuentes solo tienen el estado actual (el CRM sobrescribe; la API devuelve el presente). Tu bronce con historia es, a menudo, el único registro histórico que la organización tiene — y los modelos se entrenan con historia.

Ojo: “el crudo es sagrado” tiene una excepción con nombre propio que el módulo 9 desarrollará: los datos personales no se acumulan alegremente por opcionalidad — la retención de PII es una decisión de política, no de conveniencia técnica (la lección del honeypot, que este curso hereda). Crudo sagrado sí; crudo con RUT y tarjetas para siempre, no.

El vocabulario que ordena todo lo demás

Push vs. pull: ¿la fuente te empuja los datos (webhooks, eventos) o tú los traes (consultas programadas)? Pull es más simple de operar; push es más fresco y exige estar listo para recibir (las colas del curso cloud reaparecerán).
Idempotencia del pipeline: correr la misma carga dos veces no debe duplicar datos — el pariente del principio de los consumidores de colas, ahora a escala de lote. Se implementa con claves de partición y escrituras que reemplazan (módulo 5); es la propiedad que permite re-correr sin miedo, y re-correr sin miedo es la mitad de operar pipelines.
Backfill: re-procesar el pasado (cargar los 3 años de correos históricos, re-correr enero tras arreglar el bug). Un pipeline que no puede hacer backfill limpio es un pipeline que le teme a su propia historia — el módulo 6 lo convierte en operación de rutina.
Linaje (lineage): de qué fuentes y transformaciones desciende cada dato — la trazabilidad que responde “¿de dónde salió este número?” y “¿a quién rompo si cambio esta tabla?”. Se cosecha gratis si usas las herramientas de los módulos 5-6 con disciplina; el módulo 12 lo gobierna.

Errores comunes

Transformar durante la ingesta. El dato “arreglado” en el aire es información destruida: el bug de la limpieza se vuelve irrecuperable. Ingesta cruda a bronce; transformación como etapa propia.
Elegir herramientas antes que anatomía. “Usemos Kafka/dbt/Spark” antes de saber qué etapa resuelven produce el zoológico de siglas sin organigrama. El mapa primero; las piezas caen solas.
Un solo ritmo para todo. Streaming para el reporte mensual (complejidad regalada) o batch para el fraude (frescura imposible): el ritmo se decide por consumidor, y conviven ambos en el mismo pipeline.
SLA de frescura implícito. “Los datos están desactualizados” sin un SLA acordado es una discusión sin árbitro. Cada consumidor declara su frescura tolerable; el pipeline se diseña contra ella.
Pipelines no idempotentes. El pipeline que duplica al re-correrse convierte cada incidente en dos: el original y la limpieza de los duplicados. La idempotencia se diseña el día uno, cuando es gratis.
Descubrir el backfill en la emergencia. “¿Y cómo cargamos lo histórico?” preguntado en la semana del lanzamiento revela que el pipeline solo sabe avanzar. El backfill se diseña con el pipeline, no después.

La frase para llevarse

“Cinco etapas y una regla de oro: guarda el crudo intacto — las transformaciones se rehacen, la fuente olvida, y tu bronce con historia suele ser la única memoria real de la organización. Todo lo demás del curso es poblar este mapa con criterio.”

Qué viene

Módulo 3: ingesta — batch, streaming y CDC. La etapa 2 en serio: la extracción incremental que no re-lee el mundo entero, el Change Data Capture que lee el diario de la base en vez de castigarla con consultas, Kafka como el bus de eventos que desacopla productores de consumidores, y la tabla de decisión batch-vs-streaming que evita el error más caro del entusiasmo: pagar arquitectura de segundos para necesidades de horas.

Data Engineering — Módulo 2: el mapa del pipeline