Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e dell’Energia Sostenibile
Corso di Laurea in Ingegneria delle Telecomunicazioni
Tesi di Laurea
Analisi del fenomeno dei Big Data e comparazione di
DBMS NoSQL a loro supporto
1
Relatore
Candidato
Prof. Domenico Ursino
Francesco Romeo
Anno Accademico 2013-2014
Alla mia famiglia, ai miei amici e a
tutte le splendide persone che mi sono
state vicine durante questo cammino.
1
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
INTRODUZIONE
La rivoluzione digitale, la diffusione degli open data e l'accelerazione senza precedenti
dello sviluppo tecnologico hanno causato una vera e propria esplosione dei dati. Questo
fenomeno risulta in continua crescita e tale crescita sembra destinata a mantenersi anche per il futuro. I dati vengono generati attraverso qualsiasi mezzo: dai sensori per la
raccolta di informazioni sul clima ai post sui social network, passando per video e immagini digitali, dati GPS raccolti attraverso smartphone e tablet, trascrizione delle transazioni di acquisto, e tanti altri mezzi.
Gli strumenti di analisi aiutano i ricercatori a trasformare i dati in conoscenza. La capacità
di analizzare un'elevata mole di informazioni, spesso non strutturate, rappresenta, per le
aziende operanti in alcuni settori, una chiara fonte di vantaggio competitivo e di differenziazione. I Big Data, combinati con sofisticate analisi di business, hanno il potenziale per
dare alle imprese intuizioni, senza precedenti, sul comportamento dei clienti e sulle condizioni di mercato, permettendo di prendere decisioni più velocemente e più efficacemente rispetto alla concorrenza.
1
Per far fronte a tali esigenze le aziende fanno uso di nuove soluzioni ICT, sia a livello infrastrutturale che applicativo, in tutte le fasi del processo, dall'acquisizione, passando per la
fase di analisi, fino ad arrivare alla visualizzazione dei risultati ottenuti.
Uno dei problemi che sta dietro ai Big Data è che, nella maggior parte dei casi, questi dati
non sono strutturati, quindi non sono facilmente riconducibili a modelli di dati o a metodi
classici di archiviazione. Cambiare in corsa una determinata tabella, magari introducendo
nuovi attributi, è problematico e, spesso, sconsigliato proprio per evitare problemi di
corruzione al DBMS. Questa limitazione rende i DBMS relazionali molto poco adatti alle
trasformazioni dei Big Data. La nascita e il recente sviluppo dei DBMS NoSQL si sono
rivelati di importanza fondamentale per garantire la crescita di tutta una serie di applicazioni ricche di contenuti e spesso distribuite agli utenti tramite Internet.
Francesco Romeo | 1
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Di soluzioni per affrontare la problematica dei Big Data ne esistono di diversi tipi, ma quella che
va per la maggiore è sicuramente basata su Hadoop. Questa tecnologia, open source, ha rivoluzionato la percezione delle aziende su cosa può essere fatto con i propri dati. La crescita esplosiva dei dati, associata al crollo dei costi dei server e alla crescita delle infrastrutture cloud, ha
fatto diventare Hadoop il punto di riferimento per le medie e grandi aziende.
Esistono varie tipologie di DBMS NoSQL, ciascuna delle quali presenta caratteristiche differenti. La scelta su quale DBMS usare va fatta accuratamente dal progettista software in base alle
caratteristiche del sistema da gestire. All’interno della tesi si è scelto di dare maggiore importanza a tre dei DBMS più utilizzati: Cassandra, MongoDB e HBase.
In questa tesi presenteremo una panoramica sui Big Data e, più in particolare, su quanto precedentemente specificato.
La tesi è strutturata come di seguito specificato:
Nel primo capitolo sarà descritto il fenomeno dei Big Data. Verrà presentato il tema della
Social Business Intelligence e i vantaggi che ne derivano. Inoltre, verranno presentati i più
diffusi contesti di utilizzo.
Il secondo capitolo si concentrerà sul processo di analisi dei Big Data, partendo dal processo di estrazione della conoscenza dai database (KDD) e dando maggiore rilievo alla
fase di Data Mining. Verrà presentata la figura del data scientist e sarà affrontato il tema
della Privacy By Design.
Nel terzo capitolo sarà introdotto il concetto di NoSQL e verrà fatto un confronto con i
DBMS relazionali. Inoltre, verranno elencate le varie tipologie di DBMS NoSQL.
Nel quarto capitolo si parlerà dell’utilità del framework Hadoop per l’analisi distribuita di
grandi insiemi di dati. Verranno, inoltre, presentati i sottoprogetti fondamentali, MapReduce e HDFS, e l’innovativo YARN.
Nel quinto capitolo verranno trattati tre dei più utilizzati DBMS NoSQL: Cassandra, MongoDB e HBase. Inoltre, verranno presentate, e poi confrontate le caratteristiche, di ognuno di essi.
Infine, nell’ ultimo capitolo, verranno tratte le conclusioni e verranno esaminati alcuni
possibili sviluppi futuri.
2 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1. INTRODUZIONE AI BIG DATA
In questo capitolo verrà descritto il concetto di Big Data. Partendo dal significato del termine verranno delineate le caratteristiche generali di questo fenomeno. Successivamente,
verrà affrontato il tema della Social Business Intelligence con i vantaggi che ne derivano. Il capitolo si concluderà con una presentazione dei più diffusi contesti di utilizzo,
appunto, dei Big Data.
1
Cosa si intende per
Big Data
2
La Social Business
Intelligence
3
Contesti di utilizzo
dei Big Data
1
Francesco Romeo | 3
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.1 COSA SI INTENDE PER BIG DATA
“What is Big Data? A meme and a marketing term, for sure, but also shorthand for advancing
trends in technology that open the door to a new approach to understanding the world and
making decisions .”
Il termine Big Data, sicuramente abusato nelle moderne strategie di mercato, indica grandi
aggregazioni di dati che non possono essere processati o analizzati con i tradizionali processi e
strumenti di analisi. I Big Data aprono le porte verso nuovi modi di percepire il mondo e di prendere decisioni.
I Big Data sono ovunque, e ogni giorno sempre più applicazioni vengono create per trarne
valore e arricchire la vita personale e professionale degli utenti. I nostri desideri, opinioni, sentimenti lasciano traccia nei social media a cui partecipiamo, nelle domande che facciamo ai
motori di ricerca, nei tweet che inviamo e riceviamo, così come i nostri stili di vita lasciano
traccia nei record dei nostri acquisti. I nostri movimenti lasciano traccia nelle traiettorie disegnate dai nostri smartphone e dai sistemi di navigazione delle nostre auto. Anche le nostre
relazioni sociali lasciano traccia nella rete dei
nostri contatti telefonici, delle email e nei link di
amicizia del nostro social network preferito.
Da un lato, alcuni fattori, quali la crescita dei dati
scientifici, hanno fortemente contribuito all'accelerazione della produzione di questi dati. Dall'altro, questa crescita esponenziale è il risultato di
alcuni mutamenti sociali ed economici estremamente positivi avvenuti nella nostra società. Si
consideri, ad esempio, la rapida diffusione dei
dispositivi mobili, ricchi di contenuti multimediali e compatibili con i sistemi GPS, e dei social
network, che hanno consentito a miliardi di persone in tutto il mondo di tenersi in contatto in
modo digitale.
4 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
I Big Data sono il nuovo strumento che rende “misurabile” la società. Ci indirizzano verso una
nuova scienza dei dati in grado di misurare e, in prospettiva, prevedere crisi economiche,
epidemie e pandemie, diffusione di opinioni, distribuzione delle risorse economiche o energetiche, bisogni di mobilità.
Molti analisti, per poter definire il concetto di Big Data, utilizzano le tre caratteristiche descritte di seguito:
Velocità;
Varietà;
Volume;
Un equivoco molto diffuso è la convinzione che il
concetto di Big Data riguardi esclusivamente le dimensioni dei dati. Per quanto le dimensioni rappresentino sicuramente un elemento della questione, esistono anche altri aspetti o altre proprietà dei Big Data che non sono necessariamente associati a esse. Si prendano in considerazione, ad esempio, la velocità di generazione dei Big Data da un lato e, dall'altro, il numero e la
varietà di origini da cui i dati vengono generati contemporaneamente.
Per stabilire quando effettivamente i vari tipi di dati rientrano nella categoria dei Big Data è
necessario analizzare gli elementi sopra citati. È fuor di dubbio che una presentazione di
PowerPoint da 40 MB, un'immagine medica da 1 TB o un filmato da 1 PB hanno tutti dimensioni elevate, ma dobbiamo capire se si tratti di Big Data. Si potrebbe sostenere che non si
possono definire Big Data solo in virtù delle dimensioni, poiché il concetto di dimensioni
elevate, così come inteso oggigiorno, potrebbe cambiare in futuro. Si potrebbe, invece, asserire che si tratta oggi di Big Data perché ognuno di essi sfrutta al massimo la comune tecnologia disponibile per il loro utilizzo. Si può considerare Big Data una presentazione di PowerPoint da 40 MB se non è possibile condividerla via email con colleghi o aziende. Analogamente, si può considerare Big Data un'immagine medica da 1 TB se non è possibile visualizzarla in
tempo reale su uno schermo remoto in modo semplice e accurato e consentire al medico di
utilizzarla durante le visite dei pazienti. Un filmato da 1 PB rientra fra i Big Data se non è
possibile eseguire il rendering dell'editing entro l'orario di attività aziendale.
È chiaro, quindi, che qualunque attributo, comprese le dimensioni, riguarda i Big Data nel
momento in cui mette alla prova i limiti delle funzionalità dei sistemi o incide sulle esigenze
Francesco Romeo | 5
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
aziendali. In merito agli altri attributi che
possono rientrare nella definizione precedentemente esposta, quali la velocità di
generazione dei dati o il numero e la varietà
di origini da cui provengono, in questo caso è
possibile applicare la classificazione di Big
Data a quei dati che, di per sé, non sono
affatto “GRANDI”.
Un altro aspetto interessante dei Big Data è la loro diversità dal punto di vista della struttura.
Alcuni hanno un formato ben definito, ad esempio nel caso delle transazioni di un database, in
cui ogni voce può essere divisa in campi, ciascuno dei quali contenente un tipo di dati ben chiaro e definito. Altri possono essere, semplicemente, una raccolta di interventi su blog con testo,
tabelle, immagini, audio e video, tutti memorizzati all'interno dello stesso storage di dati.
Possiamo affermare che i Big Data sono intorno a noi e che noi stessi siamo tra i principali generatori. L'aggiornamento dei Big Data avviene, inoltre, in modo estremamente iterativo e
incrementale con una frequenza elevata.
I dati vengono costantemente modificati e divengono più accurati e precisi con il passare del
tempo e con l'aumentare dei dati relativi ai dati creati, calcolati o desunti.
L'esecuzione di analisi con la maggiore granularità possibile, che producano allo stesso tempo
una quantità di dati sufficiente affinché il risultato sia significativo e accurato, richiede iniziative
più precise e, in compenso, porta maggiori profitti o guadagni per l'azienda e i clienti.
Tenendo conto della qualità dei dati e della loro rappresentatività, dobbiamo essere consapevoli delle grandi opportunità, così come dei nuovi rischi. Occorrono tecnologie a sostegno della
privacy, occorre un “new deal” sui temi della privacy, della trasparenza e della fiducia necessario per creare e accedere alla conoscenza dei Big Data come un bene pubblico per tutti. Certo, i
problemi relativi alla qualità, alla privacy e alla proprietà dei Big Data risultato essere decisivi.
6 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.2 LA SOCIAL BUSINESS INTELLIGENCE
La Business Intelligence (nel seguito, BI) può
essere definita come l’insieme delle metodologie, dei modelli, delle tecnologie e delle
applicazioni rivolte alla raccolta sistematica
del patrimonio di informazioni generate e
acquisite da un’azienda, alla loro aggregazione, analisi, presentazione e al loro utilizzo.
Le tecniche di BI nascono, come dice il nome, nel settore economico-finanziario, con
applicazioni oggi prevalentemente di
marketing, e hanno nomi evocativi come:
benchmarking, data mining, business performance management, etc.
Big Data Analytics è un concetto nuovo, che in realtà è l’unione di due concetti dei quali si
parla ormai da molti anni e che, quindi, nuovi non sono. Da un lato Big Data, con tutte le
problematiche connesse, come abbiamo visto. Dall’altro lato la Business Analytics.
Di modello dimensionale dei dati e applicazioni OLAP (On-Line Analytical Processing) si parla
da più di 20 anni; la Business Intelligence e il Performance Management sono tra le aree IT
che, negli ultimi anni, hanno avuto più attenzione ed investimenti; il Data Mining e le analisi
predittive sono stata l’ultima frontiera che
ha portato verso la Business Analytics.
Oggi è difficile trovare un’azienda che non
abbia affrontato almeno uno dei temi
appena citati.
Ciò che è inedito, invece, è il concetto di
Big Data Analytics. Unione che non è il
semplice accostamento dei due concetti
sopra descritti. Big Data Analytics non
significa semplicemente, o non solo, potere fare analisi su grossi volumi di dati. Anche gli altri
due fattori che caratterizzano i Big Data, ovvero la varietà dei dati e la necessità di trasformare i dati in informazioni il più velocemente possibile, sono intervenuti a determinare la definizione di questa nuova categoria di applicazioni.
Vediamo quale può essere la chiave di successo per sfruttare i grandi dati e per estrarre da
essi informazione e conoscenza. Secondo il McKinsey Global Institute, è possibile identificare cinque fattori largamente applicabili per poter sfruttare i Big Data come fonte di valore.
Questi saranno esaminati in dettaglio nel prossimo paragrafo.
Francesco Romeo | 7
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.2.1 BIG DATA COME FONTE DI VALORE
I cinque fattori capaci di dare valore ai
Big Data sono i seguenti:
La creazione della trasparenza: si
può ottenere la trasparenza
semplicemente rendendo accessibili e disponibili i dati e le informazioni a tutti gli “stakeholder”
in modo tempestivo e in modo
da creare un valore straordinario;
nel settore pubblico è in atto da
tempo una tendenza (Open Data), in particolare nel mondo anglosassone, di apertura del
patrimonio informativo a tutte le organizzazioni private e/o ai cittadini. Per quanto le
prime iniziative abbiano messo in luce elementi di criticità, si tratta di una tendenza che
prosegue e che, anche in Italia, ha messo in moto alcune interessanti iniziative sia a livello
regionale che nazionale.
Miglioramento delle prestazioni: tutte le organizzazioni, sia pubbliche che private, con una
maggiore analisi ed elaborazione dei dati e delle informazioni disponibili possono migliorare le loro prestazioni ed i loro processi. Particolarmente significativi a questo riguardo
sono le esperienze di analisi dei dati di vendita ed, in generale, di relazione con la clientela. Una più attenta elaborazione dei dati relativi alle vendite può incrementare in modo
significativo la capacità di segmentare l’offerta e
di personalizzarla sulle specifiche esigenze del
cliente. Analizzare i dati sul venduto può dare
origine ad una più precisa previsione dell’andamento futuro delle vendite con evidenti vantaggi
nella gestione logistica. Nel settore pubblico, il
processo di digitalizzazione in atto nell’area della
salute, può consentire oltre ad una analisi accurata della efficienza ed efficacia delle strutture sanitarie una disponibilità di informazioni
cliniche che contribuisce ad aumentare la qualità e la personalizzazione dei trattamenti
sanitari. Sempre nel settore pubblico, un’analisi delle tendenze e dei dati relativi al mercato del lavoro può aiutare in modo decisivo la definizione di politiche attive di supporto ai
non-occupati e l’impostazione di adeguati processi formativi.
Segmentazione dei clienti e personalizzazione delle azioni: i Big Data consentono alle orga-
8 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
nizzazioni di creare segmentazioni altamente specifiche e di
adattare i prodotti e i servizi alle esigenze dei consumatori.
Questo approccio è ben noto in marketing e nella gestione del
rischio.
Supporto alle decisioni: i processi decisionali, in tutte le organizzazioni, possono diventare sempre più data-driven e fact-based. Le decisioni prese con
il supporto di strumenti analitici possono diventare la regola e non l’eccezione. Fino ad
ora queste tecniche erano diffuse solo nelle grandi organizzazioni, anche per il costo
elevato dei sistemi e degli strumenti informatici per l’elaborazione e l’analisi dei dati. Le
attuali evoluzioni tecnologiche, come il diffondersi del “cloud-computing” e degli strumenti di analisi “open-source”, rendono molto meno costoso e più flessibile l’adozione
di queste tecniche da parte anche delle organizzazioni medio-piccole.
Innovare i prodotti, i servizi e i modelli di business. La possibilità, tramite l’analisi dei dati,
di rispondere in tempo reale alle domande:
“Cosa è successo?”, “Perché è successo?”, “Che
cosa sta succedendo?” e “Che cosa succederà?” consentono alle organizzazioni di innovare
i prodotti, i processi e i modelli di business per
cogliere le sfide di un ambiente in continuo
cambiamento.
Per cogliere al meglio le opportunità elencate è,
però, necessario rispondere efficacemente ad alcune
sfide che possono essere cosi sintetizzate:
Sfide tecniche: il tema della qualità, dell’accessibilità e della fruibilità dei dati rimane un
aspetto critico che molte organizzazioni non hanno ancora adeguatamente affrontato.
Come citato in una ricerca, IBM stima che oltre il 50% dei manager, non consideri affidabile il dataset sul quale si basano i processi decisionali.
Mancanza di talenti: la crescita esponenziale dei “big data” ha messo in evidenza la
necessità, sempre maggiore, di persone con competenza adeguate per elaborare, analizzare e visualizzare grandi dataset ed estrarre da essi le informazioni essenziali per il
supporto delle decisioni. Si valuta che nel 2018, solo in USA, vi sarà una carenza di personale con competenze di analisi stimabile in 150-190 mila unità e saranno mancanti
oltre 1,5 milioni di manager con competenze adeguate all’utilizzo dei “big data”. Emergeranno, inoltre, nuove figure professionali come quella del “data scientist”, dotate di
Francesco Romeo | 9
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
competenze multidisciplinari (statistica, informatica, economia, organizzazione), necessarie per creare valore ai “big data”.
Sfide legali: il tema della sicurezza, della
tutela della privacy e della protezione
della proprietà dei dati e delle informazioni, in molti settori (come ad esempio
quello della sanità), costituisce un’elemento forte di criticità e, talora, un
freno all’innovazione.
Sfide culturali: la cultura delle decisioni data-driven e fact-based non è ancora sufficientemente diffusa nelle organizzazioni, sia pubbliche che private (soprattutto in Italia). È
indispensabile, dunque, dedicare adeguata attenzione alle politiche formative ed alla
gestione del cambiamento.
Questa grande complessità e quantità dei dati può essere gestita solo attraverso soluzioni
tecnologiche nuove. È stata sviluppata e adattata un'ampia varietà di tecniche e tecnologie per
aggregare, manipolare, analizzare e visualizzare i Big Data. L'insieme di tecniche e tecnologie
attingono da settori diversi, quali la statistica, l’informatica, la matematica applicata e l'economia: questo significa che un'azienda, la quale intende trarre valore dai Big Data, dovrebbe
adottare un approccio flessibile e multidisciplinare. Le tecniche e le tecnologie per aggregare,
manipolare, analizzare e visualizzare i Big Data sono in continuo sviluppo per ottenere , sempre, un miglioramento delle prestazioni.
10 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.2.2 VARIETA’ DELLE INFORMAZIONI
Probabilmente esistono due distinte categorie di Big Data. La prima è relativa alle tipologie
tradizionali di dati. La seconda è relativa ai dati generati dalla rete. Se prestiamo attenzione a
quest’ultima categoria, proviamo ad elencare alcune importanti fonti di dati per la Big Data
Analytics:
Dati strutturati in tabelle (relazionali). Sono i dati sui quali si basa la tradizionale Business
Intelligence e la sua recente evoluzione, la Business Analytics. I volumi sempre crescenti
di dati memorizzabili e le architetture sempre più “performanti” rendono ancora oggi le
tabelle relazionali la principale fonte di dati per la Big Data Analytics. Tutti i sistemi
gestionali esistenti producono dati strutturati o strutturabili in tabelle relazionali. Queste restano il modello di dati preferenziale per le principali piattaforme di Data Analytics.
Dati semistrutturati (XML e standard simili). E’ il tipo di dati che sta sfidando l’egemonia
dei dati strutturati. Applicazioni transazionali e non, forniscono nativamente output di
dati in formato XML o in formati tipici di specifici settori (SWIFT, ACORD, etc. ). Si tratta, perlopiù, di dati Business-to-Business organizzabili gerarchicamente.
Dati di eventi e macchinari (messaggi, batch o real time, sensori, RFID e periferiche).
Sono i tipici dati definibili “Big Data” che, sino a pochi anni fa, venivano memorizzati
solo con profondità temporali molto brevi (massimo un mese) per problemi di storage.
Dati non strutturati (linguaggio umano, audio, video). Sono enormi quantità di metadati, perlopiù memorizzati sul web, dai quali è possibile estrarre informazioni strutturate
attraverso tecniche avanzate di analisi semantica.
Dati non strutturati da social
media (social network, blog,
tweet). Sono l’ultima frontiera
delle fonti di dati non strutturate. Crawling, parsing ed
entity extraction sono tra le
tecniche per l’estrazione di
dati strutturati e analizzabili. I
volumi aumentano esponenzialmente nel tempo. Il loro
utilizzo può aprire nuovi paradigmi di analisi prima impensabili.
Francesco Romeo | 11
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Dati relativi alla navigazione Web (Clickstream): Web Logs, Tag Javascript, Packet sniffing
per ottenere Web Analytics. Si tratta di enormi quantità di dati che portano informazioni
sui consumi e sulle propensioni di milioni di utenti. Anche per questi dati, i volumi aumentano esponenzialmente nel tempo.
Dati GIS (Geospatial, GPS). I dati geospaziali sono generati da applicazioni sempre più diffuse. La loro memorizzazione è ormai uno standard e i volumi sono in crescente aumento. I dati geospaziali, analizzati statisticamente e visualizzati cartograficamente, integrano i dati
strutturati fornendo, ad esempio, informazioni di business, informazione sulla sicurezza o informazioni sociali.
Dati scientifici (astronomici, genetica, fisica). Come i dati relativi agli eventi, sono per
definizione dei Big Data. Per il loro trattamento e la loro analisi si sono sperimentate tutte
le più innovative tecniche computazionali nella storia recente dell’Informatica. Per essi
sono stati progettati, nel tempo, tutti i più potenti calcolatori elettronici. I loro volumi
sono enormi e in costante aumento.
Dopo questa elencazione, comunque
non esaustiva, sarà risultato chiaro
quale sia la potenziale varietà di dati
da trattare in un’applicazione sviluppata per trasformare i dati in informazioni di business.
12 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.2.3 LA VELOCITA’ NEI FENOMENI AZIENDALI
Introduciamo l’ultimo fattore che ha determinato la nascita delle Big Data Analytics, ovvero
la Velocità che, per molti fenomeni aziendali, è
diventata una caratteristica sempre più determinante. Essa è fondamentale per:
Svolgere i processi e le attività aziendali
(ad esempio, un processo commerciale, la
creazione di un nuovo concept di prodotto, la comunicazione di marketing con
media digitali).
Trattare in modo integrato grandi volumi di dati eterogenei (ad esempio, i dati di vendita, i reclami a un customer care e i commenti sui blog o nei social network, dati di geolocalizzazione) e ottenere un’informazione rilevante (ad esempio, di insight nel comportamento di acquisto di un segmento di clientela e delle sue percezioni di qualità verso il
prodotto).
Rilevare, archiviare, elaborare, distribuire e presentare i dati generati utilizzando i sistemi ICT.
Gestire le relazioni digitali tra le persone, le imprese e le istituzioni in modo da permettere la “ubiquità” dei dati e degli individui.
La velocità oggi a disposizione delle aziende si concretizza nella capacità potenziale di ridurre
il tempo necessario non solo per l’esecuzione di un’attività, ma anche per la sua finalizzazione, per il cambiamento repentino e “in corsa” dei suoi obiettivi o delle sue relazioni con altri
processi; questa è la vera e rivoluzionaria novità
per la gestione d’azienda. Muoversi in un contesto dove si hanno tutti i dati a disposizione
consente di affrontare un problema con un
margine di errore ridotto e accettabile.
La complessità crescente della gestione aziendale di cui si parla spesso, è, di fatto, generata
da due fattori prevalenti: la crescente velocità
dei cambiamenti necessari, e la crescente incertezza degli scenari e dei risultati generabili dalle
scelte possibili.
I seguenti punti possono aiutare a riassumere i
Francesco Romeo | 13
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
principali cambiamenti già in atto e basati
sull’ICT, che prospettano alcuni nuovi orizzonti
del management aziendale:
Trasformare il modo in cui le persone pensano, analizzano i fatti, pianificano e agiscono:
sono necessari nuovi atteggiamenti nei
confronti dell’ICT, passando da molti fenomeni di moda e di “consumerization” (ad
esempio, riguardo i dispositivi mobili o il
social Web) ad un reale impiego nella gestione aziendale.
Velocizzare i processi di Innovation Management, sia di prodotto/servizio (dall’idea generation al concept, al testing e allo sviluppo),
sia di processo (interno esterno, operativo o manageriale), generati dall’ICT.
Far funzionare in modo sincrono elevati volumi di transazioni e operazioni aziendali con
veloci ed evolute attività di analisi dei dati strutturati e non strutturati generati da questi
processi operativi online e offline.
Velocizzare le decisioni aziendali con un numero maggiore di informazioni rilevanti e con
sistemi di comunicazione e collaborazione ad alta velocità, in tempo reale, tra persone,
tra team di lavoro, e tra imprese.
Aumentare i cicli/ritmi di misurazione, monitoraggio e analisi dei fatti aziendali per innescare veloci attività di “trial and error”, veloci cicli di “Analyze, Plan, Act and Control”, piuttosto che profondi e lenti processi di decisione analitica.
Essere coscienti che il sogno della “real time enterprise” deve avvenire attraverso azioni
innovative, fattibili, veloci, economicamente convenienti (nel marketing, nel business
development, nella finanza, etc.), altrimenti resta un potenziale inespresso e fine a se
stesso.
Questa grande complessità e questa grande
quantità dei dati possono
essere gestite solo attraverso soluzioni tecnolo-
14 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
giche nuove.
È stata sviluppata e adattata un'ampia varietà
di tecniche e tecnologie per aggregare, manipolare, analizzare e visualizzare i Big Data.
L'insieme di tecniche e tecnologie attingono da
settori diversi, quali la statistica, l’informatica,
la matematica applicata e l'economia: questo
significa che un'azienda, la quale intende trarre
valore dai Big Data, dovrebbe adottare un
approccio flessibile e multidisciplinare.
Francesco Romeo | 15
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.3 CONTESTI DI UTILIZZO DEI BIG DATA
I Big Data si configurano come un'importante risorsa per l'innovazione, la competizione e la
produttività tra le aziende e vengono considerati come dati che potrebbero generare un grande
valore al pari addirittura del petrolio, come già affermava nel 2006 il ricercatore di mercato
Clive Humby.
Allo stato attuale i dati digitali sono ovunque, in ogni settore, in ogni economia e in ogni organizzazione; l'abilità di generare, comunicare, condividere e accedere ai dati è stata rivoluzionata ulteriormente dall'aumento del numero di persone che fanno uso di dispositivi mobili e dai
sensori che sono connessi con le reti digitali.
Si pensi che più di 30 milioni di nodi sensori
collegati in rete sono presenti nel settore
dei trasporti, dell'automotive, dei servizi e
nel retail e che questi stanno crescendo
sempre di più a un tasso superiore al 30%
annuo. La qualità dei dati trasversali alle reti
continuerà ad aumentare vertiginosamente:
infatti, si pensa che entro il 2020 saranno
connessi alla rete e a Internet 50 miliardi di
dispositivi. Dunque anche la rete gioca un
ruolo chiave ai fini dello sviluppo del potenziale dei Big Data. Innanzitutto, essa può raccogliere dati a velocità elevata; i dati raccolti consentono alla rete di determinare il contesto, ad esempio abbinando ai dati le informazioni sull'identità o sulla presenza. Inoltre, la rete consente alle imprese di intervenire immediatamente
sulle informazioni ricavate dai dati.
Secondo un sondaggio di Gartner, il 64% delle organizzazioni globali sta investendo, o ha intenzione di investire, in tecnologie per i Big Data contro il 54% che già lo faceva o pensava di
farlo nel 2012. È anche vero che solo l'8% delle imprese ha implementato tali tecnologie. I settori che guidano gli investimenti in Big Data sono quelli dei media e delle comunicazioni, le
banche e i servizi, ma nel giro dei prossimi due anni si aggiungeranno molte altre aziende,
come quelle nel settore dei trasporti, nella sanità e nel benessere.
Ci sono notevoli esempi di aziende in tutto il mondo che sono bene conosciute per il vasto ed
efficace utilizzo dei dati. Di seguito menzioniamo brevemente le best practices delle aziende
mondiali che hanno sfruttato il valore dei Big Data:
Il programma di fidelizzazione di Tesco genera un ammontare di dati sui clienti, da cui
16 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
l'azienda estrae informazioni, per costruire campagne promozionali sino ad arrivare alle
strategie di segmentazione della clientela.
Harrah's ha aumentato il ricavo dell'8 - 10% analizzando i dati sulla segmentazione dei
clienti.
Amazon utilizza i dati sui consumatori per gestire il suo motore di raccomandazioni che
conosciamo con l'espressione “you may also like. . .”; questo è basato su un tipo di tecnica di modellazione predittiva chiamata “collaborative filter”. Inoltre, Amazon ha dichiarato che il 30% dei propri ricavi era riconducibile al suo motore analitico per i consigli ai consumatori.
Fedex, la società di trasporto espresso più grande al mondo, ha ottenuto in tempo reale
i dati su spedizioni e consumatori provenienti da più di 46000 centri di distribuzione e
supply chain.
WalMart, il gigante americano della grande distribuzione, ha implementato la tecnologia RFID (Radio Frequency Identication) per scambiare informazioni in tempo reale tra i
fornitori e il Data Warehouse Retail Link. In questo modo ha ottenuto la riduzione del
16% della frequenza di esaurimento delle scorte. Quest' ultima azienda merita delle
considerazioni in quanto ha agevolato la strada alle altre aziende garantendone la competitività nel settore del retail. Walmart ha facilitato l'espansione di un sistema di scambio elettronico di dati per collegare la propria catena di fornitura elettronica. Inoltre, ha
sviluppato un Retail Link, ovvero uno strumento che offre ai suoi fornitori una visione
della domanda nei suoi negozi in modo da prevedere quando questi ultimi debbano
essere riforniti senza attendere
l'ordine da Walmart. L'uso diffuso
dei dati dei clienti sempre più granulari può consentire ai retailer di migliorare l'efficacia del loro marketing
e del loro merchandising.
Le applicazioni possono essere suddivise in due grandi settori: applicazioni analitiche e applicazioni relative a determinati settori. Questi verranno esaminati in dettaglio nelle prossime
sottosezioni.
Francesco Romeo | 17
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.3.1 APPLICAZIONI ANALITICHE
Le applicazioni analitiche si possono suddividere come di seguito specificato:
Applicazioni basate su attribuzioni. Queste devono recuperare e analizzare le serie di attività, prendendo in considerazione fattori quali la frequenza, la sequenza, l’attualità, le
soglie e la perdita di efficacia nel tempo trascorso; l’obiettivo finale è quello di accreditare
un valore a ciascuna attività. Ecco alcuni esempi basati su attribuzioni:
applicazioni per l’ efficacia del marketing multicanale, grazie alle quali gli
esperti del settore tentano di attribuire credito per una vendita su canali di
marketing;
applicazioni di attribuzione relative ai partner, grazie alle quali le società commerciali tentano di quantificare il contributo dei vari partner;
applicazioni di attribuzione relative al trattamento medico, grazie alle quali le
organizzazioni di assistenza sanitarie tentano di valutare l’incidenza di varie
cure e medicinali sull’esito della terapia.
Applicazioni basate su suggerimenti. Le applicazioni basate su suggerimenti individuano e
generano serie di utenti e prodotti simili in base a comportamenti, dati demografici o altri
attributi percepibili. A partire dalle tendenze rilevate, le applicazioni riescono a fornire
suggerimenti su prodotti (come nel caso Amazon e Netfix) o persone (come accade con
Linkedln e Facebook). Ecco alcuni esempi di applicazioni basate su suggerimenti:
applicazioni per l’individuazione di pubblicità mirate ai clienti, che
suggeriscono segmenti di audience di riferimento “simili” in base a comportamenti e prodotti acquistati in passato;
applicazioni che consigliano prodotti complementari sulla base degli
acquistati effettuati da utenti simili in un determinato periodo di tempo .
Applicazioni basate su predizioni e previsione. Le applicazioni basate su predizioni e previsione acquisiscono un’ampia gamma di variabili a supporto dei processi decisionali in
svariati scenari di mercato. Esse utilizzano al meglio le tecniche statistiche e di data mining per estrarre dalla moltitudine di variabili solo quelle più efficaci per prevedere le
prestazioni in particolari situazioni. Le applicazioni predittive avanzate integrano valutazioni su rischi e dati sensibili affinché i responsabili delle decisioni possano determinare le
variabili più importanti nel processo decisionale. Ad esempio, se si ritiene che una certa
18 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
variabile sia cruciale per una decisione, è possibile investire maggiori risorse per assicurarsi che
essa venga valutata in modo preciso e completo . Ecco alcuni esempi di applicazioni basate su
predizione e/o previsione :
applicazioni per il calcolo del tasso di
abbandono dei clienti che prevedono
la possibilità di contrasti con questi
ultimi in base a fattori come attività di utilizzo, richieste di supporto e influenza sociale degli amici;
applicazioni per la manutenzione dei prodotti, che prevedono guasti delle
apparecchiature in base a informazioni sull’utilizzo dei prodotti (in particolare, informazioni attualmente fornite dai dispositivi dati integrati), registrazione degli interventi di manutenzione e informazioni generali sulle prestazioni;
applicazioni relative alle prestazioni dei dipendenti, che prevedono le prestazioni di un potenziale collaboratore in base a fattori quali formazione, posizione socio-economica, ruoli professionali precedenti, stato civile e determinate risposte psico-comportamentali;
applicazioni relative alle prestazioni degli studi clinici, che modellano i risultati di vari medicinali in base alla sperimentazione clinica, consentendo ad
un’azienda di comprendere l’efficacia di determinate terapie ed evitare conseguenze catastrofiche in caso di utilizzo di particolari farmaci; ciò assume
un’importanza ancora maggiore quando si tenta di attribuire i risultati per
più trattamenti e medicinali;
applicazioni per la gestione del rendimento, del ribasso dei prezzi e del merchandising e per l’ottimizzazione dei prezzi, in grado di creare modelli utilizzati dai responsabili delle decisioni per comprendere come e quando aumentare o ridurre i prezzi tenendo conto delle condizioni attuali della domanda e dell’offerta; questi tipi di applicazioni sono particolarmente comuni
nel caso dei prodotti di base (quali merci deperibili, biglietti aerei, camere di
alberghi, capi di abbigliamento e biglietto per eventi sportivi), il cui valore si
azzera in un determinato momento.
Applicazioni basate su approfondimenti. Le applicazioni basate su approfondimenti
Francesco Romeo | 19
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
fanno leva su tecniche statistiche e di data mining per identificare situazioni o comportamenti ”insoliti”. La crescente importanza di queste applicazioni è legata al volume in
continuo aumento dei dati dettagliati provenienti da fonti quali clic nelle pagine web e
sensori RFID. Ecco alcuni esempi di applicazioni basate su approfondimenti:
applicazioni relative alla riduzione e alla distribuzione dei prodotti, che monitorano costantemente sensori e dati RFID per individuare differenze tra la
posizione del prodotto ipotetica e quella reale;
applicazioni contro le frodi, che monitorano costantemente le transazioni
finanziarie per individuare comportamenti “insoliti” che possono essere indice
di attività fraudolente;
applicazioni antiriciclaggio, che monitorano costantemente il flusso di contante per individuare comportamenti “insoliti” associati a potenziali attività di
riciclaggio, ad esempio un numero eccessivo di transazioni di scarso valore
realizzate in contanti.
Applicazioni basate su benchmark. Le applicazioni basate su benchmark utilizzano al meglio
l’analitica che confronta le prestazioni di un’entità rispetto a uno standard di settore, un periodo o un evento precedente. Ecco alcuni esempi
di applicazioni basate su benchmark:
applicazioni relative alle quote di
mercato, che forniscono dati su quote di mercato e portafoglio; ad esempio, le aziende che creano siti web
possono fornire dati e analisi sugli
investimenti pubblicitari per consentire a inserzionisti e agenzie di confrontare
le spese sostenute nel campo del marketing con quelle della concorrenza;
applicazioni basate su benchmark competitivo, che mettono a confronto le
prestazioni di un’azienda con un’ aggregato di concorrenti o con la media del
settore;
applicazioni basate su benchmark, che confrontano le prestazioni di una campagna di marketing in corso con quelle di una campagna o di un evento di
marketing precedente e/o simile.
20 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.3.2 OPEN BIG DATA
“Chi riceve un'idea da me, ricava conoscenza senza diminuire la mia; come chi accende la
sua candela con la mia ha luce senza lasciarmi al buio” Cit. Thomas Jefferson in una lettera a
Isaac Mac Pherson nel 1813.
In realtà, i dati non sono solo big ma possono essere anche open. Gli Open Big Data, cioè la
liberazione dei dati delle amministrazioni, rispettano il
principio, secondo il quale i dati prodotti dalle istituzioni
pubbliche appartengono alla collettività e, pertanto, devono essere resi disponibili, fruibili e riutilizzabili. Alcuni
esempi di dati pubblici la cui fruibilità migliorerebbe sensibilmente la vita della comunità sono citati nel rapporto
Open Data, Open Society. Da esso deriviamo alcuni ambiti di applicazione:
La Geografia: la geografia dei luoghi porta in mente suggestioni di vastità, ricchezza e
diversità. Le istituzioni locali avrebbero l'opportunità di pianificare in modo più efficiente le proprie politiche di sviluppo territoriale e urbanistico se, oltre a disporre dei dati
che i singoli organi e enti già possiedono, li condividessero fornendo un quadro più esaustivo del
territorio, incrociandoli con mappe e visualizzazioni che rilevino aree protette o di interesse artisticoculturale, risorse idriche o forestali, etc. Inoltre, il
singolo cittadino potrebbe trarre beneficio dal
sapere, per esempio, che la casa che vorrebbe
comprare sorge in un'area a rischio idrogeologico.
I Trasporti: la conoscenza della disponibilità dei
dati sul traffico (la viabilità, il numero stimato di vetture, i lavori in corso, la mobilità
etc.) potrebbe recare un miglioramento al traffico urbano e alla progettazione dei trasporti pubblici. Si potrebbe pensare di far dialogare in real time i sistemi di rilevazione
installati ai semafori, il sistema GPS sulle vetture piuttosto che su un cellulare, con i
database dei vigili urbani, della polizia stradale rendendo i semafori intelligenti, consentendo di facilitare la viabilità al cittadino e favorendo l'azione tempestiva delle forze
dell'ordine e del pronto intervento. Allo stesso tempo si potrebbe incentivare il trasporto pubblico fornendo informazioni accurate e costantemente aggiornate, oppure si
potrebbero analizzare meglio le fasce orarie in cui è maggiore la domanda del servizio
del trasporto pubblico; altre ipotesi e scenari potrebbero emergere dalla condivisione
dei dati e dalla comunicazione intelligente tra le istituzioni.
Francesco Romeo | 21
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
La Demografia: i dati sulla composizione demografica di una precisa area (la scolarizzazione, la popolazione, l'età, il sesso, il tasso di natalità e di mortalità, etc.) si configurano
come una risorsa di una certa importanza e rappresentano il centro propulsore di qualsiasi
iniziativa di carattere sociale, ma anche politico. Per
esempio, basti pensare quali vantaggi potremmo
avere se incrociassimo solo pochi dei tanti indicatori
demografici di cui siamo in possesso. Una qualsiasi
impresa potrebbe stabilire con maggiore precisione
l'opportunità di avviare o meno una determinata attività; un'area con un alto tasso di natalità, la cui popolazione è giovane e in salute, è un luogo maggiormente
indicato per la costruzione di una struttura polisportiva con piscine attrezzate anche per il
parto in acqua o parchi giochi, piuttosto che di un servizio di riabilitazione per anziani.
La Sanità: la salute di un Paese è influenzata anche dallo stato della sanità pubblica e
privata. La fruibilità di dati in questo settore permetterebbe di individuare gli sprechi e di
ottimizzare le spese e le politiche di gestione del sistema sanitario.
La Sicurezza: la vita delle persone spesso dipende anche dalla sicurezza dell'area urbana in
cui vivono. Si tratta di un ambito particolarmente sensibile.
L'Energia: è importante conoscere i dati ufficiali sul consumo e sulla produzione energetica (così come quelli sull'inquinamento atmosferico, sul diffondersi di malattie, etc.) perché ciò recherebbe un notevole vantaggio per i cittadini e permetterebbe di ridurre gli
sprechi.
Quasi per ciascuno degli ambiti di applicazione precedentemente analizzati esiste nel mondo
un'iniziativa di Open Data. Si tratta di un patrimonio pubblico, un bacino di dati e applicazioni
che si accresce ogni giorno grazie alla volontà delle istituzioni e dei governi, ma anche per merito del contributo dei singoli cittadini. Nell'ambito istituzionale la prima iniziativa in materia di
Open Data nasce negli Stati Uniti e si chiama data.gov. Questo progetto ha l'obiettivo di accrescere l'accesso pubblico alle banche dati aperte e ad alto valore aggiunto prodotte dal ramo
esecutivo del governo federale degli Stati Uniti. Inoltre, data.gov mira a portare il governo a
livello di trasparenza senza precedenti nella convinzione che la chiarezza e l'apertura derivanti
da una simile iniziativa rafforzino la democrazia e favoriscano l'efficienza del governo. data.gov
è un progetto che vuole crescere e basa le sue prospettive di crescita sulla partecipazione e
collaborazione del pubblico, sui suoi feedback o sui suggerimenti relativamente ai settori per i
quali vorrebbe che il governo pubblicasse e rendesse accessibili i suoi dati.
22 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
1.3.3 BIG DATA NELLA STATISTICA UFFICIALE
I vantaggi apportati dai Big Data agli istituiti di statistica ufficiale sono:
produzione di nuove variabili, ad esempio (le online sales) non misurate finora;
fornitura dati in tempo reale;
possibilità di costruire informazioni che aiutano a capire i fenomeni (social data mining),
a correggere e validare le informazioni e ad aumentare l'efficienza campionaria;
aggiunta di nuova conoscenza attraverso alcuni pattern/cluster (modelli che permettono di raccontare storie e migliorare l'efficienza di certi percorsi);
produzione di variabili ausiliarie per stimare meglio e predire certi fenomeni
(nowcasting).
Alcuni esempi possono essere l'indice di disoccupazione inferito dai profili di attività ottenuti per data
mining dei record di telefonia mobile, oppure il
calcolo o il monitoraggio di nuovi indicatori di benessere/performance sociale a partire da fonti di
Big Data non standard (come social network, telefonia e navigazione satellitare, social media) e dagli
acquisti della grande distribuzione (tramite carte di
fedeltà). I Big Data, tuttavia, sono suscettibili di
problemi di qualità a vari livelli, soprattutto in termini di correttezza, aggiornamento e completezza,
affidabilità o reputazione della sorgente. Essi, inoltre, possono presentare problemi legati ai metadati. Un fattore importante in questo contesto è rappresentato dalla convalida dell'affidabilità dei dati. Per esempio, si parla di “fail profile”, un profilo falso raccontato dai social network: questo è un elemento su cui fare attenzione per quanto riguarda la qualità del dato di provenienza e il risultato che si ottiene a valle. I
Big Data possono configurarsi come un'opportunità per risolvere i problemi legati alla qualità
del dato ovvero:
possono risolvere problemi di dati mancanti attingendo all'elevato numero di fonti;
possono risolvere problemi di inconsistenza sfruttando la ridondanza delle fonti.
Francesco Romeo | 23
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
2. IL PROCESSO DI ANALISI DEI BIG DATA
In questo capitolo verrà descritto il processo di analisi dei Big Data. Si mostrerà una panoramica generale del processo di estrazione di conoscenza dai database (KDD) dando maggiore rilievo alla fase di Data Mining. In seguito verrà presentata la nuova figura
professionale del data scientist; il capitolo si concluderà affrontando il tema della Privacy
by Design.
1
Il Processo KDD
2
Data Mining
3
La nuova figura del
Data Scientist
1
4
Privacy by Design nei
Big Data
Francesco Romeo | 25
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
2.1 IL PROCESSO KDD
Tutte le grandi organizzazioni, durante lo svolgimento delle proprie
attività, accumulano una gran quantità di dati. Questi grazie al progredire delle tecniche di cattura e immagazzinamento di informazioni, contengono delle risorse, delle informazioni sfruttabili, evidenti o nascoste, con differenti gradi di utilità.
Inizialmente l'analisi dei dati era un processo “manuale” e l’analista doveva avere familiarità sia
con i dati sia con i metodi della statistica: egli stesso agiva come un sofisticato processore di
query, mentre l’ elaboratore elettronico era solo un sostegno per il calcolo. Di fronte alla crescita dimensionale degli archivi di dati ed alla sempre più crescente necessità di elaborarne i contenuti, questo tipo di analisi è risultata lenta, costosa e altamente soggettiva. Di conseguenza,
si è costituita ed è cresciuta costantemente una comunità di ricercatori e professionisti interessati al problema dell’analisi automatica di grandi quantità di dati, nota come "Knowledge Discovery in Databases (KDD)”.
Gli archivi digitali sono presenti dovunque: banche,
industrie, supermercati, attività commerciali etc., e
molti processi generano flussi di record che vengono
memorizzati in enormi database, talvolta detti Data
Warehouse (magazzini di dati). Più propriamente, un
Data Warehouse è un database costruito per agevolare l’accesso alle informazioni; tipicamente è alimentato da uno o più database di transazioni e i dati devono
essere ripuliti e strutturati per facilitare le query, i
sommari e le analisi. Da ciò segue che il problema dell'estrazione di conoscenza da database
enormi andrà risolto tramite un processo di elaborazione più complesso, formato da molti
passi, che possono andare dalla semplice manipolazione dei dati a sofisticate tecniche di inferenza statistica, di ricerca e di Artificial Intelligence. La tecnologia più recente per affrontare tali
26 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
problematiche è il Data Mining. Il Data Mining sfrutta raffinate analisi statistiche e tecniche di
modellazione per scoprire pattern e relazioni nascoste nei database, che i metodi ordinari
spesso non individuano. I dati comprendono un insieme di fatti, e il pattern è un’espressione,
in qualche linguaggio, che descrive un sottoinsieme di dati (o un modello applicabile a questo
sottoinsieme), le associazioni tra essi, le sequenze ripetute o le regolarità nascoste. In definitiva, un pattern indica una struttura o, in generale, una rappresentazione sintetica dei dati.
Con il termine “Knowlegde Discovery in Databases”, si indica l’intero processo di scoperta di
conoscenza dai dati dei database. Il processo KDD prevede come input i dati grezzi e fornisce
come output le informazioni utili ottenute. Le fasi del KDD sono le seguenti:
Selezione: i dati grezzi vengono segmentati e selezionati secondo alcuni criteri al fine di
pervenire ad un sottoinsieme di dati che rappresentano il nostro target data o dati
obiettivo. Risulta abbastanza chiaro come un database possa contenere diverse informazioni che, per il problema in esame, possono risultare inutili; per fare un esempio, se
l’obiettivo è lo studio delle associazioni tra i prodotti di una catena di supermercati, non
ha senso conservare i dati relativi alla professione dei clienti; è, invece, assolutamente
errato non considerare tale variabile, che potrebbe invece fornire utili informazioni
relative al comportamento di determinate fasce di clienti, nel caso in cui si voglia effettuare un’analisi discriminante.
Francesco Romeo | 27
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Preelaborazione: spesso, pur avendo a disposizione il target data, non è conveniente nè,
d’altra parte, necessario analizzarne l’intero contenuto; può essere più adeguato dapprima campionare le tabelle e, in seguito, esplorare tale campione effettuando, in tal modo,
un’analisi su base campionaria. Fanno, inoltre, parte di questo stadio del KDD la fase di
pulizia dei dati (data cleaning), che prevede l’eliminazione dei possibili errori, e la decisione dei meccanismi di comportamento in caso di dati mancanti.
Trasformazioni: effettuata la fase precedente, i dati, per essere utilizzabili, devono essere
trasformati. Si possono convertire tipi di dati in altri o definire nuovi dati ottenuti attraverso l’uso di operazioni matematiche e logiche sulle variabili. Inoltre, soprattutto quando
i dati provengono da fonti diverse, è necessario effettuare una loro riconfigurazione al fine
di garantirne la consistenza.
Data Mining: ai dati trasformati vengono applicate una serie di tecniche in modo da poterne ricavare informazione non banale o scontata, bensì interessante e utile. I tipi di dati
che si hanno a disposizione e gli obiettivi che si vogliono raggiungere possono fornire
un’indicazione circa il tipo di metodo/algoritmo da scegliere per la ricerca di informazioni
dai dati. Un fatto è certo: l’intero processo di KDD è un processo interattivo tra l’utente, il
software utilizzato e gli obiettivi, che devono essere costantemente inquadrati, ed iterativo nel senso che la fase di Data Mining può prevedere un’ulteriore trasformazione dei dati
originali o un’ulteriore pulizia dei dati, ritornando, di fatto, alle fasi precedenti.
Interpretazioni e Valutazioni: il Data Mining crea dei pattern, ovvero dei modelli, che possono costituire un valido supporto alle decisioni. Non basta, però, interpretare i risultati
attraverso dei grafici che visualizzano l’output del Data Mining, ma occorre valutare
questi modelli per capire in che misura questi possono essere utili. E’, dunque, possibile,
alla luce di risultati non perfettamente soddisfacenti, rivedere una o più fasi dell’intero
processo KDD.
28 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
2.2 DATA MINING
La maggior parte delle aziende utilizza strumenti OLAP (On Line Analytic Processing) per
eseguire interrogazioni specifiche sui database aziendali. Il Data Mining consente, agli utenti
che sfruttano gli strumenti OLAP, di andare oltre i report
riassuntivi. Il Data Mining dice perché si sta verificando un
certo fenomeno, mentre l'OLAP si limita a dire cosa sta
accadendo (si limita a descrivere il fenomeno stesso).
Il Data Mining è un processo atto a scoprire correlazioni, relazioni e tendenze nuove e significative, setacciando grandi quantità di dati immagazzinati nei repository, usando tecniche di
riconoscimento delle relazioni e tecniche statistiche e matematiche.
Occorre tenere presente la grande differenza esistente tra statistica e Data Mining: per le
analisi statistiche la fase della trasformazione dei dati è critica poiché alcune metodologie
statistiche richiedono che i dati siano linearmente collegati ad una variabile obiettivo, normalmente distribuiti e liberi dagli outlier. I metodi dell'intelligenza artificiale e del machine
learning, invece, non richiedono rigorosamente che i dati siano normalmente distribuiti o
lineari e alcuni metodi non richiedono neppure che gli outlier siano trattati preventivamente.
Gli algoritmi del machine learning hanno la capacità di trattare automaticamente distribuzioni non lineari e non normali, anche se, in molti casi, gli algoritmi lavorano meglio se questi
criteri sono verificati.
Tuttavia, si può effettuare Data Warehousing
anche senza l’applicazione di tecniche di Data
Mining. A questo proposito l’uso di tali tecniche
si sta diffondendo sempre di più, in quanto abbiamo:
un miglior accesso ai dati, oltre che molti
più dati a cui accedere;
un grande incremento delle capacità di
elaborazione;
una migliore educazione statistica;
grandi cambiamenti nei software, ora più facili e intuitivi da utilizzare.
Francesco Romeo | 29
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Il Data Mining trova delle relazioni nei dati, ma non prende decisioni; esso fornisce ai
decision-maker le informazioni necessarie a fronteggiare le difficoltà dei mercati competitivi. I
fattori critici di successo in un progetto di Data Mining sono la conoscenza del business e l’esperienza maturata nel tempo. Questi fattori si combinano alle migliori informazioni ottenute
con il Data Mining creando un processo sinergico che porta a decisioni brillanti e veloci. Il miglior software di Data Mining gestisce autonomamente i dettagli tecnici in modo tale che gli
utenti possano concentrarsi sulle decisioni .
CRISP è l’acronimo di Cross Industry Standard Process for Data Mining. E' un approccio standard alle analisi di Data Mining che fornisce una struttura per tale processo indipendente dalla
tipologia di business nonché una guida ai potenziali problemi aziendali e alle loro soluzioni. Ciò
avviene perché lo scopo del modello è quello di rendere l'implementazione di grandi progetti di
Data Mining sempre più veloce, più
efficiente, più sicura e meno costosa.
Una delle peculiarità del modello
CRISP-DM è quella di non aver l’obbligo di seguire sistematicamente
tutte le fasi e sottofasi che esso
propone; infatti, gli analisti possono decidere di osservare un insieme di dati, che presentano
tendenze relative o circostanze eccezionali, nell’arco di settimane, mesi e anni, seguendo due
politiche di analisi alternative, ovvero le tecniche di Data Mining oppure la completa comprensione dei dati.
Il modello si snoda in sei fasi comprendenti sotto-fasi e aspetti elencati di seguito:
Business Understanding: letteralmente tradotto “Comprensione del Business”, prevede la determinazione
degli obiettivi di Business, attraverso
Background, Obiettivi di business e
Criteri di successo del business, per
poi passare alla valutazione della
situazione con inventario delle risorse, requisiti, assunzioni e vincoli,
rischi e contingenze, terminologia,
30 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
costi e benefici. Si prosegue con la determinazione degli obiettivi di Data Mining, con
obiettivi di Data Mining e criteri di successo del Data Mining. Infine troviamo la produzione del piano di progetto con piano di
progetto, valutazione iniziale di strumenti
e tecniche.
Data Understanding: letteralmente tradotto “Comprensione dei Dati”, prevede
la raccolta dei dati iniziali, la loro descrizione, la loro esplorazione e la verifica
della loro qualità, tutti opportunamente
inseriti in report appositi.
Data Preprocessing: letteralmente tradotto “Preparazione dei Dati”, prevede la descrizione della base di dati, la selezione dei dati con annessi i criteri per inclusione ed esclusione, la pulizia dei dati con report, la costruzione dei dati con attributi derivati e record
generati, l’integrazione dei dati e, infine, impostazione dati.
Modeling: letteralmente tradotto “Modellazione”, prevede la scelta della tecnica di
modellizzazione, la generazione del progetto di test e, infine, il progetto di test, la costruzione del modello, con l’impostazione dei parametri, e la descrizione del modello
stesso, la valutazione del modello, con una possibile reimpostazione dei parametri.
Evaluation: letteralmente
tradotto “Valutazione”; in
questa sotto fase si valutano i
risultati di Data Mining in
relazione ai criteri di successo
del business e ai modelli approvati, si revisiona il processo
e si determinano i passi successivi elencando le possibili
azioni e decisioni.
Deployment: letteralmente
tradotto “Utilizzo”, prevede la
Francesco Romeo | 31
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
formazione del piano di utilizzo, del
piano di monitoraggio e mantenimento, della produzione del report finale e
la presentazione finale, nonché la
recensione del progetto, con la presentazione della documentazione
dell’esperienza.
32 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
2.3 LA NUOVA FIGURA DEL DATA SCIENTIST
Quella del data scientist è stata definita dall'economista Hal Ronald Varian «la professione
più sexy del futuro», laddove l'aggettivo “sexy” assume l'accezione di «interessante».
La continua crescita dei dati in formato digitale, disponibili nelle moderne organizzazioni, ha
fatto emergere il ruolo strategico di una nuova figura professionale che deve avere più competenze. La prima è sapere gestire, acquisire, organizzare ed elaborare dati. La seconda è di
tipo statistico, ovvero il sapere come e quali dati estrarre. La terza è il sapere comunicare a
tutti, con diverse forme di rappresentazione, cosa suggeriscono i dati.
La caratteristica principale di questa figura deve essere la “curiosità”, cioè l’attitudine, tipica
di chi utilizza il metodo scientifico, di analizzare in profondità i fenomeni, non fermandosi alla
apparenza, e di identificare un insieme di ipotesi da verificare ed esplorare con l’analisi e lo
studio dei dati. Da questo punto di vista si può paragonare il lavoro del data scientist a quello del fisico sperimentale che, spesso, deve progettare gli strumenti,
condurre gli esperimenti, analizzare i dati ottenuti e
presentare i risultati a tutta la comunità scientifica,
oltre che ai responsabili delle ricerche.
Il data scientist deve avere tre set di skill, ovvero una
preparazione informatica molto solida, una buona
comprensione degli aspetti tecnologici e, allo stesso
tempo, una conoscenza degli aspetti aziendali. Inoltre, ma non di poco conto, il data scientist
deve possedere la conoscenza delle problematiche e delle sfide del dominio settoriale
(industria, finanza, telecomunicazioni, settore pubblico, etc.) di interesse.
Ci sono decine tra atenei e centri studio che offrono formazione specifica. I poli mondiali sono
USA e UK, dove nei primi anni del Duemila si erano già create metodologie e procedure. Alle
nostre latitudini le aziende cominciano a concepire la necessità di una simile figura e cercano
di formarla al proprio interno. Il data scientist lavora con i big data ed è in questa direzione
che bisogna muoversi; le anagrafiche sono il primo patrimonio di un'azienda; questo concetto non è ancora del tutto consolidato in Italia, e questo, da solo, spiega già gran parte
dell'handicap che abbiamo in materia di scienza dei dati.
Francesco Romeo | 33
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
2.4 PRIVACY BY DESIGN NEI BIG DATA
La quantità dei dati digitali, come abbiamo visto, cresce a ritmi esponenziali. La gestione dei
Big Data pone alcune riflessioni da fare per garantire il rispetto della riservatezza e la protezione dei dati personali.
Archivi informatizzati contenenti dati personali sono posseduti dalle Pubbliche Amministrazioni, dalle aziende private, dai media, dai professionisti, dalle associazioni e dalle organizzazioni
di vario tipo.
La Dr. Ann Cavoukian (Information & Privacy Commissioner Ontario, Canada) presenta così il
tema della Privacy by Design:
“La Privacy by Design è un
concetto che ho sviluppato
negli anni ‘90 per far fronte
agli effetti sempre crescenti e
sistematici delle Tecnologie
dell’Informazione e della Comunicazione e dei sistemi di
dati delle reti su larga scala.
La Privacy by Design anticipa
la visione che il futuro della
privacy non può essere assicurato unicamente dal processo
di conformità con il sistema
normativo; piuttosto, la garanzia della privacy deve costituire idealmente un modo di operare
di default di un’organizzazione. Inizialmente, l’attuazione delle tecnologie per rafforzare la
privacy (Privacy-Enhancing Technologies - PETs) era vista come la soluzione. Oggi, realizziamo che è richiesto un approccio più sostanziale – che estende l’uso delle PET alle PETS Plus –
con un approccio di valore aggiunto (di massima funzionalità), e non di valore zero. Questo è
il Plus nelle PET Plus: valore aggiunto, non se/o di valore zero (una falsa dicotomia).”
La Privacy by Design, quindi, propone qualcosa veramente interessante ed innovativo: il processo di conformità relativo alla
sicurezza della privacy non può essere assicurato unicamente
tramite il sistema normativo; piuttosto, la garanzia della privacy
34 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
deve costituire idealmente il modo di operare di default di un’organizzazione. Privacy by
Design si riferisce alla filosofia e all'approccio di considerare la privacy nelle specifiche di
progettazione delle varie tecnologie.
La Privacy by Design trova spazio nella trilogia di applicazioni:
Tecnologia dell’informazione;
Pratiche commerciali responsabili;
Progettazione strutturale e infrastrutture di rete.
In particolare, con riferimento alla tecnologia dell’informazione, si afferma, come già evidenziato, che la tecnologia non può costituire una minaccia per la privacy, ma un ausilio per la
riduzione dei rischi. Per le pratiche commerciali responsabili, viene evidenziato come la privacy non va interpretata come un onere, ovvero un costo che appesantisce l'attività imprenditoriale, ma, al contrario, come un vantaggio per una migliore competitività. Infine, l’elemento
della progettazione delle strutture assume rilevanza poiché molto spesso siamo costretti a
vedere esposti i dati personali in aree pubbliche mal progettate come, ad esempio, le sale
d’attesa degli ospedali o degli uffici, ove è possibile che vengano, illecitamente, divulgate le
informazioni personali.
Fermo il contesto rappresentato dai tre punti precedenti, la
Privacy by Design si fonda su
sette principi:
Proattivo non reattivo (prevenire non correggere): l’approccio alla Privacy by Design
(PbD) è caratterizzato da interventi di tipo proattivo piuttosto che reattivo. Esso anticipa e previene gli eventi invasivi della privacy prima che essi accadano. La PbD non attende che i rischi della privacy si concretizzano né offre rimedi per risolvere le violazioni
della privacy una volta occorse: essa ha lo scopo di prevenirli prima che questi si verifichino. In breve, la Privacy by Design viene prima del fatto e non dopo.
Privacy come impostazione di default: possiamo tutti essere certi di una cosa - la regola
di base! La Privacy by Design cerca di realizzare il massimo livello di privacy assicurando
che i dati personali siano automaticamente protetti in un qualunque sistema IT o di
pratica commerciale. Se un individuo non fa nulla, la sua privacy rimane ancora intatta.
Francesco Romeo | 35
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Non è richiesta alcuna azione da parte dell’individuo per proteggere la propria privacy:
essa è incorporata nel sistema per default.
Privacy incorporata nella progettazione: la PbD è incorporata nella progettazione e nell’architettura dei sistemi IT e delle pratiche commerciali. Non è agganciata come un’aggiunta, dopo il fatto. Il risultato è che la privacy diventa un componente essenziale per la realizzazione del nucleo funzionale. La privacy è integrata nel sistema, senza diminuirne la
funzionalità.
Massima funzionalità − Valore positivo, non valore zero: la Privacy by Design mira a conciliare tutti gli interessi legittimi e gli obiettivi con modalità di valore positivo
“vantaggioso per tutti”, non attraverso un approccio datato di valore zero, dove sono
inutili i compromessi. La Privacy by Design evita la pretesa di false dicotomie, come la
privacy contro la sicurezza, dimostrando che è possibile avere entrambi.
Sicurezza fino alla fine − Piena protezione del ciclo vitale: la Privacy by Design, essendo
stata incorporata nel sistema prioritariamente rispetto all’acquisizione del primo elemento di informazione, si estende in modo sicuro attraverso l’intero ciclo vitale dei dati - solidi
interventi di sicurezza sono essenziali per la privacy, dall’inizio alla fine. Questo assicura
che tutti i dati siano conservati con cura, e poi distrutti in modo sicuro alla fine del processo, in maniera opportuna. Pertanto, la Privacy by Design garantisce un’intera e sicura
gestione delle informazioni, fino alla fine.
Visibilità e trasparenza − Mantenere la trasparenza: la Privacy by Design cerca di assicurare
che tutti i soggetti interessati, qualunque sia la prassi aziendale o tecnologia utilizzata, è,
di fatto, operativa secondo promesse ed obiettivi stabiliti, soggetti a verifica indipendente. I suoi componenti e le sue operazioni restano visibili e trasparenti sia agli utenti sia ai
fornitori. Si ricorda di fidarsi ma di verificare.
Rispetto per la privacy dell’utente − Centralità dell’utente: al di là di tutto, la Privacy by
Design richiede ai progettisti e agli operatori di considerare prioritari gli interessi degli
individui offrendo efficaci interventi di default della privacy e informazioni appropriate,
nonché potenziando opzioni di facile utilizzo per l’utente. Si raccomanda la centralità
dell’utente.
Come si può notare, si tratta di una vera e propria rivoluzione della privacy che non concerne
36 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
soltanto le misure tecniche per assicurare adeguata sicurezza ai dati personali, ma una serie
di concetti innovativi che prescindono dall’assolutizzare la protezione dei dati personali per
giungere alla considerazione che la sicurezza delle informazioni è insita nel concetto stesso di
privacy.
La 32 ma Conferenza Internazionale dei Garanti della Privacy (Gerusalemme, 27-29 Ottobre
2010) ha definito il concetto di Privacy by Design proposta dalla Dr. Ann Cavoukian come una
pietra miliare.
L’articolo 23 della proposta di regolamento del Parlamento Europeo e del Consiglio, concernente la tutela delle persone fisiche con riguardo al trattamento dei dati personali e alla libera
circolazione di tali dati (Gennaio 2012), prende spunto da quanto sostenuto dalla Dr. Ann
Cavoukian.
Nello specifico :
“Al momento di determinare i mezzi del trattamento e all’atto del trattamento stesso, il
titolare mette in atto adeguate misure e procedure tecniche e organizzative tali da assicurare la conformità al presente regolamento nonché la tutela dei diritti dell’interessato”,
e ancora:
“Il titolare del trattamento mette in atto meccanismi per garantire che siano trattati, di
default, solo i dati personali necessari per ciascuna finalità specifica del trattamento e che,
in particolare, la quantità di dati e la durata della loro conservazione non vadano oltre il
minimo necessario per le finalità perseguite. In particolare, detti meccanismi garantiscono
che, di default, non siano resi accessibili dati personali a un numero indefinito di persone”.
Francesco Romeo | 37
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Si chiede , quindi , che vengano rispettati due principi:
principio della “privacy by
design”, cioè protezione fin
dalla progettazione, che si
sostanzia nell’attuare, fin
dal principio, tutte le necessarie misure tecnicoorganizzative al fine di
scongiurare i rischi cui sono
esposti i dati personali;
il collegato principio della
“privacy by default”, cioè
protezione a prescindere, che si realizza attraverso l’essenzialità del trattamento sotto
ogni punto di vista.
38 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
3. NOSQL
In questo capitolo si parlerà del movimento NoSQL e verranno mostrati i principi fondanti
di questo tipo di tecnologia. Verrà fatto un confronto tra i database tradizionali
(RDBMS), che utilizzano il modello relazionale, e i database che sfruttano il modello
NoSQL. Si concluderà presentando le varie tipologie di DBMS NoSQL che sono state
sviluppate.
1
Cosa si intende per
NoSQL
2
RDBMS vs. NoSQL
3
I Principi Fondanti del
NoSQL
1
4
Tipologie di DBMS
NoSQL
Francesco Romeo | 39
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
3.1 COSA SI INTENDE PER NOSQL
Negli anni novanta Internet ha permesso a molte aziende di ampliare il proprio bacino di utenza portando online
un’enorme quantità di contenuti e
servizi; di conseguenza, la quantità dei
dati presenti in rete è aumentata esponenzialmente. Per questo motivo i
sistemi informatici, per poter elaborare
le informazioni, hanno avuto bisogno
di una maggiore potenza di calcolo,
mentre per i dati , sempre più numerosi, è stata necessaria una migliore organizzazione.
Negli ultimi anni sono aumentate le
aziende operanti esclusivamente online fornendo contenuti sempre più numerosi e strutturati. Dunque, la disponibilità e affidabilità
dei servizi, insieme alla capacità di gestire una grande mole di contenuti, fortemente correlati,
sono diventati punti di estrema importanza. Infatti, capita sempre più spesso che le aziende
rendono più stringenti gli SLA (Service Level Agreement) traducendo, a livello contrattuale, le
aspettative dell’utente finale, ovvero che il servizio sia sempre disponibile, facilmente accessibile (sia come tempi di risposta che come usabilità) e possibilmente attendibile. La tendenza è
diventata quella di garantire maggiormente il servizio o il contenuto rispetto alla correttezza
delle informazioni o alla consistenza dei dati, fatta eccezione nei casi di servizi sotto protocollo
sicuro (ad esempio il settore bancario, l’e-governance o alcune fasi di sicurezza dei dati nell’ecommerce). I sostenitori di questo nuovo approccio sono stati Google e Amazon, con i loro
sistemi proprietari (rispettivamente, BigTable e Dynamo) ma da subito, soprattutto nell’ambito
dei social network, si sono sviluppati sistemi di gestione equiparabili e diversi dai database
40 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
relazionali (RDBMS). A questi nuovi sistemi è stato dato il nome di DBMS NoSQL (NoSQL).
Con il termine NoSQL si raggruppano varie tecnologie di persistenza dei dati, anche molto
diverse fra loro. L'acronimo stesso è piuttosto vago e soggetto a varie interpretazioni, di cui
la più rilevante e accettata sembra essere “Not Only SQL”.
Per stabilire un punto di partenza, considereremo l'interpretazione fornita da Pramod e Fowler in NoSQL Distilled:
“Un insieme poco definito di database principalmente open-source, principalmente sviluppati nel XXI secolo, principalmente che non fanno uso di SQL”
Per completare questa occorre aggiungere che:
non utilizzano il modello relazionale;
non hanno (solitamente) uno schema
esplicito, ovvero specificato utilizzando
un qualsiasi linguaggio formale;
la maggior parte di essi e stata progettata da subito per funzionare “bene" in
cluster.
Francesco Romeo | 41
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
3.2 RDBMS VS. NOSQL
Mentre la caratteristica principale dei sistemi relazionali è quella di mantenere una forte consistenza fra i dati, i database NoSQL garantiscono, in ogni circostanza, alti livelli di disponibilità
dei dati ed una elevata velocità di recupero, a discapito della consistenza dell’informazione.
Per i database relazionali di parla di proprietà acide (ACID) mentre per i database NoSQL si
passa a parlare di proprietà base (BASE).
Le proprietà ACID indicano le caratteristiche che devono avere le transazioni. Nello specifico:
Atomicity – Atomicità: l’esecuzione della transazione deve essere o totale o nulla; quindi, o
si riescono ad eseguire tutte le operazioni della transazione o questa viene disfatta; un
errore prima del commit deve causare l’annullamento di tutte le operazioni eseguite
dall’inizio della transazione.
Consistency - Coerenza: la transazione trasforma la base di dati da uno stato consistente
(cioè che riflette lo stato reale del mondo che la base di dati deve modellare) ad un altro
stato ancora consistente. La consistenza richiede che l’esecuzione della transazione non
violi i vincoli di integrità definiti sulla base di dati.
Isolation - Isolamento: ogni transazione è indipendente dalle altre. Il suo fallimento non
deve provocare danni ad altre transazioni.
Durability - Persistenza: al commit della transazione, le modifiche
apportate dalla stessa non dovranno
essere perse in nessun modo.
Le proprietà BASE sono state introdotte da Eric Browers, autore del Teorema di CAP. Questo
teorema afferma che un sistema distribuito può fornire contemporaneamente solo due fra le
seguenti garanzie:
Consistency (Consistenza): tutti i nodi vedono gli stessi dati nello stesso momento;
42 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Availability (Disponibilità): il sistema risponde a tutte le richieste;
Partition tolerance (Tolleranza al Partizionamento): il sistema continua ad operare anche
se alcune delle sue parti rimangono isolate dalle altre in modo arbitrario (ovvero, se il
grafo che rappresenta il sistema è disconnesso).
In verità, poiché si sta trattando di sistemi distribuiti, è praticamente impossibile garantire
una tolleranza completa al partizionamento, perché è sempre possibile che il collegamento
fra due nodi venga meno. La scelta da compiere, dunque, si riduce a:
rinunciare alla consistenza in favore della disponibilità;
rinunciare alla disponibilità in favore della consistenza.
Questa scelta non è binaria (“tutto o niente”), ma sono possibili varie sfumature. E possibile
rinunciare ad un po' di consistenza per poter avere un sistema sempre disponibile, ovvero che
sia in grado di dare sempre una
risposta (anche se magari utilizzando dati non aggiornati), e viceversa.
L’acronimo BASE indica le caratteristiche che un sistema deve avere
sottostando al teorema di CAP,
ovvero, esso deve garantire la disponibilità delle informazioni (Basically
Available ), tuttavia non deve garantire la consistenza ogni istante (Soft
State), ma alla fine deve diventare
consistente (Eventual consistency)
se le attività di modifica ai dati cessano. Quindi, le inconsistenze sono
transitorie.
Quando la disponibilità dell’informazione è prioritaria, è possibile lasciare che l'applicativo scriva su un nodo senza che si riceva
l’autorizzazione alla propagazione di queste scritture sugli altri nodi in cui ci si aspetta venga
replicato. Questo fa si che si raggiungano alti livelli di disponibilità (non ci sono tempi di atte-
Francesco Romeo | 43
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
sa) a fronte di quella che definiamo
“eventual consistency”, ovvero la capacità
del sistema di saper sistemare le informazioni sui vari nodi, col passare del tempo,
in maniera asincrona.
Rick Cattell, nell’articolo “Scalable SQL
and NoSQL Data Stores” elenca le proprietà comuni alla maggioranza dei sistemi di tipo NoSQL:
possibilità di replicare e distribuire partizioni di dati su più server;
possibilità di scaling orizzontale per “operazioni semplici”;
un’ interfaccia o protocollo di chiamata semplificato, a differenza delle implementazioni
SQL basate su binding ;
un modello di concorrenza più debole rispetto a quello garantito dai DBMS che supportano tutte le proprietà ACID;
un uso efficiente della memoria e di indici distribuiti;
una capacità di aggiungere dinamicamente nuovi attributi.
L’ aspetto più evidente, quando si confrontano DBMS relazionali e NoSQL, è che i primi appartengono ad uno standard de facto: i risultati di richieste effettuate tramite opportune query
possono essere visualizzati in ambienti standard. Per i DBMS NoSQL, invece, non si ha una
vera e propria standardizzazione; pertanto, ogni implementazione ha una interfaccia utente
propria e, quindi, da conoscere ed imparare.
La scalabilità orizzontale è una caratteristica di particolare importanza quando si parla di Big
Data. Con questo termine si intende la possibilità di distribuire i dati e le operazioni su macchine fisiche differenti, senza memoria o dischi rigidi in comune, al fine di parallelizzare le operazioni e ottenere un minore quantitativo di dati da elaborare per singolo server. Nonostante sia
possibile aumentare le prestazioni anche tramite scaling verticale (aumentando il numero di
core e processori di una singola macchina), l’approccio distribuito permette di ridurre i costi,
44 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
utilizzando macchine assemblate, e di superare i limiti hardware dati dal quantitativo massimo di core e memoria installabili su un singolo mainframe. La scalabilità ha assunto un ruolo
particolarmente importante con l’avvento dei social network dove le operazioni più comuni
sono semplici ma molto frequenti e bisogna tener conto di milioni di utenti che operano
contemporaneamente. Una distribuzione dei dati agile e automatica è una caratteristica di
grande importanza per un DBMS non relazionale.
Francesco Romeo | 45
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
3.3 I PRINCIPI FONDANTI DEL NOSQL
Uno dei motivi che ha spinto verso l’utilizzo dei DBMS NoSQL è che, in alcuni progetti, l'integrità dei dati non è prioritaria, nè tantomeno obbligatoria. In questo contesto accade che:
Computer e sistemi di memorizzazione predisposti a garantire performance e sicurezza
delle informazioni di altissimo livello possono essere sostituiti con sistemi dotati di caratteristiche di più facile accesso, sia in termini di reperibilità del materiale che di costo.
L'accesso ai dati diventa molto più rapido: non dovendo sempre garantire una consistenza degli stessi, le letture e le scritture delle informazioni possono essere eseguite senza
attendere particolari eventi.
Quasi tutti i DBMS NoSQL sono stati progettati sin dal principio per funzionare da subito in
modalità distribuita, ovvero su più server. E’ possibile fare un elenco dei modelli di distribuzione:
Single Server: questa modalità è la più semplice, nonché la meno problematica. Con un
solo server di database; infatti, gli unici problemi da risolvere sono relativi alla gestione dei
conflitti in lettura e scrittura fra i vari client.
Ambiente Multi-Nodo: viene creato un ambiente
multi-nodo distribuito a cui viene dato comunemente il nome di anello (o ring o cluster); quest’ultimo lo si può ampliare o ridurre aggiungendo o eliminando dei nodi.
Replica delle informazioni : la replicazione dei
dati è uno stratagemma utilizzato con diversi
scopi. Il primo è che, distribuendo gli stessi dati
su più server, aumenta la loro disponibilità e
l'affidabilità dell'insieme. Se un nodo cade, infatti, ci sono gli altri che possono sostituirlo
mentre viene riparato e rimesso online. Il secondo scopo è quello di migliorare le performance in lettura. Avere molti nodi con gli stessi dati permette una parallelizzazione praticamente lineare delle letture, che possono essere distribuite in modo del tutto trasparente ai client. Inoltre, sfruttando il principio di località dei dati, è possibile erogare i dati dal
nodo più vicino al client che li ha richiesti, migliorando tempi di risposta e velocità di tra-
46 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
sferimento, alleggerendo, al
contempo, il traffico
“globale" dell'infrastruttura.
Sharding dei dati : questa
modalità è la più complessa;
essa prevede, infatti, il partizionamento dei dati in base
a vari criteri sui vari nodi,
mantenendo gli stessi vantaggi della replicazione
(affidabilità, prestazioni in
lettura) e aggiungendone di nuovi. Il principale vantaggio dello Sharding è che, per
come è utilizzato nei database aggregate-oriented, ha un effetto positivo anche sulle
scritture, oltre che sulle letture. I dati inviati dai client, infatti, vengono scritti sul primo
nodo disponibile, con tempi di risposta simili alla modalità single server.
I DBMS NoSQL usano dei sistemi per la gestione della concorrenza che permettono una
elevata efficienza a livello di prestazioni e tempi di risposta, ma non garantiscono un'altrettanto livello di sicurezza dal punto di vista della correttezza assoluta dei dati. Questo perché
essi sono stati creati per lavorare in ambienti dove vengono effettuate molte letture e scritture contemporaneamente.
Il Multi-Version Concurrency Control permette di mantenere un controllo della concorrenza
basato su continui versioning dei dati.
Quando è necessario modificare un documento precedentemente letto, il sistema confronta la versione al
tempo della lettura con quella appena prima che la
modifica sia stata apportata: se le due versioni sono
diverse significa che nel frattempo un altro processo
ha modificato il documento.
Il concetto legato al multiversioning è il seguente:
ogniqualvolta un documento viene modificato, viene
generata una copia (una nuova versione) dello stesso.
Un vantaggio che si può evidenziare è che queste non
Francesco Romeo | 47
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
sono altro che nuove versioni e non modifiche, tutto a vantaggio della velocità; tuttavia, produrre continuamente nuove versioni significa occupare spazio ed è, quindi, inevitabile che non
potranno essere mantenute tutte le versioni create.
Quando si parla di consistenza si intende il recupero delle informazioni tale che queste siano
corrette. Si parla di stretta consistenza nel caso in cui tutte le letture successive ad una scrittura
debbano garantire che i dati siano tali a come la scrittura li ha impostati; quindi, o le letture che
seguono la scrittura avvengono nello stesso nodo o deve essere utilizzato un protocollo distribuito ad hoc che permetta il verificarsi di questa condizione. Questo tipo di consistenza, ricordando il teorema di CAP, non può essere garantita insieme a disponibilità e fault-tolerance dei
dati; infatti, è necessario che si rinunci al
partizionamento dei
dati o alla disponibilità costante dell’informazione.
Si parla di “eventual
consistency”, invece,
nel caso in cui le letture possano ritornare
dei valori non aggiornati all’ultima scrittura effettuata; anche in
questo caso, però, il
sistema prima o poi farà in modo che questo valore venga correttamente propagato. Appartengono a questa categoria più tipi di consistenza:
Read Your Own Write (RYOW) Consistency: un client che effettua una scrittura può vedere
le letture successive già coerenti, indipendentemente dal server su cui la scrittura e le
letture successive siano effettuate. Questo non vale per gli altri client che eseguono letture successive alla scrittura del client in oggetto.
Session Consistency: simile alla RYOW con la differenza che le letture successive ad una
data scrittura risultano corrette solo all’interno di un certo ambito, ad esempio limitata-
48 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
mente ad un nodo.
Casual Consistency: se un client legge una Versione 1, e scrive conseguentemente una
nuova versione, tutti i client che leggono la nuova versione proposta, in precedenza
leggevano anche la Versione 1.
Monotonic Read Consistency: se un dato client legge un valore per una certa informazione allora, da questa lettura in poi, accedendo con ogni altro client su questa informazione, non sarà possibile leggere valori antecedenti.
Nei DBMS NoSQL le tipologie di versioning che vengono implementate sono legate al fatto
che le informazioni vengono distribuite su più nodi. Le varie operazioni di lettura e scrittura
possono avvenire su nodi diversi e non può, quindi, essere garantita una consistenza stretta.
Tra i vari sistemi di versioning adottati, quelli che esamineremo più nel dettaglio sono:
Vector Clocks;
Optimistic Locking.
Il Vector Clocks permette di avere un ordinamento di versioni tra le varie operazioni effettuate sui nodi. Si pensi di avere N nodi, ciascuno con un suo clock interno, che può benissimo
essere un contatore che viene incrementato quando serve. Per ogni operazione effettuata su
un nodo, sia essa di lettura o di scrittura, viene incrementato il valore del clock per il nodo
stesso. Ogni nodo memorizza al suo interno un vettore (da cui Vector Clocks) che rappresenta lo stato dei vari contatori sui singoli nodi. Ad ogni operazione eseguita su un nodo, questo
vettore, modificato il valore del nodo in cui l'operazione è avvenuta, verrà propagato sui nodi
restanti. Dunque, si generano sequenze che possono garantire di per sè la coerenza su tutti i
nodi. Se ciò non è possibile sarà un applicativo a dover sbrogliare la situazione e decidere
quale nodo definire coerente rispetto ad altri.
Nell’Optimistic Locking un unico clock viene salvato per ogni blocco di dati. Questo tipo di
versioning è stato approfondito dai fautori del progetto Project-Valdemort con la conclusione che in scenari distribuiti dove le macchine vengono aggiunte continuamente ed altre disattivate o rotte improvvisamente, il sistema risulta poco funzionale.
I sistemi di partizionamento permettono di distribuire le informazioni sul cluster che costituisce il DBMS NoSQL. Ci sono più tipi di partizionamento; di seguito ne elenchiamo alcuni:
Francesco Romeo | 49
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Consistent Hashing;
Memory Cached ;
Clustering ;
Separating Reads from Writes;
Sharding .
Di questi, quelli normalmente più
usati sono il Consistent Hashing e
lo Sharding .
Il Consistent Hashing viene usato per la distribuzione automatica dei dati tra i nodi; esso garantisce che i dati siano ugualmente distribuiti attraverso il cluster e che l’aggiunta o la rimozione
di un nodo in esso possa avvenire automaticamente, limitando il numero di spostamenti dei
dati. La stessa funzione di hashing usata per i dati viene adottata anche per le macchine del
cluster; questo permette di calcolare direttamente dal nodo contattato dall’applicazione quale
nodo contattare per scrivere o leggere dei dati, senza dover passare da un cluster di server
dedicati atti a recuperare l'informazione desiderata.
Il Consistent Hashing garantisce,
anche, un sistema
di replica basato su
una scelta di progetto dove si fissa
un valore K, ovvero
un valore numerico
che determina
quante repliche
devono essere
mantenute per i
dati.
50 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Lo Sharding è un sistema di distribuzione delle
informazioni effettuato sui nodi appartenenti al
cluster; questa distribuzione viene dettata da un
processo iniziale in cui avviene la definizione della
chiave di sharding. Supponiamo di avere 10 nodi su
cui distribuire i dati; possiamo pensare ad una
chiave di Sharding tale che il modulo della divisione per 10 della chiave primaria (numerica) di ogni
dato permetta di decidere dove posizionare il dato
stesso. Questo sistema di distribuzione dei dati
necessita di macchine dedicate a questo compito,
oltre a quelle mantenenti le informazioni.
Francesco Romeo | 51
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
3.4 TIPOLOGIE DI DBMS NOSQL
Ogni modello di DBMS NoSQL è stato ispirato da quelli sviluppati ed implementati da Amazon
e Google: Amazon con Dynamo, Google con BigTable.
Le necessità dei due colossi sono state dettate dal bisogno di mantenere disponibili e scalabili
le informazioni in alcuni ambiti che possono andare, ad esempio, dalla pagina dei libri più venduti a quello della lista dei desideri dei singoli utenti.
Si tende a raggruppare i DBMS NoSQL in quattro categorie fondamentali:
Key-Value Distribuiti;
Document Oriented;
Column Oriented;
Graph Oriented.
Tuttavia, alcuni DBMS NoSQL possono avere caratteristiche che appartengono a più di una di
queste categorie.
La caratteristica principale dei modelli Key-Value Distribuiti è, sicuramente, la semplicità delle
strutture dati, che sono “appiattite" in coppie chiave-valore. In sostanza, l'utilizzatore vede la
base di dati come una grossa hash table contenente oggetti di vario tipo (principalmente valori
primitivi, come numeri o stringhe), accessibili tramite chiave primaria. Questa soluzione rende
possibili altissime performance
(tipicamente in lettura), facilitando, al
tempo stesso, il lavoro di distribuzione
del carico su più macchine
(partizionamento o Sharding) per realizzare una scalabilità quasi lineare. L'indirizzamento di tipo hash, infatti, consente di ottenere un costo di accesso molto
basso, tipicamente compreso fra O(1)
(analisi ammortizzata nel caso di un
fattore di riempimento non troppo ele-
52 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
vato) e O(log(n)), dove n è uguale al numero di dati presenti nello storage. Il vantaggio di un
sistema di questo tipo è l’altissima concorrenza e, quindi, la disponibilità delle informazioni, a
discapito della consistenza dei dati. Questi DBMS garantiscono replica e fault-tolerance
nonché, in molti casi, anche persistenza dei dati su disco e non solo in RAM.
La categoria dei Document Oriented raggruppa quei database che permettono di effettuare
delle ricerche, oltre che sulle chiavi, anche sui valori legati ad esse: questo perché i valori sono
rappresentati da strutture in formati pensati proprio a tal fine, ovvero XML o JSON. Abbiamo
a che fare con un aggregato che può avere una struttura anche molto profonda, con più livelli
gerarchici e raggruppamenti in collezioni di vario genere (liste, insiemi, mappe, etc.). Quasi
tutte le implementazioni permettono, inoltre, di inserire dei riferimenti ad altri documenti
rendendoli molto simili nel funzionamento ai cosiddetti database a oggetti. A differenza dei
Key-Value Distribuiti, in questo caso, il fine ultimo non è quello di garantire un’altissima concorrenza, ma quello di fornire un sistema di interrogazione sui dati con performance elevate
permettendo la memorizzazione di grossi quantitativi di informazioni. Questi tipi di DBMS
sono molto apprezzati per la grandissima flessibilità, che permette di ottenere modelli dei
dati complessi senza penalizzare le performance. Per questo motivo sono molto utilizzati per
la realizzazione di siti web, per l’e-commerce, la gestione documentale, i web service e i giochi multiplayer massivi.
I DBMS che appartengono alla categoria Column Oriented introducono il concetto di Column
-Family. Una Column-Family è un’informazione che deve essere presente nello schema (a sua
volta, quindi, necessario) e che serve a raccogliere informazioni di un gruppo; un po' quello
che viene fatto per la definizione delle colonne per un DBMS relazionale, ma relativo ad un
gruppo di colonne, non ad una singola colonna. Ogni Column-Family raggruppa un insieme di
colonne appartenenti ad
una stessa tipologia di
informazione; si pensi,
ad esempio, ad una
Column-Family
“anagrafica” con colonne costituenti nome,
cognome, età e sesso.
La Column-Family deve
essere presente nello
schema, ma è ,altresì,
Francesco Romeo | 53
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
vero che le colonne che la costituiscono non devono essere definite a priori, ovvero ogni record
può avere informazioni diverse per la propria Column-Family “anagrafica”. Supponiamo, ad
esempio, di avere una singola unità informativa (quella che in un RDBMS chiamiamo tupla o
riga) e che per essa siano definite N Column-Family nello schema: se una o più informazioni
non sono disponibili per l'unità informativa in questione, allora le Column-Family (contenitori di
colonne), semplicemente non presenteranno al loro interno le colonne per le quali non si ha la
valorizzazione. Quindi, se il valore per la chiave esiste, la colonna è presente ed è nella ColumnFamily corretta; se il valore non esiste, la colonna semplicemente non esisterà e la ColumnFamily ne sarà priva.
Riassumendo, le caratteristiche principali sono:
flessibilità delle colonne appartenenti ad una Column-Family;
partizionamento orizzontale legato alla Column-Family;
una data Column-Family non può essere “spezzata”, ma ogni record appartenente ad
essa può trovarsi su un server diverso;
uso di particolari file di log per permettere un più veloce sistema di storage;
mancanza di un supporto transazionale.
Questi DBMS hanno grande successo nel campo dei Big Data, potendo fornire un modello
logico organizzato e flessibile. Inoltre, proprio per la loro maggiore adattabilità a modelli di
dati ricchi, sono sempre più spesso utilizzati al posto dei DBMS relazionali in campi come: siti
web ad alto traffico, web service, backend di applicazioni “mobile”. Infine, grazie alla facilita
con cui si possono partizionare i dati, e alla conseguente possibilità di ottimizzare moltissimo le
scritture, spesso i Column-Family store sono utilizzati per memorizzare log applicativi, statistiche per analytics e monitoring, audit di vario genere, etc.
Le precedenti tipologie focalizzano l’attenzione sulla scalabilità dei dati e sulla flessibilità delle
informazioni; esse hanno, però, il problema di non poter contenere dati troppo connessi. Da
questa nuova esigenza prende luce l’idea dei NoSQL orientati ai grafi. Possiamo immaginare
questa categoria come una Document Oriented con la clausola che i documenti sono anche
adibiti a rappresentare le relazioni. Strutture di questo tipo permettono il passaggio da un nodo
54 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
ad un altro (graph traversal) e sono, quindi,
molto utilizzati nel campo del Social Network.
I DBMS Graph Oriented permettono di estrarre, in tempi ragionevoli e in maniera molto
elegante, dati di grandissimo valore per applicazioni quali:
classificazione tramite algoritmi di vicinanza e clustering;
analisi di flussi di vario genere: navigazione in siti web e in social network,
ecologia, urbanistica, etc.
prolazione degli utenti e suggerimenti
per amicizie o acquisti.
Per questo motivo sono sempre più indispensabili quando si rende necessaria un'analisi delle
relazioni fra i dati, più che i dati stessi.
Qui di seguito riassumiamo le caratteristiche principali che contraddistinguono le tipologie
viste.
Francesco Romeo | 55
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
4. HADOOP
In questo capitolo si parlerà del framework Hadoop per l’analisi distribuita di grandi
insiemi di dati. Verranno trattati i suoi sottoprogetti fondamentali: MapReduce e HDFS.
L’ultimo paragrafo del capitolo riguarderà l’innovativo YARN.
1
Cosa è Hadoop
2
MapReduce
3
HDFS
1
4
YARN
Francesco Romeo | 57
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
4.1 COSA E’ HADOOP
Uno dei principi chiave per operare con i Big Data è l’immagazzinamento di tutti i dati originali,
indipendentemente da quando questi saranno utilizzati. Di conseguenza, col tempo, gli archivi
possono assumere dimensioni molto elevate. Anche se nulla impedisce di realizzare l’archiviazione dei dati tramite un classico DBMS relazionale, spesso questa scelta porta a investire
risorse economiche importanti sia in termini computazionali, sia di storage.
Come è già stato mostrato nel capitolo precedente, questi e altri motivi hanno portato alcuni
colossi dell’innovazione, tra cui Google e Facebook, ad adottare strumenti diversi dagli RDBMS
per gestire i loro dataset: una tra le più diffuse e utilizzate tecnologie open source create per
questo scopo è Apache Hadoop.
Hadoop nasce come progetto per l'analisi distribuita di grandi insiemi di dati attraverso un
semplice modello di programmazione. Hadoop è un framework concepito per scrivere facil-
58 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
mente applicazioni che elaborano grandi quantità di dati in parallelo, su cluster di diverse
dimensioni in modo affidabile e tollerante ai guasti. L'architettura, realizzata in Java, permette di scalare da pochi server fino a migliaia di sistemi. Ciascun server contribuisce con le proprie risorse di calcolo e la propria capacità di memorizzare i dati; quindi, aggiungendo server,
chiamati anche nodi, è possibile far crescere un sistema Hadoop in modo quasi lineare. Benché non vi siano restrizioni specifiche per i nodi, di norma, vengono utilizzati dei sistemi x86
standard; ciò permette di tenere sotto controllo i costi complessivi della soluzione e, allo
stesso tempo, di beneficiare della crescita di tali architetture in termini computazionali.
Hadoop è in grado di gestire tutti i tipi di dati provenienti da sistemi diversi: strutturati, non
strutturati, file di log, immagini, file audio, documenti, comunicazioni e-mail, e tutto quello
che si può pensare.
Anche quando i diversi tipi di dati sono stati memorizzati in sistemi non correlati, è possibile
scaricare il tutto in un cluster Hadoop prima ancora di sapere come si potrebbe trarre vantaggio in futuro. L'alta affidabilità, e dunque la protezione dei dati, viene realizzata non basandosi sulle caratteristiche hardware dei server, ma bensì a livello software. Sono le librerie di
Hadoop che si occupano di identificare se e quali componenti presentano un malfunzionamento, intervenendo per ripristinare le operazioni, ad esempio creando una nuova copia dei
dati contenuti in un server.
E' evidente che quando si trattano enormi quantità di dati, le cui dimensioni sono dell’ordine
dei Petabyte, le soluzioni di backup tradizionali non sono utilizzabili ed è, quindi, proprio la
distribuzione dei dati su nodi differenti la chiave per salvaguardare le informazioni, anche di
fronte ad un guasto di uno dei nodi. In particolare, Hadoop adotta come standard la scrittura
dello stesso dato in tre locazioni differenti.
Fra i sottoprogetti di Hadoop, quelli di maggiore importanza, e che saranno trattati nei paragrafi successivi, sono:
MapReduce, framework per la realizzazione di applicazioni con approccio MapReduce;
HDFS, un file system distribuito secondo le linee guida dettate da GFS (Google File
System).
Francesco Romeo | 59
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
4.2 MAPREDUCE
Il paradigma MapReduce definisce una
strategia per eseguire l'elaborazione dei
dati su sistemi distribuiti e con elevato
parallelismo. Lo spunto che ha dato vita
a MapReduce è stato un lavoro di Google pubblicato nel 2004. Nel documento, che costituisce il fondamento tecnologico del modello si afferma che:
“MapReduce è un modello di programmazione cui è stata associata un’implementazione per
elaborare e generare insiemi di dati di grandi dimensioni. I programmi scritti che adottano
questo stile funzionale vengono automaticamente gestiti in una logica parallela ed eseguiti su
cluster di macchine a tecnologia commodity. Il sistema runtime si occupa nel dettaglio del
partizionamento dei dati di input, pianificando l’esecuzione del programma attraverso una
serie di macchine, gestendone gli eventuali guasti e la comunicazione che ha luogo tra esse.
Tutto questo permette a programmatori senza alcuna esperienza in sistemi paralleli e distribuiti di utilizzare con molta semplicità le risorse di un grande sistema distribuito”.
Il modello di MapReduce è abbastanza semplice. L’idea è quella di suddividere la logica applicativa in due funzioni basilari, ovvero:
la funzione Map;
la funzione Reduce.
La funzione Map legge un insieme di record da un file di input, svolge le operazioni di filtraggio
e trasformazioni desiderate, dopodiché produce una serie di record di output nella forma chiave-valore. Mentre il programma Map produce questi record, la funzione Reduce utilizza, come
ingresso, l’output prodotto dalla fase di Map. L’input viene elaborato in modo che elementi con
la stessa chiave vengono fusi tra loro secondo una logica che dipende dall’elaborazione stessa.
Il risultato della fase di Reduce è una lista di valori, ciascuno dei quali rappresenta la fusione di
elementi con la stessa chiave.
Un modello di programmazione del genere deve essere supportato da un framework; ciò è
indispensabile in quanto consente di gestire, in modo trasparente, le operazioni che non incidono sulla logica applicativa del sistema realizzato dall’utilizzatore. In questo modo, l’utente del
60 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
framework è tenuto a sviluppare solamente le funzioni Map e Reduce, con gli unici vincoli di
generare delle coppie intermedie nella fase di Map e di fonderle, secondo una certa logica,
nella fase di Reduce.
È molto importante sottolineare i vantaggi di questo paradigma:
Sia la funzione Map che la funzione Reduce possono essere eseguite in parallelo, dividendo lo spazio dei valori in più porzioni esaminate individualmente da diversi nodi
della rete.
È possibile iniziare a eseguire la funzione Reduce sull'output parziale delle funzioni Map
prima che queste ultime terminino completamente l'esecuzione.
Le funzioni Map e Reduce non richiedono, di base, di gestire strutture dati con dimen-
Francesco Romeo | 61
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
sioni variabili, poiché emettono i dati man mano che vengono generati e iterano sui valori
usando dei cursori generati esternamente; quindi possono agire su quantità arbitrarie di
dati senza il rischio di esaurire la memoria di lavoro. Potrebbe sorgere l'esigenza di interrogare database o usare librerie particolari all'interno delle due funzioni; in tal caso è
necessario disporre di soluzioni adeguate per non creare colli di bottiglia che vanificherebbero la parallelizzazione
In caso di rottura o disconnessione di un nodo è possibile rieseguire il compito originariamente assegnato ad esso senza riavviare l'intera operazione. Questo richiede sistemi di
monitoraggio e gestione dei compiti.
Nella nomenclatura del MapReduce si utilizza il termine “Job” per indicare un intero ciclo di
applicazioni di Map e Reduce fino alla fine dell'elaborazione e il termine “Task” per indicare una
singola esecuzione di una delle due funzioni effettuata da un nodo.
Il sottoprogetto MapReduce di Hadoop, anch’ esso scritto in linguaggio Java, è un’implementazione del modello MapReduce. Gli input vengono prelevati localmente in ogni nodo, vengono
elaborati dalla funzione Map e vengono prodotte le coppie chiave-valore intermedie. Una volta
che tutte le fasi di Map sono state
completate, interviene il processo
Shuffle che invia ad ogni nodo, attraverso la rete, i dati da processare
durante il Reduce. Tale operazione è
necessaria per raggruppare elementi
che hanno la stessa chiave, in modo
che confluiscano allo stesso processo di Reduce.
Nella fase successiva i processi di Reduce elaborano i dati ricevuti e forniscono degli output,
che vengono scritti localmente nel nodo stesso. È da notare che la fase di Shuffle è l’unica in cui
avviene uno scambio di dati attraverso la rete. Durante gli altri stadi del processo, per minimizzare la banda necessaria, le informazioni vengono prelevate localmente. Considerando, ad
esempio, la fase di Map in un determinato nodo, i dati elaborati sono quelli che si trovano fisicamente nei dischi del nodo stesso. Altro fatto da notare è che le operazioni esterne alla procedura Map e alla procedura Reduce e quelle di comunicazione fra queste due fasi sono realizzate
dal framework in modo trasparente.
62 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Gli elementi fondamentali del task nel suo complesso sono, quindi:
Input file: è dove le informazioni da elaborare vengono inizialmente depositate. Tipicamente sono archiviati nel file system distribuito HDFS. In linea di principio, soprattutto
per le peculiarità di HDFS, si tratta di file di grandi dimensioni, di tipo arbitrario: linee di
testo, file binari, record multi-linea, etc.
InputFormat: questo elemento indica come i file in input debbano essere suddivisi e letti
durante il processo di mapping. Più specificatamente, InputFormat è una classe che
fornisce delle funzionalità necessarie alla suddivisione e alla lettura dei file in ingresso.
Essa consente le seguenti attività:
selezione degli oggetti o dei file da impiegare come input;
definizione di InputSplit, classe che indica le modalità di suddivisione di ogni
file in ingresso;
realizzazione di un Factory per gli oggetti RecordReader, necessari alla lettura del contenuto dei file in input.
Hadoop fornisce degli InputFormat di base. Sono disponibili, inoltre, delle classi
astratte dalle quali è possibile ottenere gli InputFormat necessari alla propria
applicazione; un esempio è la classe astratta FileInputFormat, impiegata in tutti i
casi in cui l’input sia costituito da file.
InputSplits: è il modulo che descrive l’unità di lavoro di un task di Map all’interno dell’intero processo MapReduce. L’impiego di un determinato InputSplit indica al framework
come il file in ingresso debba essere suddiviso. Tutte le classi che derivano da FileInputSplit suddividono, per default, i file in chunk di 64MB ciascuno. È possibile, comunque, implementare una classe che suddivida l’ingresso secondo una logica adatta ai dati
che vengono trattati. La suddivisione dell’input in blocchi indipendenti permette, ai vari
processi di Map, l’elaborazione parallela di ciascuno degli Split del file.
RecordReader: la classe RecordReader è la responsabile della lettura dei dati provenienti
dal singolo Split e della successiva conversione in chiave-valore, adatta alla lettura da
parte del Mapper. Il RecordReader è invocato ripetutamente sull’input finché l’intero
InputSplit è stato totalmente consumato. Ogni invocazione del RecordReader corri-
Francesco Romeo | 63
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
sponde ad una chiamata del metodo map() del Mapper.
Mapper: il Mapper è la classe in cui viene implementata la prima parte della logica applicativa dell’intero programma MapReduce. Data una chiave ed un valore, il metodo map()
emette una o più coppie chiave-valore come risultato dell’elaborazione effettuata. Questi
dati vengono inoltrati verso i Reducer. È importante notare che, per ogni InputSplit, viene
istanziato un nuovo Mapper. Per l’elaborazione di un intero file sono, quindi, in azione più
istanze dello stesso Mapper. Tale caratteristica è particolarmente importante considerando che lo stesso file si trova, con molta probabilità, distribuito su diversi nodi. Questo
comportamento permette di diminuire la banda necessaria per lo scambio di informazioni; infatti, ogni istanza di Mapper elabora dati presenti localmente, cioè sul nodo in cui
essa è stata creata.
64 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Partition & Shuffle: man mano che i task di Map terminano la loro elaborazione, cominciano ad essere disponibili i dati intermedi. Questi vengono inviati ai vari nodi del sistema, in base alla chiave; tale operazione prende il nome di Shuffle ed è l’unica fase
dell’intero processo in cui c’è scambio di dati attraverso la rete. L’insieme di tutte le
chiavi viene partizionato e ad ogni nodo di Reducing vengono associati uno o più elementi della partizione (quindi, un certo set di chiavi). Conseguentemente, il framework
farà in modo di inviare, ad ogni Reducer, tutte le coppie intermedie la cui chiave fa parte
del set assegnato ad esso.
Sort: considerando che ogni task di Reduce è responsabile del Reducing dei valori associati a determinate chiavi intermedie, la fase di sort si preoccupa di ordinare tali valori in
base alla chiave, prima di presentarli al Reducer. Tutto ciò viene fatto automaticamente
dal framework Hadoop.
Reduce: è dove viene implementata l’altra parte di logica applicativa del programma.
Per ogni task di Reduce viene istanziato un Reducer; per ciascuna chiave assegnata al
Reducer viene effettuata una singola chiamata al metodo reduce(). A tale metodo viene
fornito un iteratore per navigare fra i valori associati alla stessa chiave.
OutputFormat: i valori elaborati ed emessi dal Reducer vengono scritti su file di output;
il formato di scrittura di tali file dipende dall’istanza di OutputFormat impiegata nel
Reducer. Come per InputFormat esistono, in Hadoop, delle classi predefinite; è, comunque, possibile crearne di proprie specializzando le classi astratte fornite dal framework.
RecordWriter: OutputFormat fornisce un factory di oggetti RecordWriter. La corrispettiva classe viene impiegata per effettuare la scrittura vera e propria sui file di output.
Combiner: si tratta di una fase opzionale. Questa operazione viene eseguita successivamente alle operazioni di Map e prima dell’invio dei risultati intermedi verso i relativi
Reducer. Se utilizzata, è utile per ridurre la banda impiegata, in quanto, prima di inviare
i dati, effettua una sorta di mini Reduce sui risultati locali prodotti dal nodo; solo dopo
aver terminato quest’ultimo task effettua l’invio.
Come detto, il framework è scritto in linguaggio Java; esso, pertanto, accetta programmi
MapReduce scritti nativamente in Java. Hadoop fornisce, però, la possibilità di utilizzare altri
linguaggi di programmazione per scrivere il codice MapReduce.
Francesco Romeo | 65
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
4.3 HDFS
.
HDFS è un file system distribuito ideato per soddisfare
requisiti quali affidabilità e scalabilità; esso è in grado di
gestire un numero elevatissimo di file, anche di dimensioni ragguardevoli, attraverso la realizzazione di cluster che
possono contenere migliaia di nodi. HDFS presenta i file
organizzati in una struttura gerarchica di cartelle. Dal
punto di vista dell’architettura, un cluster è costituito dai
seguenti tipi di nodi:
NameNode: è l’applicazione che gira sul server principale. Gestisce il file system ed, in
particolare, il namespace, cioè l’elenco dei nomi dei file e dei blocchi (i file, infatti, vengono divisi in blocchi da 64/128MB) e controlla l’accesso ai file eseguendo le operazioni di
apertura, chiusura e modifica dei corrispettivi nomi. Inoltre, determina come i blocchi dati
siano distribuiti sui nodi del cluster e la strategia di replica che garantisce l’affidabilità del
sistema. Il NameNode monitora anche che i singoli nodi siano in esecuzione senza problemi e, in caso contrario, decide come riallocare i blocchi. Tale applicazione distribuisce le
informazioni contenute nel namespace su due file:
Il primo è fsimage, che costituisce l’ultima immagine del namespace.
Il secondo è un log dei cambiamenti avvenuti al namespace a partire dall’ultima volta in cui il file fsimage è stato aggiornato. Quando il NameNode parte,
effettua un merge di fsimage con il log dei cambiamenti così da produrre uno
snapshot dell’ultima situazione.
DataNode: può rappresentare una o più applicazioni che girano su altri nodi del cluster,
generalmente una per nodo, e gestiscono fisicamente lo storage di ciascun nodo. Tali
applicazioni eseguono, logicamente, le operazioni di lettura e scrittura richieste dai client
e gestiscono fisicamente la creazione, la cancellazione o la replica dei blocchi di dati.
SecondaryNameNode: noto anche come CheckPointNode, si tratta di un servizio che aiuta
il NameNode ad essere più efficiente. Infatti, si occupa di scaricare periodicamente il file
fsimage e i log dei cambiamenti dal NameNode e di unirli in un unico snapshot che viene,
poi, restituito al NameNode.
66 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
BackupNode: è il nodo di failover e consente di avere un nodo simile al SecondaryNameNode sempre sincronizzato con il NameNode.
Come è stato affermato in precedenza, i file sono organizzati in blocchi, chiamati chunk, da
64 o 128 MB, e sono ridondati su più nodi. Sia la dimensione dei blocchi, sia il numero di repliche possono essere configurate per ogni file. Le repliche, distribuite tra i vari DataNode, sono
utilizzate sia per garantire l’accesso a tutti i dati, anche in presenza di problemi a uno o più
nodi, sia per rendere più efficiente il recupero degli stessi. Quindi, HDFS è strutturato a blocchi e ogni file è suddiviso in blocchi di dimensione fissata. Questi ultimi sono archiviati all’interno delle macchine, dette DataNode, che fanno parte del cluster. I file possono, quindi,
essere composti da un notevole quantitativo di blocchi che, non necessariamente, sono memorizzati all’interno della stessa macchina. Tale metodologia comporta un carico maggiore
in fase di accesso ai file, ma, d’altra parte, permette la memorizzazione di oggetti di dimensioni considerevoli, cosa altrimenti di difficile realizzazione.
In HDFS le richieste di lettura dati seguono una politica relativamente semplice: in particolare, avvengono scegliendo i nodi più vicini al client che effettua la lettura e, ovviamente, in
presenza di dati ridondati risulta più semplice soddisfare tale requisito. Inoltre, occorre precisare che la creazione di un file non avviene direttamente attraverso il NameNode. Infatti, il
Francesco Romeo | 67
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
client HDFS crea un file temporaneo in locale e, solo quando tale file supera la dimensione di un
blocco, è preso in carico dal NameNode. Quest’ultimo crea il file all’interno della gerarchia del
file system e identifica un DataNode e i blocchi su cui posizionare i dati. Successivamente DataNode e blocchi sono comunicati al client HDFS che provvede a copiare i dati dalla cache locale
alla sua destinazione finale.
È possibile affermare che quando vengono trattati file di grandi dimensioni, HDFS è molto
efficiente. Invece, quando devono essere trattati file di dimensioni inferiori al blocco, è molto
inefficiente; questo perché i file utilizzano spazio all’interno del namespace, che coincide con
l’elenco dei file mantenuti dal NameNode, che ha un limite dato dalla memoria del server che
ospita il NameNode stesso. Se HDFS contenesse troppi file associati ad una dimensione molto
68 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
inferiore al singolo blocco, genererebbe un riempimento del namespace. Questo problema
viene risolto dagli archivi Hadoop che compattano molti piccoli file in file più grandi ai quali è
possibile accedere dal sistema in parallelo e senza necessità di espanderli.
E’ importante notare che i diversi servizi di DataNode e Worker MapReduce possono girare
sullo stesso server fisico, rendendo molto veloce lo scambio di dati tra i due. Un server centrale chiamato JobTracker coordina le elaborazioni dei Worker e distribuisce i programmi
MapReduce lanciati dagli utenti. I TaskTracker sono i servizi che eseguono l’algoritmo
MapReduce vero e proprio e scambiano dati con i DataNode. Prima di lanciare un Job
MapReduce, l’utente deve caricare in HDFS i file di input necessari.
All’avvio del Job, ad ogni Mapper viene assegnata una partizione dei dati di input presenti su
HDFS che, molto spesso, risulta di competenza del DataNode presente sulla stessa macchina
fisica del TaskTracker, perché Hadoop cerca di ottimizzare l’esecuzione secondo criteri di
località dei dati.
Inizialmente, i TaskTracker chiamano la funzione map() specificata dal programmatore su
ogni singola coppia chiave-valore presente nei file di input. I risultati delle map() vengono,
poi, “bufferizzati” o memorizzati su file temporanei locali. Successivamente, nella fase
Shuffle, le coppie chiave-valore vengono inviate ai Reducer per poter essere ordinate e raggruppate per chiave. Al termine dello Shuffle, tutti i valori corrispondenti a una certa chiave
saranno stati inviati allo stesso Reducer. Viene, quindi, richiamata la funzione reduce(), fornita dal programmatore, per ogni chiave diversa, che procede ad emettere le coppie chiave
valore finali.
Tipicamente, i risultati finali vengono scritti separatamente su diversi file in HDFS e vengono
utilizzati per un successivo Job MapReduce, oppure vengono restituiti all’utente dopo essere
stati concatenati.
Mentre il numero di Mapper è pari al numero di partizioni di dimensione fissa in cui sono
divisi i file di input, il numero di Reducer non è vincolato e può essere specificato dal programmatore o lasciato scegliere al sistema. Oltre alla map(), Hadoop supporta due ulteriori
funzioni, setup() e cleanup(), che, se sovrascritte dal programmatore, vengono richiamate,
rispettivamente, alla creazione del Mapper e al termine delle chiamate a map().
Francesco Romeo | 69
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
4.4 YARN
Hadoop 2.0 è una completa ristrutturazione della piattaforma Hadoop 1.0 ed è retrocompatibile con i Job di MapReduce scritti per Hadoop 1.0. L’evoluzione rende Hadoop 2.0 più vicino ad
una vera piattaforma distribuita in grado di gestire i Big Data e compatibile con qualsiasi tipo di
applicazione di data management. Rispetto alla versione precedente, l’architettura più complessa permette maggiori gradi di libertà e un maggior controllo delle risorse disponibili sul
cluster.
L’ambiente di cluster management e gestione delle applicazioni, che in Hadoop 1.0 non aveva
un nome, anche perché c’era solo MapReduce, in Hadoop 2.0 si chiama YARN.
In sostanza, i principali cambiamenti sono i seguenti:
HDFS è sostituito con HDFS2, che introduce funzionalità evolute da file system distribuito
come la possibilità di effettuare snapshot, di far collaborare tra loro più cluster HDFS e di
mettere in alta affidabilità il NameNode.
A differenza di Hadoop 1.0 dove si partiva dal concetto di Job MapReduce, in YARN si
parla di applicazioni. Un’applicazione YARN è qualsiasi tipo di applicazione che possa
sfruttare un sistema distribuito o parallelo. MapReduce è una di queste possibili applicazioni, ma non l’unica. Quindi, YARN implementa anche MapReduce, ma lascia allo sviluppatore la libertà di scrivere qualsiasi tipo di applicazione distribuita.
70 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
L’architettura fisica è sempre a due livelli, ovvero:
Il Resource Manager, che rappresenta il master del sistema distribuito che contiene, a
sua volta, uno Scheduler e un Application Manager. Quest'ultimo è il componente che
negozia con i Node Manager le risorse per lanciare le applicazioni sui nodi del cluster.
Il Node Manager, in esecuzione su ogni nodo di calcolo del cluster escluso il Resource
Manager, che gestisce le risorse locali del nodo e crea dei container; questi sono, in
pratica, delle sendbox dove vengono fatte girare le applicazioni.
Con Hadoop 1.0 si parlava di Mapper e Reducer. In questo caso non c’è un ruolo specifico: un
nodo di calcolo è solo un nodo di calcolo.
Dal momento che YARN è un puro e semplice ambiente di esecuzione per applicazioni distribuite, ogni applicazione deve essere auto contenuta, cioè deve essere in grado di lanciare le
varie copie dei Job in parallelo, ricevere i risultati delle sottoelaborazioni, combinarli e restituirli al client. YARN non si occuperà di cosa faccia l’applicazione, ma solo di assegnare ad
essa le risorse sui nodi del cluster.
Le applicazioni sul cluster YARN presentano il seguente funzionamento: l’utente scrive la
propria applicazione, che prende il nome di Application Master, e, tramite il client YARN,
Francesco Romeo | 71
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
richiede al Resource Manager la possibilità di installare l’Application Master sul cluster. Il Resource Manager richiede a un nodo del cluster la creazione di un container per eseguire l’Application Master. Il container è una sandbox con un determinato ammontare di risorse RAM e
CPU che limitano l’utilizzo, da parte dell’applicazione, per evitare di bloccare il nodo.
L’Application Master viene, quindi, mandato in esecuzione sul container ottenuto con ID=O.
Una volta in esecuzione, il Master si moltiplica, richiedendo, a sua volta, al Resource Manager,
tramite le apposite API di YARN, altri container su altri nodi su cui lanciare le varie copie
dell’applicazione distribuita. Ogni replica dell’applicazione viene lanciata, quindi, in un container e comunica con l’Application Master secondo quanto definito nel codice. L’Application
Master, a sua volta, invia segnali di heartbeat al Resource Manager per indicare di essere ancora vivo e funzionante.
Il Resource Manager si occupa di gestire le richieste di container da parte dei vari Application
Master in esecuzione sul cluster. L’allocazione è dinamica, tramite lo scheduler, cioè ogni Application Master si troverà ad avere a disposizione più o meno container a seconda di quanto il
cluster ha a disposizione. Il client, a questo punto, comunica direttamente con il suo Application Master per avere i risultati dell’esecuzione dell’applicazione, di nuovo a seconda di come è
scritto il codice, e YARN non interviene su tali comunicazioni.
Un esempio di un’applicazione YARN è proprio MapReduce. In questo caso l’Application Master è il JobTracker mentre le varie repliche lanciate sui vari container sono i vari TaskTracker
Mapper o Reducer. MapReduce è un Application Master già disponibile in YARN, in modo da
mantenere un minimo di retrocompatibilità con Hadoop 1.0, anche se essa non è, però, sempre garantita. Per le aziende che pensano di adottare un cluster Hadoop al posto dei vecchi
Data Warehouse sarebbe buona cosa partire già da Hadoop 2.0 non dando tanto peso alla
retrocompatibilità e cercando di capire bene quali applicazioni di analisi o gestione dei dati
possano beneficiare di una esecuzione distribuita. Come già detto, il valore di YARN è la flessibilità che sta nella sua capacità di eseguire qualsiasi tipo di applicazione distribuita, non solo
MapReduce.
Un altro punto di forza per Hadoop 2 e YARN è, sicuramente, la capacità di elaborare dati in
tempo reale (stream processing), a differenza di MapReduce, limitato esclusivamente al batch
processing. E proprio le mutate necessità dell’utenza, le cui esigenze di stream processing sono
aumentate sensibilmente negli ultimi tempi, avrebbero portato Google all’abbandono di
MapReduce in favore di Cloud Dataflow, in grado di combinare stream e batch processing.
72 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
5. CASSANDRA, MONGODB, HBASE
In questo capitolo verranno trattati tre dei più importanti DBMS NoSQL utilizzati dai
progettisti software, rispettivamente Cassandra, MongoDB e HBase. Verranno presentate
le caratteristiche peculiari di ognuno di essi e si procederà ad una valutazione comparativa
degli stessi.
1
Cassandra
2
MongoDB
3
HBase
1
4
Confronto tra i DBMS
NoSQL trattati
Francesco Romeo | 73
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
5.1 CASSANDRA
Cassandra è un DBMS NoSQL, open source,
nato inizialmente come progetto interno a
Facebook per poi diventare, nel marzo 2009,
parte del progetto Incubator di Apache. Da quel
momento anche altre compagnie iniziarono ad
usarlo, tra le quali Twitter, Netflix e Cisco.
Cassandra appartiene alla famiglia dei DBMS Column Oriented fornendo, tramite il concetto di
Column-Family, una versione estesa del metodo Key-Value store, costruito su una struttura
Column Oriented; esso, inoltre, introduce una struttura aggiuntiva, ovvero le Super ColumnFamily.
Tutto in Cassandra si potrebbe riassumere in una struttura ricorsiva, a quattro o cinque livelli,
basati sul concetto di chiave-valore:
Column-Family: è una struttura, forse la più complessa, che funge da contenitore delle
colonne.
La Chiave: è l'entità principale per mezzo della quale Cassandra può recuperare i dati
contenuti in una Column-Family. La chiave deve essere univoca a livello di ColumnFamily, può essere generata applicativamente e può essere un numero, una stringa, una
data nel formato timestamp o un generico UUID. Tuttavia, Cassandra supporta anche
altri tipi di dati.
Colonna: all’interno di una Column-Family trovano posto una o più coppie chiave-valore.
L’unione di una chiave con il suo relativo set di colonne è chiamato Riga.
Attraverso queste tre entità Cassandra gestisce i dati. Occorre considerare anche le seguenti,
ulteriori, entità:
74 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
KeySpace: è l'unita informativa di più alto livello per Cassandra, associabile ad un intero
DBMS di un modello relazionale; deve essere creato prima di poter effettuare qualsiasi
operazione. Esso conterrà quindi tutte le singole tabelle le quali erediteranno gli attributi definiti sul KeySpace che le contiene. Questi attributi sono essenzialmente tre: il
Replication factor, la Replica placement strategy, (indicanti quante copie del dato si
vuole tenere nella rete e il modo in cui si voglia distribuire queste copie), e le ColumnFamily, paragonabili alle tabelle di un DBMS relazionale ed appartenenti ad uno e un
solo KeySpace.
Super Column: è un aggregato di Column-Family. Non sono altro che colonne il cui campo value contiene un array di colonne.
Questo DBMS rispetta le proprietà di Partitioning e Availability rispetto a quanto detto nel
Capitolo 3 riguardo al CAP Theorem. I nodi, anche se non comunicanti tra loro, rendono sempre disponibile la possibilità di scrivere e leggere i propri dati, lasciando poi decidere all'utente quali politiche di merge adottare nel momento in cui la comunicazione tra nodi torni stabile.
Cassandra utilizza la tecnica del Consistent Hashing in cui i nodi della rete formano un anello;
ogni nodo è gerarchicamente uguale agli altri. Poiché Cassandra è stato ideato e pensato per
contesti in cui è presente un elevato dinamismo della rete, questa tecnica permette di ridurre
al minimo la quantità di dati da dover “rimappare” al variare della quantità di nodi presenti.
L'architettura di Cassandra è Shared Nothing; quindi, non ci sono configurazioni master-slave
Francesco Romeo | 75
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
o simili, permettendo di avere un sistema no-single-point-of-failure, cioè in grado di essere
disponibile anche dopo la caduta di un qualsiasi nodo della rete. Per individuare quali sono i
nodi responsabili di una determinata chiave, il client può contattare un qualunque nodo che
diventerà il coordinatore della richiesta. Il bilanciamento del carico è fortemente dipendente
dal tipo di partizionamento che è stato configurato per il cluster. Tutte le informazioni topologiche sono memorizzate nel servizio di Snich che mappa gli IP ai Rack e ai data center definendo come i nodi sono raggruppati. Ogni nodo di uno stesso cluster deve utilizzare lo stesso
Snich.
Essendo Shared Nothing, Cassandra rende persistenti i dati solo in locale, senza utilizzare un
servizio di file system distribuito. I nodi Cassandra hanno un modulo di scrittura, nelle operazioni di write, che salva i commit su un file di log e su una struttura in-memory, che viene salvata
su disco in maniera asincrona una volta raggiunta una dimensione soglia. Le scritture su disco
avvengono in un formato indicizzato per la lettura basata su chiave, aggiungendo anche indici
sulle Column-Family e sulle colonne. All'aumentare dei file su disco, al fine di ottimizzare la
gestione delle risorse su quest’ultimo dispositivo, un processo in background esegue compressione e accorpamento. Le operazioni di read sono il risultato della visione unificata tra le informazioni in-memory e quelle su disco.
Nella versione base di Cassandra le chiavi vengono distribuite in maniera uniforme, senza contare le reali risorse hardware delle macchine fisiche. Cassandra usa suddividere il data center in
diversi anelli e sposta i nodi al fine di migliorare l'utilizzo delle risorse disponibili. Nella configurazione iniziale di Cassandra è possibile selezionare due strategie di partizionamento. La prima,
casuale, è il RandomPartitoner (RP), che distribuisce le coppie chiave-valore con il vantaggio di
avere un buon bilanciamento dei dati ma con lo svantaggio di dover contattare diversi nodi per
ricostruire una riga. Diversamente, è possibile designare un ordinamento che preserva l'ordine,
OrderPreservingPartitioner (OPP), distribuendo le coppie in modo tale che le stesse chiavi non
siano distanti tra loro.
Per quanto riguarda la disposizione dei nodi nel cluster, la creazione di un singolo anello è una
soluzione comunemente utilizzata, soprattutto per la sua semplicità implementativa. È possibile, comunque, disporre, in caso si voglia riservare particolare attenzione alla distribuzione fisica
dei dati, di più anelli cooperanti tra loro, soluzione in cui ovviamente tutti i nodi sono considerati ancora uguali. La possibilità di avere una rete multicluster viene utilizzata spesso per la replicazione dei dati, aumentando l’affidabilità dell'intero sistema.
76 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Per verificare il corretto funzionamento della rete e controllarne l'integrità, Cassandra utilizza
un protocollo di tipo GOSSIP, basato sulla distribuzione casuale e continua dell'informazione
da un nodo all'altro, quest'ultimo scelto casualmente dal primo. Proprio per la semplicità
strutturale della ring, l'elasticità dell'intero anello viene gestita in modo facile e completamente automatico. Quando un nodo si aggiunge al cluster, calcola un token casuale per
trovare la sua posizione all'interno dell'anello e l'intervallo di chiavi di cui deve essere responsabile. Tali informazioni vengono memorizzate sia in locale che su un servizio di sincronizzazione distribuito. Una volta entrato nella rete, il nodo inizia a cercare indirizzi degli altri, sia
dalle configurazioni locali che dal servizio distribuito, ed annuncia ad essi la propria presenza,
lanciando il protocollo GOSSIP, che porterà l'intera rete sulla nuova membership. Dopodiché
avviene la riassegnazione/migrazione dei dati da un nodo all'altro in base al nuovo assegnamento dei token. Nel caso in cui un nodo viene tolto dalla rete o non riesce ad essere raggiungibile, i nodi rimanenti si occuperanno di distribuire tra loro i dati del nodo rimosso, riassegnando, anche in questo caso, i token per un più equilibrato bilanciamento del DBMS.
I nodi della rete Cassandra provano a identificare se un nodo è attivo o meno utilizzando un
meccanismo di failure detector, in cui non si determina in maniera booleana il fallimento di
un nodo, ma se ne determina un livello di sospetto. Tramite questo meccanismo si ottiene
Francesco Romeo | 77
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
un'ottima accuratezza e una buona velocità nel reagire ai possibili cambiamenti della rete.
Tutti i moduli che permettono a una macchina di entrare in una rete Cassandra sono scritti in
Java e operano su un software in cui lo scambio di messaggi utilizza il protocollo UDP per le
operazioni di sistema, e il TCP per rispondere alle richieste del client.
La replicazione, in un DBMS, consiste nel creare una copia del dato originale, permettendo di
disporre dei dati anche nel momento in cui un nodo presenti degli errori. Cassandra crea tante
copie del dato originale quante ne sono state definite tramite l'attributo Replication
factor, del Keyspace nel quale si sta lavorando. Le copie sono recuperabili in qualunque
momento dal DBMS, garantendo la disponibilità dei dati anche nel caso di malfunzionamento
del nodo contenente i dati originali. Le copie ricoprono, inoltre, un ruolo di controllo di correttezza e consistenza che può avere impatti anche molto rilevanti riguardo alle prestazioni. Esse
possono essere distribuite sui vari nodi in accordo a due principali strategie tra cui scegliere,
ovvero la Simple Strategy o la Network Topology Strategy. La prima distribuisce i dati seguendo l'ordine dell'anello: se, ad esempio, si vuole creare una singola copia del dato originale,
78 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
memorizzato nel nodo numero due, la copia andrà collocata nel prossimo nodo seguendo la
rete, vale a dire nel nodo numero tre. Si segue, all'aumentare del Replication factor, la circolarità dell'anello fino a quando non si ha la memorizzazione di tutte le copie. Con la seconda
strategia, invece, vengono distribuiti i dati in base alla conoscenza della rete, dando priorità
alla distribuzione su vari anelli poiché ci si aspetta che nodi appartenenti allo stesso anello
abbiano più probabilità di fallire rispetto ai nodi inseriti in anelli diversi, tenendo in considerazione la vicinanza fisica delle macchine.
Cassandra sceglie un modello Eventual Consistency, facendo decidere al client che tipo di
consistenza debba essere utilizzata. Occorre stabilire quanti nodi devono confermare l'avvenuta operazione, prima che questa possa essere considerata conclusa, permettendo, inoltre,
di controllare periodicamente la consistenza tra tutte le copie del dato richiesto presenti nella
rete. Si può attribuire il valore ONE nel caso in cui , per considerare la transazione riuscita, è
necessaria la conferma da parte di un solo nodo , TWO, se occorre la conferma di due nodi, e
così via; esistono, infine, altre possibilità, quali ANY per l'attesa di tutti i nodi della rete, o
QUORUM, che prevede di effettuare una votazione tra i nodi dell’anello.
Francesco Romeo | 79
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
5.2 MONGODB
MongoDB è divenuto il più utilizzato DBMS NoSQL grazie alla sua estrema facilita di installazione e manutenzione. Questa semplicità non impedisce, però, di ottenere ottime prestazioni
da questo DBMS. Grazie ad una campagna di vendita aggressiva e ad un supporto continuo,
oltre alla fornitura di API in molti linguaggi di programmazione, continua la sua scalata verso le
prime posizioni tra i DBMS più usati, anche più di alcuni DBMS relazionali. Scritto in C++ è
orientato alla velocità e scalabilità, pur mantenendo un buon livello di consistenza. Può essere
usato anche per memorizzare e distribuire file binari di grandi dimensioni, come immagini o
video. Questo DBMS mira a colmare l'enorme distanza tra la velocità e la scalabilità tipica dei
DBMS chiave-valore con le ricche funzionalità dei DBMS relazionali.
MongoDB è un DBMS Document Oriented; pertanto l'unita fondamentale sono i documenti, in
formato BSON (Binary JSON, che è una estensione del formato JSON con il supporto a tipi
aggiuntivi), equivalenti alle singole tabelle di un DBMS relazionale, ma molto più espressivi. I
documenti sono tutti identificati da una chiave speciale ed univoca (ID). Occorre aggiungere
anche il concetto di Collection che rappresenta un insieme di documenti. La possibilità di innestare documenti o di avere delle referenze tra essi rende molto potente, flessibile e dinamico
questo modello. Infatti, nei DBMS NoSQL classici il valore memorizzato viene trattato come
un'informazione binaria e l'applicazione sovrastante gestisce la struttura dei dati. Per quanto
riguarda il CAP Theorem, MongoDB utilizza le proprietà di Partitioning e Consistency. I dati
non sono disponibili nel momento in cui il nodo principale, detto primario, non risulta disponibile Occorre, quindi, aspettare che essi vengano recuperati.
La replicazione in MongoDB avviene creando un replica set. Questo è un gruppo di nodi in cui,
tramite una votazione interna al set, uno di
questi viene eletto come primario, mentre gli
altri vengono catalogati come secondari. Questi ultimi ricevono i commit log e li utilizzano
per aggiornare i propri dati, memorizzando
solo copie esatte degli stessi dati contenuti
nella macchina primaria. I commit log possono
essere scritti solo dai nodi primari. Nel caso in
cui la macchina primaria non dovesse essere
più funzionante viene sostituita con una delle
secondarie, scelta tramite una votazione effet-
80 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
tuata dall'intero gruppo. Quindi, mentre la macchina primaria può eseguire sia operazioni di
scrittura che di lettura, le secondarie possono
servire solo per operazioni di lettura. Di conseguenza, MongoDB risulta essere particolarmente
efficace in applicazioni che fanno uso intensivo di
operazioni di read. Di default MongoDB permette, comunque, la sola lettura sul nodo primario,
attribuendo ai nodi secondari una funzione finalizzata solo al recupero dati in caso di guasto. Un
replica set è vincolato ad avere una sola macchina
primaria e al massimo fino a sei macchine secondarie, a cui possono essere aggiunte fino a
cinque macchine che entrano in funzione solamente durante la fase di votazione. Le macchine dedicate a questa funzione sono denominate arbiter e, al contrario delle macchine secondarie che possono diventare primarie, non cambiano mai il proprio stato. Si noti che, al contrario di Cassandra, questo sistema permette fino ad un massimo di sette replicazioni, limitazione dovuta al numero di macchine secondarie implementabili in un replica set.
Tutti i nodi che compongono una implementazione di MongoDB comunicano
attraverso un protocollo denominato Wire
Protocol, che è sostanzialmente un protocollo TCP/IP semplificato. Un messaggio è
costituito da un contenitore con un header
al cui interno sono descritti il tipo di operazione da eseguire, la lunghezza del messaggio, il nome della collezione sulla quale
eseguire la richiesta e un documento,
generalmente in JSON, rappresentante
l'informazione. Un altro messaggio scambiato è l’heartbeat request, richiesta inviata ogni due secondi tra ogni macchina per verificare lo stato del cluster. Altra interessante
funzione di tale richiesta è quella di verificare che il nodo primario possa raggiungere la maggioranza degli altri nodi. Nel caso in cui ciò non risulti, il nodo si autosqualifica come primario
della rete, procedendo a far partire una votazione tra i membri del cluster per una nuova
elezione.
Francesco Romeo | 81
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
Per distribuire i dati ed eseguire il partizionamento di questi sui diversi nodi della rete,
MongoDB utilizza il processo detto Sharding. Ogni shard, il cui numero non è limitato, diventa
comproprietaria di un certo numero di dati, i quali possono essere replicati rendendo lo shard
un replica set. È possibile
avere un numero di repliche diverso per ogni
shard. Per consentire il
corretto funzionamento
di tale struttura devono
essere eseguiti, su una o
più macchine, diversi
processi:
Mongod: è il processo base per MongoDB. Gestisce le
richieste e il formato
dei dati, ed esegue operazioni di gestione. Questo processo fa svolgere le votazioni necessarie per dichiarare il nodo primario. Permette, anche, di risolvere le richieste provenienti dai client e relative ad operazioni di lettura e scrittura in base al ruolo, primario o
secondario, della macchina oggetto della richiesta stessa.
Config server: Nel momento in cui si decide di avere una rete multi shard, bisogna inserire
due nuovi processi all'interno dell'architettura di MongoDB. Il primo tra questi è il config
server, processo chiave dell'intero cluster. Tale processo tiene traccia dei vari dati presenti
in un determinato nodo del cluster. Esso è una particolare istanza del processo mongod
ed è possibile, nell'intero cluster, istanziarne solamente uno o tre, per permettere un
risultato sicuro ed immediato nel momento in cui debba svolgersi una votazione, necessario nel caso di inconsistenza dei dati.
Mongos: è il secondo processo necessario qualora si decida di creare piu shard. Questo
dispone di un elenco contenente tutti i nodi che compongono il DBMS e il relativo replica
set di appartenenza, dati recuperati e continuamente aggiornati attraverso la continua
comunicazione con i config server. È, inoltre, l'unico processo ad essere abilitato a comunicare con i client, reindirizzando la loro richiesta ai nodi delle varie shard e restituendo i
82 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
risultati al richiedente il servizio. Non ci sono limiti sul numero di istanze possibili di
questo processo; come conseguenza di ciò, il numero di entry point per MongoDB
uguale al numero di processi mongos istanziati.
Per ogni istanza del processo mongod viene creato, sulla stessa macchina, il rispettivo Journal, sul quale vengono memorizzati l'esatta locazione sul disco ed i relativi byte cambiati,
riguardo ai dati inseriti in seguito ad un’operazione di scrittura. Ciò permette, in seguito ad un
crash di alcuni nodi della rete, di recuperare e rieseguire i cambiamenti svolti sul DBMS dalle
write che non sono state fisicamente scritte su disco. Le operazioni vengono, infatti, memorizzate su disco ogni 60 secondi (di default); perciò il Journal necessita di memorizzare solo gli
ultimi 60 secondi circa di quanto accaduto al DBMS riguardo le scritture.
Write Concern rappresenta quanta garanzia MongoDB fornisce all'applicazione client riguardo al successo di un’operazione di tipo write. Ci sono diversi livelli di garanzia sviluppati per
soddisfare le varie applicazioni. I livelli di Write Concern sono:
Error ignored: tale configurazione rappresenta il livello più basso in cui nessuna notifica
viene ricevuta dal client. Qualunque fallimento della rete o dello storage stesso viene
ignorato.
Unacknowledged: assenza di riscontro da parte del client, è simile al livello ignored, con
la differenza che il driver cattura errori della rete.
Normal: MongoDB fornisce al client una risposta sull'avvenuta ricezione dell'operazione
di scrittura.
Journaled: con un journaled write concern il client viene avvisato della corretta esecuzione della scrittura solo una volta che è stata eseguita l'operazione ed è stato effettuato
un commit di essa sul Journal.
Replica acknowledged: prevede un invio di avvenuta esecuzione della scrittura solo
quando questa è stata eseguita sul nodo primario ed è stata replicata sull'intero replica
set.
Francesco Romeo | 83
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
5.3 HBASE
HBase è un DBMS scritto in Java, nato come
clone di BigTable, un DBMS fortemente distribuito e costruito sopra un file system
apposito. Questa caratteristica necessita di
applicazioni e tecnologie che forniscano
sincronizzazione e gestione di un ambiente particolarmente dinamico. Il file system su cui
HBase si appoggia è HDFS, uno dei principali componenti di Hadoop, descritto nel capitolo 4.
HBase sta riscuotendo particolare successo negli ultimi tempi. Essendo in grado di gestire
cluster di notevoli dimensioni, si sposa adeguatamente alle tecniche di analisi su grandi quantità di dati. Riesce a soddisfare diverse esigenze; alcune richiedono basse latenze per garantire
all'utente risposte in tempo reale, mentre altre sono più orientate all'elevato volume di produzione dei dati.
HBase fa parte della famiglia Column Oriented DBMS.
Al contrario di Cassandra, però, qui non si hanno Super
Column-Family, concetto esclusivo di Cassandra. Particolarità interessante è però data dal fatto che HBase
supporta esclusivamente l’Ordered Partitioning. Le
righe di una Column-Family devono essere sempre memorizzate in ordine di row-key. Questo permette di interrogare il DBMS con operazioni quali
scan, definendo un range di row-key, e di estrarre tutti i valori trovati con delle performance
particolarmente elevate. Da notare che i file di una Column-Family possono essere sparsi su
vari nodi, ma, visto l'utilizzo di Hadoop, il quale presenta dei blocchi di dimensioni elevate,
un’operazione di scan su un range elevato di row-key, utilizzando questi grossi blocchi, impiega
brevi tempi di latenza dati dal seek time. Facendo riferimento al CAP Theorem, come MongoDB, anche HBase presenta le proprietà di Partitioning e Consistency. Quando un nodo non è
più riconosciuto dal cluster, i suoi dati non sono più accessibili. Si avvia, quindi, una fase di
recupero, nel caso in cui i dati siano stati precedentemente replicati, in cui HDFS e HBase cooperano per ripristinare i dati persi.
L'unità di base in HBase è detta Region; si tratta, sostanzialmente, di un insieme di righe contigue, memorizzate insieme e riguardanti una tabella. La particolarità di queste è che il nodo che
le contiene è in grado, una volta raggiunta una certa dimensione, di eseguire uno split di esse,
cioè un partizionamento in una o più Region di dimensioni minori, creando diverse Region per
84 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
un'unica tabella. In questo modo si vengono a creare
diverse regioni cui l'intero sistema si prenderà cura
bilanciandone il carico sulla rete e distribuendole
lungo l'intero cluster. Questo metodo viene visto
come una sorta di Autosharding proprio per il suo
automatico partizionamento dei dati. Si noti che la
Region iniziale risiede su un singolo nodo e che il
partizionamento avviene gradualmente, generando
carichi di lavoro non uniformemente distribuiti se
non per carichi di dati estremamente elevati. Due
tabelle sono fondamentali per l'intero DBMS ed il
corretto funzionamento riguardante le Region: le
tabelle ROOT e META. La tabella ROOT tiene traccia di dove sia memorizzata la tabella META,
con informazioni relative ai nodi su quali risiede e sulle Region nei quali è partizionata. La
tabella META è incaricata di contenere una lista sempre aggiornata sull'elenco di tutte le
Region presenti sui nodi. Queste due tabelle sono create ed assegnate automaticamente dal
master di rete durante l'avvio dell' intero DBMS.
Due processi risultano di rilevante importanza in HBase, ovvero HMaster, il master della rete,
e uno o più HRegionServer, che si occupano della gestione dei dati. Il primo si occupa di gestire l' assegnazione, per ogni HRegionServer, delle varie Region nel momento in
cui queste vengono create o partizionate, prendendosi cura anche della corretta gestione delle Region speciali ROOT e
META. Il secondo contiene le Region,
gestendo la loro crescita e dimensione,
oltre, ovviamente, a fornire le operazioni di base per il recupero e memorizzazione dei dati. Questi secondi processi
possono essere eseguiti tutti su una macchina, oppure possono essere distribuiti su più nodi.
A causa della possibilità di avere più HMaster, che risultano essere il punto critico dell'intera
infrastruttura di HBase, e che possono essere anche spostati da una macchina all'altra, HBase
necessita di un coordinatore esterno. Questa funzione viene fornita da Zookeeper, un servizio centralizzato di configurazione e sincronizzazione per grandi sistemi distribuiti. Questo si
Francesco Romeo | 85
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
occupa, quindi, di tenere traccia dello stato dei master di HBase, di prendersi carico dei messaggi heartbeat, di controllare lo stato tra HMaster e HRegionServer, e di tenere traccia delle
tabelle ROOT e META, fornendo dati per far comunicare direttamente il client con i nodi della
rete. Si noti che, vista questa comunicazione diretta con gli HRegionServer, il numero di entry
point della rete non è definibile: il client accederà direttamente al nodo su cui risiedono i dati a
cui è interessato. Zookeeper viene generalmente eseguito su un cluster esterno, rispetto a
quello dove avvengono i processi di HBase, per ragioni di sicurezza e di disponibilità. In caso di
recupero dei dati o in presenza di conflitti deve essere eseguita una votazione dalle istanze dei
processi di Zookeeper .
La replicazione fornita da questo DBMS permette di replicare dati esclusivamente tra diversi
cluster di HBase; tale replicazione, asincrona, viene effettuata solitamente per avere una copia
in caso di malfunzionamenti sul cluster principale. Per avere una replicazione sul singolo cluster
ci si appoggia, invece, ad Hadoop e al relativo HDFS. Per HBase la replicazione è assolutamente
ininfluente da un punto di vista prestazionale poiché essa viene eseguita in modo del tutto
trasparente al DBMS. Il vantaggio di tale meccanismo è dato dal fatto che, in caso di guasto ad
una macchina, il DBMS è conscio della presenza sul file system di copie dei dati andati perduti,
permettendo, quindi, un processo di recupero. Da notare che, al contrario di Cassandra, il numero di replicazioni impostato tramite Hadoop non può essere configurato come superiore al
numero di HRegionServer presenti nella rete.
86 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
5.4 CONFRONTO TRA I DBMS NOSQL TRATTATI
Le differenze tra i diversi DBMS NoSQL sono molto più grandi di quanto non ci siano tra un
DBMS SQL e l’altro. Ciò significa che, fin dall’inizio, c’è una maggiore responsabilità affidata
ai progettisti software nello scegliere la tecnologia per un progetto.
Cassandra viene spesso visto come il punto di incontro tra l'architettura fortemente orientata
alla distribuzione e alla scalabilità di Dynamo e il modello dei dati potente e flessibile di
BigTable. Gran parte dei vantaggi risiedono nel buon compromesso tra le idee di due DBMS
molto potenti e sviluppati. In generale, Cassandra può essere vista come una delle migliori
implementazioni di sistemi Shared Nothing da cui ne deriva gran parte dei vantaggi e svantaggi. In termini del teorema CAP, il DBMS si colloca sulla classificazione di tipo AP, ossia
orientato alla scalabilità e alla disponibilità a discapito della consistenza, non garantita da
uno strato di file system distribuito. Inoltre, Cassandra richiede un’amministrazione continua
del DBMS in relazione all'andamento dei dati.
I principali vantaggi di Cassandra sono i seguenti:
distribuzione open source;
modello dei dati di BigTable con supporto alle Super Column;
range e filtered query efficienti;
livello di consistenza dinamico;
controllo di integrità e riparazione automatica;
elevatissime prestazioni e scalabilità;
elevata disponibilità;
assenza di colli di bottiglia sul nodo master;
bilanciamento dei dati dinamico;
gestione delle membership e dei failure
dinamici;
Francesco Romeo | 87
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
elevata configurabilità.
I principali svantaggi sono, invece, i seguenti:
sistema di difficile amministrazione;
sistema fortemente dipendente dalla strategia di partizionamento;
supporto a MapReduce non nativo;
nessuna gestione di relazioni tra righe;
consistenza non sempre garantita.
Nonostante sia un DBMS NoSQL relativamente recente, MongoDB si è velocemente imposto
come uno dei più conosciuti ed utilizzati. Le elevate prestazioni sono garantire dal modello di
dati che permette di accorpare molte informazioni sotto forma di documenti sui quali applicare
indici secondari. Il modello a documenti, sotto questo punto di vista, può essere visto come una
forma di partizionamento implicito delle informazioni. Questo schema si adatta bene a molti
contesti ma ha il difetto di rendere il sistema poco flessibile. Un altro punto a favore di questo
modello è la disponibilità alla replicazione delle informazioni con gestione automatizzata dei
fallimenti, in cui è anche possibile decidere il livello di consistenza desiderato. Infine, il partizionamento è reso efficiente dalla gestione automatizzata dei blocchi di documenti che vengono
splittati e spostati nella rete tramite processi eseguiti in background.
A livello di CAP, MongoDB permette, quindi, di lasciar scegliere al client un comportamento
consistente (CP) o più disponibile (AP).
Cercando di fare un elenco dei vantaggi che si hanno utilizzando MongoDB, abbiamo:
doppia licenza;
supporto ufficiale per molti linguaggi;
modello a documenti facile da usare;
modello query ad oggetti;
88 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
indicizzazione dei campi e dei sotto-documenti;
operazioni atomiche su documenti;
livello di consistenza adattabile lato client;
partizionamento automatico;
ottimizzazione delle range query opzionale;
assenza di colli di bottiglia;
gestione dei fallimenti automatica;
membership facile via processi.
I principali svantaggi di questo tool sono, invece, i seguenti:
modello a documenti poco flessibile a grandi cambiamenti strutturali;
operazioni di write solo su un singolo nodo;
nessuna gestione delle transazioni.
L'introduzione di BigTable nel mondo dei NoSQL ha portato molte novità che sono state
riprese anche da altri software. Per HBase la flessibilità che deriva dal modello ColumnFamily rappresenta il vero punto di forza. In termini del Teorema CAP, HBase si colloca nella
categoria CP.
Per quanto concerne i vantaggi di questo sistema, abbiamo:
modello di dati semplice e flessibile;
concetto di Column-Family potente;
controllo degli accessi potente e basato su Column-Family;
range e filltered query efficienti;
Francesco Romeo | 89
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
supporto a MapReduce;
elevata consistenza delle write;
replicazione garantita dal file system;
elevate prestazioni tramite gestione in-memory;
assenza di colli di bottiglia sul nodo master;
bilanciamento dei dati dinamico;
gestione delle membership e delle failure dinamici.
Gli svantaggi di tale DBMS sono, invece, i seguenti:
necessità, per l’applicazione client, di inviare le richieste ai server;
nessuna gestione di relazioni tra righe;
disponibilità non sempre garantita;
single point of failure nel serivizio di lock.
Grazie a DB-Engines Ranking è possibile collocare i DBMS NoSQL da noi studiati in base alla
loro popolarità. DB-Engines Ranking , per calcolare la popolarità di un sistema, sfrutta i seguenti parametri:
Numero di citazioni del sistema su siti web, misurato come numero delle query effettuate
nei motori di ricerca. Al momento, per questa misurazione, vengono utilizzati Google e
Bing.
Interesse generale nel sistema. Per questa misurazione, si usa la frequenza delle ricerche in
Google Trends.
Frequenza delle discussioni tecniche sul sistema. Vengono utilizzati il numero delle discus-
90 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
sioni e il numero di utenti interessati nei ben noti siti Internet stackoverflow.com e
dba.stackexchange.com .
Numero di offerte di lavoro, in cui è citato il sistema. Viene utilizzato il numero di offerte
nei principali motori di ricerca del lavoro, Indeed e Simply Hired.
Numero di profili in reti professionali, in cui è menzionato il sistema. Viene utilizzata la
più diffusa rete internazionale riguardante le professioni, ovvero LinkedIn.
Pertinenza nelle reti sociali. Vengono contati il numero di tweet di Twitter in cui è menzionato il sistema.
Come era prevedibile, MongoDB ottiene un risultato migliore rispetto agli altri due DBMS. Di
seguito la figura che rappresenta la popolarità in funzione del tempo:
Francesco Romeo | 91
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
CONCLUSIONI
1
In questa tesi è stato studiato il fenomeno dei Big Data e sono stati mostrati i benefici che
le aziende, attraverso la fase di analisi, riescono ad ottenere. In particolare, i risultati
ricavati grazie all’analisi predittiva risultano essere di fondamentale importanza per ottenere la strada del successo. La produzione dei dati ha una crescita continua e si prevede
che, nei prossimi anni, abbia un andamento esponenziale. Grazie allo sviluppo tecnologico i dati possono essere ottenuti mediante svariati mezzi. I Big Data possono essere
sfruttati , oltre che per le aziende che lavorano in ambito commerciale, anche in altri
svariati settori; si pensi, ad esempio, al lavoro svolto dai navigatori satellitari oppure agli
open data, nati allo scopo di aumentare i livelli di trasparenza, efficienza e responsabilizzazione delle Pubbliche Amministrazioni. L’intero processo di estrazione della conoscenza dai database, dall’acquisizione dei dati fino alla visualizzazione dei risultati ottenuti, ed
in particolare la fase di Data Mining, svolgono un lavoro straordinario per tutte le medie e
grandi aziende che hanno intenzione di essere un passo avanti rispetto alla concorrenza.
In azienda è, quindi, necessaria l’innovativa figura professionale del Data Scientist, soggetto che deve avere più competenze. Tale figura deve avere l’abilità di sapere gestire,
acquisire, organizzare ed elaborare dati. La seconda competenza è di tipo statistico,
ovvero il sapere come e quali dati estrarre. La terza capacità è il saper comunicare a tutti,
con diverse forme di rappresentazione, cosa suggeriscono i dati.
L’ immagazzinamento delle grandi moli di dati, spesso personali, deve essere in grado di
garantire un alto livello di sicurezza e rispetto della privacy. Ciò non può essere assicurato
unicamente dal processo di conformità con il sistema normativo. Una nuova idea è rappresentata dal concetto di Privacy By Design. Tale novità si riferisce alla filosofia e all'approccio di considerare la privacy nelle specifiche di progettazione delle varie tecnologie.
Un ruolo fondamentale per lo sviluppo e la diffusione dei Big Data è svolto dalle tecnologie NoSQL ed Hadoop. La prima consente di acquisire ed immagazzinare dati strutturati,
ovvero la maggior parte dei dati generati dai diversi mezzi tecnologici, ed inoltre permet-
Francesco Romeo |
93
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
te flessibilità nel partizionare, distribuire e replicare i dati. Ci sono progetti che hanno il
compito di ospitare dati che crescono in maniera costante, e a volte non lineare, la cui
memorizzazione su un solo server di storage richiede costi, sia hardware che software,
elevati e, con i tempi che corrono, difficilmente giustificabili al cliente finale. Da contare
l’esigenza di avere un sistema di replica online per la continuità del servizio. Altro punto
forte di questa tecnologia è che essa permette di effettuare delle statistiche precise del
dato. Si tende a raggruppare i database NoSQL in quattro categorie fondamentali: KeyValue Distribuiti, Document Oriented, Column Oriented, Graph Oriented. Ogni categoria
presenta pro e contro; all’interno della tesi, si è scelto di studiare tre dei più utilizzati
DBMS NoSQL: Cassandra, MongoDB e HBase. Tra questi, dopo un’ analisi approssimativa, MongoDB risulta essere quello maggiormente popolare, addirittura più di vari DBMS
relazionali. Ogni DBMS trattato presenta caratteristiche differenti ed è, quindi, compito
del progettista software decidere quale strada seguire, in base alle necessità del sistema
che si vuole sviluppare.
La tecnologia Hadoop sostanzialmente consente la distribuzione dei dati su più macchine, abbattendo costi computazionali e di storage, per l’immagazzinamento e l’analisi dei
Big Data. Hadoop è un framework concepito per scrivere facilmente applicazioni che
elaborano grandi quantità di dati in parallelo, su cluster di diverse dimensioni, in modo
affidabile e tollerante ai guasti. Fra i sottoprogetti di Hadoop, quelli di maggiore importanza e che meritano particolare attenzione sono MapReduce e HDFS. Il primo rappresenta una strategia per eseguire l'elaborazione dei dati su sistemi distribuiti e con elevato
parallelismo. HDFS è un file system distribuito ideato per soddisfare requisiti quali affidabilità e scalabilità, ed è in grado di gestire un numero elevatissimo di file, anche di dimensioni elevate, attraverso la realizzazione di cluster che possono contenere migliaia di
nodi.
1Per quanto riguarda i possibili sviluppi futuri in questo settore, appare interessante citare
Automatic Statistician, un progetto annunciato da Google per condurre “Intelligenza
Artificiale per la scienza dei dati”. Ad oggi i Big Data hanno un potenziale ancora non
completamente espresso, proprio a causa dell’impossibilità di farne un utilizzo concreto,
dovuta ai limiti delle facoltà computazionali umane. Per elaborare enormi quantità di dati
un cervello umano non basta. Un sistema intelligente, che operi senza bisogno di intermediazioni umane, è quel che ci vuole. Nato in collaborazione con l’Università di Cambridge, Automatic Statician ha lo scopo di automatizzare la selezione, la costruzione e la
spiegazione di modelli statistici per l’analisi dei Big Data. In sostanza, esso sarà in grado
di passare in rassegna grandi quantità di dati e determinare quale sarebbe il miglior algoritmo per analizzarli, mettendone in evidenza le caratteristiche più importanti. Il risultato
94 |Francesco Romeo
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
di tale lavoro sarà spiegato nel dettaglio in un rapporto elaborato automaticamente dal
sistema perché gli umani ne prendano visione.
Ecco spiegata la sfida intrapresa da Google, l’azienda che dispone forse del maggior
quantitativo di dati interpretabili al mondo. Elaborare i dati in maniera più rapida ed
efficiente grazie all'Intelligenza Artificiale offrirebbe a Google opportunità senza precedenti nell'erogazione di servizi di advertising più mirati.
1
Francesco Romeo |
95
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
BIGLIOGRAFIA
Big Data. http://www.webopedia.com/TERM/B/big_data.html, 2014.
Big Data Analytics. http://www.sobigdata.eu/master/bigdata, 2014.
Cassandra. http://cassandra.apache.org/, 2014.
Data Mining. http://www.laits.utexas.edu/~anorman/BUS.FOR/
course.mat/Alex/, 2014.
5. Data Scientist. http://www.rainews.it/dl/rainews/articoli/datascientist-il-lavoro-sexy-50712477-5a83-4682-8f73522428eb3281.html, 2014.
6. Hadoop. http://hadoop.apache.org/, 2014.
7.
HBase. http://hbase.apache.org/, 2014.
8. HDFS. http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html,
2014.
9. KDD. http://www.kdd.org/kdd2014/index.html, 2014.
10. MapReduce. http://www.mapreduce.it/, 2014.
11. MongoDB. http://www.mongodb.org/, 2014.
12. NoSQL. http://nosql-database.org/, 2014.
13. Open data. http://www.dati.gov.it/, 2014.
14. Privacy By Design. http://www.privacybydesign.ca/, 2014.
15. YARN. http://hadoop.apache.org/docs/current/hadoop-yarn/
hadoop-yarn-site/YARN.html, 2014.
16. V. Agneeswaran. Big Data Analytics Beyond Hadoop. Pearson FT Press, 2014.
17. E. Capriolo. Cassandra High Performance Cookbook. Packt Publishing, 2011.
18. K. Chodorow. MongoDB: The Definitive Guide. O'Reilly Media, 2013.
19. A. Di Ciaccio and W. Lanzani. Gli analytics come motore per i big data, la ricerca e il
sistema paese. Aracne, 2012.
20. E. Dumbill. Planning for Big Data. O'Reilly Media, 2012.
21. N. Garg. HBase Essentials. Packt Publishing, 2014.
22. J. Han, M. Kamber, J. Pei. Data Mining: Concepts and Techniques. Morgan Kaufmann
Pub, 2011. E. Hewitt. Cassandra: The Definitive Guide. O'Reilly Media, 2010.
23. S. Hoberman. Data Modeling for MongoDB: Building Well-Designed and Supportable
MongoDB Databases. Technics Publications, 2014.
1.
2.
3.
4.
1
Francesco Romeo | 97
Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto
24. H.Karambelkar. Scaling Big Data With Hadoop and Solr: Learn Exciting New Ways to Build
Efficient, High Performance Enterprise Search Repositories for Big Data Using Hadoop and
Solr. Packt Publishing, 2013.
25. G. Lars. HBase: The Definitive Guide. O'Reilly Media, 2011.
26. G. S. Linoff and M. J. Berry. Data Mining Techniques: For Marketing, Sales, and Customer
Relationship Management. John Wiley & Sons Inc, 2011.
27. O. Maimon and L. Rokach. Data Mining and Knowledge Discovery Handbook. Springer US,
2006.
28. M. Manoochehri. Data Just Right: Introduction to Large-Scale Data & Analytics . AddisonWesley Professional, 2013.
29. V. Mayer-Schönberger, K. N. Cukier, R. Merlini. Big data. Una rivoluzione che trasformerà il
nostro modo di vivere e già minaccia la nostra libertà. Garzanti Libri, 2013.
30. A. C. Murthy, V. K. Vavilapalli, D. Eadline, J. Niemiec, J. Markham. Apache Hadoop YARN:
Moving beyond MapReduce and Batch Processing with Apache Hadoop 2. Addison-Wesley
Professional, 2014.
31. V. Prajapati. Big Data Analytics with R and Hadoop. Packt Publishing, 2013.
32. F. Provost and T. Fawcett. Data Science for Business. O’ Reilly & Associates Inc, 2013.
33. A. Rezzani. Big data. Architettura, tecnologie e metodi per l'utilizzo di grandi basi di dati.
Apogeo Education, 2013.
34. P. J. Sadalage. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley Professional, 2012.
35. The Enlightened DBA. DBA's Guide to NoSQL: Apache Cassandra. DataStax, 2014.
36. G. Vaish. Getting Started with NoSQL. Packt Publishing, 2013.
37. S. Wadkar and M. Siddalingaiah. Pro Apache Hadoop. Apress, 2014.
38. T. White. Hadoop: The Definitive Guide. Oreilly & Associates Inc, 2012.
98 |Francesco Romeo
