Per decenni, la qualità dei dati è stata gestita con un approccio reattivo: test manuali, controlli schedulati, validazioni a valle della pipeline. Un modello che funzionava quando i dati risiedevano in database centralizzati e i processi ETL erano relativamente semplici e controllabili. Ma il panorama è cambiato radicalmente. Le moderne architetture distribuite come i Data Lake o i Data Lake House, hanno introdotto una complessità esponenziale con evidenti ricadute. Già nel 2023 l’indagine “State of Data Quality”, realizzata da Wakefield Research, confermava che erano aumentati sia gli incidenti legati alla qualità dei dati che i tempi medi della loro risoluzione, il cosiddetto Mean Time to Recovery (MTTR).
Il gap temporale tra l’insorgenza del problema e la sua scoperta è il vero tallone d’Achille. Le pipeline moderne elaborano dati in tempo reale o near-real-time, ma i controlli di qualità rimangono spesso schedulati una volta al giorno o alla settimana. A ciò si aggiunge il limite dei test manuali: a parte assorbire tempo prezioso, coprono soprattutto scenari noti, lasciando vulnerabili le organizzazioni rispetto ad anomalie impreviste.
Il risultato? Il Data Downtime – ovvero il tempo in cui i dati sono inaccurati, incompleti o non disponibili – cresce. E per le organizzazioni, per cui ormai l’accuratezza e la velocità nella presa di decisione sono strategiche, questo è un grande problema.
Il monitoraggio continuo come nuova frontiera
Questo handicap rende necessario adottare la cosiddetta Data Observability, una pratica di monitoraggio, gestione e manutenzione continua dei dati che tocca – grazie a vere e proprie piattaforme di Data Observability o sistemi di Data Quality evoluti integrati nei Data Stack – in modo automatico e costante cinque aspetti principali:
- Freshness: viene controllato se i dati vengono aggiornati secondo la frequenza attesa. Ad esempio, se una tabella dovrebbe ricevere nuovi dati ogni ora ma l’ultimo aggiornamento risale a tre ore prima, questo segnala anomalie, per esempio nelle pipeline di ingestion;
- Volume: si monitora se la quantità di record processati rientra nei range normali attesi. Ad esempio, se una tabella riceve solitamente 10.000 righe al giorno ma improvvisamente ne arrivano solo 100 o 50.000, ciò può indicare problemi nei sistemi upstream o duplicazioni di dati;
- Structure: in questo caso il monitoraggio si concentra sulla coerenza strutturale dei dati rispetto alle aspettative. Ad esempio, se un campo viene eliminato, rinominato o il suo tipo di dato viene modificato, questo segnala una devianza che può derivare da problemi di compatibilità o errori nelle trasformazioni;
- Lineage: viene tracciato il percorso completo dei dati attraverso i vari sistemi e trasformazioni. Questa visibilità sulle correlazioni può indicare quali asset downstream saranno compromessi da un problema, facilitando l’analisi d’impatto e la risoluzione prioritaria degli incidenti;
- Distribution: in questo caso si verifica se i valori nei dati seguono i pattern statistici attesi. Ad esempio, se il 95% degli ordini ha valori tra 50-200€ ma compaiono improvvisamente molti ordini da 0€, questo segnala anomalie. Queste deviazioni possono indicare problemi nelle integrazioni tra sistemi o dati corrotti che necessitano investigazione.
Rispetto alla Data Quality tradizionale, nella Data Observability non si conferma quindi se i dati rispettano certe regole, ma si analizza e valuta la salute dell’intero ecosistema dati in tempo reale.
Un cambio di prospettiva di cui molte organizzazioni stanno comprendendo la necessità tanto che Gartner stima che già nel 2026 il 50% delle aziende che detengono architetture di dati distribuite, adotteranno strumenti di Data Observability.
I benefici tangibili
La crescita di queste soluzioni è sostenuta dai benefici di questa pratica, per cominciare sul fronte della velocità nel Mean Time to Recovery (MTTR) che in alcuni casi può passare da ore a minuti, con un impatto diretto sulla continuità operativa e sulla reputazione.
La fiducia nei dati è un ulteriore vantaggio, anche se più difficile da quantificare. Non da ultimo, il risparmio di costi. A prima vista, aggiungere un layer di Data Observability è una spesa aggiuntiva ma prevenire è più economico che curare. Un incidente di dati costa molto di più – in termini di blocco dell’operatività, fiducia e rework – di quanto serve per implementare un monitoraggio proattivo.
Un esempio? Recentemente un incidente dati ha causato la cancellazione di oltre 2.000 voli nel Regno Unito e Irlanda, con perdite stimate in oltre 126 milioni di dollari per le compagnie aeree. Questo non è un caso isolato, è la punta dell’iceberg di un problema sistemico che le soluzioni di Data Observability sono progettate a prevenire.
Le sfide dell’adozione
Ovviamente, implementare la Data Observability non è semplice. Le sfide sono significative e quindi vanno tenute in attenta considerazione. La prima riguarda la complessità tecnologica all’interno delle aziende. La proliferazione e frammentazione di tecnologie, repository, etc. richiedono una scelta accurata del tool da adottare e un’integrazione molto attenta nell’infrastruttura esistente.
A questo si aggiunge il rischio di generare troppi alert, rendendo difficile distinguere problemi reali da falsi positivi e quindi congestionando e non aiutando il team data/IT, ma superabile partendo con ambiti limitati e affinando progressivamente le soglie.
Tuttavia ancora più insidiosa è la sfida culturale, che richiede un cambio di mentalità da un approccio reattivo a uno proattivo: non basta acquistare una soluzione di Data Observability, servono nuove competenze che combinino Data Engineering a una comprensione del business; e ciò richiede investimenti in formazione fino a nuove assunzioni. Aspetti che possono condizionare negativamente un’evoluzione invece sempre più strategica.
A cura di Mirko Gubian, Global Demand Senior Manager & Partner di Axiante
