Università degli Studi Mediterranea di Reggio Calabria

1

Relatore Candidato

Prof. Domenico Ursino Francesco Romeo

Tesi di Laurea

Analisi del fenomeno dei Big Data e comparazione di

DBMS NoSQL a loro supporto

Anno Accademico 2013-2014

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

1

Alla mia famiglia, ai miei amici e a

tutte le splendide persone che mi sono

state vicine durante questo cammino.

Analisi del fenomeno dei Big Data e comparazione di DBMS NoSQL a loro supporto

1

Francesco Romeo | 1

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 an-

che 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 imma-

gini digitali, dati GPS raccolti attraverso smartphone e tablet, trascrizione delle transa-

zioni 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 differen-

ziazione. 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 con-

dizioni di mercato, permettendo di prendere decisioni più velocemente e più efficace-

mente rispetto alla concorrenza.

Per far fronte a tali esigenze le aziende fanno uso di nuove soluzioni ICT, sia a livello infra-

strutturale 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 applica-

zioni ricche di contenuti e spesso distribuite agli utenti tramite Internet.

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 rivolu-

zionato la percezione delle aziende su cosa può essere fatto con i propri dati. La crescita esplo-

siva 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 differen-

ti. 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 impor-

tanza 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 prece-

dentemente 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 pro-

cesso 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, MapRe-

duce e HDFS, e l’innovativo YARN.

Nel quinto capitolo verranno trattati tre dei più utilizzati DBMS NoSQL: Cassandra, Mon-

goDB e HBase. Inoltre, verranno presentate, e poi confrontate le caratteristiche, di ognu-

no di essi.

Infine, nell’ ultimo capitolo, verranno tratte le conclusioni e verranno esaminati alcuni

possibili sviluppi futuri.

2 |Francesco Romeo


In questo capitolo verrà descritto il concetto di Big Data. Partendo dal significato del ter-

mine verranno delineate le caratteristiche generali di questo fenomeno. Successivamente,

verrà affrontato il tema della Social Business Intelligence con i vantaggi che ne deriva-

no. Il capitolo si concluderà con una presentazione dei più diffusi contesti di utilizzo,

appunto, dei Big Data.

1. INTRODUZIONE AI BIG DATA


1

Francesco Romeo | 3

1 Cosa si intende per

Big Data 3 Contesti di utilizzo

dei Big Data 2 La Social Business

Intelligence

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 pren-

dere 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, senti-

menti 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 dise-

gnate 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'acce-

lerazione della produzione di questi dati. Dall'al-

tro, questa crescita esponenziale è il risultato di

alcuni mutamenti sociali ed economici estrema-

mente 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


Francesco Romeo | 5


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 ener-

getiche, bisogni di mobilità.

Molti analisti, per poter definire il concetto di Big Data, utilizzano le tre caratteristiche de-

scritte di seguito:

Velocità;

Varietà;

Volume;

Un equivoco molto diffuso è la convinzione che il

concetto di Big Data riguardi esclusivamente le di-

mensioni dei dati. Per quanto le dimensioni rappre-

sentino sicuramente un elemento della questione, esistono anche altri aspetti o altre proprie-

tà dei Big Data che non sono necessariamente associati a esse. Si prendano in considerazio-

ne, 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 dimen-

sioni 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, asse-

rire che si tratta oggi di Big Data perché ognuno di essi sfrutta al massimo la comune tecnolo-

gia disponibile per il loro utilizzo. Si può considerare Big Data una presentazione di Power-

Point da 40 MB se non è possibile condividerla via email con colleghi o aziende. Analogamen-

te, 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

aziendali. In merito agli altri attributi che

possono rientrare nella definizione prece-

dentemente 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 chia-

ro 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 ge-

neratori. 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 consape-

voli 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 necessa-

rio 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


Francesco Romeo | 7


La Business Intelligence (nel seguito, BI) può

essere definita come l’insieme delle metodo-

logie, dei modelli, delle tecnologie e delle

applicazioni rivolte alla raccolta sistematica

del patrimonio di informazioni generate e

acquisite da un’azienda, alla loro aggregazio-

ne, analisi, presentazione e al loro utilizzo.

Le tecniche di BI nascono, come dice il no-

me, 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 trasforma-

re i dati in informazioni il più velocemente possibile, sono intervenuti a determinare la defini-

zione 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 identifica-

re cinque fattori largamente applicabili per poter sfruttare i Big Data come fonte di valore.

Questi saranno esaminati in dettaglio nel prossimo paragrafo.

1.2 LA SOCIAL BUSINESS INTELLIGENCE

I cinque fattori capaci di dare valore ai

Big Data sono i seguenti:

La creazione della trasparenza: si

può ottenere la trasparenza

semplicemente rendendo acces-

sibili e disponibili i dati e le infor-

mazioni 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 miglio-

rare 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 cliente-

la. 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’anda-

mento 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 accura-

ta 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 merca-

to 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


1.2.1 BIG DATA COME FONTE DI VALORE

Francesco Romeo | 9


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 organiz-

zazioni, 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 stru-

menti 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 succede-

rà?” 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 affida-

bile 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, ana-

lizzare 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 per-

sonale 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”. Emer-

geranno, inoltre, nuove figure professionali come quella del “data scientist”, dotate di

competenze multidisciplinari (statistica, informatica, economia, organizzazione), neces-

sarie 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 informa-

zioni, in molti settori (come ad esempio

quello della sanità), costituisce un’ele-

mento forte di criticità e, talora, un

freno all’innovazione.

Sfide culturali: la cultura delle decisioni data-driven e fact-based non è ancora sufficiente-

mente 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'econo-

mia: 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 , sem-

pre, un miglioramento delle prestazioni.

10 |Francesco Romeo


Francesco Romeo | 11


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. Que-

ste restano il modello di dati preferenziale per le principali piattaforme di Data Analy-

tics.

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 trat-

ta, 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 metada-

ti, 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 struttu-

rate. Crawling, parsing ed

entity extraction sono tra le

tecniche per l’estrazione di

dati strutturati e analizzabili. I

volumi aumentano esponen-

zialmente nel tempo. Il loro

utilizzo può aprire nuovi para-

digmi di analisi prima impen-

sabili.

1.2.2 VARIETA’ DELLE INFORMAZIONI

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 aumen-

tano esponenzialmente nel tempo.

Dati GIS (Geospatial, GPS). I dati geospaziali sono gene-

rati da applicazioni sempre più diffuse. La loro memoriz-

zazione è ormai uno standard e i volumi sono in cre-

scente aumento. I dati geospaziali, analizzati statistica-

mente e visualizzati cartograficamente, integrano i dati

strutturati fornendo, ad esempio, informazioni di busi-

ness, informazione sulla sicurezza o informazioni socia-

li.

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 au-

mento.

Dopo questa elencazione, comunque

non esaustiva, sarà risultato chiaro

quale sia la potenziale varietà di dati

da trattare in un’applicazione svilup-

pata per trasformare i dati in infor-

mazioni di business.

12 |Francesco Romeo




Introduciamo l’ultimo fattore che ha determi-

nato la nascita delle Big Data Analytics, ovvero

la Velocità che, per molti fenomeni aziendali, è

diventata una caratteristica sempre più deter-

minante. Essa è fondamentale per:

Svolgere i processi e le attività aziendali

(ad esempio, un processo commerciale, la

creazione di un nuovo concept di prodot-

to, la comunicazione di marketing con

media digitali).

Trattare in modo integrato grandi volumi di dati eterogenei (ad esempio, i dati di vendi-

ta, i reclami a un customer care e i commenti sui blog o nei social network, dati di geo-

localizzazione) e ottenere un’informazione rilevante (ad esempio, di insight nel compor-

tamento 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 siste-

mi ICT.

Gestire le relazioni digitali tra le persone, le imprese e le istituzioni in modo da permet-

tere 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 finalizzazio-

ne, 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 con-

testo 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 azien-

dale di cui si parla spesso, è, di fatto, generata

da due fattori prevalenti: la crescente velocità

dei cambiamenti necessari, e la crescente incer-

tezza degli scenari e dei risultati generabili dalle

scelte possibili.

I seguenti punti possono aiutare a riassumere i

1.2.3 LA VELOCITA’ NEI FENOMENI AZIENDALI

principali cambiamenti già in atto e basati

sull’ICT, che prospettano alcuni nuovi orizzonti

del management aziendale:

Trasformare il modo in cui le persone pensa-

no, analizzano i fatti, pianificano e agiscono:

sono necessari nuovi atteggiamenti nei

confronti dell’ICT, passando da molti feno-

meni di moda e di “consumerization” (ad

esempio, riguardo i dispositivi mobili o il

social Web) ad un reale impiego nella ge-

stione aziendale.

Velocizzare i processi di Innovation Manage-

ment, 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 innesca-

re veloci attività di “trial and error”, veloci cicli di “Analyze, Plan, Act and Control”, piutto-

sto 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 comples-

sità e questa grande

quantità dei dati possono

essere gestite solo attra-

verso soluzioni tecnolo-

14 |Francesco Romeo




giche nuove.

È stata sviluppata e adattata un'ampia varietà

di tecniche e tecnologie per aggregare, mani-

polare, 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.

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 orga-

nizzazione; l'abilità di generare, comunicare, condividere e accedere ai dati è stata rivoluziona-

ta 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 poten-

ziale dei Big Data. Innanzitutto, essa può raccogliere dati a velocità elevata; i dati raccolti con-

sentono alla rete di determinare il contesto, ad esempio abbinando ai dati le informazioni sull'i-

dentità 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 in-

tenzione 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 set-

tori 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




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 tec-

nica di modellazione predittiva chiamata “collaborative filter”. Inoltre, Amazon ha di-

chiarato che il 30% dei propri ricavi era riconducibile al suo motore analitico per i consi-

gli 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 tecnolo-

gia 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 com-

petitività nel settore del retail. Walmart ha facilitato l'espansione di un sistema di scam-

bio 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ù granu-

lari può consentire ai retailer di mi-

gliorare l'efficacia del loro marketing

e del loro merchandising.

Le applicazioni possono essere suddivise in due grandi settori: applicazioni analitiche e ap-

plicazioni relative a determinati settori. Questi verranno esaminati in dettaglio nelle prossime

sottosezioni.

Le applicazioni analitiche si possono suddividere come di seguito specificato:

Applicazioni basate su attribuzioni. Queste devono recuperare e analizzare le serie di atti-

vità, 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à com-

merciali 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 suggeri-

menti:

applicazioni per l’individuazione di pubblicità mirate ai clienti, che

suggeriscono segmenti di audience di riferimento “simili” in base a compor-

tamenti 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 previ-

sione 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 mi-

ning per estrarre dalla moltitudine di variabili solo quelle più efficaci per prevedere le

prestazioni in particolari situazioni. Le applicazioni predittive avanzate integrano valuta-

zioni 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


1.3.1 APPLICAZIONI ANALITICHE



variabile sia cruciale per una decisione, è possibi-

le investire maggiori risorse per assicurarsi che

essa venga valutata in modo preciso e comple-

to . 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 in-

fluenza sociale degli amici;

applicazioni per la manutenzione dei prodotti, che prevedono guasti delle

apparecchiature in base a informazioni sull’utilizzo dei prodotti (in particola-

re, informazioni attualmente fornite dai dispositivi dati integrati), registra-

zione degli interventi di manutenzione e informazioni generali sulle presta-

zioni;

applicazioni relative alle prestazioni dei dipendenti, che prevedono le presta-

zioni di un potenziale collaboratore in base a fattori quali formazione, posi-

zione socio-economica, ruoli professionali precedenti, stato civile e determi-

nate risposte psico-comportamentali;

applicazioni relative alle prestazioni degli studi clinici, che modellano i risul-

tati di vari medicinali in base alla sperimentazione clinica, consentendo ad

un’azienda di comprendere l’efficacia di determinate terapie ed evitare con-

seguenze 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 mer-

chandising e per l’ottimizzazione dei prezzi, in grado di creare modelli utiliz-

zati dai responsabili delle decisioni per comprendere come e quando au-

mentare o ridurre i prezzi tenendo conto delle condizioni attuali della do-

manda 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

fanno leva su tecniche statistiche e di data mining per identificare situazioni o comporta-

menti ”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 moni-

torano 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 contan-

te 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 applica-

zioni basate su benchmark utilizzano al meglio

l’analitica che confronta le prestazioni di un’en-

tità rispetto a uno standard di settore, un perio-

do o un evento precedente. Ecco alcuni esempi

di applicazioni basate su benchmark:

applicazioni relative alle quote di

mercato, che forniscono dati su quo-

te di mercato e portafoglio; ad esem-

pio, 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 cam-

pagna di marketing in corso con quelle di una campagna o di un evento di

marketing precedente e/o simile.

20 |Francesco Romeo




“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, de-

vono essere resi disponibili, fruibili e riutilizzabili. Alcuni

esempi di dati pubblici la cui fruibilità migliorerebbe sensi-

bilmente la vita della comunità sono citati nel rapporto

Open Data, Open Society. Da esso deriviamo alcuni ambi-

ti 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ù efficien-

te le proprie politiche di sviluppo territoriale e urbanistico se, oltre a disporre dei dati

che i singoli organi e enti già possiedono, li condivi-

dessero fornendo un quadro più esaustivo del

territorio, incrociandoli con mappe e visualizzazio-

ni che rilevino aree protette o di interesse artistico-

culturale, 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 tra-

sporti 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, consen-

tendo 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 traspor-

to 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.

1.3.2 OPEN BIG DATA

La Demografia: i dati sulla composizione demografica di una precisa area (la scolarizzazio-

ne, 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 attivi-

tà; un'area con un alto tasso di natalità, la cui popola-

zione è 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 energeti-

ca (così come quelli sull'inquinamento atmosferico, sul diffondersi di malattie, etc.) per-

ché 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 meri-

to 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 accre-

scere 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




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 permetto-

no 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 disoccupa-

zione inferito dai profili di attività ottenuti per data

mining dei record di telefonia mobile, oppure il

calcolo o il monitoraggio di nuovi indicatori di be-

nessere/performance sociale a partire da fonti di

Big Data non standard (come social network, tele-

fonia 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 ter-

mini di correttezza, aggiornamento e completezza,

affidabilità o reputazione della sorgente. Essi, inol-

tre, possono presentare problemi legati ai metadati. Un fattore importante in questo conte-

sto è rappresentato dalla convalida dell'affidabilità dei dati. Per esempio, si parla di “fail profi-

le”, un profilo falso raccontato dai social network: questo è un elemento su cui fare attenzio-

ne 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.

1.3.3 BIG DATA NELLA STATISTICA UFFICIALE

In questo capitolo verrà descritto il processo di analisi dei Big Data. Si mostrerà una pano-

ramica generale del processo di estrazione di conoscenza dai database (KDD) dando mag-

giore 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.

2. IL PROCESSO DI ANALISI DEI BIG DATA


1


1 Il Processo KDD 3 La nuova figura del

Data Scientist 2

Data Mining

4 Privacy by Design nei

Big Data

2.1 IL PROCESSO KDD

Tutte le grandi organizzazioni, durante lo svolgimento delle proprie

attività, accumulano una gran quantità di dati. Questi grazie al pro-

gredire delle tecniche di cattura e immagazzinamento di informa-

zioni, contengono delle risorse, delle informazioni sfruttabili, evi-

denti 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 cresci-

ta dimensionale degli archivi di dati ed alla sempre più crescente necessità di elaborarne i con-

tenuti, questo tipo di analisi è risultata lenta, costosa e altamente soggettiva. Di conseguenza,

si è costituita ed è cresciuta costantemente una comunità di ricercatori e professionisti interes-

sati al problema dell’analisi automatica di grandi quantità di dati, nota come "Knowledge Di-

scovery 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 agevola-

re l’accesso alle informazioni; tipicamente è alimenta-

to 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 infe-

renza statistica, di ricerca e di Artificial Intelligence. La tecnologia più recente per affrontare tali

26 |Francesco Romeo




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 defini-

tiva, 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 infor-

mazioni 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 effet-

tuare un’analisi discriminante.

Preelaborazione: spesso, pur avendo a disposizione il target data, non è conveniente nè,

d’altra parte, necessario analizzarne l’intero contenuto; può essere più adeguato dappri-

ma 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 decisio-

ne 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 attra-

verso 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 poter-

ne 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 iterati-

vo 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 pos-

sono 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




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 signifi-

cative, 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, nor-

malmente 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 distribuzio-

ni 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 ab-

biamo:

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.

2.2 DATA MINING

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’e-

sperienza 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 mi-

glior 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 stan-

dard 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’ob-

bligo 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 compren-

sione dei dati.

Il modello si snoda in sei fasi comprendenti sotto-fasi e aspetti elencati di seguito:

Business Understanding: letteralmen-

te tradotto “Comprensione del Busi-

ness”, 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 risor-

se, requisiti, assunzioni e vincoli,

rischi e contingenze, terminologia,

30 |Francesco Romeo




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 produ-

zione del piano di progetto con piano di

progetto, valutazione iniziale di strumenti

e tecniche.

Data Understanding: letteralmente tra-

dotto “Comprensione dei Dati”, prevede

la raccolta dei dati iniziali, la loro descri-

zione, la loro esplorazione e la verifica

della loro qualità, tutti opportunamente

inseriti in report appositi.

Data Preprocessing: letteralmente tradotto “Preparazione dei Dati”, prevede la descri-

zione della base di dati, la selezione dei dati con annessi i criteri per inclusione ed esclu-

sione, 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 co-

struzione 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 ap-

provati, si revisiona il processo

e si determinano i passi suc-

cessivi elencando le possibili

azioni e decisioni.

Deployment: letteralmente

tradotto “Utilizzo”, prevede la

formazione del piano di utilizzo, del

piano di monitoraggio e mantenimen-

to, della produzione del report finale e

la presentazione finale, nonché la

recensione del progetto, con la pre-

sentazione della documentazione

dell’esperienza.

32 |Francesco Romeo




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ù com-

petenze. 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ò parago-

nare il lavoro del data scientist a quello del fisico speri-

mentale 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 concet-

to 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.

2.3 LA NUOVA FIGURA DEL DATA SCIENTIST

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 protezio-

ne dei dati personali.

Archivi informatizzati contenenti dati personali sono posseduti dalle Pubbliche Amministrazio-

ni, 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 Co-

municazione 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 assicu-

rato 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, realizzia-

mo 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 inte-

ressante 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


2.4 PRIVACY BY DESIGN NEI BIG DATA



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à eviden-

ziato, 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 priva-

cy non va interpretata come un onere, ovvero un costo che appesantisce l'attività imprendi-

toriale, 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 rappresenta-

to 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 antici-

pa e previene gli eventi invasivi della privacy prima che essi accadano. La PbD non at-

tende 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 verifi-

chino. 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.

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’ar-

chitettura dei sistemi IT e delle pratiche commerciali. Non è agganciata come un’aggiun-

ta, dopo il fatto. Il risultato è che la privacy diventa un componente essenziale per la rea-

lizzazione 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 con-

ciliare 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 elemen-

to 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 proces-

so, 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 indipenden-

te. 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




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, concer-

nente 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 assicura-

re 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”.

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 neces-

sarie misure tecnico-

organizzative 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


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.

3. NOSQL


1


1 Cosa si intende per NoSQL

3 I Principi Fondanti del NoSQL

2 RDBMS vs. NoSQL

4 Tipologie di DBMS

NoSQL

3.1 COSA SI INTENDE PER NOSQL

Negli anni novanta Internet ha permes-

so a molte aziende di ampliare il pro-

prio bacino di utenza portando online

un’enorme quantità di contenuti e

servizi; di conseguenza, la quantità dei

dati presenti in rete è aumentata espo-

nenzialmente. 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ù numero-

si, è stata necessaria una migliore orga-

nizzazione.

Negli ultimi anni sono aumentate le

aziende operanti esclusivamente onli-

ne 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 accessi-

bile (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’e-

commerce). 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




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 Fow-

ler in NoSQL Distilled:

“Un insieme poco definito di database principalmente open-source, principalmente sviluppa-

ti 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 progetta-

ta da subito per funzionare “bene" in

cluster.

Mentre la caratteristica principale dei sistemi relazionali è quella di mantenere una forte consi-

stenza 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 transa-

zioni.

Durability - Persistenza: al com-

mit 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


3.2 RDBMS VS. NOSQL



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 utilizzan-

do dati non aggiornati), e viceversa.

L’acronimo BASE indica le caratteri-

stiche che un sistema deve avere

sottostando al teorema di CAP,

ovvero, esso deve garantire la dispo-

nibilità delle informazioni (Basically

Available ), tuttavia non deve garan-

tire la consistenza ogni istante (Soft

State), ma alla fine deve diventare

consistente (Eventual consistency)

se le attività di modifica ai dati ces-

sano. Quindi, le inconsistenze sono

transitorie.

Quando la disponibilità dell’informa-

zione è 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-

sa) a fronte di quella che definiamo

“eventual consistency”, ovvero la capacità

del sistema di saper sistemare le informa-

zioni sui vari nodi, col passare del tempo,

in maniera asincrona.

Rick Cattell, nell’articolo “Scalable SQL

and NoSQL Data Stores” elenca le pro-

prietà comuni alla maggioranza dei siste-

mi 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 supporta-

no 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 appar-

tengono 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 macchi-

ne fisiche differenti, senza memoria o dischi rigidi in comune, al fine di parallelizzare le opera-

zioni 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




utilizzando macchine assemblate, e di superare i limiti hardware dati dal quantitativo massi-

mo 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.

Uno dei motivi che ha spinto verso l’utilizzo dei DBMS NoSQL è che, in alcuni progetti, l'integri-

tà 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 carat-

teristiche 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 consisten-

za 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 distribuzio-

ne:

Single Server: questa modalità è la più semplice, nonché la meno problematica. Con un

solo server di database; infatti, gli unici proble-

mi 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 comune-

mente il nome di anello (o ring o cluster); que-

st’ultimo lo si può ampliare o ridurre aggiun-

gendo 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 perfor-

mance in lettura. Avere molti nodi con gli stessi dati permette una parallelizzazione prati-

camente lineare delle letture, che possono essere distribuite in modo del tutto trasparen-

te 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


3.3 I PRINCIPI FONDANTI DEL NOSQL



sferimento, alleggerendo, al

contempo, il traffico

“globale" dell'infrastruttura.

Sharding dei dati : questa

modalità è la più complessa;

essa prevede, infatti, il parti-

zionamento dei dati in base

a vari criteri sui vari nodi,

mantenendo gli stessi van-

taggi 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'altret-

tanto 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 scrittu-

re contemporaneamente.

Il Multi-Version Concurrency Control permette di mantenere un controllo della concorrenza

basato su continui versioning dei dati.

Quando è necessario modificare un documento prece-

dentemente 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

sono altro che nuove versioni e non modifiche, tutto a vantaggio della velocità; tuttavia, pro-

durre 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 distri-

buito ad hoc che permetta il verificarsi di questa condizione. Questo tipo di consistenza, ricor-

dando il teorema di CAP, non può essere garantita insieme a disponibilità e fault-tolerance dei

dati; infatti, è neces-

sario che si rinunci al

partizionamento dei

dati o alla disponibili-

tà costante dell’infor-

mazione.

Si parla di “eventual

consistency”, invece,

nel caso in cui le lettu-

re possano ritornare

dei valori non aggior-

nati all’ultima scrittu-

ra effettuata; anche in

questo caso, però, il

sistema prima o poi farà in modo che questo valore venga correttamente propagato. Appar-

tengono 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 lettu-

re 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




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 informazio-

ne allora, da questa lettura in poi, accedendo con ogni altro client su questa informazio-

ne, 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 effettua-

te 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 rappresen-

ta 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 conclusio-

ne che in scenari distribuiti dove le macchine vengono aggiunte continuamente ed altre di-

sattivate o rotte improvvisamente, il sistema risulta poco funzionale.

I sistemi di partizionamento permettono di distribuire le informazioni sul cluster che costitui-

sce il DBMS NoSQL. Ci sono più tipi di partizionamento; di seguito ne elenchiamo alcuni:

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 garan-

tisce 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 Ha-

shing garantisce,

anche, un sistema

di replica basato su

una scelta di pro-

getto dove si fissa

un valore K, ovvero

un valore numerico

che determina

quante repliche

devono essere

mantenute per i

dati.

50 |Francesco Romeo




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 divisio-

ne 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.

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ù ven-

duti 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 realiz-

zare una scalabilità quasi lineare. L'indi-

rizzamento di tipo hash, infatti, consen-

te 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


3.4 TIPOLOGIE DI DBMS NOSQL



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 con-

correnza, 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 gio-

chi 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 colon-

ne costituenti nome,

cognome, età e sesso.

La Column-Family deve

essere presente nello

schema, ma è ,altresì,

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 Column-

Family corretta; se il valore non esiste, la colonna semplicemente non esisterà e la Column-

Family 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, statisti-

che 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




ad un altro (graph traversal) e sono, quindi,

molto utilizzati nel campo del Social Network.

I DBMS Graph Oriented permettono di estrar-

re, in tempi ragionevoli e in maniera molto

elegante, dati di grandissimo valore per appli-

cazioni quali:

classificazione tramite algoritmi di vici-

nanza e clustering;

analisi di flussi di vario genere: naviga-

zione 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.

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.

4. HADOOP


1


1 Cosa è Hadoop 3

HDFS 2

MapReduce

4 YARN

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’archivia-

zione 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




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, permet-

te di scalare da pochi server fino a migliaia di sistemi. Ciascun server contribuisce con le pro-

prie 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. Ben-

ché 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 vantag-

gio in futuro. L'alta affidabilità, e dunque la protezione dei dati, viene realizzata non basando-

si 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 malfunziona-

mento, 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 para-

grafi 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).

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 Goo-

gle pubblicato nel 2004. Nel documen-

to, 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 distri-

buiti 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 applica-

tiva 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 chia-

ve-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 incido-

no sulla logica applicativa del sistema realizzato dall’utilizzatore. In questo modo, l’utente del

60 |Francesco Romeo


4.2 MAPREDUCE



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, divi-

dendo 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-

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 inter-

rogare 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 vanifiche-

rebbero la parallelizzazione

In caso di rottura o disconnessione di un nodo è possibile rieseguire il compito originaria-

mente 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’implementa-

zione 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, attra-

verso 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 proces-

so 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 minimiz-

zare 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 fisi-

camente nei dischi del nodo stesso. Altro fatto da notare è che le operazioni esterne alla proce-

dura Map e alla procedura Reduce e quelle di comunicazione fra queste due fasi sono realizzate

dal framework in modo trasparente.

62 |Francesco Romeo




Gli elementi fondamentali del task nel suo complesso sono, quindi:

Input file: è dove le informazioni da elaborare vengono inizialmente depositate. Tipica-

mente 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 lettu-

ra 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’in-

tero 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 FileIn-

putSplit suddividono, per default, i file in chunk di 64MB ciascuno. È possibile, comun-

que, 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-

sponde ad una chiamata del metodo map() del Mapper.

Mapper: il Mapper è la classe in cui viene implementata la prima parte della logica applica-

tiva 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 consideran-

do 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 informazio-

ni; infatti, ogni istanza di Mapper elabora dati presenti localmente, cioè sul nodo in cui

essa è stata creata.

64 |Francesco Romeo




Partition & Shuffle: man mano che i task di Map terminano la loro elaborazione, comin-

ciano ad essere disponibili i dati intermedi. Questi vengono inviati ai vari nodi del siste-

ma, 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ù ele-

menti 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 asso-

ciati 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; è, comun-

que, possibile crearne di proprie specializzando le classi astratte fornite dal framework.

RecordWriter: OutputFormat fornisce un factory di oggetti RecordWriter. La corrispetti-

va 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 successiva-

mente 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.

.

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 dimensio-

ni 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, vengo-

no 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 proble-

mi 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’ulti-

ma 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


4.3 HDFS



BackupNode: è il nodo di failover e consente di avere un nodo simile al SecondaryName-

Node 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 repli-

che 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 bloc-

chi e ogni file è suddiviso in blocchi di dimensione fissata. Questi ultimi sono archiviati all’in-

terno 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 me-

morizzati 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 dimen-

sioni considerevoli, cosa altrimenti di difficile realizzazione.

In HDFS le richieste di lettura dati seguono una politica relativamente semplice: in particola-

re, 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 preci-

sare che la creazione di un file non avviene direttamente attraverso il NameNode. Infatti, il

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 Data-

Node 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




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 cen-

trale 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 rag-

gruppate 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(), forni-

ta 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 pro-

grammatore 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().

Hadoop 2.0 è una completa ristrutturazione della piattaforma Hadoop 1.0 ed è retrocompatibi-

le 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ù com-

plessa 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 applica-

zioni, ma non l’unica. Quindi, YARN implementa anche MapReduce, ma lascia allo svilup-

patore la libertà di scrivere qualsiasi tipo di applicazione distribuita.

70 |Francesco Romeo


4.4 YARN



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 distri-

buite, 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 resti-

tuirli 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,

richiede al Resource Manager la possibilità di installare l’Application Master sul cluster. Il Re-

source Manager richiede a un nodo del cluster la creazione di un container per eseguire l’Appli-

cation 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 contai-

ner 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 anco-

ra 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 Ap-

plication 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 Applica-

tion 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 Ma-

ster è 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ò, sem-

pre 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 flessi-

bilità 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


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.

5. CASSANDRA, MONGODB, HBASE


1


1 Cassandra 3

HBase 2

MongoDB

4 Confronto tra i DBMS

NoSQL trattati

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 Column-

Family.

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 Column-

Family, 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




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 attri-

buti 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 Column-

Family, 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 cam-

po 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 sem-

pre disponibile la possibilità di scrivere e leggere i propri dati, lasciando poi decidere all'uten-

te quali politiche di merge adottare nel momento in cui la comunicazione tra nodi torni stabi-

le.

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

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 topolo-

giche sono memorizzate nel servizio di Snich che mappa gli IP ai Rack e ai data center definen-

do 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 operazio-

ni 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 compres-

sione e accorpamento. Le operazioni di read sono il risultato della visione unificata tra le infor-

mazioni in-memory e quelle su disco.

Nella versione base di Cassandra le chiavi vengono distribuite in maniera uniforme, senza con-

tare 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 configu-

razione 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. È possibi-

le, 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 considera-

ti ancora uguali. La possibilità di avere una rete multicluster viene utilizzata spesso per la repli-

cazione dei dati, aumentando l’affidabilità dell'intero sistema.

76 |Francesco Romeo




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 completa-

mente 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 respon-

sabile. Tali informazioni vengono memorizzate sia in locale che su un servizio di sincronizza-

zione 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 assegna-

mento dei token. Nel caso in cui un nodo viene tolto dalla rete o non riesce ad essere rag-

giungibile, i nodi rimanenti si occuperanno di distribuire tra loro i dati del nodo rimosso, rias-

segnando, 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

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 corret-

tezza 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 seguen-

do l'ordine dell'anello: se, ad esempio, si vuole creare una singola copia del dato originale,

78 |Francesco Romeo




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 circo-

larità 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 considera-

zione 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'avve-

nuta 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.

MongoDB è divenuto il più utilizzato DBMS NoSQL grazie alla sua estrema facilita di installa-

zione 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 inne-

stare 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 disponi-

bile 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. Que-

sti 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


5.2 MONGODB



tuata dall'intero gruppo. Quindi, mentre la mac-

china primaria può eseguire sia operazioni di

scrittura che di lettura, le secondarie possono

servire solo per operazioni di lettura. Di conse-

guenza, MongoDB risulta essere particolarmente

efficace in applicazioni che fanno uso intensivo di

operazioni di read. Di default MongoDB permet-

te, comunque, la sola lettura sul nodo primario,

attribuendo ai nodi secondari una funzione finaliz-

zata 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 macchi-

ne dedicate a questa funzione sono denominate arbiter e, al contrario delle macchine secon-

darie che possono diventare primarie, non cambiano mai il proprio stato. Si noti che, al con-

trario di Cassandra, questo sistema permette fino ad un massimo di sette replicazioni, limita-

zione dovuta al numero di macchine secondarie implementabili in un replica set.

Tutti i nodi che compongono una imple-

mentazione di MongoDB comunicano

attraverso un protocollo denominato Wire

Protocol, che è sostanzialmente un proto-

collo TCP/IP semplificato. Un messaggio è

costituito da un contenitore con un header

al cui interno sono descritti il tipo di opera-

zione da eseguire, la lunghezza del mes-

saggio, il nome della collezione sulla quale

eseguire la richiesta e un documento,

generalmente in JSON, rappresentante

l'informazione. Un altro messaggio scam-

biato è l’heartbeat request, richiesta invia-

ta 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 mag-

gioranza 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.

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 repli-

che diverso per ogni

shard. Per consentire il

corretto funzionamento

di tale struttura devono

essere eseguiti, su una o

più macchine, diversi

processi:

Mongod: è il proces-

so base per Mon-

goDB. Gestisce le

richieste e il formato

dei dati, ed esegue operazioni di gestione. Questo processo fa svolgere le votazioni ne-

cessarie per dichiarare il nodo primario. Permette, anche, di risolvere le richieste prove-

nienti 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, neces-

sario 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 comu-

nicare con i client, reindirizzando la loro richiesta ai nodi delle varie shard e restituendo i

82 |Francesco Romeo




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 Jour-

nal, 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, memo-

rizzate 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 riguar-

do 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 esecuzio-

ne 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.

HBase è un DBMS scritto in Java, nato come

clone di BigTable, un DBMS fortemente di-

stribuito 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 quanti-

tà 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 produ-

zione 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. Parti-

colarità interessante è però data dal fatto che HBase

supporta esclusivamente l’Ordered Partitioning. Le

righe di una Column-Family devono essere sempre me-

morizzate 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 Mon-

goDB, 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 coo-

perano per ripristinare i dati persi.

L'unità di base in HBase è detta Region; si tratta, sostanzialmente, di un insieme di righe conti-

gue, 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


5.3 HBASE



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 gesti-

re l' assegnazione, per ogni HRegionSer-

ver, delle varie Region nel momento in

cui queste vengono create o partiziona-

te, prendendosi cura anche della corret-

ta gestione delle Region speciali ROOT e

META. Il secondo contiene le Region,

gestendo la loro crescita e dimensione,

oltre, ovviamente, a fornire le operazio-

ni di base per il recupero e memorizza-

zione 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 servi-

zio centralizzato di configurazione e sincronizzazione per grandi sistemi distribuiti. Questo si

occupa, quindi, di tenere traccia dello stato dei master di HBase, di prendersi carico dei mes-

saggi 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 nu-

mero di replicazioni impostato tramite Hadoop non può essere configurato come superiore al

numero di HRegionServer presenti nella rete.

86 |Francesco Romeo




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 svan-

taggi. 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 ma-

ster;

bilanciamento dei dati dinamico;

gestione delle membership e dei failure

dinamici;

5.4 CONFRONTO TRA I DBMS NOSQL TRATTATI

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 partizio-

namento è 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




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 Column-

Family 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;

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 se-

guenti 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




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 è men-

zionato 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:


1


CONCLUSIONI

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 otte-

nere 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 tecnologi-

co 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 responsabiliz-

zazione delle Pubbliche Amministrazioni. L’intero processo di estrazione della conoscen-

za 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, sog-

getto 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 è rap-

presentata dal concetto di Privacy By Design. Tale novità si riferisce alla filosofia e all'ap-

proccio 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 tecnolo-

gie 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-


1

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: Key-

Value 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 approssimati-

va, 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ù macchi-

ne, 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 impor-

tanza e che meritano particolare attenzione sono MapReduce e HDFS. Il primo rappre-

senta 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 affida-

bilità e scalabilità, ed è in grado di gestire un numero elevatissimo di file, anche di dimen-

sioni elevate, attraverso la realizzazione di cluster che possono contenere migliaia di

nodi.

Per 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 inter-

mediazioni umane, è quel che ci vuole. Nato in collaborazione con l’Università di Cam-

bridge, 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 algo-

ritmo per analizzarli, mettendone in evidenza le caratteristiche più importanti. Il risultato

94 |Francesco Romeo


1


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 prece-

denti nell'erogazione di servizi di advertising più mirati.


1


BIGLIOGRAFIA

1. Big Data. http://www.webopedia.com/TERM/B/big_data.html, 2014.

2. Big Data Analytics. http://www.sobigdata.eu/master/bigdata, 2014.

3. Cassandra. http://cassandra.apache.org/, 2014.

4. Data Mining. http://www.laits.utexas.edu/~anorman/BUS.FOR/

course.mat/Alex/, 2014.

5. Data Scientist. http://www.rainews.it/dl/rainews/articoli/data-scientist-il-lavoro-sexy-50712477-5a83-4682-8f73-

522428eb3281.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.

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 . Addison-

Wesley 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 Persis-

tence. 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


Università degli Studi Mediterranea di Reggio Calabria

Documents

Transcript of Università degli Studi Mediterranea di Reggio Calabria