Materializaciones e incremental models

Objetivo

Elegir view/table/incremental según coste y uso.

Explicación

view recalcula al consultar; table se reconstruye al ejecutar; incremental procesa subconjuntos. El incremental necesita unique_key y lógica que considere cambios tardíos. dbt aporta valor cuando las transformaciones dejan de ser consultas sueltas y pasan a formar un DAG versionado, testeable y documentado. En trabajo real tendrás que justificar dependencias, contratos de datos y cómo despliegas cambios sin romper modelos downstream. Un modelo incremental correcto debe producir el mismo estado lógico que un full refresh, incluso tras reejecuciones y datos tardíos. El ahorro de tiempo no justifica sacrificar exactitud; por eso compararás ambos modos y documentarás la clave/ventana incremental. Para trabajar Materializaciones e incremental models 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: Identificas el trade-off entre coste y cobertura de late data. La verificación principal será: Ejecuta dos veces y comprueba unicidad/total. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

dbt aporta valor cuando las transformaciones dejan de ser consultas sueltas y pasan a formar un DAG versionado, testeable y documentado. En trabajo real tendrás que justificar dependencias, contratos de datos y cómo despliegas cambios sin romper modelos downstream. Un modelo incremental correcto debe producir el mismo estado lógico que un full refresh, incluso tras reejecuciones y datos tardíos. El ahorro de tiempo no justifica sacrificar exactitud; por eso compararás ambos modos y documentarás la clave/ventana incremental.

Ejemplo real

{{ config(materialized='incremental', unique_key='order_id') }}
select * from {{ ref('stg_orders') }}
{% if is_incremental() %} where updated_at >= (select dateadd(day,-2,max(updated_at)) from {{ this }}) {% endif %}

Archivos o datos de entrada

• dbt/dbt_project.yml
• dbt/models/staging/stg_orders.sql

Práctica guiada

Convierte un modelo de pedidos en incremental conceptual.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: dbt/dbt_project.yml, dbt/models/staging/stg_orders.sql. 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 «Materializaciones e incremental models».
• Ejecuta la práctica guiada: Convierte un modelo de pedidos en incremental conceptual. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Explica qué pasaría con un update de hace 5 días usando ventana de 2 días. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: Identificas el trade-off entre coste y cobertura de late data. Después ejecuta la comprobación: Ejecuta dos veces y comprueba unicidad/total.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Incremental rápido pero incorrecto es peor que full refresh correcto.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Explica qué pasaría con un update de hace 5 días usando ventana de 2 días.

Resultado esperado

Identificas el trade-off entre coste y cobertura de late data.

Cómo verificarlo

Ejecuta dos veces y comprueba unicidad/total.

Checklist de validación

• El resultado cumple: Identificas el trade-off entre coste y cobertura de late data.
• Has ejecutado esta verificación y puedes explicar el resultado: Ejecuta dos veces y comprueba unicidad/total.
• 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

• Incremental rápido pero incorrecto es peor que full refresh correcto.

Qué debes recordar

dbt debe hacer explícitas dependencias, tests y documentación de tus transformaciones.

Preguntas de entrevista

• ¿Qué test o contrato añadirías a este modelo y por qué? Aplícalo concretamente a «Materializaciones e incremental models».
• ¿Cómo comprobarías que el cambio no rompe modelos downstream? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Cerrarás con documentación y CI.

Recursos de esta lección