Seminar Great Expectations (GX Core) – Expectation-Parameter, Row Conditions und Severity

Viele Qualitätsregeln ändern sich nach Land, Produktgruppe, Zeitraum oder Betriebsstufe. Das Seminar zeigt, wie GX-Core-Expectations mit Parametern wiederverwendbar werden, mit Row Conditions nur für relevante Zeilen gelten und über Severity unterschiedliche Handlungs- und Eskalationsstufen auslösen.

Inhaltsübersicht

• Zielsetzung und fachliche Einordnung
• Schrittweise Seminarinhalte
• Praxisübungen und Laborszenarien
• Zielgruppe und Voraussetzungen
• Didaktik und Arbeitsweise

Zielsetzung

• Statische und dynamische Expectation-Parameter sinnvoll abgrenzen.
• Schwellen und Vergleichswerte aus Laufzeitkontexten reproduzierbar übergeben.
• Row Conditions mit logischen Verknüpfungen lesbar und testbar formulieren.
• Severity in Regelkatalog, Validation Results und Betriebsreaktion verankern.
• Komplexität, Fehlinterpretationen und unkontrollierte Ausnahmen vermeiden.

Zielgruppe

Data Engineers, Analytics Engineers, Data Stewards und Entwickler, die wiederverwendbare oder bedingte Qualitätsregeln in GX Core aufbauen.

Voraussetzungen

Grundkenntnisse zu Expectations, Suites und Validation Results sowie sichere Python-Grundlagen. Kenntnisse der zu prüfenden Datenlogik sind erforderlich.

Seminarinhalte

1. Schritt 1: Variabilität einer Regel analysieren

   Feste fachliche Anforderungen, umgebungsabhängige Werte, Zeitbezug und Ausnahmen werden getrennt erfasst, bevor Parameter oder Bedingungen eingeführt werden.

2. Schritt 2: Expectation-Parameter identifizieren

   Grenzwerte, Wertemengen, Spaltennamen und Referenzgrößen werden nach Stabilität, Quelle und Änderungsfrequenz klassifiziert.

3. Schritt 3: Parameterwerte bereitstellen

   Laufzeitwerte werden aus Konfiguration, Pipeline-Kontext oder kontrollierten Berechnungen übergeben. Herkunft und Typ werden dokumentiert.

4. Schritt 4: Standardwerte und Pflichtparameter festlegen

   Fehlende Werte dürfen nicht unbemerkt zu schwachen Regeln führen. Standard, Pflicht und bewusste Deaktivierung werden unterschiedlich behandelt.

5. Schritt 5: Row Conditions modellieren

   Zeilenbedingungen werden mit Spaltenausdrücken und logischen AND-/OR-Verknüpfungen aufgebaut. Gültigkeitsbereich und Nullsemantik werden explizit geprüft.

6. Schritt 6: Bedingungen lesbar strukturieren

   Komplexe Bedingungen werden benannt, dokumentiert und in kleinere fachliche Teilregeln zerlegt, wenn dies Diagnose und Wartung verbessert.

7. Schritt 7: Bedingte Erwartungen testen

   Treffermenge, ausgeschlossene Zeilen und Regelresultat werden getrennt kontrolliert. False Positives und ungewollte Leermengen werden erkannt.

8. Schritt 8: Severity festlegen

   Critical, Warning und Info erhalten fachliche Kriterien. Gleiche Fehlerbilder werden nicht allein nach persönlicher Einschätzung unterschiedlich eingestuft.

9. Schritt 9: Severity in Suites einsetzen

   Regeln verschiedener Schweregrade werden sinnvoll gruppiert und in Validation Results sowie Data Docs eindeutig sichtbar gemacht.

10. Schritt 10: Reaktionen aus Severity ableiten

    Pipeline-Abbruch, Quarantäne, Warnung, Ticket oder Beobachtung werden über Checkpoint-Logik und Actions an die Severity gekoppelt.

11. Schritt 11: Parameter, Condition und Severity kombinieren

    Ein mehrstufiger Anwendungsfall verwendet dynamische Schwellen, bedingte Teilmengen und unterschiedliche Reaktionen, ohne die Regel unlesbar zu machen.

12. Schritt 12: Governance und Änderungsnachweis sichern

    Parameterquelle, genehmigte Schwelle, Bedingungslogik, Eigentümer und Änderungshistorie werden in Regelmetadaten und Tests festgehalten.

Praxisübungen

• Statische Regel in parametrisierte Varianten für Entwicklung und Produktion überführen.
• Row Condition für einen fachlich begrenzten Teilbestand mit AND und OR aufbauen.
• Treffermenge und ausgeschlossene Zeilen separat validieren.
• Severity-Matrix mit Reaktion, Frist und Verantwortlichkeit erstellen.
• Checkpoint so konfigurieren, dass kritische und warnende Regeln unterschiedlich behandelt werden.

Methodik

Das Seminar arbeitet mit einem Regelkatalog, der schrittweise variabler und bedingter wird. Jede Erweiterung wird durch Testdaten, Trefferkontrolle und Betriebsreaktion geprüft; unnötige Komplexität wird bewusst zurückgebaut.