Con el mapa puesto, entramos a la etapa 2 — la ingesta — con su pregunta doble: cómo extraer sin re-leer el mundo entero (y sin tumbar la fuente), y a qué ritmo mover lo extraído. Este módulo responde ambas y desactiva el error más caro del entusiasmo: confundir “sería lindo tenerlo al segundo” con “el caso lo exige”.

La tesis del módulo

La ingesta madura extrae solo lo que cambió — con marcas de agua en batch o leyendo el diario de la base con CDC — y elige el ritmo por el SLA de frescura del consumidor, no por moda: batch por defecto, streaming cuando segundos de retraso cambian una decisión. El streaming es un compromiso de operación 24/7 que se firma con razones; el batch bien hecho cubre la enorme mayoría de los casos de IA por una fracción del costo operativo.

Batch incremental: la marca de agua

El batch ingenuo (re-extraer la tabla completa cada noche) muere de dos muertes: el volumen crece y la ventana nocturna no alcanza, y la fuente OLTP sufre la consulta gigante en su horario de operación. La forma adulta es incremental con marca de agua (watermark): recordar hasta dónde llegaste y pedir solo lo posterior.

# Extracción incremental — el patrón, no un framework
ultima_marca = leer_estado("correos.watermark")   # ej: 2026-09-06T02:00
filas = consultar(
    "SELECT * FROM correos WHERE updated_at > %s ORDER BY updated_at",
    ultima_marca,
)
escribir_bronce(filas, particion=hoy())            # crudo, intacto (módulo 2)
guardar_estado("correos.watermark", max(f.updated_at for f in filas))

Las tres trampas del patrón, que distinguen al que lo operó del que lo leyó:

La columna de la marca debe ser confiable. Un updated_at que la aplicación no siempre actualiza = filas invisibles para siempre. Se verifica con la gente de la fuente, no se asume.
Los relojes mienten. Filas con timestamps levemente pasados (transacciones largas, relojes desincronizados) se pierden si la marca avanza demasiado rápido. El seguro barato: extraer con solape (> ultima_marca - 5 minutos) y dejar que la idempotencia del módulo 2 absorba los duplicados.
Los borrados no aparecen. La fila eliminada en la fuente no matchea ningún WHERE updated_at > — tu copia la conserva como zombi. Detectar borrados exige comparaciones periódicas… o la herramienta siguiente, que los ve pasar.

CDC: leer el diario en vez de interrogar

El Change Data Capture cambia el enfoque: en vez de preguntarle a la base qué cambió, lee su diario de transacciones (el WAL de PostgreSQL, el binlog de MySQL — el registro interno donde la base anota cada cambio antes de aplicarlo). Herramientas como Debezium (el estándar open source) se conectan a ese diario y emiten cada inserción, actualización y borrado como un evento, típicamente hacia Kafka.

Dimensión	Batch incremental	CDC
Carga sobre la fuente	Una consulta por corrida	Casi nula (lee el diario, no consulta)
Frescura	La del schedule (minutos-horas)	Segundos
¿Ve los borrados?	No (el problema zombi)	Sí — son eventos como cualquier otro
Complejidad operativa	Baja	Media-alta (conector, permisos de replicación, Kafka)
Cuándo	Default sano	Fuentes de alto cambio, necesidad de deletes o frescura, réplicas analíticas

CDC es la respuesta técnica más elegante de la etapa — y una pieza más que operar. La vara de decisión honesta: se adopta cuando el batch incremental duele (frescura insuficiente, borrados que importan, fuente castigada), no como punto de partida.

Kafka: el bus que desacopla

Apache Kafka es el bus de eventos distribuido — el lugar donde los flujos (eventos de la aplicación, cambios del CDC) se publican en topics particionados y persistentes, y los consumidores leen a su propio ritmo, cada uno con su offset (su marcador de posición independiente). Conceptualmente es el Pub/Sub de la serie cloud — mismo patrón de desacople — con los rasgos que lo hicieron el estándar de datos:

Retención re-leíble: los eventos persisten días o semanas; un consumidor nuevo (o uno arreglado tras un bug) puede rebobinar y re-leer — el backfill del módulo 2 como propiedad del bus.
Orden por partición y throughput masivo: la razón de su reinado en pipelines de eventos de verdad.
El desacople como arquitectura: el productor no sabe cuántos consumidores hay. El mismo topic de correos alimenta hoy al triaje y mañana al dataset de entrenamiento — sin tocar la fuente. Esa es la gracia estructural para IA: los consumidores de datos se multiplican con los casos de uso, y el bus los absorbe.

En la práctica gestionada, Kafka aparece como servicio (MSK en AWS, Confluent, o el pariente Pub/Sub/Event Hubs de cada nube) — la regla del build-vs-managed aplica: operar Kafka propio es un oficio; se justifica con escala o requisitos, no por default.

La decisión: batch por defecto, streaming con razones

   ¿BATCH O STREAMING? — EL ÁRBOL HONESTO

START ──► ¿segundos de retraso cambian
          una DECISIÓN del negocio?
          (fraude, alerta operativa,
          personalización en sesión)
                │
       sí ──────┴────── no
        │                │
        ▼                ▼
  ¿y el consumidor   BATCH incremental
  puede ACTUAR en    (schedule por SLA
  segundos?          de frescura)
        │
   ┌────┴────┐
   ▼ sí      ▼ no
 STREAMING  BATCH
 (Kafka/CDC (más frecuente
 + consumo  si hace falta:
 continuo)  cada 15 min es
            batch también)

Las dos preguntas del árbol desarman la mayoría de los “necesitamos streaming”: el reporte que se mira una vez al día no decide nada en segundos, y el proceso cuyo paso siguiente es humano-mañana tampoco puede actuar al instante. Para el catálogo del curso: el triaje de correos vive perfecto con micro-batch de minutos (la cola ya desacopla); el índice del RAG del módulo 10 se refresca por batch frecuente; el fraude bancario — si lo tuviéramos — sí firmaría el compromiso streaming. Y el punto medio existe: batch cada 5-15 minutos da frescura de “casi ahora” con la operación simple de batch — el secreto peor guardado de la industria.

Ojo — streaming es un compromiso de operación, no una configuración: consumidores corriendo 24/7, manejo de eventos tardíos y desordenados, reprocesamiento más delicado, monitoreo continuo. El curso de Voz mostró la versión audio de esta verdad; en datos es igual: el tiempo real se paga en operación permanente. Fírmalo cuando el caso lo cobre.

Errores comunes

Full extract eterno. “Recargamos todo cada noche” funciona hasta que el volumen o la ventana lo matan — y castiga la fuente mientras tanto. Incremental con marca de agua desde el diseño.
Marca de agua sin solape. Los relojes y las transacciones largas roban filas en el borde. Solape + idempotencia: duplicar-y-deduplicar es barato; perder es invisible.
Olvidar los borrados. La copia analítica llena de zombis que la fuente ya mató. O comparaciones periódicas, o CDC — pero decidido, no descubierto.
Streaming por currículum. La arquitectura de segundos para consumidores de horas: complejidad 24/7 comprada sin cobrador. El árbol se recorre con el SLA del consumidor en la mano.
Tratar Kafka como una cola simple. Sin retención pensada, sin partición por clave, sin aprovechar la re-lectura: pagar Kafka para usarlo de SQS. Si no necesitas sus rasgos, la cola simple era más barata; si los necesitas, úsalos.
CDC sin hablar con el DBA. El conector necesita permisos de replicación y configuración de la base — y el diario que no se consume se acumula. CDC es un acuerdo con quien opera la fuente, no un plugin.

La frase para llevarse

“Extrae solo lo que cambió — con marca de agua y solape, o leyendo el diario con CDC — y elige el ritmo con el SLA del consumidor en la mano: batch por defecto, micro-batch cuando apriete, y streaming solo cuando segundos cambian decisiones y alguien puede actuar en segundos. El tiempo real se paga en operación.”

Qué viene

Módulo 4: dónde vive el dato — lake, warehouse y lakehouse. Los datos ya entran; falta la casa: por qué los formatos columnar (Parquet) cambian la economía de la analítica, qué separa un data lake de un warehouse, y cómo los formatos de tabla abiertos (Iceberg, Delta) crearon el híbrido que domina la década — el lakehouse — con las capas medallón del módulo 2 viviendo encima.

Data Engineering — Módulo 3: ingesta — batch, streaming y CDC