Il termine Big Data associato alle famose tre V (volume, velocità, varietà) che lo hanno caratterizzato è stato introdotto ormai 15 anni fa dall’allora META Group – ora Gartner, che gli ha poi dedicato il suo primo Big Data Hype Cycle solo nel 2012, quando l’utilizzo del termine è diventato davvero pervasivo, segno anche di un interesse vivo del mercato e della aziende che cominciavano seriamente ad interrogarsi sul potenziale nascosto nella molteplicità dei dati. Nel 2013-2014 ha percorso una curva molto veloce, articolandosi subito in diverse categorie tecnologiche, per muoversi rapidamente verso la zona ‘Trough of Disillusionment’ dell’Hype Cycle ed uscirne definitivamente nel 2015. Segno positivo di una maturità della domanda prima ancora che dell’offerta, poiché è diventato ormai chiaro che si può trarre un grande valore dalla molteplicità di dati oggi potenzialmente disponibili.
È evidente che il valore di alcuni colossi recenti (Twitter, Facebook, Linkedin) basato sulla valutazione del dato come ricchezza, così come la capacità espressa da altri mega player (Google, Amazon) nel ricavarne informazioni di valore, ha trasmesso fiducia nella possibilità di far fruttare i propri dati anche in commistione con dati esterni, non solo per efficientare processi interni, ma anche per impostare politiche di sviluppo su nuove basi.
Layer caratteristici, problematiche e tecnologie specifiche
Big Data è un argomento plurimo, che riguarda diversi aspetti del ciclo di vita del dato, con problematiche, tecnologie e finalità specifiche a seconda del momento. Se scalabilità e gestione distribuita sono gli asset tecnologici qualificanti, non esauriscono comunque le problematiche e le specificità dell’intero paradigma Big Data, che va invece declinato sui vari livelli di un’architettura logica di gestione del dato, anche per capire quale sia la novità e la sfida in ciascun momento.
- Storage. Ovviamente il primo problema di un’architettura basata sui dati è quello dell’archiviazione e della gestione operativa degli stessi. È il livello tradizionalmente occupato dagli RDBMS nelle loro varie declinazioni (oltp, olap, analytical db, db machine, appliance) ma sostanzialmente orientati alla gestione di un dato strutturato, per il quale la modellazione della base dati è un momento fondativo e fondamentale non solo per garantire adeguate prestazioni ma anche per assicurare un primo livello di qualità e pulizia del dato. Velocità e volume sul dato strutturato sono gestibili anche con soluzioni tradizionali, che tendono a stringere il problema su singole macchine sempre più potenti e ottimizzate. Big Data vuol dire cambiare però direzione, andare verso architetture distribuite, raggiungendo teoricamente una logica di commodity hardware. Ma oltre a questo, cambia sostanzialmente il modo di intendere la base dati, non più fortemente e rigidamente modellata, ma molto più aperta ad accogliere dati in qualunque forma, come una grande riserva, un data lake o data reservoir, come si usa dire di recente. Il principio guida è quello di salvare il dato, qualunque esso sia, privilegiando la possibilità di averlo piuttosto che l’esigenza di dargli immediatamente una semantica chiara o un livello di qualità minima garantito, pensando ovviamente alla possibilità di accogliere nuovi dati oltre a quelli tradizionalmente presenti e gestiti nei processi aziendali.
- Data processing. A livello di trattamento dati ne consegue che i processi non sono più orientati ad una struttura ospite rigidamente vincolante, ma la fase di caricamento (ora ingestion) è molto più snella e volge sostanzialmente a rendere disponibili i dati sul cluster, come fosse una grande area di staging, senza perdita di dato anche nel caso di altissime frequenze di produzione e/o consumo. Ne risulta che, almeno in prima istanza, il data lake è un grande magazzino di dati nel quale l’urgenza di depositare e conservare prevale sulla necessità di comprendere e organizzare. Questo avviene in un secondo momento del processing, quando però guida già la finalità di utilizzo e di analisi specifica, più che la semantica intrinseca del dato. Si opera per dataset ed algoritmi anziché per modellazione e trasporto, con il risultato che il data processing, prima molto schiacciato sul livello di storage, ora si avvicina molto di più al livello dell’analisi e della fruizione.
- Analysis. È chiaro che la prima finalità nel collezionare e conservare dati, è quella di analizzarli anche a posteriori e fruirne nel tempo. Le tecnologie Big Data sono nate però pensando soprattutto alle problematiche di storage e di processing più che a quelle di analisi, con il risultato che, nelle prime battute, fare analisi massiva risultava molto critico poiché tali sistemi risultavano lenti se stressati in lettura. Questa questione è ormai superata con le varie soluzioni di accelerazione offerte nelle specifiche distribuzioni; ora il tema dell’analisi avanzata su cluster Big Data è la nuova frontiera nella sfida del valore ed ha rivitalizzato temi da sempre interessanti come il data mining ed il machine learning, finora praticati solo in ambiti specialistici. Un tratto emergente riguarda poi la data visualization per la produzione di insight, percezioni di fenomeni anziché dettagliate misurazioni. Ove i dati siano molti, eterogenei e con una semantica non necessariamente ben nota a priori, il primo passo è quello esplorativo, finalizzato alla comprensione generale piuttosto che al lavoro strettamente analitico. Per questo, avere la possibilità di fare data exploration insieme nuove forme di visualizzazione volte a comunicare piuttosto che a descrivere, sono da considerarsi a tutti gli effetti elementi essenziali della data analysis.
Il ruolo dell’Open Source e del Cloud
È ben chiaro che in questo momento Big Data è un trend dominante nell’IT, in stretta relazione ad altri temi caldi quali l’IoT e le smart city. Questo si riflette in un fermento di tecnologie e soluzioni che crea un panorama tanto ricco quanto variegato e non semplice da governare o indirizzare. Un’altra evidenza è che per i Big Data l’open source è un riferimento chiaro, almeno come punto di partenza. L’ecosistema cresciuto intorno al progetto Apache Hadoop è, di fatto, un riferimento anche per le soluzioni commerciali dei grandi vendor, che sistematicamente includono nelle proprie distribuzioni componenti open source e, in alcuni casi, contribuiscono anche a svilupparle. Organizzare un’architettura Big Data non è come scegliere un RDBMS, in cui si tratta di confrontare benchmark equiparabili.
Bisogna innanzitutto esprimere le proprie finalità e sfide sui diversi livelli enunciati, cercando poi di scegliere di conseguenza le tecnologie più adeguate. Spesso, soprattutto quando i requisiti non sono ancora ben definiti, è utile provare, procedere per POC successivi da misurare sui dati reali, al fine di valutare il beneficio che un certo sistema Big Data (fatto di tecnologia e di dati) può portare nella singola organizzazione. In tal senso open source e cloud sono sicuramente due risorse importanti almeno nei momenti più esplorativi, dove a costi contenuti e tempi ridotti, si può procedere anche per approssimazioni successive e verificare nei fatti il proprio ROI potenziale prima di procedere verso eventuali piani d’investimento e trasformazione più importanti.
Grazia Cazzin
