Catalyst vs. dbt-Tests: Monitoring jenseits Ihrer Modelle

dbt-Tests sind Assertions zur Build-Zeit auf den Modellen, die dbt gehören. Catalyst überwacht jede Tabelle nach eigenem Zeitplan — auch die Quellen, die dbt nie anfasst.

2026-09-10 · 9 min read

dbt-Tests und Catalyst sind nicht wirklich Konkurrenten, und so zu tun, als wären sie es, würde nur Ihre Zeit kosten. dbt-Tests sind Assertions, die innerhalb eines Transformations-Builds laufen, gegen die Modelle, die dbt verwaltet, und zwar genau dann, wenn dbt läuft — das ist exakt der richtige Ort, um einen Join zu erwischen, der aufgefächert hat, oder einen Primärschlüssel, der nicht mehr eindeutig ist. Catalyst ist kontinuierliches Monitoring, das nach Zeitplan gegen jede beliebige Tabelle in Ihrem Data Warehouse läuft, einschließlich der Rohquellen und der von Dienstleistern geladenen Tabellen, die dbt nie anfasst — mit einer Oberfläche und einer Lauf-Historie, die auch Nicht-Engineers nutzen können. Wenn Sie bereits dbt einsetzen: Behalten Sie Ihre dbt-Tests. Die Frage ist, was alles davor und dahinter abdeckt.

Was dbt-Tests tatsächlich sind

Ein dbt-Test ist eine SQL-Abfrage, von der erwartet wird, dass sie null Zeilen zurückgibt. Das ist das ganze Modell, und seine Einfachheit ist der Grund, warum es so gut funktioniert.

Vier generische Tests bringt dbt selbst mit, deklariert in einer schema.yml neben dem Modell:

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 kompiliert jeden dieser Tests zu einem select, das die verletzenden Zeilen zurückgibt, führt ihn gegen das Data Warehouse aus und schlägt fehl, sobald etwas zurückkommt. Packages erweitern das Vokabular erheblich — dbt_utils ergänzt Tests auf Ausdrücke und Spaltenkombinationen, dbt-expectations portiert große Teile des Great-Expectations-Katalogs in dbts YAML —, und Singular Tests erlauben es, eine reine .sql-Datei in tests/ zu legen und damit alles zu prüfen, was sich als Abfrage formulieren lässt.

Das ist ein wirklich gutes System. Die Tests liegen neben dem Modell, das sie beschreiben, sie werden im selben Pull Request geprüft wie die Transformation, sie laufen in der CI, und sie kosten nichts außer Warehouse-Compute. Wenn Ihr Datenqualitätsproblem lautet „unsere Transformationen gehen manchmal kaputt", lösen dbt-Tests es.

Wo dbt-Tests aufhören

Die Grenzen sind keine Mängel. Sie folgen unmittelbar daraus, was dbt ist: ein Transformations-Framework, kein Monitoring-Produkt.

Sie laufen, wenn dbt läuft. Ein dbt-Test ist ein Ereignis innerhalb eines Builds. Läuft Ihr Build nachts, beträgt Ihre Erkennungslatenz einen Tag — und wenn eine Tabelle um 06:00 Uhr von Fivetran geladen wird, dbt aber um 02:00 Uhr läuft, erzählt Ihnen die Prüfung etwas über gestern. Schlimmer noch: Wenn der Build früh abbricht oder der Orchestrator ihn überspringt, laufen überhaupt keine Tests — und Schweigen sieht genauso aus wie Erfolg.

Sie decken die Modelle ab, die dbt verwaltet. Auch Sources lassen sich testen, und dbt source freshness ist eine nützliche Prüfung, aber die Grenze der Abdeckung bleibt das dbt-Projekt. Der CRM-Export, der in einem Staging-Schema landet, die Finanz-Tabelle, die jemand monatlich hochlädt, die replizierte Produktionsdatenbank, die drei Teams direkt abfragen — nichts davon ist ein dbt-Modell, und genau dort beginnen viele Vorfälle.

Es gibt keine Historie und keine Oberfläche. dbt-Testergebnisse existieren in den Logs des Laufs und in run_results.json. Die Frage „Schlägt diese Prüfung seit drei Wochen sporadisch fehl?" zu beantworten, bedeutet, Artefakte zu parsen oder Elementary bzw. dbt Cloud aufzusetzen. Die Frage „Welche unserer kritischen Datasets sind auf Aktualität geprüft?" zu beantworten, bedeutet, YAML zu durchsuchen. Fehlerhafte Zeilen lassen sich mit store_failures materialisieren, aber dann muss jemand wissen, dass diese Tabelle existiert, und sie abfragen.

Alerting ist Aufgabe von jemand anderem. dbt beendet sich mit einem Exit-Code ungleich null; Airflow, Dagster, GitHub Actions oder dbt Cloud machen daraus eine Benachrichtigung. Diese Benachrichtigung sagt üblicherweise „der dbt-Job ist fehlgeschlagen", nicht „die Spalte status in orders hat einen Wert bekommen, den niemand erwartet hat". Einen konkreten Fehlschlag an die Person zu routen, der dieses Dataset gehört, ist Arbeit, die Sie selbst bauen.

Sie sind für Menschen, die YAML in einem Repository schreiben. Das ist die Einschränkung, die die meisten Tooling-Diskussionen entscheidet. Wer weiß, dass eine Rückerstattung nie den ursprünglichen Bestellwert übersteigen darf, sitzt meist im Finanzbereich und nicht in Ihrem dbt-Projekt. Diese Person kann ein Ticket aufmachen oder die Regel gar nicht erst aufschreiben — und meistens wird es Letzteres.

Was Catalyst ergänzt

Catalyst ist eine Webanwendung, die sich read-only mit Ihrem Data Warehouse verbindet und Tabellen nach einem Zeitplan überwacht, den Sie festlegen. Konkret, gemessen an der Liste oben:

• Es läuft im eigenen Takt, unabhängig von Ihrem Build. Direkt nach dem Laden, stündlich, täglich — passend dazu, wie sich die Daten tatsächlich bewegen. Eine Aktualitätsprüfung, die anschlägt, weil ein Ladelauf still nicht stattgefunden hat, ist die wertvollste einzelne Regel, die den meisten Teams fehlt — und ein Build, der ebenfalls nicht lief, kann sie unmöglich erkennen.
• Es überwacht jede Tabelle, egal ob dbt sie erzeugt hat oder nicht: Rohe Landing-Schemas, von Dienstleistern replizierte Tabellen, alte Reporting-Datenbanken und CSV-, JSON- oder Excel-Uploads, die nie eine Pipeline berühren. Konnektoren gibt es für PostgreSQL, MySQL, SQL Server, BigQuery, Redshift und Microsoft Fabric, und die Prüfungen laufen als SQL in Ihrem Data Warehouse — Catalyst speichert Ergebnisse, Verstoßzahlen und bis zu fünf Beispielzeilen pro Prüfung, niemals das Dataset selbst.
• Es hält die Lauf-Historie fest. Jede Ausführung jeder Regel wird gespeichert, sodass eine Prüfung, die an einem von vier Morgen fehlschlägt, als Muster sichtbar wird statt als vier zusammenhanglose Alarme.
• Es zeigt Beispielzeilen in der Oberfläche. Klicken Sie auf eine fehlgeschlagene Regel und sehen Sie bis zu fünf Beispielzeilen, die sie verletzt haben — ohne eine Abfrage zu schreiben und ohne ein Artefakt zu suchen.
• Es ist ohne Repository nutzbar. Schema einer Tabelle importieren, die vorgeschlagenen Basisregeln durchsehen, die falschen korrigieren. Rollen, SSO und ein Audit-Log bedeuten, dass ein Data Owner im Finanzbereich seine eigenen Schwellenwerte bearbeiten kann, ohne irgendwo Commit-Rechte zu bekommen.
• Die Regeln sind portabel. Catalyst speichert sie als ODCS-YAML-Contracts — der visuelle Builder und das YAML sind dasselbe Dokument. Eine in der Oberfläche hinzugefügte Regel ist damit ein einzeiliges Diff in einem offenen Standard, den Sie jederzeit mitnehmen können.

Im direkten Vergleich

Bleiben Sie allein bei dbt-Tests, wenn

Es gibt tatsächlich Teams, für die ein zweites Tool nur Aufwand ohne Gegenwert bedeutet. Sie gehören vermutlich dazu, wenn das meiste hiervon zutrifft:

• Jedes Dataset, auf dessen Basis irgendjemand entscheidet, ist ein dbt-Modell. Keine nebenher eingespielten Extrakte, keine direkten Abfragen gegen eine replizierte Produktionsdatenbank, keine monatliche Tabellenkalkulation.
• Ihr dbt-Build läuft mindestens so oft, wie sich Ihre Daten ändern, sodass Erkennung zur Build-Zeit nicht spürbar langsamer ist als kontinuierliches Monitoring.
• Die Menschen, die die Geschäftsregeln kennen, sind dieselben, die den dbt-Code schreiben. In einem Drei-Personen-Datenteam ist das oft buchstäblich dieselbe Person, und eine Oberfläche für Nicht-Engineers löst ein Problem, das Sie nicht haben.
• Ihr Orchestrator routet Fehlschläge bereits sinnvoll — in den richtigen Kanal, mit genug Kontext, um zu handeln.
• Sie haben Elementary oder dbt Cloud im Einsatz, um Testergebnisse historisch zu erfassen, und sind mit der Sichtbarkeit zufrieden.

Wenn das auf Sie passt, kaufen Sie nichts. Ergänzen Sie dbt source freshness, falls noch nicht geschehen, setzen Sie store_failures auf die Tests, die zählen, und machen Sie weiter.

Die Liste hört ungefähr an dem Punkt auf, die meisten Teams zu beschreiben, an dem ein zweites Team von Ihren Daten abhängig wird — oder an dem der erste Vorfall in einer Tabelle entsteht, von der dbt nie gehört hat.

Beides betreiben: eine sinnvolle Arbeitsteilung

Teams, die beides nutzen, landen meist bei derselben Aufteilung, und es lohnt sich, sie klar auszusprechen, weil sie doppelte Regeln erspart.

dbt-Tests verantworten die Korrektheit zur Build-Zeit. Alles, dessen Fehlschlag verhindern soll, dass ein Modell veröffentlicht wird: Eindeutigkeit der Granularität, Not-Null auf Schlüsseln, referenzielle Integrität zwischen Modellen, erlaubte Werte auf Enums, die Sie kontrollieren, Plausibilität der Zeilenzahl nach einem Join. Halten Sie diese Tests im Repository, geprüft gemeinsam mit dem SQL, das sie absichern.

Catalyst verantwortet das Versprechen. Alles, was beschreibt, was ein Dataset seinen Konsumenten garantiert — unabhängig davon, welche Pipeline es heute geschrieben hat: Aktualität, Vollständigkeit auf geschäftskritischen Spalten, Wertebereiche, die Geschäftsregeln kodieren, erlaubte Werte auf Feldern, die einem anderen System gehören. Das sind die dauerhaften Aussagen, sie gehören in einen versionierten Contract, und sie müssen geprüft werden, ob ein Build lief oder nicht.

Quellen werden überwacht, nicht getestet. Rohe Landing-Tabellen sind die Stelle, an der die meisten Vorfälle eintreten, und per Definition die Tabellen, über die Ihr Transformations-Framework am wenigsten zu sagen hat. Sie im Takt des jeweiligen Ladelaufs zu überwachen, ist der Punkt, an dem kontinuierliches Prüfen sich am schnellsten bezahlt macht.

Der praktische Einstieg lautet nicht „migrieren Sie Ihre dbt-Tests". Er lautet: Listen Sie die fünf Tabellen auf, von denen Ihr meistgenutztes Dashboard abhängt, halten Sie fest, welche davon dbt tatsächlich gehören, und legen Sie Monitoring auf die übrigen. Das sind ein paar Stunden Arbeit, und in der ersten Woche findet sich meist etwas. Zur breiteren Methode siehe den Leitfaden zur Datenvalidierung.

Häufige Fragen

Ersetzt Catalyst dbt-Tests?

Nein, und es ist auch nicht dafür gedacht. dbt-Tests sind Assertions zur Build-Zeit, die verhindern sollen, dass ein kaputtes Modell veröffentlicht wird, und dafür sind sie das richtige Werkzeug. Catalyst läuft nach Zeitplan gegen jede Tabelle, auch gegen Quellen und Datasets, die dbt nicht verwaltet, und ergänzt Lauf-Historie, Beispiele fehlerhafter Zeilen und Zugang für Nicht-Engineers. Die meisten Teams, die Catalyst einführen, behalten jeden dbt-Test, den sie schon hatten.

Können dbt-Tests Tabellen überwachen, die dbt nicht gebaut hat?

Teilweise. Sie können eine externe Tabelle als Source deklarieren und Tests daran hängen, und dbt source freshness prüft, wie aktuell sie zuletzt war. Die Einschränkung liegt eher im Timing als im Umfang: Auch diese Prüfungen laufen nur, wenn dbt läuft. Eine Quelle, die um 06:00 Uhr bricht, bleibt also bis zum nächsten Build unbemerkt. Für Tabellen, die vollständig außerhalb des Projekts liegen oder von Tools nach eigenem Zeitplan geladen werden, erkennt Monitoring nach Zeitplan das Problem, wenn es passiert.

Was ist der Unterschied zwischen einem dbt-Test und einem Data Contract?

Ein dbt-Test ist eine Assertion, die ein bestimmtes Tool an einer bestimmten Stelle einer Pipeline ausführt. Ein Data Contract ist eine versionierte Beschreibung dessen, was ein Dataset zusagt — Schema, Verantwortlichkeit, Service Levels und Qualitätsregeln —, geschrieben in einem Format, das unabhängig davon ist, was die Prüfungen ausführt. Catalyst nutzt den Open Data Contract Standard, sodass die Regeln portabel und als Dateien prüfbar bleiben, statt im Produkt eines einzelnen Anbieters zu stecken.

Wie werde ich benachrichtigt, wenn ein dbt-Test fehlschlägt?

dbt beendet sich mit einem Exit-Code ungleich null, und Ihr Orchestrator oder dbt Cloud macht daraus eine Benachrichtigung. Das Routing bauen Sie selbst, und die Meldung handelt meist vom Job und nicht von der konkreten Prüfung. Catalyst versendet zum jetzigen Zeitpunkt keine Benachrichtigungen: Es führt jede Regel nach ihrem eigenen Zeitplan aus und hält das Ergebnis fest, sodass das Dashboard zeigt, welche Regel auf welchem Dataset fehlgeschlagen ist, seit wie vielen Läufen sie fehlschlägt und bis zu fünf Beispielzeilen, die sie verletzt haben.

Muss ich meine dbt-Tests umschreiben, um Catalyst zu nutzen?

Nein. Lassen Sie sie, wo sie sind. Catalyst importiert das Schema der Tabellen, die Sie verbinden, und schlägt aus den gefundenen Spalten, Schlüsseln und Zeitstempeln einen Satz Basisregeln vor — Sie starten also damit, Vorschläge durchzusehen, nicht damit, etwas zu portieren. In der Praxis sind die Regeln, die Sie ergänzen, genau die, die dbt-Tests nie abdecken konnten.