Great Expectations in 2026: Datakwaliteitsvalidatie en Sollicitatievragen voor Data Engineers

Great Expectations (GX) is uitgegroeid tot het standaard open-source framework voor datakwaliteitsvalidatie in Python-gebaseerde datapipelines. Versie 1.22, uitgebracht in augustus 2026, consolideert de API-wijzigingen die in GX 1.0 zijn geïntroduceerd en voegt experimentele Python 3.14-ondersteuning toe. Voor data engineers die productie-grade pipelines bouwen, is beheersing van GX een essentiële vaardigheid geworden.

Het Probleem van Stil Falende Pipelines

Datapipelines falen vaak onopgemerkt. Een schemawijziging upstream, een null-waarde waar er geen zou moeten zijn, een datumformaat dat wisselt van ISO naar Unix-timestamp: deze problemen bereiken vaak dashboards of ML-modellen voordat iemand het opmerkt. Great Expectations behandelt data als code door assertions (genaamd Expectations) toe te passen die automatisch worden uitgevoerd op checkpoints in de pipeline.

Het framework integreert naadloos met Apache Airflow, Databricks, Snowflake en cloudopslagdiensten zoals AWS S3 en Azure Blob Storage. Elke validatie produceert Data Docs, HTML-rapporten die ook niet-technische stakeholders kunnen lezen.

Kernconcepten: Data Context, Data Sources en Expectations

GX 1.22 organiseert validatie rond vier componenten: de Data Context, Data Sources, Data Assets en Expectation Suites.

De Data Context is het centrale configuratie-object. Het slaat metadata op voor Data Sources, Expectation Suites, Checkpoints en historische validatieresultaten. In de meeste projecten bevat een enkele gx/-directory de YAML-configuratiebestanden en gegenereerde Data Docs.

Een Data Source vertegenwoordigt een verbinding met een database, datawarehouse of bestandssysteem. Een Data Asset is een logische verzameling records binnen die bron, vergelijkbaar met een tabel of het resultaat van een query.

# 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
)

Deze configuratie stelt GX in staat om elk CSV-bestand te valideren dat overeenkomt met het patroon user_events_*.csv in de data/-directory.

Een Expectation Suite Bouwen voor Kolomvalidatie

Een Expectation Suite is een verzameling van assertions tegen een Data Asset. Elke Expectation declareert een voorwaarde die waar zou moeten zijn voor de data, zoals "kolom user_id mag nooit null zijn" of "kolom age moet waarden tussen 0 en 120 bevatten."

# 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+ gebruikt een klasse-gebaseerde API voor Expectations. De oudere dictionary-gebaseerde syntax (expect_column_to_exist) blijft beschikbaar, maar de klasse-gebaseerde aanpak biedt betere IDE-autocompletion en type safety.

Validaties Uitvoeren met Checkpoints

Een Checkpoint koppelt een Data Asset, een Expectation Suite en optionele Actions die worden geactiveerd wanneer validatie slaagt of faalt. Checkpoints zijn het primaire toegangspunt voor geautomatiseerde validatie in productie.

# 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}")

Wanneer de Checkpoint wordt uitgevoerd, laadt GX de batch, past elke Expectation toe en werkt de Data Docs bij. Gefaalde validaties kunnen Slack-notificaties, PagerDuty-alerts of pipeline-beëindiging activeren, afhankelijk van de geconfigureerde Actions.

GX Integratie met Apache Airflow DAGs

De meeste productie-datapipelines gebruiken een orchestrator zoals Apache Airflow. GX biedt een officiële Airflow-integratie die de Checkpoint-uitvoering in een operator wikkelt.

# 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

Het plaatsen van validatie vóór transformatietaken voorkomt dat slechte data verder downstream terechtkomt. Dit patroon, soms "shift-left testing" genoemd, vangt problemen af bij de ingestie in plaats van na voltooiing van dure rekenjobs.

Veelgestelde Sollicitatievragen over Great Expectations

Data engineering sollicitatiegesprekken in 2026 bevatten regelmatig vragen over datakwaliteitstooling. Hieronder staan vragen die verschijnen in technische screenings, samen met antwoorden die ervaren kandidaten onderscheiden van beginners.

"Hoe zou je datakwaliteitscontroles implementeren in een productie-pipeline?"

Sterke antwoorden vermelden het inbedden van validatie als een pipeline-stap, niet als een apart dashboard. Specifiek:

• Schemavalidatie bij ingestie vangt structurele problemen direct af, bijvoorbeeld een string waar een integer werd verwacht
• Business logic validatie controleert domeinbeperkingen zoals positieve prijzen en datumbereiken
• Geautomatiseerde alerts waarschuwen bereikbaarheidsengineers wanneer validatie faalt, waardoor stille datacorruptie wordt voorkomen
• dbt-tests behandelen controles op de transformatielaag terwijl GX ingestie- en outputvalidatie afhandelt

"Wat is het verschil tussen een Expectation Suite en een Checkpoint?"

Een Expectation Suite bevat de assertions zelf: welke kolommen zouden moeten bestaan, welke waardebereiken acceptabel zijn, welke regex-patronen zouden moeten matchen. Het definieert wat te controleren.

Een Checkpoint definieert wanneer en hoe die controles worden uitgevoerd. Het verbindt een specifieke Data Asset (de te valideren data), een Expectation Suite (de toe te passen regels) en Actions (wat er na validatie gebeurt).

"Hoe ga je om met Expectations die variëren per omgeving?"

Productiedata heeft vaak andere eigenschappen dan stagingdata. Twee benaderingen:

1. Geparametriseerde Expectations: Gebruik omgevingsvariabelen of runtime-parameters om drempels aan te passen. Bijvoorbeeld min_value=int(os.getenv("AGE_MIN", 0)).

2. Meerdere Suites: Onderhoud aparte suites voor staging en productie. Staging zou nulls in optionele velden kunnen toestaan voor het testen van onvolledige datastromen.

"Wat gebeurt er wanneer een Checkpoint faalt in een geplande pipeline?"

De Checkpoint retourneert een CheckpointResult met success=False. Het pipelinegedrag hangt af van hoe de orchestrator de fout afhandelt:

• In Airflow markeert het gooien van een exception de taak als gefaald, waardoor downstream taken worden geblokkeerd
• In Databricks kan de notebook afsluiten met een foutstatus
• Actions gekoppeld aan de Checkpoint kunnen Slack-berichten sturen, Jira-tickets aanmaken of rollback-procedures activeren

Aangepaste Expectations voor Domeinspecifieke Validatie

GX bevat meer dan 300 ingebouwde Expectations, maar domeinspecifieke regels vereisen vaak aangepaste implementaties. Een aangepaste Expectation breidt de basisklasse uit en implementeert de validatielogica.

# 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
            }
        }

Aangepaste Expectations worden geregistreerd door ze in de great_expectations/plugins/-directory te plaatsen of de module toe te voegen aan de plugins_directory in great_expectations.yml.

Data Docs: Kwaliteit Communiceren naar Stakeholders

Data Docs zijn statische HTML-sites gegenereerd uit validatieresultaten. Elke run produceert een pagina die toont welke Expectations zijn geslaagd of gefaald, met drill-down details over onverwachte waarden.

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

Voor productiesystemen kunnen Data Docs worden gehost op S3, GCS of Azure Blob Storage met passende toegangscontroles. Het GX Cloud-platform biedt gehoste Data Docs met teamsamenwerkingsfunctionaliteiten.

Migratie naar GX 1.0: Breaking Changes van 0.x

Teams die upgraden van GX 0.x worden geconfronteerd met API-wijzigingen. De belangrijkste verschillen:

De officiële migratiegids behandelt elke wijziging. Voor grote codebases vermindert incrementele migratie met compatibiliteitsshims het risico.

Kernpunten voor Datakwaliteit met GX 1.22

• Great Expectations 1.22 (augustus 2026) ondersteunt Python 3.10 tot 3.13, met experimentele 3.14-ondersteuning via de GX_PYTHON_EXPERIMENTAL-omgevingsvariabele
• Expectation Suites definiëren wat te valideren, Checkpoints definiëren wanneer en hoe
• Embed Checkpoints als pipeline-stappen in Airflow DAGs of Databricks-notebooks om slechte data bij ingestie af te vangen
• Aangepaste Expectations behandelen domeinspecifieke regels die ingebouwde Expectations niet kunnen dekken
• Data Docs bieden stakeholder-leesbare HTML-rapporten; host ze op cloudopslag voor productietoegang
• Sollicitatie-antwoorden moeten datakwaliteit benadrukken als een ingebedde pipeline-stap, niet als een achteraf toegevoegd dashboard