Quando si parla di “Big Data Revolution“, la dimensione e la velocità delle informazioni con cui aziende e organizzazioni hanno a che fare sono senza dubbio gli aspetti in primo piano. Tuttavia, un fattore importante, spesso sottovalutato, è la frequenza con la quale nuove informazioni, generate internamente o provenienti dall’esterno, entrano in contatto con le organizzazioni e ne ampliano il patrimonio informativo.
Decidere se queste nuove informazioni siano rilevanti o meno è uno step cruciale e altrettanto complesso. Si tratta infatti di un processo spesso destrutturato, difficile da individuare e isolare, oltre che molto costoso in termini di tempo ed energie per i Data Analyst e, talvolta, per i Data Scientist.
Proviamo a riassumerne i passaggi in quattro fasi principali:

  1. Inizialmente, le nuove informazioni vengono memorizzate in un ambiente di lavoro isolato (sandbox), insieme a una estrazione di dati statici provenienti dai sistemi analitici aziendali (solitamente dal Data Warehouse);
  2. In seguito, il Data Analyst lavora sull’integrazione dei dati utilizzando tool di data preparation, spesso esterni alla governance del settore IT, o addirittura strumenti di produttività personale (a volte persino Excel);
  3. Seguendo un processo iterativo trial and error, il Data Analyst determina quindi se le nuove informazioni sono interessanti per l’organizzazione e meritevoli di essere integrate nei sistemi analitici aziendali.
  4. A questo punto, il reparto IT è chiamato a procedere alla re-implementazione delle logiche all’interno del Data Warehouse. Non solo deve ricostruire a ritroso le logiche sviluppate dal Data Analyst nella sua sandbox, ma spesso deve “districarsi” fra i vari tentativi fatti e poi abbandonati alla ricerca del risultato desiderato.

É semplice intuire perché questo processo decisionale si riveli spesso causa di grande inefficienza.

Ripensare gli approcci, gli strumenti e i modelli

Ad indicare l’esigenza di nuovi approcci, strumenti e modelli di Governance rispetto a quelli tradizionali, analisti come Gartner hanno coniato termini come Bimodal approach e soprattutto Rapid Prototyping.
Nella definizione di un ambiente di Rapid Prototyping, un possibile approccio è sfruttare il Data Lake: in questo modo tutte le informazioni vengono prima memorizzate nella loro forma nativa all’interno della Data Platform e, in un secondo momento, ne viene interpretato e modellato il contenuto per dare vita a logiche di data preparation e data analysis. All’interno della moderna Data Platform, infatti, Data Warehouse e Data Lake non sono “antagonisti”, ma coesistono e lavorano all’unisono per creare architetture nelle quali ospitare le migliori tecniche e metodologie in relazione a diversi tipi di dati e di use case.
Proprio per questo, la realizzazione di un Data Lake è una delle importanti decisioni che molte aziende stanno affrontando o che hanno affrontato negli ultimi anni.

Perché proprio il Data Lake?

Figura 1. Big Data Analytics Lifecycle

Il Data Lake è un approccio architetturale che utilizza tecnologie e, in parte, metodologie diverse da quelle applicate per i sistemi analitici tradizionali, come appunto il Data Warehouse.

Grazie a sistemi di storage e computazione più flessibili, il Data Lake è oggi lo “strumento” principale per trattare i Big Data e gestire a pieno i dati all’interno di diversi contesti organizzativi aziendali. Non solo copre tutta una serie di azioni complesse da implementare e manutenere nelle architetture basate su Data Warehouse, ma contemporaneamente ne amplifica anche le potenzialità, rivoluzionando il concetto di Data Platform e aprendo nuovi scenari analitici.
Data Lake e Big Data Analysis consentono infatti:

  • L’analisi di dati semi-strutturati e non strutturati;
  • Lo sviluppo di flussi flessibili ai cambiamenti e processi automatizzabili event-driven;
  • La definizione di ambienti di data discovery e prototipazione per Data Analyst e Data Scientist;
  • Una facile integrazione con sistemi utili a sviluppare processi di Machine Learning, Advanced Analytics e Internet of Things.

Data Analyst e Data Scientist: i Top Player

La presenza di un Data Lake apre la strada a una nuova filiera di analisi, ma per sfruttarne a pieno le potenzialità sono spesso necessari i Data Analyst e i Data Scientist, figure di business che possiedono anche competenze tecniche specifiche.
Figure di questo tipo permettono di identificare nuovi “use case”, che, attraverso una facile e veloce interazione con l’IT, consentono l’individuazione e la condivisione di nuovi data set e strutture analitiche. Per questo è fondamentale riservare loro ambienti dedicati e permettergli di lavorare in (quasi) totale autonomia, beneficiando di tutte le possibilità dell’infrastruttura.

Come costruire un Data Lake per il Rapid Prototyping? Le nostre best practice

Figura 2. Architettura di alto livello Data Lake basato su HDP e IaaS Azure

Nel disegno di un’architettura Data Lake in contesti Enterprise è fondamentale definire una corretta suddivisione di dati e workflow all’interno di ambienti separati. Questi definiscono raggruppamenti logici ben definiti, che hanno l’obiettivo di consentire alle diverse figure coinvolte (developer IT, Data Analyst e Data Scientist) di svolgere il proprio lavoro e far evolvere la piattaforma attraverso lo sviluppo di nuovi processi di elaborazione e analisi.

In primo luogo, viene definita la separazione logica degli ambienti dedicati ai Data Analyst, che verranno utilizzati per implementare nuovi flussi ai fini della Data Discovery e del Rapid Prototyping. Successivamente vengono definiti gli ambienti di “produzione”, cioè quelli dedicati ai flussi industrializzati ai quali accederanno gli specialisti e i developer IT.
Con una separazione verticale di questo tipo, gli ambienti Playground e Industrializzato vengono anche profilati in termini di sicurezza, attraverso l’associazione di gruppi e ruoli per gli utenti che hanno accesso alla piattaforma: entrambi gli ambienti sfruttano l’intero stack tecnologico consentendo piene funzionalità a tutti gli attori coinvolti.

Inoltre, per un corretto utilizzo della piattaforma e per mantenere il più possibile flessibilità e manutenibilità dell’intera infrastruttura, viene applicata su entrambi gli ambienti un ulteriore separazione logica in layer.
Ogni layer viene predisposto a precise funzionalità e a un compito specifico, così da migliorare la tracciabilità del codice implementato e dei passaggi di trasformazione del dato. La suddivisione è pensata per creare un disaccoppiamento logico e fisico e per migliorare il troubleshooting della piattaforma.
Infine, Ambiente industrializzato e Playground si suddividono logicamente nei seguenti layers:


Figura 3. Architettura di dettaglio – Suddivisione in Layer del Data Lake
  • Landing Zone: il livello dove i dati vengono salvati nel formato originario
  • Raw Layer: vengono salvati i dati in maniera armonizzata e applicate le prime logiche di data tagging
  • Control e Staging Layer: vengono effettuati i controlli di chiave, popolamento di dummy values, certificazione del dato e tutti i processi di trasformazione e normalizzazione del contenuto informativo
  • Consumption Layer: vengono create le viste finali che possono essere utilizzate dai tools di Analytics e Data Visualization

Un importante alleato per i Data Analyst

Una volta costruite le fondamenta della Data Platform, è possibile avviare il popolamento del Data Lake con dati e analisi. Tutto parte dall’ambiente Playground, deputato agli utenti più tecnici e ai Data Analyst, che consente un accesso profilato per utente, ne governa le policy di utilizzo dei dati e abilita le diverse funzionalità in maniera puntuale.
L’approccio “da letteratura” prevede che il Data Analyst utilizzi strumenti,“notebook”, per la scrittura di codice utile a definire processi di data ingestion e data processing a fini analitici.
L’obiettivo dell’approccio proposto è però quello di mitigare le conoscenze tecniche necessarie per ottenere nuovi insight basati sui dati che rispondano ad esigenze di business: per questo l’architettura consente un approccio “governato” alla Data Analysis, con lo scopo di abilitare la potenza intrinseca del Data Lake anche a figure con competenze prettamente di business e meno tecniche.
Per questo vengono integrati nell’architettura i moderni strumenti di data preparation/visualization (per citarne alcuni MS PowerBI, QlikSense e Tableau), consentendo di sfruttare processi di data preparation guidati e di facile apprendimento. Attraverso questi strumenti è possibile predisporre analisi di elevata complessità grazie all’integrazione dei diversi dataset contenuti nel Data Lake, permettendo la definizione di business rules e formule di trasformazione del dato facilmente intellegibili.

Figura 4. Processo di Rapid Prototyping guidato

Inoltre, all’interno della Data Platform, vengono innestati opportuni automatismi che, attraverso l’identificazione di eventi di sistema (come la creazione, sovrascrittura o cancellazione di dati), svolgono le operazioni base per strutturare il dato all’interno dei vari layer.
Il processo si occupa ad esempio, in totale autonomia, di effettuare classiche operazioni quali: la copia del dato in formato “grezzo” su Landing Zone, l’armonizzazione dello stesso sui layer Raw, la strutturazione del dato in ambiente HIVE e l’applicazione di una nomenclatura standardizzata e di facile comprensione.
In un contesto in cui i Data Analyst operano seguendo i processi governati di gestione dei dati e grazie all’utilizzo degli strumenti di data preparation moderni e intellegibili, il Data Lake consente di rendere trasparenti e ricostruibili tutte le operazioni effettuate dai Data Analyst. In questo scenario, le figure IT possono quindi, seguendo semplici procedure guidate, industrializzare i flussi dati ritenuti opportuni per rendere persistenti le analisi prodotte dai Data Analyst.

Due take-away da non dimenticare

Secondo la nostra esperienza, un’architettura come quella illustrata in questo Highlight è un potente asset per qualunque realtà che voglia davvero prendere decisioni basate sui dati. A queste in particolare, dedichiamo due take-away, a nostro avviso fondamentali, da tenere in considerazione in fase di definizione e disegno della Data Architecture aziendale:

  • Intraprendendo un percorso di costruzione del Data Lake, uno spunto interessate è la possibilità di configurarlo e utilizzarlo per ospitare l’ambiente di Governed Rapid Prototyping a supporto delle attività dei Data Analyst, affiancandolo al tradizionale Data Warehouse;
  • Implementando semplici meccanismi di governance nella gestione del Data Lake, i Data Analyst e le figure IT possono finalmente lavorare in piena sinergia, accorciando la filiera del dato e minimizzando i tempi per la produzione di insight rilevanti per l’organizzazione.


Giorgio Gabbani – Senior Manager

All the tech, business news and trends you need to know. Delivered to your inbox.
Share
Share