Catalyst vs. Soda: Tools für Datenqualität im Vergleich

SodaCL und Soda Core gegen Contracts im Open Data Contract Standard — Einrichtung, Konnektoren, Anomalieerkennung und wann welches die falsche Wahl ist.

2026-09-10 · 10 min read

Nehmen Sie Soda, wenn Sie eine Open-Source-CLI wollen, die Prüfungen aus einer Datei in Ihrer eigenen Infrastruktur ausführt, wenn Sie Konnektoren brauchen, die Catalyst noch nicht hat, oder wenn Sie ML-gestützte Anomalieerkennung auf Metriken wollen. Nehmen Sie Catalyst, wenn Sie ein gehostetes Produkt ohne Installation wollen, wenn die Regeln im Browser von Menschen geschrieben werden, die kein Terminal benutzen, und wenn die Contracts in ODCS gespeichert sein sollen — in einem offenen Standard statt in der hauseigenen Prüfsprache eines Anbieters. Beide sind deklarativ, beide reichen die Prüfungen nach SQL herunter, und beide lesen sich angenehm. Der eigentliche Unterschied: Soda ist ein Runner, den Sie betreiben, und Catalyst ist ein Dienst, den Sie anschließen.

Was Soda ist

Soda besteht aus zwei Hälften. Soda Core ist eine Open-Source-CLI in Python: Sie installieren sie mit pip, beschreiben Ihre Datenquelle in einer Konfigurationsdatei, schreiben Checks in SodaCL — der Soda Checks Language, einem YAML-Dialekt — und führen soda scan aus. Der Befehl endet mit einem Exit-Code ungleich null, wenn ein Check fehlschlägt, was ihn in CI, Airflow oder einem dbt-Job natürlich wirken lässt.

Soda Cloud ist das kommerzielle SaaS darüber: Dashboards, Check-Historie, Incident-Workflow, Alerting nach Slack und in Ticketsysteme, dazu Anomalieerkennung, die die normale Gestalt einer Metrik lernt, statt sie gegen einen Schwellenwert zu halten, den Sie raten mussten. Für Organisationen, die kein SaaS direkt an das Data Warehouse lassen dürfen, bietet Soda einen selbst gehosteten Agenten, der im eigenen Netz läuft und nach außen mit Soda Cloud spricht, sodass sich Scans trotzdem zentral konfigurieren lassen.

Sodas Konnektorliste ist breit — die gängigen Data Warehouses plus Snowflake, Databricks, Athena, Trino, Oracle und weitere zum jetzigen Zeitpunkt —, und SodaCL ist eine der lesbareren Prüfsprachen dieser Kategorie. Ehre, wem Ehre gebührt: Es kommt dem Schreiberlebnis eines Contracts am nächsten, ohne selbst ein Contract-Format zu sein.

Was Catalyst ist

Catalyst ist ein gehostetes Produkt für Datenqualität ohne CLI und ohne Bibliothek. 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 den Rest. Regeln werden als Contracts nach dem Open Data Contract Standard gespeichert — der visuelle Builder und das YAML sind zwei Sichten auf ein Dokument, und das YAML ist die maßgebliche Quelle, sodass eine Änderung in der Oberfläche ein einzeiliges Diff ergibt.

Die Prüfungen laufen nach Zeitplan als SQL innerhalb Ihres Data Warehouse. Das Dataset bleibt dort; 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

Die erste Stunde mit Soda Core ist eine kleine Engineering-Aufgabe: eine Python-Umgebung anlegen, das Package für Ihr Data Warehouse installieren, eine configuration.yml mit Zugangsdaten schreiben, eine checks.yml schreiben, den Scan ausführen — und dann entscheiden, was ihn nach Zeitplan ausführt und wohin die Ergebnisse gehen. Nichts davon ist schwierig, und die Dokumentation ist gut. Es ist dennoch eine Komponente, die Ihnen ab jetzt gehört: eine Python-Umgebung zum Patchen, Zugangsdaten, die sicher liegen müssen, und ein Scheduler, der verdrahtet werden will.

Soda Cloud nimmt Ihnen einiges davon ab, aber wenn Ihre Sicherheitsvorgaben den selbst gehosteten Agenten verlangen, haben Sie ein pip install gegen ein Kubernetes-Deployment getauscht. Für eine große Organisation mit Plattform-Team ist das ein sinnvoller Tausch, für ein Fünf-Personen-Datenteam ein schlechter.

Die erste Stunde mit Catalyst ist Konfiguration: eine Rolle mit Lesezugriff anlegen, Verbindungsdaten einfügen, eine Tabelle auswählen. Der Schema-Import liest den Katalog und schlägt aus den gefundenen Typen und Nullable-Angaben einen Basis-Contract vor — Sie starten also damit, dreißig generierte Regeln zu bearbeiten, statt sie zu tippen. Der PostgreSQL-Leitfaden enthält die genauen Grants; Redshift hat eigene Eigenheiten, die man vorher lesen sollte.

Regeln schreiben

SodaCL liest sich wirklich angenehm:

checks for orders:
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0
  - invalid_count(status) = 0:
      valid values: [pending, paid, shipped, refunded]
  - freshness(created_at) < 24h
  - row_count > 0

Der entsprechende ODCS-Contract ist ausführlicher, und diese Ausführlichkeit erkauft etwas:

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
        required: true
        primaryKey: true
        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']"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"

Drei Unterschiede zählen. Der Contract trägt das Schema mit, nicht nur die Prüfungen — er beschreibt also das Dataset, statt nur Aussagen darüber zu treffen. Jede Regel trägt eine dimension, sodass sich hundert Regeln zu einer Abdeckungsmatrix verdichten — Sind wir bei der Aktualität abgedeckt oder nur bei der Vollständigkeit? — statt zu einer flachen Liste. Und das Format ist ein offener Standard im Bitol-Projekt der Linux Foundation, nicht die Sprache eines einzelnen Anbieters, sodass sich die Regeln zu jedem Runner mitnehmen lassen, der sie spricht.

Dem steht entgegen: SodaCL ist kompakter, und für jemanden, der Checks in einem Texteditor schreibt, ist Kompaktheit ein echtes Feature. Wenn Ihre Regeln ohnehin nur von Menschen geschrieben werden, die sich in einem Repository wohlfühlen, ist die zusätzliche Struktur in ODCS Aufwand, den Sie vielleicht nicht wollen.

Anomalieerkennung — und eine Lücke, ehrlich benannt

Die Anomalieerkennung von Soda Cloud beobachtet eine Metrik über die Zeit und markiert Abweichungen von ihrem gelernten Muster. Catalyst hat das nicht. Catalyst-Prüfungen sind deterministische Regeln mit Schwellenwerten, die Sie setzen: eine Zeilenzahl, die über null liegen muss, ein Aktualitätsfenster von 24 Stunden, ein Bereich plausibler Werte.

Was Sie wollen, hängt davon ab, welchen Fehler Sie erwischen möchten. Deterministische Regeln fangen Verstöße gegen ein ausgesprochenes Versprechen ab, und sie schlagen nie an, nur weil der Dienstag ruhig war. Anomalieerkennung fängt die Fehler, für die niemand auf die Idee kam, eine Regel zu schreiben — ein Rückgang der Zeilenzahl um 40 %, der technisch gesehen über Ihrer Schwelle > 0 liegt —, und sie kostet Sie eine Tuning-Phase und einige Fehlalarme, während sie lernt. Wenn unbekannte Unbekannte bei Volumen und Verteilung Ihre Hauptsorge sind, ist das ein echter Grund, Soda zu wählen.

Nehmen Sie Soda, wenn …

• Sie einen Open-Source-Runner wollen, den Sie kontrollieren. Soda Core steht unter der Apache-Lizenz und ist kostenlos; die Prüfungen laufen vollständig in Ihrer Infrastruktur, ohne Anbieter im Pfad.
• Sie ein Data Warehouse brauchen, das Catalyst noch nicht unterstützt — Snowflake, Databricks, Athena, Trino und Oracle sind die naheliegenden Fälle.
• Validierung eine Pipeline zum Fehlschlagen bringen muss. soda scan liefert einen Exit-Code ungleich null zurück, genau das, was ein CI-Job oder ein Airflow-Task will. Catalyst überwacht nach eigenem Zeitplan; es blockiert Ihren Build nicht.
• Sie Anomalieerkennung wollen, nicht nur Schwellenwertregeln.
• Richtlinien es verbieten, dass ein SaaS Ihr Data Warehouse erreicht. Der selbst gehostete Agent hält die Verbindung im eigenen Netz. Catalyst wird in der EU gehostet und speichert nur Ergebnisse, Verstoßzahlen und bis zu fünf Beispielzeilen pro Prüfung — aber die Verbindung kommt weiterhin von außen durch einen Dienst.
• Ihre Checks neben Ihrem dbt-Projekt leben und Sie sie versioniert, geprüft und im selben Job ausgeführt haben wollen wie die Modelle, die sie abdecken.
• Ihr Team SodaCL bereits kennt. Vertrautheit wiegt mehr als ein geringfügig besseres Format.

Nehmen Sie Catalyst, wenn …

• Die Menschen, die die Geschäftsregeln kennen, kein Terminal benutzen. Eine Analystin oder ein Fachverantwortlicher kann eine Regel ergänzen — ohne Pull Request, ohne Python-Umgebung und ohne Code-Review durch das Plattform-Team.
• Sie Regeln in einem offenen Standard wollen. ODCS-Contracts exportieren als Datei und importieren in alles, was die Spezifikation spricht. SodaCL ist lesbar, aber es gehört Soda.
• Sie das Ganze als ein Produkt wollen. Zeitplanung, Historie, Abdeckung und Detailanalyse kommen fertig konfiguriert, statt aus CLI plus Cloud-Account plus Agent plus Orchestrator zusammengesetzt zu werden.
• Governance Teil der Anforderung ist. RBAC, ein Audit-Log und SSO stecken vom ersten Tag an im Produkt.
• Sie die fehlerhaften Zeilen sehen wollen. Eine fehlgeschlagene Prüfung verlinkt direkt auf eine Stichprobe der betroffenen Datensätze — meist das Erste, wonach jemand fragt.
• Sie eine vorhersehbare, kleine Preisgestaltung wollen. Starter ist kostenlos für eine Verbindung und ein Dataset (PostgreSQL und MySQL); Team kostet 29 € pro Nutzer und Monat.

Können beide nebeneinander bestehen?

Ja, und die Aufteilung ist sauber. Soda in der Pipeline, als Gate: schnelle Assertions, die einen schlechten Ladelauf stoppen, bevor er landet, ausgeführt von demselben Job, der die Tabelle gebaut hat. Catalyst oberhalb der Pipeline, als Contract- und Monitoring-Schicht: die dauerhaften Versprechen über die Datasets, von denen Ihre Konsumenten abhängen, versioniert als ODCS, nach Zeitplan geprüft und unabhängig davon, welche Pipeline sie heute geschrieben hat — mit der Lauf-Historie und Abdeckungssicht, die sich die Menschen wünschen, die den Zahlen vertrauen müssen, statt eines Job-Logs.

SodaCL nach ODCS zu migrieren ist zum jetzigen Zeitpunkt Handarbeit — einen Importer gibt es nicht —, aber die gängigen Checks bilden sich fast eins zu eins ab (missing_count auf nullCount, duplicate_count auf duplicateCount, invalid_count mit erlaubten Werten auf validValues, freshness auf freshness), und wenn Sie zuerst das Schema importieren, wird der Großteil des Contracts erzeugt, bevor Sie irgendetwas übersetzen. Falls Sie noch überlegen, was überhaupt zu prüfen ist, starten Sie mit dem Leitfaden zur Datenvalidierung.

Häufige Fragen

Ist Soda kostenlos?

Soda Core, die Open-Source-CLI, ist unter der Apache-2.0-Lizenz kostenlos, und Sie können sie produktiv betreiben, ohne jemanden zu bezahlen. Soda Cloud — die gehosteten Dashboards, das Alerting, der Incident-Workflow und die Anomalieerkennung — ist ein kommerzielles Produkt mit eigener Preisgestaltung; die aktuellen Konditionen finden Sie auf Sodas Website. Das meiste von dem, was sich Menschen unter „Soda" vorstellen, ist die Cloud-Hälfte.

Braucht Catalyst Python oder eine CLI?

Nein. Catalyst ist eine Webanwendung. Sie verbinden einen Datenbanknutzer mit Lesezugriff, die Regeln werden im Browser gebaut oder im Editor als ODCS-YAML geschrieben, und die Läufe werden im Produkt geplant. Es gibt nichts zu installieren, keine Umgebung zu pflegen und keinen Scan-Befehl einzuplanen.

Was ist der Unterschied zwischen SodaCL und ODCS?

SodaCL ist Sodas eigene Prüfsprache: kompakt, lesbar und von Sodas Runnern verstanden. ODCS ist der Open Data Contract Standard, eine offene Spezifikation aus dem Bitol-Projekt der Linux Foundation, die Schema, Verantwortlichkeit, Service Levels und Qualitätsregeln eines Datasets in einem versionierten YAML-Dokument beschreibt und von jedem kompatiblen Tool ausgeführt werden kann. Der praktische Unterschied ist die Portabilität — ein ODCS-Contract überlebt einen Anbieterwechsel.

Macht Catalyst Anomalieerkennung?

Zum jetzigen Zeitpunkt nicht. Catalyst führt deterministische Regeln gegen Schwellenwerte aus, die Sie definieren, hält die pass/warn/fail-Historie fest und zeigt Trends über die Zeit. Wenn Sie ausdrücklich statistisches Monitoring brauchen, das den Normalbereich einer Metrik lernt, hat Soda Cloud das und Catalyst nicht.

Kann ich Soda und Catalyst zusammen nutzen?

Ja. Eine verbreitete Anordnung ist Soda Core als Build-Gate innerhalb der Pipeline und Catalyst als Contract- und Monitoring-Schicht über den Tabellen, die landen: Pipeline-Fehler stoppen schlechte Daten früh, während Contracts den Konsumenten ein versioniertes, nachvollziehbares Versprechen mit eigenem Zeitplan und eigener Lauf-Historie geben.