Il processo di Data Science: suggerimenti per la qualità, la pulizia e l’archiviazione dei dati

Artificial Intelligence

,

Data Intelligence

Il processo di Data Science: suggerimenti per la qualità, la pulizia e l’archiviazione dei dati

Jaime Pérez Cuadrado | ago 01, 2019

Recentemente, abbiamo discusso di come inquadrare un problema nei progetti di data science (approccio ben diverso dalla tradizionale raccolta dei requisiti di BI) e del processo e degli strumenti utili per la raccolta dei dati grezzi. Ora che sappiamo come porre le domande giuste per identificare un problema aziendale e siamo stati in grado di raccogliere i dati grezzi su cui contare, è il momento di dedicarsi a un’attività fondamentale: l’elaborazione dei dati.

Al fine di esaminare i dati ad alto livello, l’ingegnere dei dati deve distinguere le fasi di manipolazione e di elaborazione degli stessi in modo da proporre l’architettura e i componenti che meglio si adattano alle esigenze di ciascuna fase.

Ma di quali fasi stiamo parlando? Per non complicarci la vita, diciamo

  • Qualità e pulizia dei dati
  • Archiviazione dei dati

L’elaborazione dei dati su cui ci concentriamo in questo articolo è propedeutica alle fasi successive del processo di scienza dei dati (vedi il primo post della serie), vale a dire Esplorazione dei dati e Analisi approfondita.

Il processo di Data Science - suggerimenti per la qualità, la pulizia e l'archiviazione dei dati

Qualità e pulizia dei dati 

I dati hanno tutta una serie di proprietà che li definiscono: tipo, formato, accesso, disponibilità, volume, natura... Ognuno di questi elementi va a influenzare la definizione dei componenti dell’architettura e dei processi di acquisizione e manipolazione dei dati.

Iniziando dai dati grezzi, che è bene conservare così come sono per salvare una «immagine digitale» delle informazioni da cui si parte, gli ingegneri dei dati avviano un’analisi di alto livello, in genere alla ricerca di errori formali come tipi di dati errati (es. mi aspettavo una data ma trovo un numero, o codici e classificazioni incoerenti, valori mancanti, ecc.) e applicano tecniche per ripulire i dati e migliorarne la qualità (es. l’interpolazione per stimare i valori mancanti).

Qui è dove teoria e pratica potrebbero scontrarsi: esiste una suddivisione netta tra i compiti di un Data Engineer e di un Data Scientist? Ciò che intendo dire è che le attività di pulizia dei dati possono essere svolte da una prospettiva puramente «formale» (vedi sopra), oppure con un occhio rivolto al problema aziendale che si vuole risolvere. Per esempio, eliminare picchi e valli in una serie di dati può essere una buona prassi nei processi di previsione, ma ci si potrebbe trovare di fronte a un caso in cui i picchi sono eventi interessanti che è bene approfondire piuttosto che scartare.

Partendo dal presupposto che un team debba disporre di entrambe le competenze (altrimenti il personale non ha le qualifiche adeguate), non è un problema grave e può essere risolto con il classico lavoro di squadra. Il nostro consiglio è di avere scienziati che tengano d’occhio e supportino le attività di qualità dei dati svolte dagli ingegneri: in fin dei conti, quattro occhi sono sempre meglio di due.    

In termini di strumenti e competenze, ci sono molte piattaforme di integrazione dati che includono caratteristiche di qualità elevata (Oracle, Informatica, IBM, Talend, solo per citare le più diffuse sul mercato) in grado di ridurre i tempi di esecuzione di determinate attività, soprattutto se finalizzate alla standardizzazione dei dati (per es. normalizzazione di nomi, indirizzi, numeri telefonici). Oltre a questo, spesso vediamo linguaggi e framework come Python, R e Scala, utilizzati per requisiti di pulizia dei dati più «esotici» e basati su condizioni. Ovviamente, le piattaforme cloud forniscono servizi a supporto delle attività di gestione dei dati in modo da poter implementare qualsiasi tipo di architettura, on-premise, full cloud e ibrida.

Archiviazione dei Dati 

Un’altra decisione importante a carico degli ingegneri dei dati riguarda il repository, cioè il luogo dove memorizzare i dati estratti, con un’ampia gamma di opzioni disponibili: file, database relazionali, database NoSQL (colonne, documenti, grafici), key-value e XML, per citare i più comuni.

Il dilemma più frequente è costituito dalla scelta tra database relazionali o NoSQL.

I database NoSQL (non relazionali) hanno il vantaggio di essere più scalabili e progettati per supportare strutture distribuite, oltre a essere generalmente più veloci, adattabili e flessibili dei database relazionali. Inoltre, avendo una struttura a documenti in cui le informazioni vengono memorizzate in una gerarchia di cartelle, i database non relazionali sono l’opzione migliore quando si tratta di memorizzare dati non strutturati come documenti, immagini, tweet e qualsiasi tipo di informazioni difficili da inserire in una struttura di tipo strettamente tabulare.

D’altra parte, i database NoSQL non sono compatibili al 100% con l’SQL standard e, in particolare, non possono garantire l’integrità assoluta dei dati (cioè il nirvana del data warehouse). Inoltre, se per le tue esigenze analitiche ti bastano i dati strutturati e non prevedi che il tuo business possa crescere in modo esponenziale, puoi tranquillamente utilizzare un DB relazionale.

Non tutte le soluzioni di apprendimento automatico necessitano di big data (wow, l’ho detto): in realtà dipende dalla natura del problema aziendale e dal tipo di dati su cui si deve lavorare di conseguenza. La buona notizia è che si può ottenere un’architettura di dati in cui i due tipi di database coesistono, sfruttando il supporto più vantaggioso a seconda dei carichi di lavoro e dei tipi di archiviazione. 

L’attuale innovazione tecnologica ci permette di sfruttare l’archiviazione distribuita (replicata), che consiste essenzialmente nel distribuire copie dei dati su server diversi, in modo da migliorare flessibilità, prestazioni e scalabilità e di risolvere i problemi in caso di crash di sistema. Tutto questo non richiede conoscenze specifiche da parte degli ingegneri dei dati, in quanto è qualcosa che viene fatto in modo trasparente dal database stesso, soprattutto se si utilizzano servizi cloud come Amazon Aurora, Google Spanner o Microsoft Cosmos DB.

Il processo di Data Science Process - Data Architecture

Scegliere l'architettura più appropriata per la propria soluzione

Una volta che abbiamo i dati, il Data Scientist può iniziare i suoi processi di analisi per raggiungere gli obiettivi proposti. Per implementare questi processi, possiamo utilizzare gli stessi linguaggi di programmazione e framework utilizzati per la generazione dei dati, o addirittura ricorrere a strumenti completi come Knime, RapidMiner, DataRobot, SAS Visual Data Mining e Machine Learning, ma concentriamoci sul nostro obiettivo originale, cioè attenerci ai dati e all’architettura di elaborazione.

Le modalità di organizzazione ed esecuzione dei processi analitici ci portano a parlare di concetti come sistemi distribuiti e sistemi paralleli, la cui differenza, in termini generali, è che un sistema parallelo può essere definito come un sistema che divide un processo in compiti eseguiti contemporaneamente, mentre il sistema distribuito divide un processo in compiti che vengono eseguiti in luoghi diversi, utilizzando risorse diverse. Conoscere la modalità di esecuzione dei processi è utile per incrementarne le possibilità tramite la scalabilità delle risorse.

I risultati dell’analisi e dell’esecuzione degli algoritmi possono essere integrati e memorizzati negli stessi sistemi da cui abbiamo ottenuto i dati di input, memorizzati nel nostro nuovo repository (potenzialmente un data lake) o addirittura in un nuovo repository analitico dedicato che permetta un modello di sfruttamento più agile e veloce.

Si raccomanda che i Data Engineer creino e mantengano un dizionario dei dati, con la definizione delle fonti, dei processi di caricamento, delle trasformazioni, dei KPI e, in generale, di tutte le informazioni che abbiamo bisogno di raccogliere, poiché può essere molto utile sia a livello di progettazione sia per sfruttare queste informazioni in analisi successive.

Ora, una volta che gli scienziati dei dati hanno individuato l’algoritmo migliore per rispondere alle esigenze di business e ottenere risultati di qualità, è tempo di porci domande sulla visibilità, l’accessibilità e l’affidabilità delle informazioni da noi prodotte. Come abbiamo detto sopra, a volte si tratta di «dove memorizzare i dati», ma sempre più spesso è questione di «come gli utenti accederanno ai dati», per cui potremmo trovarci di fronte a una varietà di scenari.

È possibile che le nuove conoscenze desunte dall’applicazione delle tecniche di Data Science vengano utilizzate per supportare il processo di analisi effettuato da team interni specializzati, ma potrebbe anche essere che le informazioni debbano essere utilizzate da applicazioni di terzi, anche transazionali (si pensi ad un algoritmo per suggerire le Next Best Offering in un processo di vendita). In questi casi, dovremo implementare meccanismi e protocolli per accedere alle informazioni con interfacce di comunicazione come le API o sviluppare meccanismi di pubblicazione utilizzando tecnologie specifiche (Apache Beam, per citarne una).

Per concludere, anche in una fase del processo di Data Science come l’elaborazione dei dati, che a prima vista potrebbe sembrare meno complessa di altre, la quantità di incroci tecnici, decisioni da prendere, opzioni di selezione e tecnologie coinvolte è talmente grande che è raro trovare tutte le competenze necessarie in una sola persona: l’ennesima conferma che la scienza dei dati è decisamente uno sport di squadra!

Risorse aggiuntive sul processo di Data Science 

Di seguito riportiamo un indice degli argomenti trattati nel corso di questa serie:

 

Vuoi Saperne di Più?

Sei pronto a sviluppare strategie guidate dai dati per le tue operazioni di business? Scopri i nostri servizi e le nostre soluzioni per la Data Intelligence

Scopri di più 

Iscriviti!