Data Quality Frameworks

Executive summary

Quando i dati che alimentano i sistemi decisionali di un'azienda contengono errori, lacune o arrivano in ritardo, le conseguenze si propagano silenziosamente fino a compromettere le analisi, le previsioni e i processi automatizzati che da quei dati dipendono. Il problema non è nuovo, ma la crescita dei volumi e la diffusione di sistemi che prendono decisioni in autonomia lo hanno reso molto più urgente e costoso. Questo articolo analizza gli strumenti e le metodologie oggi disponibili per verificare, misurare e garantire la qualità dei dati lungo l'intero ciclo di vita, dall'analisi statistica iniziale ai controlli continui in produzione, confrontandone le architetture, i punti di forza e i limiti concreti. L'analisi mostra che le soluzioni più efficaci combinano verifiche preventive integrate nelle fasi di produzione dei dati con un monitoraggio continuo capace di rilevare problemi che nessuna regola predefinita potrebbe anticipare, ma che il coordinamento tra questi approcci resta una sfida organizzativa e tecnica significativa.

Background

La qualità dei dati è oggetto di studio sistematico da oltre tre decenni. La letteratura accademica ha prodotto numerose tassonomie delle dimensioni della qualità: Batini et al., nella loro survey pubblicata su ACM Computing Surveys, hanno identificato e classificato le metodologie di assessment della qualità dei dati organizzandole in fasi di analisi, definizione dei requisiti, identificazione delle aree critiche e misurazione, stabilendo un framework di riferimento che distingue dimensioni quali accuratezza, completezza, consistenza e tempestività [1]. Batini e Scannapieco hanno successivamente consolidato questi risultati in un trattato sistematico che formalizza principi, tecniche e metriche per la valutazione della qualità dei dati, proponendo un modello che separa le dimensioni intrinseche (dipendenti dai dati stessi) da quelle contestuali (dipendenti dall'uso che se ne fa) [2]. Più recentemente, Ehrlinger e Wöß hanno condotto una survey su 667 strumenti software dedicati alla qualità dei dati, selezionandone 13 per un'analisi approfondita lungo tre assi funzionali, data profiling, misurazione della qualità e monitoraggio continuo, evidenziando come la maggior parte degli strumenti copra solo parzialmente lo spettro delle esigenze operative [3].

Il contesto tecnologico in cui questi strumenti operano è radicalmente diverso da quello in cui le tassonomie classiche furono concepite. Le architetture moderne, data warehouse cloud con separazione tra storage e compute (Snowflake, BigQuery, Databricks), pipeline ELT, data lakehouse, hanno moltiplicato i punti in cui la qualità può degradarsi. Un'indagine condotta da Monte Carlo nel 2026 su centinaia di organizzazioni ha rilevato un rapporto medio di circa un incidente di qualità ogni 15 tabelle per anno, con il tempo medio di risoluzione (time to resolution) cresciuto del 166% rispetto all'anno precedente [4]. Il tasso di engagement degli operatori sugli alert di qualità cala del 15% quando un canale di notifica riceve più di 50 alert settimanali e di un ulteriore 20% oltre le 100 notifiche, un segnale di alert fatigue che compromette l'efficacia dei sistemi di monitoraggio [4]. L'adozione crescente di sistemi di intelligenza artificiale amplifica ulteriormente il rischio: un drift nello schema o nella distribuzione dei dati, che in passato avrebbe prodotto un report errato, può propagarsi attraverso modelli di machine learning che operano in tempo reale, moltiplicando l'impatto di un singolo errore nei dati di input [5, 18].

In risposta a questa complessità, l'ecosistema degli strumenti di data quality si è stratificato in categorie funzionali complementari. Il data profiling fornisce la conoscenza statistica di base sui dataset. Le regole di validazione, implementate in framework come Great Expectations, Soda e dbt tests, codificano le aspettative di qualità come codice eseguibile. I data contract formalizzano gli accordi tra produttori e consumatori di dati. La data observability applica al dominio dei dati i principi del monitoraggio continuo derivati dal software engineering. L'analisi che segue esamina ciascuna di queste categorie, ne confronta le architetture e ne discute i limiti in contesti di produzione.

Data profiling: la conoscenza statistica come prerequisito

Il data profiling costituisce il fondamento di qualsiasi strategia di qualità dei dati. Prima di poter definire regole di validazione o soglie di anomalia, è necessario comprendere la struttura, il contenuto e le relazioni statistiche dei dataset. Il profiling opera su tre livelli distinti di analisi, ciascuno con finalità e complessità computazionale differenti.

Il profiling a livello di colonna (column-level profiling) calcola statistiche descrittive per ciascun attributo: cardinalità, distribuzione dei valori, percentuale di valori nulli, valori minimi e massimi, deviazione standard, pattern sintattici ricorrenti e tipi di dato inferiti. Ehrlinger e Wöß hanno identificato cinque sotto-categorie di profiling, cardinalità, distribuzioni dei valori, tipi e pattern, dipendenze funzionali e profiling multi-colonna avanzato, osservando che la maggior parte degli strumenti commerciali e open-source si concentra sulle prime tre, trascurando l'analisi delle dipendenze e le correlazioni inter-attributo [3]. Questa lacuna è significativa: le dipendenze funzionali violate (ad esempio, un codice postale che non corrisponde alla provincia dichiarata) rappresentano una classe di errori invisibile al profiling a singola colonna.

Il profiling a livello di tabella (table-level profiling) esamina proprietà aggregate: conteggio delle righe, dimensione dello storage, frequenza di aggiornamento, distribuzione temporale degli inserimenti. Queste metriche sono essenziali per stabilire le baseline operative che i sistemi di monitoraggio utilizzano per rilevare anomalie volumetriche, un improvviso calo del 40% nel conteggio giornaliero delle righe può indicare un problema nella pipeline di ingestion prima che si manifesti nei report downstream.

Il profiling inter-tabella (cross-table profiling) analizza le relazioni tra dataset: integrità referenziale, sovrapposizione delle chiavi, consistenza dei valori condivisi tra tabelle correlate. Questo livello di analisi è il più costoso computazionalmente e il meno supportato dagli strumenti attuali, nonostante sia critico per identificare problemi di consistenza che il profiling isolato di singole tabelle non può rilevare.

Un approccio emergente utilizza i profili statistici non solo come output descrittivo, ma come input per la generazione automatica di test di qualità. L'idea è stata formalizzata da Schelter et al. nel sistema Deequ, presentato al VLDB 2018, che propone un'architettura per la verifica automatica della qualità dei dati su larga scala: i vincoli di qualità vengono suggeriti algoritmicamente a partire dai profili statistici dei dataset e verificati in modo incrementale ad ogni aggiornamento, riducendo il costo computazionale rispetto alla validazione completa [19]. DataKitchen TestGen applica un principio analogo: scansiona i dataset, calcola profili dettagliati e genera algoritmicamente test di validazione e anomaly detector calibrati sulla distribuzione effettiva dei dati [5]. Questo approccio, il profiling come input automatico per la generazione di test, colma parzialmente il divario tra la fase analitica e la fase di validazione attiva, che nella maggior parte delle implementazioni rimangono processi separati.

Framework di validazione: regole come codice

La validazione basata su regole rappresenta l'approccio più maturo e diffuso alla garanzia della qualità dei dati. Il principio fondamentale è la codifica delle aspettative di qualità in asserzioni eseguibili, test che restituiscono successo o fallimento, integrate nel ciclo di vita della pipeline. Tre framework dominano il panorama open-source, ciascuno con una filosofia architetturale distinta.

Great Expectations (GX Core)

Great Expectations, rilasciato come GX Core 1.0 nell'agosto 2024, è il framework open-source di validazione più diffuso, con oltre 11.000 stelle su GitHub [6]. L'architettura di GX Core 1.0 è organizzata attorno a cinque componenti principali. Il Data Context funge da punto di ingresso per l'interazione con il framework, gestendo configurazione, connessioni e stato. Le Expectations sono asserzioni dichiarative sulla forma dei dati, ad esempio, che una colonna non contenga valori nulli, che i valori rientrino in un intervallo specificato, o che la distribuzione statistica di un attributo sia compatibile con un profilo di riferimento. Le Expectations vengono raggruppate in Expectation Suites, collezioni configurabili che rappresentano il contratto di qualità per un dataset specifico. Le Validation Definitions combinano un batch di dati, una Expectation Suite e un nome, creando un'unità eseguibile di validazione. I Checkpoints orchestrano l'esecuzione di una o più Validation Definitions e attivano Actions basate sui risultati, notifiche Slack, aggiornamento di Data Docs, invio di alert [6].

La libreria fornisce oltre 300 Expectations predefinite, organizzate in categorie che coprono le principali dimensioni della qualità: completezza (valori nulli, valori mancanti), unicità (chiavi primarie duplicate), conformità (pattern, tipi, range), consistenza (integrità referenziale, relazioni tra colonne) e distribuzione (test statistici sulla forma dei dati). GX supporta connessioni native a Pandas, Spark e database SQL, consentendo l'esecuzione delle validazioni sia in fase di sviluppo sia all'interno di pipeline orchestrate [6].

Un aspetto architetturale significativo è la generazione automatica di Data Docs: documentazione HTML navigabile che registra le definizioni delle Expectations e i risultati delle validazioni, creando un audit trail persistente della qualità dei dati. Questo meccanismo risponde a un'esigenza concreta di governance: non è sufficiente eseguire test, è necessario dimostrare che i test sono stati eseguiti e documentarne i risultati nel tempo.

La potenza espressiva di GX ha un costo in complessità di setup e manutenzione. La configurazione richiede familiarità con Python e con il modello a oggetti del framework (Data Context, Data Source, Batch Request, Expectation Suite, Checkpoint). L'integrazione con orchestratori come Airflow o Dagster è supportata ma richiede codice di connessione specifico. La riscrittura dell'API nella versione 1.0 ha migliorato l'ergonomia rispetto alle versioni precedenti, ma il framework resta orientato a team con competenze Python consolidate [6].

Soda Core e SodaCL

Soda Core adotta una filosofia architetturale diversa da Great Expectations, privilegiando l'accessibilità e la velocità di configurazione rispetto all'estensibilità programmatica. Il linguaggio dichiarativo SodaCL (Soda Checks Language) consente di definire controlli di qualità in YAML con una sintassi leggibile anche da profili non strettamente ingegneristici [7]:

checks for orders:
  - row_count > 0
  - missing_count(customer_id) = 0
  - duplicate_count(order_id) = 0
  - freshness(created_at) < 6h
  - avg(amount) between 50 and 500

La sintassi di SodaCL è progettata per essere auto-documentante: ogni check è una frase leggibile che esprime un'aspettativa. Soda Core supporta oltre 50 tipi di check predefiniti che coprono conteggi, completezza, unicità, freshness, validità dei pattern, distribuzioni statistiche e confronti tra partizioni temporali [7]. L'esecuzione avviene traducendo i check in query SQL ottimizzate per il data source di destinazione, Snowflake, BigQuery, Databricks, PostgreSQL, DuckDB, SQL Server, Redshift, tra gli altri, ed eseguendole direttamente sul warehouse.

Soda Core opera come strumento CLI senza necessità di un server persistente: un singolo comando soda scan legge i file di configurazione SodaCL, si connette al database, compila i check in query SQL native, li esegue e restituisce i risultati. Questa architettura minimale lo rende particolarmente adatto all'integrazione in pipeline CI/CD e script di orchestrazione. L'anomaly detection è supportata nativamente: Soda mantiene uno storico delle metriche e rileva deviazioni significative dalla baseline senza richiedere la definizione esplicita di soglie [7].

La semplicità di SodaCL è anche il suo limite: le validazioni che richiedono logica procedurale complessa (cross-table validation con join articolati, validazioni condizionali basate su valori di runtime) sono difficili o impossibili da esprimere nel linguaggio dichiarativo. Per questi casi, Soda supporta check SQL custom, query SQL arbitrarie nel file SodaCL, ma la leggibilità e la strutturazione degradano.

dbt tests

dbt implementa un framework di testing integrato nella trasformazione dei dati, operando esclusivamente sulla fase "T" dell'ELT. A differenza di GX e Soda, che sono strumenti indipendenti dalla trasformazione, i dbt tests sono parte integrante del DAG (Directed Acyclic Graph) di trasformazione, eseguiti nello stesso contesto dei model SQL [8].

Il framework offre tre livelli di testing. I generic tests sono asserzioni parametriche dichiarate in YAML e applicate a colonne o model: unique, not_null, accepted_values e relationships sono i quattro test nativi, estensibili tramite pacchetti come dbt-utils e dbt-expectations [8, 9]. I singular tests sono query SQL personalizzate salvate nella directory tests/ del progetto: ogni query restituisce le righe che violano un'asserzione, e zero righe significa test superato. Questo consente asserzioni complesse non esprimibili con i test generici, verifiche cross-model, validazioni di business logic specifiche, controlli di coerenza temporale.

Gli unit tests, introdotti in dbt Core 1.8 nel 2024, validano la logica SQL dei model su input statici definiti in YAML, senza eseguire query sul warehouse [10]. A differenza dei data test (che verificano i dati prodotti dopo la materializzazione), gli unit test verificano la correttezza della logica di trasformazione in modo deterministico, indipendente dallo stato del warehouse. Questa capacità è particolarmente rilevante per la logica di business complessa, calcoli di margine, allocazioni, aggregazioni condizionali, dove un errore nella formula produce risultati plausibili ma errati.

I source freshness tests monitorano l'aggiornamento delle tabelle sorgente, rilevando interruzioni nella pipeline di ingestion prima che i dati stantii contaminino le trasformazioni downstream [8]. Tuttavia, l'integrazione nel DAG di trasformazione comporta un vincolo strutturale: i dbt tests operano solo sui dati gestiti da dbt. I dati che entrano nel warehouse da pipeline non-dbt restano fuori dal perimetro di validazione, richiedendo strumenti complementari.

Confronto architetturale

La scelta tra questi framework non è neutra e dipende dal contesto organizzativo e tecnico. Great Expectations offre la massima estensibilità e il catalogo più ampio di Expectations, ma richiede competenze Python e un overhead di configurazione significativo. Soda Core privilegia la velocità di adozione e la leggibilità, con una curva di apprendimento inferiore, ma con minore flessibilità per validazioni complesse. I dbt tests sono la scelta naturale per team che già utilizzano dbt per la trasformazione, ma non sostituiscono un framework di validazione general-purpose per dati fuori dal perimetro dbt.

In contesti enterprise, non è infrequente trovare i tre strumenti utilizzati in modo complementare: dbt tests per le trasformazioni, GX o Soda per la validazione dei dati in ingestion, e un layer di osservabilità per il monitoraggio continuo. Il pacchetto dbt-expectations, che porta in dbt la sintassi di Great Expectations con oltre 60 test aggiuntivi tra cui controlli di distribuzione, regex e confronto tra dataset, rappresenta un esempio concreto di convergenza tra gli approcci [9].

Data contract: qualità come accordo formale

Il concetto di data contract rappresenta un cambio di paradigma nella gestione della qualità: dalla validazione reattiva (verificare i dati dopo la produzione) alla definizione preventiva (stabilire formalmente cosa i dati devono garantire prima che vengano consumati). Un data contract è un accordo formale tra un produttore di dati e i suoi consumatori che specifica schema, semantica, qualità attesa, livelli di servizio e modalità di evoluzione di un dataset [11].

Andrew Jones, tra i principali promotori del concetto, ha formalizzato il data contract come pattern architetturale che porta i team di dati più vicini al business, favorisce l'autonomia dei team e integra qualità e governance nella piattaforma dati fin dalla progettazione [11]. L'idea non è nuova in senso assoluto, i contratti di interfaccia esistono nel software engineering da decenni sotto forma di API contract, schema registry e interface definition language, ma la sua applicazione sistematica al dominio dei dati è un fenomeno recente, catalizzato dalla diffusione del paradigma data mesh di Dehghani [12], in cui i dati sono gestiti come prodotti da team distribuiti con ownership di dominio.

Open Data Contract Standard (ODCS)

L'Open Data Contract Standard (ODCS), mantenuto dal progetto Bitol sotto la Linux Foundation (LF AI & Data Foundation), rappresenta il tentativo più strutturato di standardizzare il formato dei data contract. Rilasciato nella versione 3.1.0 nel dicembre 2025 sotto licenza Apache 2.0, ODCS definisce una struttura YAML che organizza il contratto in dieci sezioni principali: fondamentali e schema, riferimenti, qualità dei dati, supporto e comunicazione, pricing, team, ruoli, SLA, infrastruttura e proprietà custom [13]. La genesi di ODCS è radicata nel lavoro di Jean-Georges Perrin presso PayPal, che nel 2022 pubblicò un template di data contract nel contesto di un'implementazione data mesh, successivamente evoluto in standard aperto attraverso il progetto Bitol.

L'evoluzione dalla versione 2 alla versione 3 ha significativamente ampliato il supporto per le regole di qualità, consentendo di esprimere aspettative di completezza, accuratezza, freshness e consistenza direttamente nel contratto. L'adozione come standard sotto la Linux Foundation segnala la maturazione del concetto da pratica emergente a infrastruttura di governance, sebbene l'adozione su larga scala resti ancora limitata.

Implementazioni operative dei data contract

Oltre allo standard ODCS, i data contract trovano implementazione operativa in diversi strumenti dell'ecosistema.

dbt ha introdotto i model contracts come meccanismo di enforcement dello schema nei model pubblici esposti ad altri progetti attraverso dbt Mesh. Un model contract specifica nomi delle colonne, tipi di dato e vincoli di nullità; le modifiche che violano il contratto vengono bloccate in fase di compilazione, proteggendo i consumatori downstream da breaking change non coordinati [8]. A differenza di ODCS, i model contract di dbt operano esclusivamente sullo schema e non coprono dimensioni di qualità come freshness, distribuzione o SLA, una forma più limitata ma immediatamente operativa di contratto, integrata nel flusso di lavoro esistente.

Soda Core 4.0 ha integrato nativamente un data contracts engine che consente di definire contratti in YAML comprensivi di schema, regole di qualità e soglie di accettazione, verificabili programmaticamente all'interno della pipeline [14]. Questo approccio unifica il concetto di contratto con il motore di validazione, eliminando la necessità di strumenti separati per la definizione e la verifica. La convergenza tra framework di validazione e data contracts è una tendenza significativa: il contratto non è più un documento statico, ma un artefatto eseguibile verificato ad ogni esecuzione della pipeline.

Limiti operativi dei data contract

L'adozione dei data contract in contesti reali evidenzia sfide che vanno oltre la tecnologia. La definizione e manutenzione dei contratti richiede un processo organizzativo che coinvolge produttori e consumatori, un coordinamento che molte organizzazioni faticano a sostenere. Il versioning dei contratti introduce complessità nella gestione delle evoluzioni dello schema: come gestire una modifica che soddisfa le esigenze del produttore ma viola le aspettative di un consumatore? La granularità del contratto è un altro punto critico: contratti troppo stringenti bloccano l'evoluzione legittima dei dati, contratti troppo laschi non proteggono i consumatori [11]. Queste tensioni, tra rigidità e flessibilità, tra autonomia del produttore e garanzie per il consumatore, sono intrinseche al concetto stesso di contratto e non ammettono soluzioni puramente tecnologiche.

Data observability: monitoraggio continuo e rilevamento anomalie

La validazione basata su regole, per quanto rigorosa, presenta un limite strutturale: può verificare solo ciò che è stato esplicitamente codificato. Un test che controlla che il conteggio delle righe sia maggiore di zero non rileva un calo del 50% nel volume se il conteggio resta positivo. Un test di non-nullità su una colonna non rileva un cambiamento nella distribuzione dei valori che la rende inutilizzabile per un modello di machine learning. La data observability nasce per colmare questo gap, applicando al dominio dei dati i principi del monitoraggio continuo sviluppati nel software engineering per i sistemi distribuiti.

I cinque pilastri della data observability

Il termine "data observability" è stato introdotto da Barr Moses nel 2019 e formalizzato attorno a cinque pilastri che rappresentano lo stato di salute dei dati, in analogia con i segnali fondamentali (metriche, log, trace) dell'osservabilità software [4, 15]:

• Freshness: misura quanto sono aggiornati i dati. Un ritardo nell'aggiornamento di una tabella, rilevabile confrontando il timestamp dell'ultimo record con una soglia attesa, può indicare un problema nella pipeline di ingestion e produce dati stantii che compromettono le decisioni downstream.
• Volume: monitora la quantità di dati attesa rispetto ai pattern storici. Variazioni anomale, un improvviso raddoppio o dimezzamento del volume giornaliero, segnalano problemi nella sorgente o nella pipeline che i test rule-based non rilevano se la soglia assoluta è rispettata.
• Schema: rileva modifiche nella struttura formale dei dati, colonne aggiunte, rimosse, rinominate o con tipo modificato. Le modifiche di schema non coordinate sono tra le cause più frequenti di rottura delle pipeline downstream.
• Distribution: analizza la salute a livello di campo, range dei valori, percentuale di nulli, unicità, distribuzione statistica. Un campo che storicamente contiene valori tra 0 e 100 e improvvisamente presenta valori negativi indica un problema che nessun test di non-nullità o unicità rileverebbe.
• Lineage: ricostruisce automaticamente il grafo delle dipendenze tra dataset, consentendo di tracciare l'impatto di un problema a monte su tutti i consumatori a valle e di localizzare rapidamente la causa radice di un'anomalia.

Approcci architetturali

Le piattaforme di data observability si dividono in due categorie architetturali con trade-off significativamente diversi.

Le piattaforme basate su apprendimento automatico (Monte Carlo, Anomalo) si connettono al data warehouse e ai sistemi di orchestrazione, raccolgono metadati e statistiche tramite query periodiche, e applicano algoritmi di machine learning per apprendere i pattern normali di ciascun dataset e rilevare deviazioni senza richiedere la configurazione manuale di soglie [4]. Il vantaggio è la copertura automatica: una volta connessa la piattaforma, il monitoraggio si estende a tutte le tabelle senza intervento umano. I limiti sono la latenza di rilevamento (le anomalie vengono scoperte alla successiva scansione, non in tempo reale), il costo delle licenze commerciali e la necessità di un periodo di apprendimento durante il quale il sistema accumula i dati storici necessari per stabilire le baseline.

Le piattaforme basate su check dichiarativi integrati nella pipeline (Elementary, Soda con anomaly detection) eseguono monitoraggio e anomaly detection come step del DAG di orchestrazione. Elementary opera come pacchetto dbt nativo, eseguendo anomaly detection e monitoraggio direttamente all'interno del DAG dbt senza richiedere infrastruttura aggiuntiva [16]. Questo approccio garantisce che i controlli vengano eseguiti in sincrono con la pipeline e non richiede strumenti esterni, ma esige una configurazione esplicita per ogni dataset e metrica monitorata, con una copertura che dipende dalla diligenza del team nell'aggiungere i monitor.

Il concetto di data downtime

Moses, Gavish e Vorwerck hanno formalizzato il concetto di data downtime, il periodo durante il quale i dati sono parzialmente o totalmente inutilizzabili a causa di problemi di qualità, come metrica fondamentale per quantificare l'impatto della scarsa qualità [15]. Analogamente al downtime nei sistemi software, il data downtime si misura in termini di tempo medio di rilevamento (MTTD), tempo medio di risoluzione (MTTR) e impatto sul business. L'introduzione di SLA, SLI e SLO specifici per i dati, mutuati dalle pratiche SRE (Site Reliability Engineering), consente di trattare la qualità dei dati con lo stesso rigore applicato alla disponibilità dei servizi software, trasformando la qualità da preoccupazione qualitativa a metrica operativa con obiettivi misurabili.

Limiti e problemi aperti

L'ecosistema dei data quality framework, nonostante la rapida maturazione degli ultimi anni, presenta limiti strutturali e problemi aperti che meritano un'analisi critica.

Frammentazione degli strumenti. Un'organizzazione che adotta dbt per la trasformazione, Great Expectations per la validazione in ingestion, un sistema di data observability per il monitoraggio continuo e ODCS per i data contract si trova a gestire quattro strumenti distinti con linguaggi, configurazioni e modelli di metadati differenti. La mancanza di uno standard unificato per la definizione delle regole di qualità, ogni strumento ha la propria sintassi (Expectations, SodaCL, YAML dbt, ODCS), produce duplicazione delle regole e rischio di inconsistenza. Il report DataKitchen 2026 sul panorama open-source identifica oltre 50 vendor nel solo segmento data quality e observability, segnalando una frammentazione che complica la scelta e l'integrazione [5].

Scalabilità dei test basati su regole. La validazione basata su regole scala linearmente con il numero di dataset e colonne monitorate. In organizzazioni con migliaia di tabelle e decine di migliaia di colonne, la definizione e manutenzione manuale delle regole diventa un collo di bottiglia operativo. L'approccio algoritmico alla generazione dei test, partendo dai profili statistici per dedurre automaticamente le aspettative, è una direzione promettente, ma ancora limitata nella capacità di catturare regole di business complesse che richiedono conoscenza di dominio [3, 5].

Qualità dei dati per il machine learning. Le dimensioni tradizionali della qualità (completezza, accuratezza, consistenza) non coprono adeguatamente le esigenze specifiche del machine learning. Budach et al. hanno dimostrato empiricamente che l'impatto delle diverse dimensioni di qualità sulle performance dei modelli varia significativamente a seconda dell'algoritmo e del task, con effetti non lineari e talvolta controintuitivi [17]. La survey di Gupta et al. del 2024 ha identificato dimensioni aggiuntive rilevanti per il machine learning, assenza di bias, rappresentatività del campione, stabilità della distribuzione nel tempo, ed evidenziato il potenziale emergente dei large language model nell'automazione della valutazione della qualità, una direzione ancora in fase esplorativa [18].

Costo computazionale. L'esecuzione di test di qualità su data warehouse cloud comporta costi proporzionali al volume di dati scansionati. Per dataset di grandi dimensioni, una suite completa di test può rappresentare una voce di costo non trascurabile. Le strategie di mitigazione, campionamento, pre-aggregazioni, esecuzione incrementale, introducono trade-off tra copertura e costo che richiedono calibrazione specifica per ogni contesto. In warehouse con pricing pay-per-query (BigQuery), ogni check è una query fatturata; in warehouse con warehouse virtuali (Snowflake), i check competono per risorse di compute con le query analitiche.

Governance organizzativa. La tecnologia è una condizione necessaria ma non sufficiente. La qualità dei dati richiede ownership chiara (chi è responsabile della qualità di un dataset?), processi di definizione e revisione delle regole, meccanismi di escalation per le violazioni e metriche condivise di successo. I data contract forniscono un framework per formalizzare queste responsabilità, ma la loro adozione dipende da una maturità organizzativa che non può essere sostituita da uno strumento software [11, 12].

Riferimenti

[1] C. Batini et al., "Methodologies for Data Quality Assessment and Improvement," in ACM Computing Surveys, vol. 41, no. 3, 2009. https://dl.acm.org/doi/10.1145/1541880.1541883

[2] C. Batini, M. Scannapieco, Data and Information Quality: Dimensions, Principles and Techniques, Springer, 2016. https://link.springer.com/book/10.1007/978-3-319-24106-7

[3] L. Ehrlinger, W. Wöß, "A Survey of Data Quality Measurement and Monitoring Tools," in Frontiers in Big Data, vol. 5, 2022. https://www.frontiersin.org/articles/10.3389/fdata.2022.850611/full

[4] Monte Carlo, "The Annual State of Data Quality Survey, 2026," 2026. https://www.montecarlodata.com/blog-data-quality-survey

[5] DataKitchen, "The 2026 Open-Source Data Quality and Data Observability Landscape," 2026. https://datakitchen.io/the-2026-open-source-data-quality-and-data-observability-landscape/

[6] Great Expectations, "GX Core Overview," 2026. https://docs.greatexpectations.io/docs/core/introduction/gx_overview/

[7] Soda, "Write SodaCL Checks," 2026. https://docs.soda.io/soda-cl/soda-cl-overview.html

[8] dbt Labs, "dbt Documentation," 2026. https://docs.getdbt.com/

[9] Calogica, "dbt-expectations: Port of Great Expectations to dbt," 2025. https://hub.getdbt.com/calogica/dbt_expectations/latest/

[10] dbt Labs, "Unit Tests," 2024. https://docs.getdbt.com/docs/build/unit-tests

[11] A. Jones, Driving Data Quality with Data Contracts, Packt Publishing, 2023. https://data-contracts.com/

[12] Z. Dehghani, Data Mesh: Delivering Data-Driven Value at Scale, O'Reilly Media, 2022.

[13] Bitol (LF AI & Data Foundation), "Open Data Contract Standard (ODCS) v3.1.0," 2025. https://github.com/bitol-io/open-data-contract-standard

[14] Soda, "Set Up Data Contracts," 2026. https://docs.soda.io/soda/data-contracts.html

[15] B. Moses, L. Gavish, M. Vorwerck, Data Quality Fundamentals: A Practitioner's Guide to Building Trustworthy Data Pipelines, O'Reilly Media, 2022.

[16] Elementary, "Open-Source Data Observability for dbt," GitHub repository, 2026. https://github.com/elementary-data/elementary

[17] L. Budach et al., "The Effects of Data Quality on Machine Learning Performance," arXiv:2207.14529, 2022. https://arxiv.org/abs/2207.14529

[18] S. Gupta et al., "A Survey on Data Quality Dimensions and Tools for Machine Learning," arXiv:2406.19614, 2024. https://arxiv.org/abs/2406.19614

[19] S. Schelter et al., "Automating Large-Scale Data Quality Verification," in Proc. VLDB Endowment, vol. 11, no. 12, 2018. https://www.vldb.org/pvldb/vol11/p1781-schelter.pdf