Seminar Soda Core v3 zu v4 – Migration von SodaCL zu Data Contracts

Das Seminar führt bestehende SodaCL-Prüfungen kontrolliert in das Data-Contract-Modell von Soda Core v4 über. Nicht jede Regel wird mechanisch übernommen; Semantik, Datenumfang, Schwellenwerte und Betriebswirkung werden einzeln validiert.

Der Migrationsprozess verwendet Inventar, Mapping-Matrix, Dual Run und definierte Abbruchkriterien. Dadurch bleiben fachliche Aussage und betriebliche Stabilität während des Übergangs nachvollziehbar.

Lernziele

• v3-Artefakte, Abhängigkeiten und Betriebsabläufe vollständig inventarisieren
• SodaCL-Regeln semantisch korrekt in v4-Data-Contracts überführen
• Paket-, Konfigurations-, CLI- und Cloud-Änderungen kontrolliert testen
• Dual Run, Cutover, Rollback und Nachkontrolle mit messbaren Kriterien planen

Inhaltsübersicht

1. Istbestand und Abhängigkeiten erfassen
2. v4-Zielbild und Migrationswellen planen
3. SodaCL-Regeln auf Contract-Semantik abbilden
4. Pakete, Konfiguration und CLI umstellen
5. Ergebnisse im Dual Run vergleichen
6. Cloud- und Betriebsprozesse migrieren
7. Cutover, Rollback und Nachkontrolle durchführen

Seminarinhalte

1. Istbestand und Abhängigkeiten erfassen

1. Schritt 1: Soda-Core-Versionen, Datenquellenpakete und Python-Laufzeiten inventarisieren.
2. Schritt 2: Checks-YAML, Konfigurationen, Variablen, Filter und Custom SQL sammeln.
3. Schritt 3: Automationsjobs, Exitcode-Auswertung und Cloud-Veröffentlichung dokumentieren.
4. Schritt 4: Kritikalität, Owner und letzte erfolgreiche Ausführung je Prüfpaket festhalten.

2. v4-Zielbild und Migrationswellen planen

1. Schritt 1: Data Contracts als Zielartefakt und neue CLI-Arbeitsweise einordnen.
2. Schritt 2: Datasets und Verträge anhand fachlicher Produkte neu strukturieren.
3. Schritt 3: Einfache, komplexe und nicht direkt übertragbare Regeln klassifizieren.
4. Schritt 4: Migrationswellen mit Abnahme-, Rückfall- und Freeze-Zeiträumen definieren.

3. SodaCL-Regeln auf Contract-Semantik abbilden

1. Schritt 1: Schema-, Dataset- und Spaltenchecks der passenden Contract-Struktur zuordnen.
2. Schritt 2: Schwellenwerte, Filter und Variablen auf gleiche fachliche Bedeutung prüfen.
3. Schritt 3: Check-Namen, Attribute und Qualifier für Nachvollziehbarkeit ergänzen.
4. Schritt 4: Nicht äquivalente Regeln als Neuentwurf statt als Blindkopie kennzeichnen.

4. Pakete, Konfiguration und CLI umstellen

1. Schritt 1: Neue isolierte Umgebung mit v4-Paketen aufbauen.
2. Schritt 2: Datenquellen- und Cloud-Konfiguration in das aktuelle Format überführen.
3. Schritt 3: Contract-Test, Veröffentlichung, Abruf und Verifikation als Befehlsfolge validieren.
4. Schritt 4: Automationsskripte auf neue Parameter, Ausgaben und Fehlerzustände anpassen.

5. Ergebnisse im Dual Run vergleichen

1. Schritt 1: Identischen Datenstand mit v3- und v4-Prüfung ausführen.
2. Schritt 2: Checkabdeckung, Pass-Fail-Zustand, Schwellenwerte und Laufzeiten vergleichen.
3. Schritt 3: Abweichungen nach Semantik, Datenumfang, Rundung oder Implementierung erklären.
4. Schritt 4: Freigabe nur bei dokumentierter Gleichwertigkeit oder bewusst genehmigter Änderung erteilen.

6. Cloud- und Betriebsprozesse migrieren

1. Schritt 1: Vertragsversion, Ergebnisveröffentlichung und Ownership in Soda Cloud prüfen.
2. Schritt 2: Alert- und Incident-Regeln auf neue Check-Identitäten abstimmen.
3. Schritt 3: Dashboards, Berichte und technische Korrelationsschlüssel aktualisieren.
4. Schritt 4: Runbooks, Supportpfade und Monitoring auf v4-Fehlerbilder erweitern.

7. Cutover, Rollback und Nachkontrolle durchführen

1. Schritt 1: Cutover-Checkliste und Verantwortlichkeiten für den Wechsel festlegen.
2. Schritt 2: Alte Jobs kontrolliert deaktivieren und neue Jobs überwacht aktivieren.
3. Schritt 3: Rollback bei Qualitäts-, Leistungs- oder Integrationsabweichung testen.
4. Schritt 4: Nachkontrolle über mehrere Datenzyklen mit Abschlusskriterien dokumentieren.

Praxislabor

Ein vorhandenes SodaCL-Prüfpaket wird inventarisiert, in einen v4-Data-Contract überführt und im Dual Run verglichen. Paket- und CLI-Wechsel, Cloud-Veröffentlichung, Cutover und ein getesteter Rollback werden protokolliert.

Zielgruppe und Voraussetzungen

Zielgruppe: Bestehende Soda-Core-v3-Teams, Data Engineering, Data Quality Engineering, Plattformbetrieb und technische Migrationsleitung.

Voraussetzungen: Praktische Erfahrung mit Soda Core v3, SodaCL, Checks-YAML und bestehenden Automationsjobs; sichere YAML- und SQL-Kenntnisse.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurationsschritte, Praxisübungen und kontrollierte Fehlerfälle vertieft. Jede Übung verwendet definierte Ausgangswerte, Prüfpunkte und Dokumentationsanforderungen, damit die erarbeiteten Abläufe als Betriebsstandard wiederholbar bleiben.