Il miglior framework di qualità dei dati per gli ingegneri di piattaforma senior

Ecco perché qualsiasi organizzazione che consideri i dati importanti per il funzionamento della propria attività, sia interna che esterna, deve praticare la gestione della qualità dei dati e implementare un framework di qualità dei dati. Il che significa: sviluppare processi e modelli ripetibili e idealmente automatici per garantire che i dati che entrano nel tuo sistema e vengono trasmessi a valle siano quelli che tu e i tuoi clienti vi aspettate.

E come voi ingegneri dei dati senior ben sapete, comprendere queste aspettative significa essere solo a metà dell'opera. Gran parte dell'altra metà viene spesa per tradurre tali aspettative in monitoraggio e avvisi che ti aiuteranno a trovare e risolvere i problemi nei complicati processi di inserimento.

In questa guida, condivideremo le strategie per garantire che la gestione della qualità dei dati non sia semplicemente sovrapposta ai processi hard-coded esistenti, ma sia integrata in ogni DAG. Per gestirla bene, è necessario rilevare le anomalie molto prima che i dati di bassa qualità entrino nel livello di trasformazione.

Cominciamo con una definizione. Il framework per la qualità dei dati è uno strumento che un'organizzazione può utilizzare per definire gli attributi di qualità dei dati pertinenti e fornire indicazioni per un processo di gestione della qualità dei dati volto a garantire che quest'ultima continuamente le aspettative dei consumatori (SLA).

Questa frase è ingannevolmente complessa, per cui cerchiamo di analizzarla nel dettaglio:

1. Hai bisogno di un processo: a meno che tu non disponga di ore di lavoro illimitate per gli ingegneri, un processo dovrebbe includere test unitari ripetibili e idealmente automatici in ogni fase della pipeline di dati (soprattutto al momento dell'acquisizione se si desidera rilevare i problemi in modo proattivo) e un flusso di lavoro per la gestione dei problemi relativi ai dati.
2. Devi garantire continuamente: la qualità dei dati decade in proporzione alla velocità dei dati, nota anche come deriva dei dati. I dati ad alta velocità, come quelli che molti di noi trattano oggi, richiedono controlli frequenti.
3. È necessario soddisfare le aspettative dei consumatori, non le proprie: la qualità dei dati è fondamentalmente un processo aziendale. I tuoi SLA o "accordi di servizio" sui dati sono stipulati con i consumatori e nulla di ciò che riguarda il lato ingegneristico conta se i data scientist non possono eseguire i loro modelli, se i clienti ricevono stime di consegna imprecise o se il tuo vicepresidente regionale deve andare alla riunione del consiglio di amministrazione a mani vuote perché la dashboard non si è caricata.

C'è molto da fare per mantenere la promessa di cui sopra e ognuno di questi elementi è pieno di dipendenze. Ad esempio, se dovessi chiederti come progettare un sistema del genere, ti porresti le seguenti domande:

1. In che modo riuscirai a comprendere le aspettative dei consumatori sulla qualità dei dati?
2. In che modo tradurrai queste aspettative in misure quantificabili della qualità dei dati?
3. In che modo implementerai misure automatiche di qualità per ciascuna delle tue pipeline?
4. In che modo determinerai le soglie per ciascuna dimensione della qualità dei dati?
5. In che modo avviserai il tuo team quando i dati violano tali soglie?
6. Cosa farà il tuo team quando riceve un avviso?
7. Come giudicheranno la validità e l'urgenza dell'avviso?
8. Se c'è un problema, come identificheranno la causa o le cause secondarie?
9. Come identificheranno le cause principali?
10. In che modo faranno sapere ai consumatori cosa aspettarsi?
11. Come affronteranno la causa principale?
12. Come verificheranno di aver affrontato la causa principale?
13. Come documenteranno ciò che è accaduto per contribuire al know-how?

Ti sembra un elenco lungo e con molti passaggi? Niente paura. Puoi delegare.

La domanda 1 è più adatta all'analista aziendale del tuo gruppo o del tuo team. Spetta a loro parlare con le unità aziendali per scomporre le storie degli utenti, le preferenze dichiarate, le preferenze implicite, le richieste e i post-mortem degli eventi in un elenco di "richieste" per i dati. Queste sono le aspettative qualitative che i consumatori hanno nei confronti dei dati e si tratta di una conversazione un po' bidirezionale, perché potrebbero non avere le parole per descrivere esattamente ciò che vogliono. (A meno che i consumatori di dati non siano i tuoi data scientist, il che accelererebbe di molto questo processo.)

Alla domanda 2 devi rispondere insieme ai tuoi data scientist (soprattutto se sono anche i consumatori). Date le caratteristiche dei tuoi dati per ogni pipeline, quali attributi puoi effettivamente misurare per scomporre ulteriormente l'elenco delle aspettative qualitative in un elenco di misurazioni quantitative?

A seconda del modello di qualità dei dati seguito, ci sono quattro o cinque dimensioni di qualità da considerare. In IBM Databand, preferiamo un modello con quattro caratteristiche:

• Idoneità
  • Accuratezza: i dati riflettono la realtà
  • Integrità: qualità/tempo
• Lineage
  • Fonte: il fornitore soddisfa le tue aspettative?
  • Origine: da dove viene?
• Governance
  • Controlli sui dati
  • Riservatezza dei dati
  • Normative
  • Protezione
• Stabilità
  • Consistenza
  • Affidabilità
  • Tempestività
  • Distorsione

Con queste metriche in mano, gli ingegneri dei dati possono affrontare le domande 3-13 e iniziare a costruire una strategia di gestione della qualità dei dati. E prima di capire esattamente come farlo, vale la pena chiedersi: perché fare tutto questo sforzo?

Alcuni anni fa, un'innocua modifica della configurazione di Microsoft Dynamics CRM di un importante rivenditore ha fatto sì che il numero di inventario visualizzato su ogni articolo online smettesse di riflettere la realtà. Il contatore ha semplicemente smesso di aggiornarsi.

La gente ha continuato ad acquistare, ma il volume è rimasto costante. Quando il team di ingegneria dei dati è stato avvisato, le cose si erano ormai messe male.

La maggior parte degli articoli era disponibile per l'acquisto online, ma anche per il ritiro in negozio. Molte persone hanno scelto il ritiro in negozio. Gli ordini sono stati elaborati e gli articoli che non esistevano sono stati comunque venduti. Quindi i consumatori si sono recati nei negozi, dove gli addetti alla vendita al dettaglio si affannavano a trovare prodotti sostitutivi o a promettere sconti o a tranquillizzarli in qualche modo. Si sono formate delle code. I visitatori dei negozi hanno dovuto aspettare per effettuare i loro acquisti e sono stati scoraggiati da così tante persone che si agitavano con rabbia sui loro telefoni. E poiché ci sono voluti giorni per scoprire il problema e per riparare la pipeline, c'è voluto dell'altro tempo prima che la situazione si risolvesse.

Tenendo conto della perdita di reputazione del marchio, l'errore è costato decine di milioni e non sarebbe dovuto accadere.

Tutto questo per dire che i problemi relativi ai dati si aggravano. Possono essere difficili da individuare e affrontare e, di conseguenza, crescere inosservati. È facile cadere nella convinzione che tutto funzioni solo perché si continuano a ricavare alcuni insight, anche se si sta accumulando una quantità crescente di debiti di dati sotterranei.

Inoltre, i segnali più veritieri di problemi di qualità dei dati tendono a essere indicatori in ritardo. Ad esempio, i consumatori che ti avvisano. O, come nell'esempio precedente del CRM per la vendita al dettaglio, migliaia di manager e vicepresidenti regionali che ti avvisano. E questo non va bene. Significa che i dati sono nel tuo sistema da tempo e che ci vorranno giorni prima che una correzione produca risultati. Si tratta di non soddisfare le aspettative dei consumatori.

Questa è la situazione in cui si è trovata la startup di spedizioni Shipper e il motivo per cui hanno investito così tanto per evitare che si verificasse. Il loro team di ingegneria dei dati fornisce dati il più possibile in tempo reale a un'applicazione che aiuta i fornitori di e-commerce a consegnare il loro inventario a un porto di spedizione. Non devono preoccuparsi solo delle aspettative dei loro consumatori, ma anche di quelle dei consumatori dei loro consumatori. E quando il loro sistema, a volte, non era aggiornato da due giorni, si creava un'ondata di aspettative mancate. Per questo motivo, hanno investito molto nella gestione della qualità dei dati e in strumenti in grado di fornire avvisi tempestivi con controlli automatici.

La gestione della qualità dei dati è un modo per rendere automatici e pervasivi i controlli sulla qualità dei dati, in modo da combattere le forze dell'entropia sui set di dati e sulle pipeline con una forza uguale e contraria.

Torniamo al nostro esempio precedente e all'elenco di domande. I tuoi analisti parlano con l'azienda per raccogliere i requisiti e tu riceve un elenco di aspettative quantitative dei consumatori dai tuoi data scientist. Come si fa quindi a procedere e a costruire il sistema?

Disegna il tuo framework di qualità dei dati. Il tuo framework dovrebbe innanzitutto riconoscere che il sistema è un ciclo e tutto ciò che impari sulle aspettative dei consumatori, che sono in continua evoluzione, dovrebbe influenzare il sistema.

Esploriamo ciascuna di queste fasi:

1. Qualificare: gli analisti aziendali scompongono le esigenze dei consumatori in un elenco di requisiti.
2. Quantificare: i data scientist scompongono i requisiti in misure quantificabili della qualità dei dati, che a questo punto sono ancora solo teoriche.
3. Pianificare: gli ingegneri dei dati traducono le misure quantitative della qualità dei dati in controlli che possono eseguire nella loro piattaforma di osservabilità della pipeline di dati. Una piattaforma del genere è fondamentale: i sistemi di pianificazione del flusso di lavoro e delle pipeline come Airflow e Spark possono rilevare problemi con una pipeline, ma non all'interno dei dati, che è il punto in cui si presentano la maggior parte dei problemi. I tuoi ingegneri dovranno capire cosa può e cosa non può essere tracciato nel tuo sistema.
4. Implementare: gli ingegneri dei dati implementano il tracciamento e lo testano. Per fare un esempio molto semplice, se i dati devono essere tutti presenti e non devono mancare campi o colonne, si può impostare un avviso sui parametri di completezza dei dati. Una piattaforma di osservabilità come Databand lo rende possibile e può permetterle di impostare il rilevamento delle anomalie, in modo da non dover impostare manualmente ogni valore.
5. Gestire: gli ingegneri dei dati eseguono un backtest di questi avvisi rispetto ai dati storici della pipeline per verificare che abbiano effettivamente funzionato come previsto. In caso affermativo, li mettono in produzione insieme a un piano di gestione degli incidenti che stabilisce chi è responsabile dell'attivazione di un avviso e cosa farà quando lo riceverà.
6. Verificare: gli ingegneri dei dati e i data scientist confermano che la presenza del framework di gestione dei dati ha migliorato in modo misurabile le prestazioni lungo le metriche desiderate. Gli analisti aziendali confermano ai consumatori che è davvero così.

E tu cosa fai con il tuo framework? Lo metti in pratica.

Come abbiamo esplorato in molti dei nostri esempi, l'indicatore peggiore di un problema di qualità dei dati è un indicatore in ritardo, ad esempio quando un consumatore ti dice che qualcosa non funziona. Gran parte di ciò che facciamo nell'ingegneria dei dati è creare fiducia insieme alle pipeline.

Investendo in un framework di gestione della qualità dei dati che aiuta il tuo team a identificare automaticamente i problemi, creerai dati di cui vale la pena fidarsi. E questo rende il tuo lavoro molto più semplice.

Scopri come IBM Databand offre un migliore monitoraggio della qualità dei dati rilevando modifiche impreviste alle colonne e record nulli per aiutarti a rispettare gli SLA sui dati. Se desideri approfondire ulteriormente l'argomento, prenota subito una demo.