Un elenco dei 13 problemi più comuni relativi ai dati della pipeline (e alcuni esempi)

Forse la parte più complicata della gestione dei data pipeline è comprendere il fantasma nella macchina, ovvero i dati ex machina, per chiamarli così.

Come si correggono i problemi di qualità dei dati? Tutto inizia con la consapevolezza che ciò che distingue i migliori data engineer dagli altri è la loro capacità di individuare la causa principale dei problemi relativi ai dati. Chiunque può resettare la pipeline, fare spallucce e riprendere il lavoro. Pochissimi giocano a detective per arrivare al fondo del problema, anche se è proprio quello che serve.

È la differenza tra accontentarsi delle cause prossime o della causa principale. Le cause prossimali sono le cose che sembrano essere andate male, come un errore di runtime. La causa principale è quella che ha causato la causa prossimale, ed è molto più difficile da individuare. A volte le cause prossimali sono cause principali, ma raramente.

Pensa alle cause prossimali come semplici avvisi. Ti dicono che da qualche parte nella tua pipeline c'è un errore root. Puoi ignorarlo, ma a tuo rischio e pericolo, perché quel debito di dati si aggrava.

Siccome piove sempre sul bagnato, quando hai un problema, tendi ad averne molti. Di seguito sono riportate possibilità comuni di problemi di dati prossimi. Questi problemi non si escludono a vicenda e l'elenco è tutt'altro che esaustivo:

• L'orario è cambiato
• La pipeline è scaduta
• Un lavoro è rimasto bloccato in una coda
• C'è stata una trasformazione inaspettata
• Un run specifico non è andato a buon fine (o forse è fallito proprio all'inizio)
• Il run è durato insolitamente a lungo
• Si è verificato un errore a livello di sistema
• Si è verificato un errore di trasformazione
• Molti lavori sono falliti la sera prima
• C'è stata una dimensione di input anomala
• C'è stata una dimensione di output anomala
• C'è stato un tempo di esecuzione anomalo
• Un compito si è bloccato inaspettatamente
• Si è verificato un errore di tempo di esecuzione

Ma non è tutto, vero? Ancora una volta, non considerarli come problemi, ma come segnali. Ecco tutte le cose che possono andare storte e che indicano che è accaduto qualcosa di più preoccupante. Molte appariranno contemporaneamente.
Una piattaforma di observability può essere molto utile per fare una cernita. Ti consentirà di raggruppare i problemi concomitanti per dargli un senso.

Può anche raggruppare i problemi in base alla dimensione della qualità dei dati a cui si aggregano, ad esempio fitness, lineage, governance o stabilità. Raggruppando i problemi dei dati in questo modo, si possono individuare le dimensioni lungo le quali si riscontrano i maggiori problemi, e si possono contestualizzare quelli che sembrano problemi isolati.

E naturalmente non è necessario aspettare che un lavoro fallisca per provarci. Databand ti consente di analizzare retroattivamente le anomalie (poiché acquisisce tutti i metadati storici) in modo da poter chiarire cosa è casuale e cosa è semplicemente correlato.

È così che puoi individuare un problema come il blocco di un'attività tra una dozzina di errori, e testare su molti problemi che la causa principale è probabilmente un guasto nel provisioning del cluster. Ed è così che dovresti vederlo. Cerca sempre la causa principale del problema con i dati.

Le cause principali sono la fine del percorso. Dovrebbero essere l'evento originale nella linea di causalità, il primo domino, per così dire, e soprattutto spiegare il problema. Se la causa principale del problema con i dati non si verifica, non dovrebbe farlo nemmeno una delle cause prossimali. È direttamente causale per tutti loro.

Le cause principali, ovviamente, non sono sempre chiare e le correlazioni non sono sempre esatte. Se non ti senti sicuro della tua risposta, un modo probabilistico per scoprire il tuo vero punteggio di fiducia è provare questo esperimento mentale: supponiamo che il tuo capo ti dica che il tuo team punterà tutto sulla tua ipotesi e che nessuno la verificherà prima che entri in produzione, e che il tuo nome sarà ovunque. Se è sbagliato, è tutta colpa tua. Da 0 a 100, quale punteggio di sicurezza assegneresti alla tua ipotesi? Se è inferiore a 70, continua a indagare.

Le cause principali comuni dei problemi relativi ai dati includono:

1. Errore dell'utente: iniziamo con gli errori dell'utente perché sono comuni. Forse qualcuno ha inserito uno schema sbagliato o un valore sbagliato, il che significa che la pipeline non legge i dati, oppure ha fatto la cosa giusta con valori sbagliati, e ora si è verificato un fallimento dell'attività.

2. Dati etichettati in modo errato: a volte le righe si spostano su una tabella e le etichette giuste vengono applicate alle colonne sbagliate.

3. Il partner di dati ha saltato una consegna: anche questo è molto comune. Si può costruire un sistema a prova di proiettile, ma non si può controllare ciò che non si può vedere e se i problemi dei dati si trovano nei dati di origine, questo causerà un comportamento errato di pipeline perfettamente valide.

4. C'è un bug nel codice: è comune quando c'è una nuova versione della pipeline. È possibile scoprirlo abbastanza rapidamente con software di versioning come Git o GitLab. Confronta il codice di produzione con una versione precedente ed esegui un test con quella versione precedente.

5. Errore dei dati OCR: il tuo scanner ottico legge i dati in modo errato, portando a valori strani (o mancanti).

6. Problema di dati obsoleti: il set di dati è talmente datato da non essere più valido.

7. Problema di dati duplicati: spesso un fornitore non è stato in grado di consegnare i dati e quindi la pipeline ha eseguito i dati della settimana precedente.

8. Problema di autorizzazione: la pipeline è fallita perché il sistema non aveva l'autorizzazione a prelevare i dati o a eseguire una trasformazione.

9. Errore di infrastruttura: forse hai raggiunto il limite di memoria o chiamate API disponibili, il cluster Apache Spark non è stato eseguito, o il tuo data warehouse è insolitamente lento, causando l'esecuzione senza i dati.

10. Modifiche alla pianificazione: qualcuno (o qualcosa) ha modificato la pianificazione e questo ha causato il mancato funzionamento o la mancata esecuzione della pipeline.

11. Set di dati distorti: molto difficile da risolvere. Non esiste un modo efficace per scoprirlo, se non eseguendo alcuni test per verificare se i dati sono anomali rispetto a un set di dati reale simile, oppure scoprendo come sono stati raccolti o generati.

12. Guasto dell'orchestratore: il tuo pianificatore della pipeline non ha pianificato o eseguito il lavoro.

13. Fantasma nella macchina (dati ex machina): è impossibile da prevedere. È difficile ammetterlo, ma per alcune cose è vero. La cosa migliore che puoi fare è documentare ed essere pronto per la prossima volta, quando potrai raccogliere più dati e iniziare a tracciare correlazioni.

E poi, ovviamente, c'è la realtà in cui la causa principale non è del tutto chiara. Molte cose sono correlate e probabilmente interdipendenti, ma non esiste una risposta univoca e, dopo aver apportato le modifiche, hai risolto il problema dei dati, anche se non sei sicuro del perché.

In questi casi, come in qualsiasi altro, annota la tua ipotesi nel registro e, quando puoi, continua a testare i dati storici e stai attento a nuovi problemi e cause più esplicative.

La caratteristica che più separa l'ingegnere dei dati dilettante dall'esperto è la sua capacità di individuare le cause principali e il suo comfort con risposte ambigue. Le cause prossimali a volte sono cause principali, ma non sempre. Le cause principali a volte sono correlate a cause prossimali specifiche, ma non sempre. A volte non è possibile distinguere tra un errore umano e un errore dei dati.

I grandi ingegneri dei dati sanno che le loro pipeline sono volubili e talvolta hanno personalità. Ma sono in sintonia con essi, hanno gli strumenti per misurarli e sono sempre alla ricerca di una spiegazione più affidabile.

Scopri come IBM Databand fornisce il monitoraggio delle pipeline di dati per rilevare rapidamente gli incidenti relativi ai dati, come esecuzioni e lavori non andati a buon fine, in modo da poter gestire la crescita della pipeline. Se desideri approfondire ulteriormente l'argomento, prenota subito una demo.