L’architettura Data Lake

Cosa sono i Data Lake

Nel nostro articolo Big Data as a Service abbiamo parlato di come, in conseguenza della tendenza di crescita nella domanda di elaborazione dei Big Data, le aziende possono rivolgersi alle soluzioni Big Data as a Service (BDaaS) per colmare il divario di archiviazione ed elaborazione.

Ci occuperemo qui di definire l’architettura che, nei sistemi informativi aziendali, è deputata alla raccolta e all’utilizzo dei big data: i Data Lake.

I Data Lake sono un repository in grado di contenere grandi volumi di dati nel loro formato nativo. Nei Data Lake, costituiti da un insieme di componenti in grado di realizzare tutte le fasi del ciclo di vita dei dati, confluiscono i dati attraverso strumenti di Data Ingestion, avvengono le trasformazioni in grado di preparare i dati per le analisi e, grazie agli strumenti di Analytics, è possibile operare analisi predittive, arricchendo così la base dati.

Schema-on-read e schema-on-write

I Data Lake aggregano i dati provenienti da fonti diverse salvandoli nel loro formato originale e senza subire alcuna trasformazione tra l’acquisizione e il salvataggio. I Data Lake supportano qualsiasi formato di dati oltre all’assenza di un formato per i dati.

I dati subiscono un processo di trasformazione dal quale si ricava un formato pronto per l’elaborazione. Durante questo processo vi è l’applicazione di uno schema, ovvero di una struttura tabellare al dato. Ciò è ovviamente praticabile se i dati, già all’origine, presentano una struttura, oppure sono state attuate elaborazioni in grado di ottenerla a partire da dati non strutturati.

Il processo con cui si attribuisce uno schema al momento dell’utilizzo dei dati nei database relazionali si chiama schema-on-write. Con questo metodo non è possibile scrivere dati nel database se prima non si è definita la struttura tabellare atta a ospitarli.

Nei Data Lake si utilizza invece il metodo completamente opposto: lo schema-on-read.

Il principio dello schema-on-read è migliore dello schema-on-write in un ambiente dove ci sono grandi quantità di dati non strutturati, come i dati che rientrano nell’ambito dei Big Data.

Non solo il processo schema-on-read è più veloce del processo schema-on-write, ma ha anche la capacità di scalare rapidamente. La ragione è che il costrutto schema-on-read non utilizza modellatori di dati per modellare un database rigido. Consuma i dati mentre vengono letti ed è adatto a volumi massicci di dati non strutturati.

Al contrario, il processo schema-on-write è lento e richiede molte risorse. L’unica fattispecie in cui l’uso di questo principio ha valore è per piccole quantità di dati strutturati immutabili. Non appena i volumi di dati grezzi e non strutturati iniziano ad aumentare, il costrutto schema-on-read non è più praticabile.

I Data Lake conservano tutti i dati e ciò li differenziano dai data warehouse nei quali, invece, vengono attuate scelte che portano a ridurre, anche in misura considerevole, i dati effettivamente inclusi nelle strutture.

Vista la natura olistica dei Data Lake, è indispensabile adottare un processo di Data Governance, ossia di gestione del dato in termini di integrità, conformità alle regole del business, sicurezza ed accessibilità, per prevenire il rischio che i Data Lake diventino un assembramento disordinato di dati siffatto da rendere i dati stessi inutilizzabili.

Occorre quindi identificare precisamente i dati, i processi di ingestion e di trasformazione attraverso metadati che possano essere facilmente consultabili e ricercabili.

Il ricorso ad un motore di ricerca è quasi indispensabile per trovare i dati, siano essi grezzi o elaborati.

Pleonastico aggiungere che i Data Lake devono implementare meccanismi di sicurezza, di controllo degli accessi e di autorizzazione alla lettura dei contenuti.

Architettura Lambda

L’Architettura Lambda è un modello di implementazione di architetture Big Data con Data Lake che bilancia le problematiche in merito alla latenza, la coerenza dei dati, la scalabilità, la tolleranza ai guasti e la tolleranza agli errori umani.

Nel nostro articolo Architettura Lambda abbiamo visto come l’architettura Lambda sia un modello di implementazione per l’elaborazione dei dati utilizzata per combinare una tradizionale pipeline batch con una pipeline real-time stream per l’accesso ai dati.

L’architettura, come visto nel nostro articolo ad essa dedicato, presenta cinque principali componenti: Data Sources, Batch Layer, Serving Layer, Speed Layer e Query.

Data quality

Nei Data Lake, così come dovrebbe accadere in tutti i sistemi analitici, è rilevante l’attenzione da porre in essere in merito alla qualità dei dati.

La qualità dei dati si riferisce allo stato delle informazioni sia qualitative che quantitative. Ci sono molte definizioni di qualità dei dati, ma i dati sono generalmente considerati di alta qualità se sono adatti agli usi previsti nelle operazioni, nei processi decisionali e nella pianificazione.

Inoltre, i dati sono considerati di alta qualità se rappresentano correttamente il costrutto del mondo reale a cui si riferiscono.

Quando il numero di fonti di dati aumenta, la questione della coerenza interna dei dati diventa significativa, indipendentemente dall’idoneità all’uso per qualsiasi scopo esterno particolare.

I punti di vista delle persone sulla qualità dei dati possono spesso essere in disaccordo, anche quando si parla dello stesso set di dati usati per lo stesso scopo. Quando si verifica tale fattispecie, la Data Governance è usata per formare definizioni e standard concordati per la qualità dei dati. In questi casi, la pulizia dei dati, compresa la standardizzazione, può essere necessaria per assicurare la qualità dei dati.

A cosa servono?

Con i Data Lake è possibile realizzare una Data Management Platform (DMP) che aggrega sia i dati prodotti internamente all’organizzazione, sia i dati provenienti dall’esterno dell’organizzazione. All’interno del sistema, i dati strutturati e non, sono integrati, trasformati e analizzati, anche con algoritmi predittivi.

L’output di una Data Management Platform, costituito da analisi descrittive o predittive supporta decisioni tattiche o strategiche. Può essere utilizzato per campagne pubblicitarie, direct marketing, campagne sui social network e per definire strategie di marketing, vendita e advertising.

Dal punto di vista tecnico, una Data Management Platform può essere implementata con un’architettura Data Lake, soprattutto per le organizzazioni che devono trattare grandi volumi di dati, magari con una forte componente non strutturata.

Inoltre, le Data Management Platform supportano funzioni aziendali, come il marketing o le vendite, che tipicamente presentano esigenze complesse e variabili nel tempo, per le quali un’architettura troppo rigida potrebbe costituire una forte limitazione.

I Data Lake sono nati dalla necessità di sfruttare i big data e trarre vantaggio dai dati grezzi, granulari, strutturati e non strutturati per l’apprendimento automatico, ma c’è ancora la necessità di creare Data Warehouse per l’uso analitico da parte degli utenti aziendali.

I Data Warehouse sono stati utilizzati per molti anni nel settore sanitario, ma non hanno mai avuto un grande successo. A causa della natura non strutturata di molti dati nel settore sanitario (note mediche, dati clinici, ecc.) e la necessità di approfondimenti in tempo reale, i Data Warehouse non sono generalmente un modello ideale. I Data Lake permettono una combinazione di dati strutturati e non strutturati, che tende ad essere un modello migliore per le aziende sanitarie.

In ambito istruzione, i dati sui voti degli studenti, la frequenza e altro ancora non solo possono aiutare gli studenti in difficoltà a rimettersi in carreggiata, ma possono effettivamente aiutare a prevedere potenziali problemi prima che si verifichino. Molti di questi dati sono vasti e molto grezzi, quindi molte volte, le istituzioni nella sfera dell’istruzione beneficiano meglio della flessibilità dei Data Lake.

Nella finanza, così come in altre aree di business, un Data Warehouse è spesso il miglior modello di archiviazione perché può essere strutturato per l’accesso di tutta l’azienda piuttosto che di un data scientist. I Big Data hanno aiutato l’industria dei servizi finanziari a fare grandi passi avanti, e i Data Warehouse sono stati un grande protagonista di questi passi avanti. L’unica ragione per cui una società di servizi finanziari può essere allontanata da un tale modello è perché è più conveniente, ma non così efficace per altri scopi.

Nell’ambito dei trasporti, gran parte del vantaggio della conoscenza dei Data Lake risiede nella capacità di fare previsioni. Nel settore dei trasporti, in particolare nella gestione della catena di approvvigionamento, la capacità di previsione che proviene da dati flessibili in un Data Lake può avere enormi benefici, vale a dire benefici di taglio dei costi realizzati esaminando i dati da forme all’interno della pipeline di trasporto.

Data Lake e Data Warehouse

I Data Lake incorporano componenti che hanno una corrispondenza con quelli delle architetture di business intelligence. Nel Data Lake confluiscono infatti i dati grezzi a partire da una molteplicità di fonti, esattamente come accade nell’area di staging di un Data Warehouse. Gli strumenti di data ingestion e di elaborazione dei dati sono assimilabili alle procedure ETL (Extract, Transform, Load), mentre i dati strutturati prodotti dalle elaborazioni e conservati in formato tabellare possono essere assimilati al Data Warehouse.

Gli strumenti con cui operano i Data Lake, su moli di dati gestibili con tecnologie tradizionali, non riescono a garantire le stesse performance di un RDBMS (Relational Database Management System) o di un OLAP (On Line Analytical Processing). Diversamente, volumi importanti di dati portano a rendere poco convenienti le architetture tradizionali, in particolare dal punto di vista economico. Quindi Data Lake e Data Warehouse sono complementari.

I dati grezzi sono dati che non sono ancora stati elaborati per uno scopo. Forse la più grande differenza tra i Data Lake e i Data Warehouse è la diversa struttura dei dati grezzi rispetto a quelli elaborati. I Data Lake memorizzano principalmente dati grezzi e non elaborati, mentre i Data Warehouse memorizzano dati elaborati e raffinati.

Per questo motivo, i Data Lake richiedono tipicamente una capacità di archiviazione molto più grande dei Data Warehouse. Inoltre, i dati grezzi e non elaborati sono malleabili, possono essere analizzati rapidamente per qualsiasi scopo e sono ideali per l’apprendimento automatico. Il rischio di tali dati grezzi, tuttavia, è che i Data Lake a volte diventano paludi di dati senza un’adeguata qualità dei dati e misure di governance dei dati.

I Data Warehouse, memorizzando solo i dati elaborati, risparmiano spazio di archiviazione costoso non mantenendo dati che potrebbero non essere mai utilizzati. Inoltre, i dati elaborati possono essere facilmente compresi da un pubblico più ampio.

I dati grezzi fluiscono in un Data Lake, a volte con un uso futuro specifico in mente e a volte solo per averli a portata di mano. Questo significa che i Data Lake hanno meno organizzazione e meno filtraggio dei dati rispetto ai Data Warehouse.

I dati elaborati sono dati grezzi che sono stati destinati a un uso specifico. Poiché i Data Warehouse ospitano solo dati elaborati, tutti i dati in un Data Warehouse sono stati utilizzati per uno scopo specifico all’interno dell’organizzazione. Questo significa che lo spazio di archiviazione non viene sprecato per dati che potrebbero non essere mai utilizzati.

I Data Lake sono spesso difficili da navigare per coloro che non hanno familiarità con i dati non elaborati. I dati grezzi e non strutturati di solito richiedono un data scientist e strumenti specializzati per capirli e tradurli per qualsiasi uso aziendale specifico.

In alternativa, c’è uno slancio crescente dietro gli strumenti di preparazione dei dati che creano un accesso self-service alle informazioni memorizzate nei Data Lake.

I dati elaborati vengono utilizzati in grafici, fogli di calcolo, tabelle e altro, in modo che la maggior parte, se non tutti, i dipendenti di un’azienda possano leggerli. I dati elaborati, come quelli memorizzati nei Data Warehouse, richiedono solo che l’utente abbia familiarità con l’argomento rappresentato.

L’accessibilità e la facilità d’uso si riferiscono all’uso del repository di dati nel suo complesso, non ai dati al loro interno. L’architettura dei Data Lake non ha struttura ed è quindi facile da accedere e facile da cambiare. Inoltre, qualsiasi modifica apportata ai dati può essere fatta rapidamente poiché i Data Lake hanno pochissime limitazioni.

I Data Warehouse sono, per progettazione, più strutturati. Uno dei principali vantaggi dell’architettura dei Data Warehouse è che l’elaborazione e la struttura dei dati rende i dati stessi più facili da decifrare. Le limitazioni della struttura rendono però i Data Warehouse difficili e costosi da manipolare.

Data Lake come fonte per il Data Warehouse

I Data Lake possono fungere da collettore dei dati provenienti da fonti interne o esterne e possono esercitare una funzione di archiviazione permanente, dalla quale si alimenta il Data Warehouse tradizionale.

Insieme ai dati originali, nel Data Lake è possibile conservare i risultati intermedi di ciascuno step di trasformazione e la profondità storica degli archivi può essere molto ampia. I dati non strutturati o i dati di estremo dettaglio acquisiti e conservati nel Data Lake possono essere elaborati dando luogo a sintesi che hanno un volume molto ridotto rispetto all’originale. Si verifica quindi un processo di Data Distillation che genera dati importabili infine nel Data Warehouse.

Nei Data Lake possono essere portate a termine tutte le operazioni di trasformazione tipiche delle fasi di ETL, che sono batch oriented e che, quindi, non hanno necessità di restituire dati con bassissima latenza.

I Data Lake sono funzionali rispetto alle analisi che non possono essere portate a termine sui sistemi tradizionali, come quelle riferite ai dati non strutturati.

Data Warehouse come fonte per il Data Lake

Contrariamente a quanto descritto nel paragrafo precedente, può essere il contenuto del data warehouse a confluire nel data lake.

Ciò avviene ad esempio quando è necessario compiere integrazioni tra i dati delle due architetture.

Un ulteriore scenario di integrazione tra Data Warehouse e Data Lake è quello di configurare quest’ultimo come un’estensione del Data Warehouse. Il Data Lake può essere deputato all’archiviazione dei dati interrogati molto di rado, tipicamente molto vecchi e che sono periodicamente eliminati dal data warehouse.

Pro e contro dei Data Lake

Come abbiamo visto, i Data Lake non sono una mera alternativa ai Data Warehouse. L’adozione di un’architettura Data Lake deve essere attentamente valutata. Con riferimento alle interrogazioni che devono avere tempi di risposta brevissimi, il Data Warehouse è ancora la risposta migliore.

Osserviamo inoltre come, l’adozione di tecnologie quali Hadoop o Spark non è priva di costi, diretti ed indiretti e richiede un servizio gestito dedicato all’infrastruttura.

Inoltre, il ricorso alle professionalità necessarie, siano esse interne o esterne all’organizzaione, non è ancora così facile.

Bibliografia:

• Data Quality: The Accuracy Dimension, Olsen J.E.
• Logical analysis of numerical data, Boros E., Hammer P.L., Ibaraki T. et al.
• Il Sistema Informativo Aziendale, Camussone P.F.
• Applied Missing Data Analysis, Craig K.
• Learning Scala, Wartz J.
• Hadoop: The Definitive Guide, White T.
• Spark Cookbook, Yadav R.
• Data Mining. Metodi informatici, statistici e applicazioni, Giudici P.
• Multiple Correspondence Analysis and Related Methods, Greenacre M., Blasius J.
• Data Mining: Concepts and Techniques, Han J., Kamber M.
• Data Mining: Concepts, Models, Methods, and Algorithms, Kantardzic M.
• Learning Spark, Karau H., Konwinski A., Wendell P., Zaharia M.
• Little’s test of missing completely at random, Li C.
• Multiple Factor Analysis by Example Using R, Pagès J.
• Business Intelligence. Processi, metodi, Utilizzo in azienda, Rezzani A.
• Big data. Architettura, tecnologie e metodi per l’utilizzo di grandi basi di dati, Rezzani A.
• Advanced Analytics with Spark, Ryza S., Laserson U., Owen S., Wills J.
• Big Data Analytics: Il manuale del data scientist, Rezzani A.