# Great Expectations nel 2026: Validazione della Qualità dei Dati e Domande per Colloqui di Data Engineering > Guida completa a Great Expectations 1.22 per la validazione della qualità dei dati. Expectation Suite, Checkpoint, Data Docs e domande frequenti nei colloqui tecnici con esempi Python. - Published: 2026-09-13 - Updated: 2026-09-13 - Author: Anthony Fillion-Maillet - Reading time: 5 min --- Great Expectations (GX) rappresenta lo standard de facto per la validazione della qualità dei dati nelle pipeline Python. La versione 1.22, rilasciata ad agosto 2026, consolida le modifiche API introdotte in GX 1.0 e aggiunge il supporto sperimentale per Python 3.14. Per i data engineer che costruiscono pipeline di produzione, la padronanza di GX è diventata una competenza fondamentale. > **GX Core vs GX Cloud** > > GX Core è la libreria open-source (licenza Apache 2.0) con oltre 11.400 stelle su GitHub. GX Cloud è la piattaforma SaaS gestita costruita sopra di essa, che offre strumenti di collaborazione e dashboard di monitoraggio in tempo reale. Questo articolo si concentra su GX Core. ## Il Problema delle Pipeline che Falliscono Silenziosamente Le pipeline di dati falliscono in modo silenzioso. Una modifica allo schema a monte, un valore null dove non dovrebbe esserci, un formato data che passa da ISO a Unix timestamp: questi problemi spesso raggiungono dashboard o modelli ML prima che qualcuno se ne accorga. Great Expectations tratta i dati come codice, applicando asserzioni (chiamate Expectation) che vengono eseguite automaticamente ai checkpoint della pipeline. Il framework si integra con [Apache Airflow](/blog/data-engineering/apache-airflow-pipeline-orchestration-dags-interview-2026), Databricks, Snowflake e servizi di cloud storage come AWS S3 e Azure Blob Storage. Ogni validazione produce Data Docs, report HTML che anche gli stakeholder non tecnici possono leggere. ## Concetti Fondamentali: Data Context, Data Source ed Expectation GX 1.22 organizza la validazione attorno a quattro componenti: il Data Context, le Data Source, i Data Asset e le Expectation Suite. Il **Data Context** è l'oggetto di configurazione centrale. Memorizza i metadati per Data Source, Expectation Suite, Checkpoint e risultati storici delle validazioni. Nella maggior parte dei progetti, una singola directory `gx/` contiene i file di configurazione YAML e i Data Docs generati. Una **Data Source** rappresenta una connessione a un database, un data warehouse o un file system. Un **Data Asset** è una collezione logica di record all'interno di quella sorgente, simile a una tabella o al risultato di una query. ```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 ) ``` Questa configurazione permette a GX di validare qualsiasi file CSV che corrisponde al pattern `user_events_*.csv` nella directory `data/`. ## Costruire un'Expectation Suite per la Validazione delle Colonne Un'Expectation Suite è una collezione di asserzioni contro un Data Asset. Ogni Expectation dichiara una condizione che dovrebbe essere vera per i dati, come "la colonna `user_id` non deve mai essere null" oppure "la colonna `age` deve contenere valori tra 0 e 120." ```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+ utilizza un'API basata su classi per le Expectation. La vecchia sintassi basata su dizionari (`expect_column_to_exist`) rimane disponibile, ma l'approccio basato su classi offre migliore autocompletamento IDE e type safety. ## Eseguire Validazioni con i Checkpoint Un Checkpoint collega un Data Asset, un'Expectation Suite e Action opzionali che si attivano quando la validazione passa o fallisce. I Checkpoint sono il punto di ingresso principale per la validazione automatizzata in produzione. ```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}") ``` Quando il Checkpoint viene eseguito, GX carica il batch, applica ogni Expectation e aggiorna i Data Docs. Le validazioni fallite possono attivare notifiche Slack, alert PagerDuty o terminazione della pipeline a seconda delle Action configurate. ## Integrazione di GX con i DAG di Apache Airflow La maggior parte delle pipeline di dati in produzione utilizza un orchestratore come Apache Airflow. GX fornisce un'[integrazione ufficiale con Airflow](https://docs.greatexpectations.io/docs/core/introduction/community_resources/#integrations) che incapsula l'esecuzione dei Checkpoint in un operatore. ```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 ``` Posizionare la validazione prima dei task di trasformazione impedisce ai dati corrotti di propagarsi a valle. Questo pattern, a volte chiamato "shift-left testing", intercetta i problemi all'ingestion piuttosto che dopo il completamento di costosi job di calcolo. ## Domande Frequenti nei Colloqui su Great Expectations I colloqui di data engineering nel 2026 includono frequentemente domande sul tooling per la qualità dei dati. Di seguito sono riportate domande che compaiono negli screening tecnici, insieme alle risposte che distinguono i candidati esperti dai junior. ### "Come implementeresti i controlli di qualità dei dati in una pipeline di produzione?" Le risposte migliori menzionano l'incorporazione della validazione come fase della pipeline, non come dashboard separata. Nello specifico: - La validazione dello schema all'ingestion intercetta immediatamente problemi strutturali, ad esempio una stringa dove ci si aspettava un intero - La validazione della business logic verifica vincoli di dominio come prezzi positivi e intervalli di date - Gli alert automatizzati notificano gli ingegneri di turno quando la validazione fallisce, prevenendo la corruzione silenziosa dei dati - I [test dbt](/blog/data-engineering/dbt-data-transformations-testing-interview-2026) gestiscono i controlli a livello di trasformazione mentre GX gestisce la validazione di ingestion e output ### "Qual è la differenza tra un'Expectation Suite e un Checkpoint?" Un'Expectation Suite contiene le asserzioni stesse: quali colonne dovrebbero esistere, quali intervalli di valori sono accettabili, quali pattern regex dovrebbero corrispondere. Definisce *cosa* controllare. Un Checkpoint definisce *quando* e *come* eseguire quei controlli. Collega un Data Asset specifico (i dati da validare), un'Expectation Suite (le regole da applicare) e le Action (cosa succede dopo la validazione). ### "Come si gestiscono le Expectation che variano in base all'ambiente?" I dati di produzione hanno spesso caratteristiche diverse dai dati di staging. Due approcci: 1. **Expectation Parametrizzate**: Utilizzare variabili d'ambiente o parametri runtime per regolare le soglie. Ad esempio, `min_value=int(os.getenv("AGE_MIN", 0))`. 2. **Suite Multiple**: Mantenere suite separate per staging e produzione. Lo staging potrebbe permettere null nei campi opzionali per testare flussi di dati incompleti. ### "Cosa succede quando un Checkpoint fallisce in una pipeline schedulata?" Il Checkpoint restituisce un `CheckpointResult` con `success=False`. Il comportamento della pipeline dipende da come l'orchestratore gestisce il fallimento: - In Airflow, sollevare un'eccezione marca il task come fallito, bloccando i task a valle - In Databricks, il notebook può uscire con uno stato di errore - Le Action collegate al Checkpoint possono inviare messaggi Slack, creare ticket Jira o attivare procedure di rollback ## Expectation Personalizzate per Validazione di Dominio GX include oltre 300 Expectation integrate, ma le regole specifiche del dominio spesso richiedono implementazioni personalizzate. Un'Expectation personalizzata estende la classe base e implementa la logica di validazione. ```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 } } ``` Le Expectation personalizzate vengono registrate posizionandole nella directory `great_expectations/plugins/` o aggiungendo il modulo al `plugins_directory` in `great_expectations.yml`. ## Data Docs: Comunicare la Qualità agli Stakeholder I Data Docs sono siti HTML statici generati dai risultati delle validazioni. Ogni esecuzione produce una pagina che mostra quali Expectation sono passate o fallite, con dettagli drill-down sui valori inaspettati. ```python # Generate and open Data Docs context = gx.get_context() context.build_data_docs() context.open_data_docs() # Opens browser ``` Per i sistemi di produzione, i Data Docs possono essere ospitati su S3, GCS o Azure Blob Storage con appropriati controlli di accesso. La [piattaforma GX Cloud](https://greatexpectations.io/) offre Data Docs ospitati con funzionalità di collaborazione di team. ## Migrazione a GX 1.0: Breaking Change da 0.x I team che effettuano l'upgrade da GX 0.x affrontano modifiche API. Le principali differenze: | GX 0.x | GX 1.0+ | |--------|--------| | `context.create_expectation_suite()` | `context.suites.add()` | | `context.add_datasource()` | `context.data_sources.add_*()` | | Expectation basate su dizionari | Expectation basate su classi | | `context.run_checkpoint()` | `checkpoint.run()` | La [guida ufficiale alla migrazione](https://docs.greatexpectations.io/docs/core/introduction/gx_overview/) copre ogni modifica. Per codebase di grandi dimensioni, la migrazione incrementale utilizzando shim di compatibilità riduce il rischio. ## Punti Chiave per la Qualità dei Dati con GX 1.22 - Great Expectations 1.22 (agosto 2026) supporta Python da 3.10 a 3.13, con supporto sperimentale per 3.14 tramite la variabile d'ambiente `GX_PYTHON_EXPERIMENTAL` - Le Expectation Suite definiscono *cosa* validare, i Checkpoint definiscono *quando* e *come* - Incorporare i Checkpoint come fasi della pipeline nei [DAG Airflow](/blog/data-engineering/apache-airflow-pipeline-orchestration-dags-interview-2026) o nei notebook Databricks per intercettare dati corrotti all'ingestion - Le Expectation personalizzate gestiscono regole specifiche del dominio che le Expectation integrate non possono coprire - I Data Docs forniscono report HTML leggibili dagli stakeholder; ospitarli su cloud storage per l'accesso in produzione - Le risposte nei colloqui dovrebbero enfatizzare la qualità dei dati come fase integrata della pipeline, non come dashboard aggiunta successivamente --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/data-engineering/great-expectations-data-quality-validation-interview-2026