Catalyst vs. Great Expectations: Was sollten Sie einsetzen?

Ein gehosteter, contract-basierter Monitor gegen ein Open-Source-Framework in Python — was jedes gut kann, wo jedes die falsche Wahl ist und wie Teams beides parallel betreiben.

2026-09-10 · 10 min read

Nehmen Sie Great Expectations, wenn Ihr Team Python schreibt, wenn Ihre Prüfungen in Pipelines gehören, die Sie ohnehin orchestrieren, und wenn Sie das Framework um Logik erweitern müssen, die keine Regelsprache ausdrücken kann. Nehmen Sie Catalyst, wenn die Menschen, die wissen, was „gute Daten" bedeutet, kein Python schreiben, wenn Sie Warehouse-Tabellen nach Zeitplan überwachen wollen, ohne einen Runner zu betreiben, und wenn die Regeln als portable ODCS-Contracts gespeichert sein sollen statt als Code in einem einzelnen Repository. Great Expectations ist ein Framework, das Sie zusammensetzen; Catalyst ist ein Produkt, das Sie anschließen. Die Entscheidung dreht sich vor allem darum, wer die Regeln schreibt und verantwortet — nicht darum, welches Tool eine Null-Prüfung ausdrücken kann.

Was Great Expectations ist

Great Expectations (meist kurz „GX") ist ein Open-Source-Framework in Python zur Datenvalidierung. Sie installieren es mit pip, richten es auf eine Datenquelle und schreiben Expectations — deklarative Assertions wie expect_column_values_to_not_be_null oder expect_column_values_to_be_between —, die zu Expectation Suites gruppiert werden. Ein Checkpoint führt eine Suite gegen einen Batch von Daten aus und löst Aktionen anhand des Ergebnisses aus. Die Ergebnisse werden in Data Docs gerendert, einer generierten statischen HTML-Site, die beschreibt, was lief und was fehlschlug.

Es steht unter der Apache-Lizenz, ist ausgereift und hat mit deutlichem Abstand den größten Katalog eingebauter Prüfungen in dieser Kategorie, dazu einen erstklassigen Weg, eigene Prüfungen in Python zu schreiben. Das Unternehmen dahinter verkauft außerdem GX Cloud, ein gehostetes Angebot, das eine Managed-Oberfläche, geplante Läufe und Alerting über die Open-Source-Engine legt. Zum jetzigen Zeitpunkt hat die Python-API über die Hauptversionen hinweg mehr als einmal ihre Form verändert — die 1.x-API ist nicht die 0.x-API —, und diese Migrationen waren in der Vergangenheit echte Arbeit und nicht nur ein Versionssprung.

Was Catalyst ist

Catalyst ist ein gehostetes Produkt für Datenqualität. Sie verbinden einen Datenbanknutzer mit Lesezugriff, Catalyst importiert das Schema, und Sie bauen die Regeln im Browser — Not-Null, Eindeutigkeit, Wertebereiche, Muster, erlaubte Wertemengen, Aktualität, referenzielle Integrität und eigenes SQL für alles Maßgeschneiderte. Jede Regel wird als Contract nach dem Open Data Contract Standard gespeichert: Der visuelle Builder und das YAML sind zwei Sichten auf dasselbe Dokument, und das YAML ist die maßgebliche Quelle — eine in der Oberfläche hinzugefügte Regel erzeugt also ein einzeiliges Diff, das Sie prüfen können.

Die Prüfungen laufen nach Zeitplan als SQL gegen Ihr Data Warehouse. Das Dataset verlässt es nie — Catalyst speichert Ergebnisse, Verstoßzahlen und bis zu fünf Beispielzeilen pro Prüfung, erfasst während des Laufs, niemals das Dataset selbst. Konnektoren zum jetzigen Zeitpunkt: PostgreSQL, MySQL, SQL Server, BigQuery, Redshift, Microsoft Fabric, dazu Upload von CSV, JSON und Excel.

Direkt gegenübergestellt

Einrichtung: Wie die erste Stunde aussieht

Bei Great Expectations ist die erste Stunde Engineering. Die Bibliothek in eine Umgebung installieren, einen Data Context anlegen, eine Datenquelle und ein Data Asset definieren, eine Suite bauen, einen Checkpoint definieren, festlegen, wo Validierungsergebnisse und Data Docs gespeichert werden — und dann entscheiden, was das Ganze ausführt. Keiner dieser Schritte ist schwer; es sind sechs davon, sie leben alle in Code, und sie müssen alle gepflegt werden. Wenn Sie bereits ein Python-Repository mit einem Orchestrator darin haben, existiert das meiste Gerüst schon und die Zusatzkosten sind klein. Wenn nicht, stellen Sie einen kleinen Service auf die Beine, bevor Sie eine einzige Zeile validiert haben.

Bei Catalyst ist die erste Stunde Konfiguration. Eine Rolle mit Lesezugriff anlegen, die Verbindungsdaten einfügen, eine Tabelle auswählen. Der Schema-Import liest information_schema und schlägt aus dem Gefundenen einen Basis-Contract vor — Pflichtspalten werden zu Not-Null-Regeln, Primärschlüssel zu Eindeutigkeitsregeln, Zeitstempel zu Kandidaten für Aktualitätsprüfungen — und von dort aus bearbeiten Sie. Der PostgreSQL-Leitfaden enthält die genauen GRANT-Anweisungen, einschließlich der ALTER DEFAULT PRIVILEGES-Zeile, die alle vergessen.

Ehrlich eingeordnet: Der Einrichtungsaufwand von GX erkauft Ihnen ein Allzweck-Framework, das alles validieren kann, was ein Python-Prozess lesen kann. Der Einrichtungsaufwand von Catalyst ist geringer, weil sein Geltungsbereich enger ist — Tabellen in einem Data Warehouse, an Ort und Stelle geprüft.

Regeln schreiben

So sieht eine Suite in der aktuellen Python-API von GX ungefähr aus:

import great_expectations as gx

context = gx.get_context()
suite = context.suites.add(gx.ExpectationSuite(name="orders"))

suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeInSet(
        column="status",
        value_set=["pending", "paid", "shipped", "refunded"],
    )
)

Und dieselben Expectations als ODCS-Contract:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: data-platform
schema:
  - name: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"

Als Text ist keines von beidem offensichtlich besser. Der Unterschied liegt darin, wer es schreiben kann und was passiert, wenn die Regel falsch ist. Die Python-Variante kann Dinge, die das YAML nicht kann — ein Modell aufrufen, gegen ein zweites System abgleichen, eine Statistik über ein gleitendes Fenster berechnen —, weil sie ein Programm ist. Die YAML-Variante können Analystinnen, Data Stewards oder Fachverantwortliche lesen und bearbeiten, die nie ein Terminal öffnen werden, und sie trägt eine dimension, sodass sich hundert Regeln zu einer Abdeckungsübersicht verdichten statt zu einer Liste.

Die Expectation-Bibliothek von GX ist wirklich groß, und wenn Sie expect_column_kl_divergence_to_be_less_than brauchen, sollten Sie GX nehmen, denn Catalyst hat das nicht und wird auch nicht so tun. Catalyst deckt die Prüfungen ab, die die überwältigende Mehrheit echter Vorfälle erwischen, und weicht für den Rest auf eigenes SQL aus.

Wo die Regeln leben

Das ist der Teil, der die Toolentscheidung überdauert. Expectation Suites sind GX-Format: lesbar, aber für einen bestimmten Runner geschrieben und in dem Python-Repository beheimatet, dem die Pipeline gehört. Das ist in Ordnung, solange GX die Antwort ist — und es ist eine Neuschreibung, sobald es aufhört, die Antwort zu sein.

Catalyst speichert Contracts in ODCS, einer offenen Spezifikation, die im Bitol-Projekt der Linux Foundation entwickelt wird. Der Contract beschreibt das Versprechen eines Datasets unabhängig davon, wer es durchsetzt, lässt sich als Datei exportieren und in alles importieren, was den Standard spricht. Wenn Sie Catalyst verlassen, kommen die Regeln mit — eine merkwürdige Sache für einen Anbieter zu bewerben, und der Hauptgrund, dem Format zu vertrauen.

Nehmen Sie Great Expectations, wenn …

• Ihr Team Python schreibt und bereits einen Orchestrator betreibt. GX fügt sich als Task in Airflow, Dagster oder Prefect ein. Das ist sein natürliches Zuhause, und dort ist es sehr gut.
• Sie eigene Logik brauchen, die keine deklarative Regelsprache ausdrückt — Verteilungs-Drift, statistische Tests, systemübergreifende Abstimmung, Prüfungen, die ein Modell aufrufen. Eigene Expectations in Python haben keine Obergrenze.
• Sie DataFrames validieren, nicht nur Tabellen. GX prüft Daten mitten in der Pipeline, in pandas oder Spark, bevor irgendetwas landet. Catalyst validiert, was bereits im Data Warehouse liegt, und kann einen DataFrame nicht sehen.
• Validierung einen Build zum Fehlschlagen bringen muss. Ein Checkpoint, der mit einem Exit-Code ungleich null endet, blockiert einen DAG oder einen CI-Job. Das ist eine andere Aufgabe als Monitoring, und GX erledigt sie nativ.
• Ihr Budget null ist und Ihre Engineering-Zeit nicht. Apache 2.0, keine Lizenzplätze, kein Anbieter.
• Sie ein Data Warehouse nutzen, das Catalyst noch nicht unterstützt. Snowflake und Databricks sind die naheliegenden Beispiele; über SQLAlchemy kommt GX heute damit zurecht.
• Richtlinien es verbieten, dass ein externer Dienst Warehouse-Metadaten hält. Catalyst wird in der EU gehostet und speichert nur Ergebnisse, Verstoßzahlen und bis zu fünf Beispielzeilen pro Prüfung — aber selbst gehostet bleibt selbst gehostet.

Nehmen Sie Catalyst, wenn …

• Die Menschen, die die Geschäftsregeln kennen, kein Python schreiben. Das ist der mit Abstand häufigste Grund, warum Teams hier landen. Regeln, geschrieben von der Person, die die Daten versteht, schlagen Regeln, geschrieben von der Person, die das Framework versteht.
• Sie Monitoring wollen, nicht nur Assertions. Geplante Läufe, pass/warn/fail-Historie und Trendlinien kommen fertig konfiguriert statt selbst zusammengesetzt.
• Sie ein offenes Regelformat wollen. ODCS-Contracts lassen sich in Pull Requests prüfen und zwischen Tools mitnehmen.
• Niemand einen Validierungsdienst betreiben will. Keine Umgebung zu patchen, kein Data-Docs-Bucket, keine Dependency-Upgrades, keine Migration, wenn die API ihre Form ändert.
• Sie Rollen, SSO und eine Audit-Spur brauchen. RBAC und ein Audit-Log stecken im Produkt, nicht in einem Projekt.
• Ihre Daten an gemischten Orten liegen — darunter BigQuery, eine Postgres-Primärdatenbank und die gelegentliche Tabellenkalkulation — und Sie eine Sicht über alles davon wollen.

Beides nutzen

Die beiden schließen einander nicht aus, und eine ganze Reihe von Teams betreibt bewusst beides. Die Aufteilung, die funktioniert: GX innerhalb der Pipeline, als Gate — Prüfungen, die einen Build blockieren müssen, bevor schlechte Daten landen, plus die exotischen statistischen Expectations. Catalyst oberhalb der Pipeline, als Monitor — die dauerhaften, nachvollziehbaren Versprechen über die Tabellen, von denen Konsumenten abhängen, laufend nach Zeitplan und unabhängig davon, welcher Job sie heute geschrieben hat, mit der Historie, die ein CI-Fehlerlog Ihnen nicht gibt.

Wenn Sie bereits GX-Suites haben, läuft die Migration nicht automatisch — zum jetzigen Zeitpunkt gibt es keinen Importer —, aber für die gängigen Expectations ist die Übersetzung mechanisch, und wenn Sie zuerst das Schema importieren, wird der Großteil des Contracts ohnehin für Sie generiert. Für das größere Bild, was zu prüfen ist und warum, starten Sie mit dem Leitfaden zur Datenvalidierung.

Häufige Fragen

Ist Great Expectations kostenlos?

Die Python-Bibliothek Great Expectations ist Open Source unter der Apache-2.0-Lizenz und kostenlos nutzbar, auch kommerziell. GX Cloud, das gehostete Produkt desselben Unternehmens, ist ein kommerzielles Angebot mit eigener Preisgestaltung — die aktuellen Konditionen finden Sie auf deren Website. „Kostenlos" im Open-Source-Sinn bedeutet weiterhin, dass Sie die Compute-Leistung bezahlen, auf der es läuft, und die Engineering-Zeit für den Betrieb.

Braucht Catalyst Python?

Nein. Catalyst verbindet sich über einen Nutzer mit Lesezugriff zu Ihrer Datenbank, und die Regeln werden im Browser gebaut oder als ODCS-YAML geschrieben. Es gibt nichts zu installieren und keinen Code auszuführen. SQL ist optional und nur für eigene Regeln nötig, die die eingebauten Typen nicht abdecken.

Kann ich Great Expectations und Catalyst zusammen nutzen?

Ja, und das ist eine vernünftige Architektur. Nutzen Sie Great Expectations als Gate in der Pipeline — Assertions, die einen Build scheitern lassen, bevor schlechte Daten landen — und Catalyst als Monitoring- und Contract-Schicht über den Tabellen, die bereits gelandet sind, mit geplanten Läufen und pass/warn/fail-Historie. Sie lesen dieselben Daten und beantworten unterschiedliche Fragen.

Kann Catalyst pandas- oder Spark-DataFrames validieren?

Nein. Catalyst validiert ruhende Daten — Tabellen und Views in einem verbundenen Data Warehouse, dazu hochgeladene CSV-, JSON- und Excel-Dateien. In-Memory-DataFrames innerhalb eines laufenden Python-Jobs sind genau der Fall, für den es Great Expectations gibt.

Was ist besser für ein kleines Datenteam?

Besteht das Team aus ein bis zwei Engineers, die in Python zu Hause sind und ohnehin einen Orchestrator betreiben, kostet Great Expectations nichts und passt in den bestehenden Workflow. Gehören zum Team Analystinnen oder Fachverantwortliche, die die Regeln schreiben sollten, oder will niemand einen weiteren Dienst pflegen, gewinnt ein gehostetes Tool bei der insgesamt aufgewendeten Zeit. Der Starter-Tarif von Catalyst ist kostenlos für eine Verbindung und ein Dataset (PostgreSQL und MySQL) — genug, um die Grundannahme zu testen, bevor Sie sich festlegen.