Concepto clave

Monitorear y depurar fallos en tests de dbt es como ser el mecánico de un coche de carreras durante una competición. No basta con saber que algo falló; necesitas herramientas de diagnóstico rápidas, un proceso sistemático para identificar la raíz del problema, y la capacidad de aplicar soluciones sin detener toda la operación. En dbt Cloud, los tests validan la calidad de tus datos, y cuando fallan, indican problemas que podrían afectar decisiones empresariales.

El monitoreo proactivo implica revisar regularmente los resultados de ejecución de tests, mientras que la depuración es la investigación detallada cuando algo sale mal. Piensa en esto como un sistema de alertas tempranas: un test fallido sobre unicidad en una columna clave podría significar duplicados en tus datos de ventas, lo que distorsionaría reportes de ingresos. No resolverlo rápidamente puede llevar a errores costosos.

Cómo funciona en la practica

Imagina que eres Analytics Engineer en una empresa de e-commerce. Cada mañana, ejecutas un job en dbt Cloud que incluye tests en tus modelos. Hoy, el test not_null en la columna order_id del modelo stg_orders ha fallado. Tu proceso paso a paso:

Accede a dbt Cloud y navega a la pestaña Runs para ver el job fallido.
Haz clic en el run específico y revisa la sección de logs, filtrando por errores o warnings.
Identifica el test fallido: verás un mensaje como "FAILED test not_null_stg_orders_order_id".
Usa el enlace al artefacto de documentación generado (como el archivo run_results.json) para detalles técnicos.
Investiga la fuente de datos: consulta directamente el warehouse (ej., BigQuery) para verificar si hay valores nulos en order_id.
Corrige el problema en la fuente o ajusta el modelo, luego re-ejecuta los tests.

Codigo en accion

Antes: Un test básico que falla sin contexto claro en los logs.

# En schema.yml del modelo stg_orders
version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - not_null
          - unique

Después: Mejora el test con configuraciones para depuración más fácil.

# En schema.yml con configuraciones avanzadas
version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - not_null:
              error_if: ">0"  # Falla si hay más de 0 nulos
              warn_if: ">0"   # También emite warning para monitoreo
          - unique:
              severity: error  # Define la severidad para filtrado en logs

Ejemplo de consulta SQL para depurar después de un fallo:

-- En tu warehouse, investiga valores nulos en order_id
SELECT *
FROM `tu_proyecto.tu_dataset.stg_orders`
WHERE order_id IS NULL
LIMIT 10;

-- Para ver duplicados si falla el test unique
SELECT order_id, COUNT(*) as count
FROM `tu_proyecto.tu_dataset.stg_orders`
GROUP BY order_id
HAVING COUNT(*) > 1
ORDER BY count DESC;

Errores comunes

Ignorar tests fallidos temporalmente: Desactivar tests con --exclude en ejecuciones sin investigar la causa raíz. Solución: Usa logs y consultas SQL para diagnosticar antes de saltar tests.
No configurar severidades en tests: Todos los tests como error pueden causar pánico innecesario. Solución: Usa warn para problemas menores y error para críticos, ajustando en dbt_project.yml.
Depurar solo con logs de dbt Cloud: Los logs pueden ser limitados. Solución: Integra con herramientas como Slack para alertas o usa queries personalizadas en el warehouse.
No versionar cambios en tests: Modificar tests sin track en Git dificulta el rollback. Solución: Trata los archivos .yml como código y usa commits descriptivos.
Sobrecargar un job con muchos tests: Ejecutar todos los tests en cada run ralentiza el pipeline. Solución: Usa tags para ejecutar tests críticos diarios y el resto semanalmente.

Checklist de dominio

Puedo acceder a logs de dbt Cloud y filtrar por tests fallidos en menos de 2 minutos.
Sé configurar severidades (error/warn) en tests para priorizar incidentes.
Utilizo consultas SQL en mi warehouse para investigar datos cuando un test falla.
He integrado alertas de tests fallidos en un canal de equipo (ej., Slack o email).
Documento las causas raíz de fallos de tests en un registro para análisis recurrente.
Optimizo la ejecución de tests usando tags y configuraciones de schedule en dbt Cloud.
Reviso periódicamente el historial de runs para identificar patrones de fallos.

Depura un test fallido en un modelo de ventas

En este ejercicio, simularás un escenario real donde un test de dbt ha fallado en tu pipeline de datos. Sigue estos pasos para diagnosticar y resolver el problema.

Prepara el entorno: En dbt Cloud, crea un nuevo proyecto o usa uno existente. Asegúrate de tener un modelo llamado sales_summary en tu warehouse con al menos 100 filas de datos de ejemplo.
Configura un test que falle: En el archivo schema.yml del modelo sales_summary, añade un test not_null en la columna customer_id. Inserta manualmente una fila con customer_id NULL en tu tabla para forzar el fallo.
Ejecuta y monitorea: Corre el comando dbt test --models sales_summary en dbt Cloud. Navega a la pestaña Runs y revisa los logs del job fallido. Anota el mensaje de error específico.
Investiga con SQL: En tu warehouse (ej., BigQuery, Snowflake), ejecuta una consulta para identificar todas las filas donde customer_id es NULL en la tabla sales_summary. Usa LIMIT para controlar la salida.
Corrige y re-ejecuta: Elimina o corrige la fila con NULL (puedes usar una actualización UPDATE o DELETE). Luego, ejecuta el test nuevamente en dbt Cloud y verifica que pase.
Documenta el proceso: En un archivo README o en comentarios del código, registra la causa del fallo y la solución aplicada para referencia futura.

Pistas

Usa la interfaz web de dbt Cloud para ver logs detallados; no te limites a la salida de terminal.
Si tu warehouse no permite INSERT directo, crea un dataset de prueba con datos simulados usando dbt seeds.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Monitorear y Depurar Fallos en Tests