Documentación, lineage y CI

Objetivo

Convertir el proyecto dbt en un artefacto mantenible.

Explicación

Descriptions, tests y lineage permiten entender impacto. En CI conviene construir sólo cambios y dependencias en un entorno aislado, pero siempre validar contratos clave. 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. Para trabajar Documentación, lineage y CI 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: Otra persona puede entender modelos, columnas y dependencias sin leer todo el SQL. La verificación principal será: dbt build termina sin errores y la documentación refleja los modelos. 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.

Ejemplo real

dbt build --select state:modified+

Archivos o datos de entrada

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

Práctica guiada

Documenta dim_customers y fact_orders con descriptions.

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 «Documentación, lineage y CI».
  • Ejecuta la práctica guiada: Documenta dim_customers y fact_orders con descriptions. Documenta el comando, consulta o acción exacta y el resultado obtenido.
  • Resuelve el reto sin mirar la solución: Diseña un PR que cambie una columna y enumera qué tests deberían ejecutarse. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
  • Compara tu resultado con el criterio esperado: Otra persona puede entender modelos, columnas y dependencias sin leer todo el SQL. Después ejecuta la comprobación: dbt build termina sin errores y la documentación refleja los modelos.
  • Provoca deliberadamente un caso problemático relacionado con este error frecuente: Un proyecto con SQL correcto pero sin tests/documentación es difícil de operar.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Diseña un PR que cambie una columna y enumera qué tests deberían ejecutarse.

Resultado esperado

Otra persona puede entender modelos, columnas y dependencias sin leer todo el SQL.

Cómo verificarlo

dbt build termina sin errores y la documentación refleja los modelos.

Checklist de validación

  • El resultado cumple: Otra persona puede entender modelos, columnas y dependencias sin leer todo el SQL.
  • Has ejecutado esta verificación y puedes explicar el resultado: dbt build termina sin errores y la documentación refleja los modelos.
  • 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).
Pista específica

Documenta el porqué, no sólo repitas el nombre de columna.

Solución paso a paso

1) Empieza reproduciendo el caso base con los datos indicados. 2) Aplica esta estrategia específica: Describe grain, reglas y fuente de cada modelo clave. 3) Usa como referencia técnica el ejemplo de la lección (dbt build –select state:modified+). 4) Ejecuta la verificación: dbt build termina sin errores y la documentación refleja los modelos. 5) Compara con el resultado esperado: Otra persona puede entender modelos, columnas y dependencias sin leer todo el SQL. 6) Repite el reto cambiando un dato o condición para demostrar que entiendes el comportamiento y no has obtenido el resultado por casualidad. Si aparece el error «Un proyecto con SQL correcto pero sin tests/documentación es difícil de operar.», corrige la causa antes de continuar; no ocultes el fallo ni cambies el resultado esperado para que la prueba pase.

Errores frecuentes

  • Un proyecto con SQL correcto pero sin tests/documentación es difícil de operar.

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 «Documentación, lineage y CI».
  • ¿Cómo comprobarías que el cambio no rompe modelos downstream? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Aplicarás dbt dentro de proyectos de portfolio.

Recursos de esta lección

Quiz de la lección

¿Qué muestra lineage?

Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.