Batch, incremental y full refresh

Objetivo

Elegir estrategia de procesamiento según volumen y semántica.

Explicación

Full refresh reconstruye todo; incremental procesa sólo cambios. Un incremental necesita una frontera fiable: timestamp, secuencia o CDC. El ahorro de coste no sirve si la lógica pierde actualizaciones tardías. Los pipelines reales fallan, se reejecutan y reciben datos tardíos. Por eso la práctica no termina cuando “funciona una vez”: debes pensar en idempotencia, reconciliación, registros inválidos y evidencia suficiente para diagnosticar un fallo sin adivinar. Para trabajar Batch, incremental y full refresh de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: La estrategia documenta watermark y tratamiento de late-arriving data. La verificación principal será: Reejecutar el mismo lote no debe duplicar filas. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

Los pipelines reales fallan, se reejecutan y reciben datos tardíos. Por eso la práctica no termina cuando “funciona una vez”: debes pensar en idempotencia, reconciliación, registros inválidos y evidencia suficiente para diagnosticar un fallo sin adivinar.

Ejemplo real

-- frontera conceptual
WHERE updated_at > :last_successful_watermark

Archivos o datos de entrada

• data/ecommerce_orders.csv

Práctica guiada

Simula dos lotes de pedidos con updated_at.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: data/ecommerce_orders.csv. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Batch, incremental y full refresh».
• Ejecuta la práctica guiada: Simula dos lotes de pedidos con updated_at. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Diseña qué ocurre si llega tarde una actualización con updated_at antiguo. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: La estrategia documenta watermark y tratamiento de late-arriving data. Después ejecuta la comprobación: Reejecutar el mismo lote no debe duplicar filas.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Append puro duplica cambios si la fuente reenvía registros.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Diseña qué ocurre si llega tarde una actualización con updated_at antiguo.

Resultado esperado

La estrategia documenta watermark y tratamiento de late-arriving data.

Cómo verificarlo

Reejecutar el mismo lote no debe duplicar filas.

Checklist de validación

• El resultado cumple: La estrategia documenta watermark y tratamiento de late-arriving data.
• Has ejecutado esta verificación y puedes explicar el resultado: Reejecutar el mismo lote no debe duplicar filas.
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• Append puro duplica cambios si la fuente reenvía registros.

Qué debes recordar

Un pipeline fiable puede reejecutarse, detectar errores y explicar qué hizo.

Preguntas de entrevista

• ¿Cómo harías este proceso idempotente? Aplícalo concretamente a «Batch, incremental y full refresh».
• ¿Qué registrarías para poder reanudar o investigar una ejecución fallida? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Implementarás MERGE/upsert.

Recursos de esta lección