Great Expectations 2026: Datenqualitätsvalidierung und Interviewfragen für Data Engineers

Great Expectations (GX) hat sich als das führende Open-Source-Framework für Datenqualitätsvalidierung in Python-basierten Datenpipelines etabliert. Version 1.22, veröffentlicht im August 2026, festigt die in GX 1.0 eingeführten API-Änderungen und fügt experimentelle Python 3.14-Unterstützung hinzu. Für Data Engineers, die produktionsreife Pipelines entwickeln, ist das Beherrschen von GX zu einer unverzichtbaren Kernkompetenz geworden.

Das Problem stiller Pipeline-Fehler

Datenpipelines scheitern oft unbemerkt. Eine Schema-Änderung am Anfang der Pipeline, ein Null-Wert wo keiner sein sollte, ein Datumsformat das von ISO zu Unix-Timestamp wechselt: Diese Probleme erreichen häufig Dashboards oder ML-Modelle bevor jemand sie bemerkt. Great Expectations behandelt Daten wie Code und wendet Assertions (genannt Expectations) an, die automatisch an Checkpoints in der Pipeline ausgeführt werden.

Das Framework integriert sich nahtlos mit Apache Airflow, Databricks, Snowflake und Cloud-Speicherdiensten wie AWS S3 und Azure Blob Storage. Jede Validierung erzeugt Data Docs, HTML-Berichte die auch nicht-technische Stakeholder verstehen können.

Kernkonzepte: Data Context, Data Sources und Expectations

GX 1.22 organisiert die Validierung um vier Komponenten: den Data Context, Data Sources, Data Assets und Expectation Suites.

Der Data Context ist das zentrale Konfigurationsobjekt. Er speichert Metadaten für Data Sources, Expectation Suites, Checkpoints und historische Validierungsergebnisse. In den meisten Projekten enthält ein einzelnes gx/-Verzeichnis die YAML-Konfigurationsdateien und generierten Data Docs.

Eine Data Source repräsentiert eine Verbindung zu einer Datenbank, einem Data Warehouse oder einem Dateisystem. Ein Data Asset ist eine logische Sammlung von Datensätzen innerhalb dieser Quelle, ähnlich einer Tabelle oder dem Ergebnis einer Abfrage.

# gx_setup.py
import great_expectations as gx

# Initialize or load an existing Data Context
context = gx.get_context()

# Add a Pandas Data Source for local files
data_source = context.data_sources.add_pandas("local_files")

# Define a Data Asset pointing to a specific CSV pattern
data_asset = data_source.add_csv_asset(
    name="user_events",
    filepath_or_buffer="data/user_events_*.csv"  # Glob pattern
)

Diese Konfiguration ermöglicht es GX, jede CSV-Datei zu validieren, die dem Muster user_events_*.csv im data/-Verzeichnis entspricht.

Aufbau einer Expectation Suite für Spaltenvalidierung

Eine Expectation Suite ist eine Sammlung von Assertions gegen ein Data Asset. Jede Expectation deklariert eine Bedingung, die für die Daten gelten sollte, wie etwa "Spalte user_id darf niemals null sein" oder "Spalte age sollte Werte zwischen 0 und 120 enthalten."

# build_suite.py
import great_expectations as gx

context = gx.get_context()

# Create or retrieve an Expectation Suite
suite = context.suites.add(
    gx.ExpectationSuite(name="user_events_suite")
)

# Add Expectations to the suite
suite.add_expectation(
    gx.expectations.ExpectColumnToExist(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="age",
        min_value=0,
        max_value=120
    )
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToMatchRegex(
        column="email",
        regex=r"^[\w.-]+@[\w.-]+\.\w+$"
    )
)

# Save the suite to the Data Context
context.suites.save(suite)

GX 1.0+ verwendet eine klassenbasierte API für Expectations. Die ältere Dictionary-basierte Syntax (expect_column_to_exist) bleibt verfügbar, aber der klassenbasierte Ansatz bietet bessere IDE-Autovervollständigung und Typsicherheit.

Validierungen mit Checkpoints ausführen

Ein Checkpoint verbindet ein Data Asset, eine Expectation Suite und optionale Actions, die bei bestandener oder fehlgeschlagener Validierung ausgelöst werden. Checkpoints sind der primäre Einstiegspunkt für automatisierte Validierung in der Produktion.

# run_checkpoint.py
import great_expectations as gx

context = gx.get_context()

# Create a Checkpoint
checkpoint = context.checkpoints.add(
    gx.Checkpoint(
        name="user_events_checkpoint",
        validation_definitions=[
            gx.ValidationDefinition(
                name="validate_user_events",
                data=context.data_sources.get("local_files")
                    .get_asset("user_events")
                    .build_batch_request(),
                suite=context.suites.get("user_events_suite")
            )
        ],
        actions=[
            gx.checkpoint.UpdateDataDocsAction(name="update_docs"),
        ]
    )
)

# Run the Checkpoint
result = checkpoint.run()

# Check overall success
if result.success:
    print("All validations passed")
else:
    print("Validation failures detected")
    for validation_result in result.run_results.values():
        for expectation_result in validation_result.results:
            if not expectation_result.success:
                print(f"  Failed: {expectation_result.expectation_config}")

Wenn der Checkpoint läuft, lädt GX den Batch, wendet jede Expectation an und aktualisiert die Data Docs. Fehlgeschlagene Validierungen können je nach konfigurierten Actions Slack-Benachrichtigungen, PagerDuty-Alerts oder Pipeline-Abbrüche auslösen.

GX-Integration mit Apache Airflow DAGs

Die meisten Produktions-Datenpipelines verwenden einen Orchestrator wie Apache Airflow. GX bietet eine offizielle Airflow-Integration, die die Checkpoint-Ausführung in einen Operator kapselt.

# dags/user_events_pipeline.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
import great_expectations as gx

def validate_user_events():
    """Run GX Checkpoint for user events data."""
    context = gx.get_context(context_root_dir="/opt/airflow/gx")
    checkpoint = context.checkpoints.get("user_events_checkpoint")
    result = checkpoint.run()
    
    if not result.success:
        # Raise exception to fail the Airflow task
        raise ValueError("Data validation failed. Check Data Docs for details.")

with DAG(
    dag_id="user_events_pipeline",
    start_date=datetime(2026, 1, 1),
    schedule_interval="@daily",
    catchup=False
) as dag:
    
    validate_task = PythonOperator(
        task_id="validate_user_events",
        python_callable=validate_user_events
    )
    
    # Downstream tasks depend on validation passing
    # transform_task >> load_task

Die Platzierung der Validierung vor Transformations-Tasks verhindert, dass fehlerhafte Daten weiter downstream gelangen. Dieses Muster, manchmal "Shift-Left-Testing" genannt, fängt Probleme bei der Ingestion ab anstatt nach Abschluss teurer Berechnungsjobs.

Häufige Interviewfragen zu Great Expectations

Data-Engineering-Interviews im Jahr 2026 enthalten regelmäßig Fragen zu Datenqualitäts-Tooling. Im Folgenden finden sich Fragen, die in technischen Screenings erscheinen, zusammen mit Antworten, die erfahrene Kandidaten von Anfängern unterscheiden.

"Wie würden Sie Datenqualitätsprüfungen in einer Produktions-Pipeline implementieren?"

Starke Antworten erwähnen die Einbettung von Validierung als Pipeline-Stufe, nicht als separates Dashboard. Konkret:

• Schema-Validierung bei der Ingestion fängt strukturelle Probleme sofort ab, beispielsweise einen String wo eine Ganzzahl erwartet wurde
• Business-Logic-Validierung prüft Domain-Constraints wie positive Preise und Datumsbereiche
• Automatisierte Alerts benachrichtigen Bereitschaftsingenieure wenn die Validierung fehlschlägt und verhindern stille Datenkorruption
• dbt-Tests behandeln Prüfungen auf der Transformationsschicht während GX die Ingestion- und Output-Validierung übernimmt

"Was ist der Unterschied zwischen einer Expectation Suite und einem Checkpoint?"

Eine Expectation Suite enthält die Assertions selbst: welche Spalten existieren sollten, welche Wertebereiche akzeptabel sind, welche Regex-Muster übereinstimmen sollten. Sie definiert was zu prüfen ist.

Ein Checkpoint definiert wann und wie diese Prüfungen ausgeführt werden. Er verbindet ein spezifisches Data Asset (die zu validierenden Daten), eine Expectation Suite (die anzuwendenden Regeln) und Actions (was nach der Validierung passiert).

"Wie geht man mit Expectations um, die je nach Umgebung variieren?"

Produktionsdaten haben oft andere Eigenschaften als Staging-Daten. Zwei Ansätze:

1. Parametrisierte Expectations: Umgebungsvariablen oder Laufzeitparameter zur Anpassung von Schwellenwerten verwenden. Zum Beispiel min_value=int(os.getenv("AGE_MIN", 0)).

2. Mehrere Suites: Separate Suites für Staging und Produktion pflegen. Staging könnte Nulls in optionalen Feldern erlauben um unvollständige Datenflüsse zu testen.

"Was passiert wenn ein Checkpoint in einer geplanten Pipeline fehlschlägt?"

Der Checkpoint gibt ein CheckpointResult mit success=False zurück. Das Pipeline-Verhalten hängt davon ab, wie der Orchestrator den Fehler behandelt:

• In Airflow markiert das Auslösen einer Exception den Task als fehlgeschlagen und blockiert nachgelagerte Tasks
• In Databricks kann das Notebook mit einem Fehlerstatus beenden
• An den Checkpoint angehängte Actions können Slack-Nachrichten senden, Jira-Tickets erstellen oder Rollback-Prozeduren auslösen

Benutzerdefinierte Expectations für domänenspezifische Validierung

GX enthält über 300 eingebaute Expectations, aber domänenspezifische Regeln erfordern oft benutzerdefinierte Implementierungen. Eine benutzerdefinierte Expectation erweitert die Basisklasse und implementiert die Validierungslogik.

# custom_expectations/expect_valid_iso_country_code.py
from great_expectations.expectations import Expectation
from great_expectations.core import ExpectationConfiguration
import pycountry

class ExpectValidIsoCountryCode(Expectation):
    """Expect column values to be valid ISO 3166-1 alpha-2 country codes."""
    
    column: str
    
    @classmethod
    def _prescriptive_template(cls) -> str:
        return "Column {column} values must be valid ISO country codes"
    
    def _validate(self, metrics, runtime_configuration=None, execution_engine=None):
        column_values = metrics.get("column_values")
        valid_codes = {c.alpha_2 for c in pycountry.countries}
        
        invalid_values = [
            v for v in column_values 
            if v is not None and v not in valid_codes
        ]
        
        return {
            "success": len(invalid_values) == 0,
            "result": {
                "observed_value": len(invalid_values),
                "unexpected_list": invalid_values[:10]  # Sample
            }
        }

Benutzerdefinierte Expectations werden registriert indem sie im Verzeichnis great_expectations/plugins/ platziert oder das Modul zum plugins_directory in great_expectations.yml hinzugefügt wird.

Data Docs: Qualitätskommunikation an Stakeholder

Data Docs sind statische HTML-Seiten, die aus Validierungsergebnissen generiert werden. Jeder Lauf erzeugt eine Seite, die zeigt welche Expectations bestanden oder fehlgeschlagen sind, mit Drill-Down-Details zu unerwarteten Werten.

# Generate and open Data Docs
context = gx.get_context()
context.build_data_docs()
context.open_data_docs()  # Opens browser

Für Produktionssysteme können Data Docs auf S3, GCS oder Azure Blob Storage mit entsprechenden Zugriffskontrollen gehostet werden. Die GX Cloud-Plattform bietet gehostete Data Docs mit Team-Kollaborationsfunktionen.

Migration zu GX 1.0: Breaking Changes von 0.x

Teams, die von GX 0.x upgraden, stehen vor API-Änderungen. Die wichtigsten Unterschiede:

Der offizielle Migrationsleitfaden behandelt jede Änderung. Für große Codebasen reduziert eine schrittweise Migration unter Verwendung von Kompatibilitäts-Shims das Risiko.

Kernpunkte für Datenqualität mit GX 1.22

• Great Expectations 1.22 (August 2026) unterstützt Python 3.10 bis 3.13, mit experimenteller 3.14-Unterstützung über die Umgebungsvariable GX_PYTHON_EXPERIMENTAL
• Expectation Suites definieren was validiert werden soll, Checkpoints definieren wann und wie
• Checkpoints als Pipeline-Stufen in Airflow DAGs oder Databricks-Notebooks einbetten um fehlerhafte Daten bei der Ingestion abzufangen
• Benutzerdefinierte Expectations behandeln domänenspezifische Regeln, die eingebaute Expectations nicht abdecken können
• Data Docs bieten Stakeholder-lesbare HTML-Berichte; für Produktionszugriff auf Cloud-Speicher hosten
• Interview-Antworten sollten Datenqualität als eingebettete Pipeline-Stufe betonen, nicht als nachträglich hinzugefügtes Dashboard