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

> Great Expectations 1.22 für Datenqualitätsvalidierung meistern. Expectation Suites, Checkpoints, Data Docs und Interviewfragen mit Python-Beispielen für Data Engineering Interviews.

- Published: 2026-09-13
- Updated: 2026-09-13
- Author: Anthony Fillion-Maillet
- Reading time: 5 min

---

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.

> **GX Core vs. GX Cloud**
>
> GX Core ist die Open-Source-Bibliothek (Apache 2.0 Lizenz) mit über 11.400 GitHub-Sternen. GX Cloud ist die darauf aufbauende verwaltete SaaS-Plattform mit Kollaborationstools und Echtzeit-Monitoring-Dashboards. Dieser Artikel konzentriert sich auf GX Core.

## 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](/blog/data-engineering/apache-airflow-pipeline-orchestration-dags-interview-2026), 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.

```python
# 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."

```python
# 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.

```python
# 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](https://docs.greatexpectations.io/docs/core/introduction/community_resources/#integrations), die die Checkpoint-Ausführung in einen Operator kapselt.

```python
# 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](/blog/data-engineering/dbt-data-transformations-testing-interview-2026) 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.

```python
# 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.

```python
# 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](https://greatexpectations.io/) 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:

| GX 0.x | GX 1.0+ |
|--------|--------|
| `context.create_expectation_suite()` | `context.suites.add()` |
| `context.add_datasource()` | `context.data_sources.add_*()` |
| Dictionary-basierte Expectations | Klassenbasierte Expectations |
| `context.run_checkpoint()` | `checkpoint.run()` |

Der [offizielle Migrationsleitfaden](https://docs.greatexpectations.io/docs/core/introduction/gx_overview/) 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](/blog/data-engineering/apache-airflow-pipeline-orchestration-dags-interview-2026) 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/de/blog/data-engineering/great-expectations-data-quality-validation-interview-2026