Catalyst frente a los tests de dbt: monitorización más allá de tus modelos

Los tests de dbt son aserciones en tiempo de build sobre los modelos que dbt gobierna. Catalyst monitoriza cualquier tabla con su propia programación, incluidas las fuentes que dbt nunca toca.

2026-09-10 · 11 min read

Los tests de dbt y Catalyst no son realmente competidores, y fingir lo contrario te haría perder el tiempo. Los tests de dbt son aserciones que se ejecutan dentro de un build de transformación, contra los modelos que dbt gestiona, en el momento en que dbt se ejecuta, que es exactamente el sitio adecuado para detectar un join que se ha disparado o una clave primaria que ha dejado de ser única. Catalyst es monitorización continua que se ejecuta según una programación contra cualquier tabla de tu almacén, incluidas las fuentes en bruto y las tablas cargadas por proveedores externos que dbt nunca toca, con una interfaz e histórico de ejecuciones que puede usar alguien que no sea ingeniero. Si ya usas dbt, conserva tus tests de dbt; la pregunta es qué cubre todo lo que queda aguas arriba y aguas abajo de ellos.

Qué son en realidad los tests de dbt

Un test de dbt es una consulta SQL de la que se espera que devuelva cero filas. Ese es todo el modelo, y su simplicidad es la razón de que funcione tan bien.

dbt incluye de serie cuatro tests genéricos, declarados en un schema.yml junto al modelo:

version: 2

models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['pending', 'paid', 'shipped', 'refunded']
      - name: customer_id
        tests:
          - relationships:
              to: ref('customers')
              field: id

dbt test compila cada uno de ellos en un select que devuelve las filas infractoras, lo ejecuta contra el almacén y falla si vuelve algo. Los paquetes amplían considerablemente el vocabulario —dbt_utils añade tests de expresión y de combinación de columnas, y dbt-expectations traslada buena parte del catálogo de Great Expectations al YAML de dbt— y los tests singulares te permiten dejar un fichero .sql en tests/ para afirmar cualquier cosa que puedas expresar en una consulta.

Es un sistema genuinamente bueno. Los tests viven junto al modelo que describen, se revisan en la misma pull request que la transformación, se ejecutan en CI y no cuestan nada más allá del cómputo del almacén. Si tu problema de calidad de datos es «a veces se nos rompen las transformaciones», los tests de dbt lo resuelven.

Dónde se detienen los tests de dbt

Los límites no son defectos. Se derivan directamente de lo que dbt es: un framework de transformación, no un producto de monitorización.

Se ejecutan cuando se ejecuta dbt. Un test de dbt es un evento dentro de un build. Si tu build es nocturno, tu latencia de detección es de un día; y si una tabla la carga Fivetran a las 06:00 y dbt se ejecuta a las 02:00, la comprobación te habla de ayer. Peor aún: si el build falla pronto o el orquestador se lo salta, no se ejecuta ningún test, y el silencio es indistinguible del éxito.

Cubren los modelos que dbt gestiona. Las fuentes también se pueden testear, y dbt source freshness es una comprobación útil, pero la frontera de cobertura sigue siendo el proyecto dbt. La exportación del CRM que aterriza en un esquema de staging, la hoja de cálculo de finanzas que alguien sube cada mes, la base de datos de producción replicada que consultan directamente tres equipos: nada de eso son modelos de dbt, y muchos de ellos son justo donde empiezan los incidentes.

No hay histórico ni interfaz. Los resultados de los tests de dbt existen en los logs de la ejecución y en run_results.json. Responder a «¿lleva esta comprobación fallando de forma intermitente tres semanas?» implica parsear artefactos o montar Elementary o dbt Cloud. Responder a «¿cuáles de nuestros datasets críticos tienen cobertura de frescura?» implica hacer grep sobre YAML. Las filas que fallan pueden materializarse con store_failures, pero entonces alguien tiene que saber que esa tabla existe e ir a consultarla.

Las alertas son cosa de otro. dbt sale con código distinto de cero; Airflow, Dagster, GitHub Actions o dbt Cloud convierten eso en una notificación. Esa notificación suele decir «el job de dbt ha fallado», no «la columna status de orders ha ganado un valor que nadie esperaba». Enrutar un fallo concreto a la persona propietaria de ese dataset es trabajo que construyes tú.

Son para quien escribe YAML en un repositorio. Esta es la restricción que decide la mayoría de las conversaciones sobre herramientas. La persona que sabe que un reembolso nunca puede superar el importe del pedido original suele estar en finanzas, no en tu proyecto dbt. Sus opciones son abrir un ticket o no dejar la regla escrita en ninguna parte, y la mayoría de las veces ocurre lo segundo.

Qué añade Catalyst

Catalyst es una aplicación web que se conecta en modo solo lectura a tu almacén y monitoriza tablas según la programación que elijas. En concreto, frente a la lista anterior:

• Se ejecuta a su propia cadencia, con independencia de tu build. Justo después de la carga, cada hora, a diario: lo que se corresponda con cómo se mueven realmente los datos. Una comprobación de frescura que salta porque una carga no se ejecutó sin avisar es la regla de mayor valor que le falta a la mayoría de los equipos, y no puede detectarla un build que tampoco se ejecutó.
• Monitoriza cualquier tabla, la haya producido dbt o no: esquemas de aterrizaje en bruto, tablas replicadas por proveedores, bases de datos de reporting heredadas y ficheros CSV, JSON o Excel subidos a mano que nunca pasan por un pipeline. Los conectores cubren PostgreSQL, MySQL, SQL Server, BigQuery, Redshift y Microsoft Fabric, y las comprobaciones se ejecutan como SQL en tu almacén: Catalyst guarda resultados, recuentos de violaciones y hasta cinco filas de ejemplo que fallan por comprobación, nunca el dataset en sí.
• Conserva el histórico de ejecuciones. Se almacena cada ejecución de cada regla, así que una comprobación que falla una mañana de cada cuatro se ve como un patrón y no como cuatro avisos inconexos.
• Muestra filas de ejemplo que fallan en la propia interfaz. Haces clic en una regla fallida y ves hasta cinco filas de ejemplo que la incumplen, sin escribir ninguna consulta ni buscar ningún artefacto.
• Se puede usar sin repositorio. Importa el esquema de una tabla, revisa las reglas de base propuestas y ajusta las que no encajen. Los roles, el SSO y un registro de auditoría te permiten dejar que un propietario de datos en finanzas edite sus propios umbrales sin darle acceso de commit a nada.
• Las reglas son portables. Catalyst las guarda como contratos ODCS en YAML: el constructor visual y el YAML son el mismo documento, así que una regla añadida en la interfaz es un diff de una línea en un estándar abierto que puedes llevarte a otra parte.

Comparativa

Quédate solo con los tests de dbt cuando

Hay un conjunto real de equipos para los que añadir una segunda herramienta es puro sobrecoste sin retorno. Probablemente estés en él si se cumple casi todo esto:

• Todos los datasets con los que alguien toma decisiones son modelos de dbt. Sin extractos cargados por la puerta de atrás, sin consultas directas contra una base de datos de producción replicada, sin hoja de cálculo mensual.
• Tu build de dbt se ejecuta al menos con la misma frecuencia con la que cambian tus datos, de modo que la detección en tiempo de build no es apreciablemente más lenta que la monitorización continua.
• Quien conoce las reglas de negocio es quien escribe el código de dbt. En un equipo de datos de tres personas suele ser literalmente la misma persona, y una interfaz para perfiles no técnicos resuelve un problema que no tienes.
• Tu orquestador ya enruta los fallos de forma útil, al canal correcto y con contexto suficiente para actuar.
• Tienes Elementary o dbt Cloud en marcha para el histórico de resultados de tests y la visibilidad te satisface.

Si eso te describe, no compres nada. Añade dbt source freshness si aún no lo tienes, activa store_failures en los tests que importan y sigue con lo tuyo.

La lista deja de describir a la mayoría de los equipos más o menos en el punto en que un segundo equipo empieza a depender de tus datos, o en que el primer incidente se origina en una tabla de la que dbt nunca ha oído hablar.

Usar ambos: una división del trabajo sensata

Los equipos que usan ambos suelen acabar en el mismo reparto, y vale la pena decirlo con claridad porque evita duplicar reglas.

Los tests de dbt se ocupan de la corrección en tiempo de build. Todo aquello cuyo fallo debería impedir que un modelo se publique: unicidad de la granularidad, not-null en las claves, integridad referencial entre modelos, valores permitidos en los enums que tú controlas, cordura del recuento de filas tras un join. Mantenlos en el repositorio, revisados junto al SQL que protegen.

Catalyst se ocupa de la promesa. Todo lo que describe qué garantiza un dataset a quienes lo consumen, con independencia de qué pipeline lo escribió hoy: frescura, completitud en las columnas críticas para el negocio, rangos que codifican reglas de negocio, valores permitidos en campos que pertenecen a otro sistema. Son las afirmaciones duraderas, su sitio es un contrato versionado y hay que comprobarlas tanto si se ejecutó un build como si no.

Las fuentes se monitorizan, no se testean. Las tablas de aterrizaje en bruto son por donde entran la mayoría de los incidentes y, por definición, son las tablas sobre las que tu framework de transformación tiene menos que decir. Monitorizarlas a la cadencia de la propia carga es donde la comprobación continua se amortiza más rápido.

El punto de partida práctico no es «migra tus tests de dbt». Es: lista las cinco tablas de las que depende tu dashboard más usado, anota cuáles gobierna dbt de verdad y pon monitorización sobre las que no. Eso son un par de horas de trabajo, y suele encontrar algo durante la primera semana. Para el método completo, consulta la guía para validar tus datos.

Preguntas frecuentes

¿Catalyst sustituye a los tests de dbt?

No, ni está diseñado para ello. Los tests de dbt son aserciones en tiempo de build que deberían bloquear la publicación de un modelo roto, y son la herramienta adecuada para eso. Catalyst se ejecuta según una programación contra cualquier tabla, incluidas las fuentes y datasets que dbt no gestiona, y añade histórico de ejecuciones, filas de ejemplo que fallan y acceso para perfiles no técnicos. La mayoría de los equipos que adoptan Catalyst conservan todos los tests de dbt que ya tenían.

¿Pueden los tests de dbt monitorizar tablas que dbt no ha construido?

En parte. Puedes declarar una tabla externa como fuente y adjuntarle tests, y dbt source freshness comprueba cuándo se actualizó por última vez. La limitación es de momento más que de alcance: esas comprobaciones solo se ejecutan cuando se ejecuta dbt, así que una fuente que se rompe a las 06:00 no se reporta hasta el siguiente build. Para tablas completamente fuera del proyecto, o cargadas por herramientas con su propia programación, la monitorización programada detecta el problema cuando ocurre.

¿Cuál es la diferencia entre un test de dbt y un contrato de datos?

Un test de dbt es una aserción que ejecuta una herramienta concreta en un punto concreto de un pipeline. Un contrato de datos es una descripción versionada de lo que un dataset promete —esquema, propiedad, niveles de servicio y reglas de calidad— escrita en un formato independiente de lo que ejecute las comprobaciones. Catalyst usa el Open Data Contract Standard, así que las reglas siguen siendo portables y revisables como ficheros en lugar de vivir dentro del producto de un único proveedor.

¿Cómo recibo una alerta cuando falla un test de dbt?

dbt termina con un código de salida distinto de cero, y tu orquestador o dbt Cloud lo convierte en una notificación. El enrutado lo construyes tú, y el mensaje suele hablar del job y no de la comprobación concreta. Catalyst no envía notificaciones a día de hoy: ejecuta cada regla según su propia programación y registra el resultado, de modo que el dashboard muestra qué regla ha fallado, sobre qué dataset, cuántas ejecuciones lleva fallando y hasta cinco filas de ejemplo que la incumplen.

¿Tengo que reescribir mis tests de dbt para usar Catalyst?

No. Déjalos donde están. Catalyst importa el esquema de las tablas que conectes y propone un conjunto de reglas de base a partir de las columnas, claves y marcas de tiempo que encuentra, así que empiezas revisando sugerencias en lugar de portando nada. En la práctica, las reglas que acabas añadiendo son justo las que los tests de dbt nunca estuvieron en posición de cubrir.