Una data pipeline è un flusso organizzato di dati che, da una sorgente attraversa diverse fasi di consolidamento e strutturazione per arrivare poi a chi quei dati dovrà utilizzarli per applicazioni.

La società odierna è pervasa da grandi flussi di dati e tali dati svolgono dei percorsi, partendo da una sorgente e raggiungendo una destinazione. Tipicamente, passano da chi li produce a punti di raccolta, per poi arrivare a chi li archivia, li usa e li analizza.

Il meccanismo che al giorno d’oggi si occupa di guidare questo percorso prende il nome di data pipeline ed è il tema chiave del settore della Data Engineering, quella branca dell’Informatica che crea dataset e li mette a disposizione di utenti e applicazioni.

In questo articolo, esploreremo i vari contesti che possono vedere la creazione di una data pipeline e quali approcci possono essere adottati. La nostra trattazione non prenderà una piega tecnica ma per lo più metodologica cercando di comprendere da quali riflessioni è necessario partire e quali domande bisogna porsi per realizzare la propria data pipeline.

Iniziamo a progettare una Data Pipeline

Una Data Pipeline è una sorta di “condotto”  (come suggerisce il suo stesso nome) tra chi produce i dati e chi ne ha bisogno. Molto spesso chi produce i dati (pensiamo a utenti di applicazioni mobile, videogiocatori o componenti elettroniche come i sensori) ignora l’esistenza della pipeline e pertanto in genere non tiene conto di eventuali requisiti in termini di prestazioni, affidabilità o interattività.

Requisiti che invece possono essere importanti per chi dovrà analizzare e utilizzare i dati che da questa saranno veicolati. Possiamo immaginare che, a seconda della dimensione del processo e dell’entità dei dati, l’amministratore della data pipeline possa essere uno stesso data analyst, un progettista di un applicativo on line o un Data Engineer appositamente dedicato.

Le fasi in cui una data pipeline si articola sono, sintetizzando:

  • Raccolta di dati
  • Trattamento iniziale dei dati
  • Immagazzinamento
  • Condivisione con i vari data analyst

Raccolta dei dati

Nella prima parte, i dati vengono prodotti da esseri umani e applicazioni in maniera quasi involontaria. Noi stessi utilizzando app o fruendo di contenuti in streaming, o anche solo passando da una porta automatica in un centro commerciale, produciamo molti di questi dati senza volerlo.

Tali informazioni – in tempo reale o con upload periodici – vengono caricati verso le loro destinazioni di stoccaggio. Considerando che queste ultime si trovano tipicamente su server o, ormai sempre più frequentemente, su strutture in Cloud, i dati prodotti dalla sorgente viaggeranno via rete.

In quest’ultimo caso, possiamo immaginare un loro caricamento mediante API REST offerte dalla controparte server o un upload più massiccio, per esempio via protocollo FTP o con strumenti crittografati come scp.

Fin qui, pertanto, l’impostazione della pipeline è piuttosto a discrezione di chi produce l’applicazione che genera i dati. Si tratta per ora di applicazioni che svolgono un ruolo di client e quindi non devono affrontare nessuna particolare problematica.

La vera battaglia si conduce negli approcci scelti per lo stoccaggio di queste informazioni.

Immagazzinare i dati

Nella progettazione di una data pipeline, i settori su cui genericamente dobbiamo sicuramente concentrarci sono i formati dei dati e le tecnologie di immagazzinamento.

Mentre l’applicazione client che genera i dati può produrli nel formato che preferisce, dopo il loro upload, al momento di immagazzinarli, può essere necessario trattarli, pulirli e trasformarli in un nuovo formato per agevolarne la memorizzazione.

Quale utilizzare dipenderà da vari fattori ma, in primis, dall’eventuale struttura interna che i dati hanno: si tratta di testo, numeri, immagini, file audio? Sono stati raccolti con precisi legami temporali o logici tra loro o la loro accumulazione è piuttosto casuale?

Inoltre, come desideriamo salvarli? Anche questo è un fattore molto importante. Al giorno d’oggi, se vogliamo provare a riassumere al massimo gli approcci comuni di memorizzazione di dati, possiamo eleggerne due: database e Data Lake.

Il primo offre ottime potenzialità ed è spesso più utilizzato perché fa parte da decenni della cultura informatica. Il problema è che dovremo adattare i dati caricati e i loro formati a quelle che sono le regole del database. Se si tratta di un database relazionale dovremo assoggettare i dati allo schema del database, nel caso invece di un database NoSQL potremmo essere più liberi da questo punto di vista ma pur sempre obbligati a convertire i dati in strutture chiave/valore, documenti o qualsiasi sia l’unità su cui la tecnologia scelta si basa.

L’approccio del Data Lake è sicuramente più in sintonia con il mondo del Cloud. Si tratta essenzialmente di accumulare i dati caricati su spazi di memorizzazione a oggetti in Cloud come S3 di AWS, tanto per fare un esempio piuttosto noto. Cosa significa “storage a oggetti”? Che il sistema non ragiona a blocchi di byte come un hard disk, pensa per lo più a caricare file di dati come oggetti unici, immagazzinarli in maniera sicura e ridondata e a offrire la massima scalabilità come dimensioni di spazio.

Un approccio di quest’ultimo tipo viene spesso scelto perché facilmente disponibile in Cloud e permette la massima libertà possibile in tema di dimensioni di file e formati permettendo di rimandare  tutte le scelte e le trasformazioni al momento della loro reale necessità.

Indipendentemente dall’approccio scelto – si tratti di database, Data Lake o altro ancora – si arriva ora  a una delle parti più delicate: i dati devono essere messi a disposizione di chi dovrà utilizzarli.

Condivisione con i data analyst

Spesso le data pipeline sono finalizzate a offrire dati per l’analisi a chi dovrà effettuare previsioni, monitoraggi di sistemi o valutazioni varie.

Anche in questo caso si potrà optare per varie soluzioni come tecnologie per Big Data tipo Spark e Hadoop o Data Warehouse. I fattori da prendere in considerazione per queste casistiche sono diversi.

Anche qui è importante il formato dei dati. Molti Data Warehouse sono relazionali pertanto richiederanno di caricare i dati nelle proprie strutture interne cosa che, a volte, sarà più agevole se come approccio per lo stoccaggio si è scelto un database. I Data Warehouse sono però strumenti che, a livello di interfaccia di interrogazione, ricordano molto i database pertanto appaiono molto più amichevoli a chi, per esempio, non è un informatico puro.

D’altro canto tecnologie come Spark e Hadoop sono estremamente generiche e permettono di lavorare con dati più o meno strutturati e in formati di vario tipo dai classici JSON e CSV o quelli nati per i Big Data come i file Parquet.

Anche le tempistiche influiscono molto sulla scelta delle tecnologie. Sia per quanto riguarda il flusso di dati generato dai client, sia per quanto riguarda l’accesso ai dati di chi dovrà analizzarli. Più questi sono prodotti di continuo più sarà necessario  un meccanismo di ingestion scalabile che all’aumentare del flusso (dovuto per esempio a un picco di eventi) sarà in grado di ricevere dati senza doverne scartare.

Una volta che i dati saranno stati inseriti all’interno del sistema, supponiamo un Data Lake, tutti o una parte dovranno essere disponibili per i data analyst.

A volte può capitare che serva eseguire operazioni di massa che coinvolgano tutti i dati, altre volte sarà necessario condurre dei monitoraggi solo sui dati più recenti per esempio per tenere d’occhio l’andamento di un fenomeno in corso.

Nel primo di questi due casi, si potranno svolgere operazioni di ETL (Extract, Transform, Load) con strumenti come Hadoop o Spark agendo direttamente su grandi file disposti all’interno del Data Lake. Nel secondo caso serviranno strumenti più agili, che non richiedano necessariamente l’abilità di programmare ma che siano controllabili tramite un linguaggio di interrogazione come SQL e magari con capacità di visualizzazione grafica. In questi ultimi casi, si potrà per esempio agire con un Data Warehouse o un qualcosa più simile a un database con i dati più recenti caricati all’interno.

Conclusioni

Uno dei tratti salienti della tematica delle data pipeline, come si è visto, è l’assoluta varietà delle impostazioni che possiamo associarle. Le finalità sono chiare – trasportare dati da chi li genera a chi li utilizza – ma i possibili percorsi e aspetti di ciò saranno dei più variegati. Tutto dipenderà dalle nostre esigenze, dall’utenza e soprattutto dall’evoluzione di un servizio: sempre meglio impostazioni elastiche che permettano alle nostre pipeline di reggere volumi sempre più ampi di dati che è ciò che chiunque si augurerebbe per il proprio business!