Capitolo 2

Big Data

2.1 Cosa sono i Big Data

Nel precedente capitolo si è detto che l’istituto di ricerca Gartner prevede per il 2020

quasi 30 miliardi di devices IoT connessi alla Rete. Questo grande numero di nuovi

dispositivi connessi a Internet raccoglieranno e genereranno una enorme quantità di dati

che verrà inserita in Rete. Con la diffusione delle tecnologie IoT, si registrerà quindi una

crescita esponenziale della disponibilità di dati, sia strutturati (database, transazioni

online, log files) che non strutturati (immagini, informazioni legate ai social network,

dati GPS, dati dei sensori), così massivi e in rapido cambiamento da non poter essere

processati usando le tradizionali tecniche di analisi, come ad esempio i database

strutturati. Il mondo dell’Internet of Things avrà quindi a che fare con i Big Data da

esso generati.

I Big Data sono dei set di dati così grandi e complessi da necessitare strumenti adeguati

e diversi dai tradizionali per la loro cattura, lo storage, la ricerca, la condivisione, il

trasferimento, l'analisi e la visualizzazione.

22

CAPITOLO 2 BIG DATA

Come l’IoT, anche quello di Big Data è un concetto ancora recente e in cui ancora non

si è giunti a definizioni standard. Come suggerisce il termine stesso, la prima

caratterizzazione dei Big Data è legata alla grandezza dei dati, il cui punto di

riferimento è già sull’ordine dei terabyte (1024 gigabyte), dei petabyte (1024 terabyte) e

anche di più fino agli zettabyte (miliardi di terabyte). E’ facile capire come processare

questi dati significa disporre di soluzioni di calcolo parallelo e massivo su anche

migliaia di server dedicati.

Ma Big Data non significa soltanto dati voluminosi, ma significa soprattutto dati

complessi. Infatti insieme al volume, l’etichetta include anche altre due caratteristiche:

varietà e velocità, a completare le caratteristiche principali dei Big Data che si possono

riassumere nelle tre “V”.

Figura 2.1: Caratteristiche dei Big Data: le tre “V”

23

CAPITOLO 2 BIG DATA

Quindi non solo volume, inteso come proprietà di acquisire, memorizzare ed accedere a

grandi quantità di dati, ma anche varietà, riferita all’eterogeneità dei dati, provenienti

da fonti diverse (strutturate e non), e velocità, cioè gestione di dati che cambiano

rapidamente e che necessitano di tecniche che rendano la loro analisi più veloce

possibile (real-time). Tra gli addetti ai lavori si sta considerando la definizione di una

quarta “V”, ossia la veridicità, che misura il potenziale informativo del dato e la sua

integrità, nonché la sua qualità al fine di essere analizzato, nonché di una quinta, il

valore economico legato ad un uso smart da parte della aziende dei Big Data a loro

disposizione.

Le caratteristiche dei Big Data fanno capire come si renda necessaria una analisi che

possa rendere possibile l’estrazione di informazioni da un grande ed unico insieme di

dati eterogenei ed in continuo cambiamento. Ad esempio analizzando il fiume

inarrestabile di dati che transitano su Internet per avere informazioni sui trend della

società o per sondare i mercati.

In campo economico e non solo sta crescendo la consapevolezza di come una gestione

smart dei Big Data possa anche e soprattutto aiutare a scoprire nuovi modi di

migliorare i processi decisionali e le prestazioni.

Qual è la maggiore challenge dei Big Data?

Convertire la grande, eterogenea e rapidamente variabile mole di dati in informazioni

usabili, attraverso patterns e modelli di analisi generati da tali patterns: questa è la sfida

dei Big Data.

Diverse realtà stanno già cercando delle soluzioni per realizzare questo. Gli sviluppatori

e i fornitori di software certificati in Business Intelligence che stanno lavorando sui Big

Data sono in aumento, trasformando la gestione di questi dati in un settore in grande

espansione con attori sia nel privato che nella comunità open source. Contributi in

campo privato già esistono attraverso aziende come SAP, Oracle, HP e IBM, ma è dal

24

CAPITOLO 2 BIG DATA

mondo open source che sta arrivando la spinta decisiva all’innovazione nel campo della

gestione dei Big Data attraverso software come Apache Hadoop, Cascading, Apache

HBase, MongoDB, Apache Storm e altri.

Già oggi i Big Data sono una realtà, e l’ascesa dell’IoT non farà altro che produrne in

quantità esponenzialmente maggiore. Secondo IBM [8], vengono creati ogni giorno 2,5

quintilioni (1030) bytes di dati, che significa che negli ultimi due anni sono stati creati il

90% dei dati presenti in Rete; eBay possiede tre sistemi di storage distribuito per una

capacità complessiva di 90PB [9]; i sistemi informatici della catena di negozi Walmart

gestiscono ogni ora un milione di transazioni di acquisti online, che vengono registrati

su database che contengono 2,5 petabytes di dati [10]; Facebook gestisce 50 miliardi di

foto nei suoi database, e ovviamente questo numero cresce costantemente [11].

Con la crescita del numero dei dispositivi e delle operazioni che generano flussi di dati

sempre più complessi, usare i Big Data in modo efficace sta rapidamente diventando un

significativo vantaggio per molte aziende. Già da anni si discute sul grande valore che

hanno i dati. Questi dati diventeranno sempre più voluminosi, eterogenei e rapidi e sarà

decisivo cercare sempre migliori soluzioni per sfruttarli e raccogliere nuovi ed

emergenti tipi di dati per prendere decisioni e rispondere a domande che prima

dell’avvento dei Big Data erano considerati fuori portata.

2.2 Aree di applicazione

La gestione smart dei Big Data è un grande elemento di innovazione e diventerà sempre

più parte integrante dei modelli di analisi economica, migliorando la capacità del settore

di competere a livello globale. Ovviamente, fare il migliore uso possibile di questi dati

richiederà la crescita di un settore dedicato che si occupi di analisi predittiva e dati raw.

Di seguito alcuni esempi di applicazioni già esistenti del concetto di analisi dei Big Data

e anche delle potenziali aree in cui lo sfruttamento di questi dati può avere molto

importanza.

25

CAPITOLO 2 BIG DATA

Big Data for Consumers

Big Data significa anche dati prodotti dai consumatori e la loro analisi intelligente non

potrà che produrre benefici per questi ultimi. Ad esempio, l’elevato grado di

personalizzazione perseguito da compagnie come Netflix e Amazon nel consigliare

l’utente circa l’acquisto di prodotti si basa sull’analisi delle sue precedenti interazioni ed

è frutto di una analisi massiva su grandi moli di dati. Già da anni diversi service

providers come Comcast e Verizon monitorano in modo proattivo i computer dei loro

clienti al fine di rilevare infezioni da virus e malware. Lo stesso completamento

automatico di Google e il servizio di traduzione si basano su una grande raccolta di dati

e operano attraverso la loro analisi real-time.

Big Data for Community

Della raccolta e l’utilizzo dei dati beneficia non solo il consumatore, ma anche in senso

lato la comunità. Esempi dell’uso dei Big Data in tal senso sono ad esempio i potenziali

servizi da offrire a clienti di un determinato prodotto o a residenti di una determinata

area geografica. Analizzando i feedback forniti dai consumatori sui prodotti si

conferiscono vantaggi a tutta la comunità che li utilizza.

Big Data for Organizations

I Big Data forniscono indubbiamente una visibilità senza precedenti nel campo

commerciale in cui è possibile sondare approfonditamente i processi decisionali dei

clienti, consentendo alle aziende di analizzare, monitorare e anche creare modelli di

acquisto utili a incentivare le vendite. I Big Data possono essere sfruttati per affrontare

le situazioni in cui le informazioni sono frammentate in diversi sistemi non collegati tra

loro centralmente. Aggregando i dati tra i sistemi e gestendoli in modo distribuito, è

possibile sfruttare le potenzialità delle grandi quantità di informazioni. La gestione dei

Big Data può anche apportare miglioramenti nei processi produttivi offrendo una

migliore visibilità sulle questioni operative, ad esempio raccogliendo i dati emessi dai 26

CAPITOLO 2 BIG DATA

computer, dai sensori, dai GPS o dai misuratori. Con più dati a disposizione, le aziende

possono ottimizzare i metodi di distribuzione, allocare efficientemente il credito ed in

generale beneficiare il cliente.

Big Data for Manifacturing

Usare i Big Data nella produzione industriale significa apportare decisivi miglioramenti

nella pianificazione dei processi e nella qualità dei prodotti. L’analisi dei dati

provenienti dalle diverse fasi del processo produttivo fornisce una inedita infrastruttura

per la gestione industriale, permettendo di avere conoscenza maggiore che in passato

circa ad esempio le prestazione dei componenti, eventuali guasti e le velocità di lavoro.

Nuovi approcci come la produzione predittiva per sfruttare i tempi di inattività e

aumentare la conoscenza le fasi poco trasparenti del processo industriale si stanno

affermando. Attraverso i dati eterogenei generati da diversi tipi di sensori e relativi a

misure di pressione, tensione, corrente, acustica e vibrazioni si costruiscono dei patterns

e dei modelli al fine di ottenere degli stumenti predittivi e delle strategie preventive per

la programmazione e la gestione dei processi.

Big Data for Society

Da non sottovalutare è anche l’utilità sociale dell’uso dei Big Data, come ad esempio

nel caso di Data Mining per finalità di sicurezza nazionale o di analisi su larga scala dei

dati di geo-localizzazione per la pianificazione urbana, gestione di situazioni di

emergenza, ottimizzazione dei consumi energetici.

Big Data for Security

Altro importante campo di applicazione dell’uso dei Big Data è quello della sicurezza

informatica. Attraverso l’accesso real-time ai dati, è possibile migliorare le piattaforme

di sicurezza, attraverso l’analisi di una più ampia varietà di tipi di dati da elaborare che

contribuisce a migliorarne l’intelligenza. Allo stesso modo, l’uso di questi dati per il

27

CAPITOLO 2 BIG DATA

rilevamento delle frodi nel settore delle carte di credito aiuta a fare in modo che le

transazioni finanziare siano sicure.

2.3 Big Data Analytics

Come anticipato ad inizio capitolo, i Big Data non si prestano ad un tipo di analisi di

tipo tradizionale, come ad esempio quella effettuata attraverso i database relazionali.

Richiedono piuttosto l’analisi attraverso software massicciamente parallelo in

esecuzione in modo distribuito. Nasce quindi l’esigenza, al fine di convertire questo

grande insieme di dati in informazioni utili, di definire strumenti e tecniche nuove ed

adatte alla natura dei Big Data.

Vanno sotto il nome di Big Data Analytics i processi di raccolta, organizzazione ed

analisi di grandi set di dati eterogenei e in rapido cambiamento al fine di scoprire

patterns, correlazioni e altre informazioni utili.

Questo tipo di analisi quindi non solo aiuta a estrarre l’informazione contenuta

nell’insieme dei dati, ma si occupa anche di catalogare e gestire i dati che si configurano

sempre più come il fattore più importante, in campo aziendale, per le scelte strategiche.

Il risultato che gli analisti di Big Data quindi ricercano è principalmente la conoscenza

che viene dai dati stessi.

L’analisi dei Big Data si configura come una operazione tutt’altro che semplice, dove

entra in gioco oltre alla bontà agli strumenti informatici utilizzati, anche la necessità di

costruire delle soluzioni smart per riuscire ad estrarre dall’insieme eterogeneo e

volatile nel minor tempo possibile e col minor dispendio di risorse il maggior numero di

informazioni utili.

Le operazioni di Big Data Analytics sono in genere eseguite utilizzando strumenti

software specializzati e applicazioni per l’analisi predittiva, data mining (estrazione di

conoscenza a partire da grandi quantità di dati), text mining (data mining basato su dati

28

CAPITOLO 2 BIG DATA

testuali), forecasting (studio attraverso algoritmi di previsione) e ottimizzazione dei dati.

Queste tecniche, tutte delle funzioni distinte con obiettivi diversi, sono fortemente

integrate nell’analisi dei Big Data.

Si iniziò a parlare di Big Data Analytics già dal 2004, quando Google pubblicò un paper

[12] in cui descriveva una nuova architettura chiamata MapReduce.

Questo framework fu pensato per fornire un modello di elaborazione parallela e

implementazione distribuita per processare grandi quantità di dati. Attraverso

MapReduce, le query vengono divise e distribuite su nodi paralleli e processate in modo

distribuito (la fase Map). I risultati dell’elaborazione vengono poi raccolti e consegnati

(fase Reduce). Il framework ebbe molto successo, così che l’algoritmo MapReduce

fornì l’ispirazione per la creazione di nuove soluzioni. Ad esempio, una

implementazione del framework fu adottata da un progetto open source di Apache,

Hadoop [13], che ancora oggi è lo strumento più diffuso per la Big Data Analytics.

Attualmente la strada maggiormente intrapresa per implementare soluzioni di Big Data

Analytics è l’uso di architetture a livelli multipli, cioè di architetture parallele e

distribuite in cui i dati vengono disposti su più unità di elaborazione. Il calcolo parallelo

processa i dati molto più velocemente, consentendo una maggiore rapidità di

ottenimento dei risultati. In questo tipo di architettura i dati sono gestiti in DBMS

distribuiti, che lavorano parallelamente implementando l’uso di framework

MapReduce come Hadoop. L’utente finale, attraverso un front-end application server,

tiene traccia del processo di analisi grazie agli strumenti forniti dal framework.

Alcuni esempi di questo tipo di architetture saranno trattate di seguito e forniranno

spunti per le scelte attuate nella progettazione e nell’implemetazione delle soluzioni

smart obiettivo di questo lavoro di tesi.

29

CAPITOLO 2 BIG DATA

2.3.1 Three-Level Architecture

Il concept alla base dell’idea di analizzare i Big Data attraverso più livelli di gestione e

di elaborazione è quello di assegnare carichi di lavoro e tasks a sistemi che lavorano ed

emettono risultati a latenze diverse.

Costruire un sistema di elaborazione a più livelli, in questo caso specificatamente a tre,

è un concetto mutuato dallo storage a 3 livelli, in cui questi diversi livelli indicano

proprio la possibile latenza di accesso alle informazioni immagazzinate nei database.

Dallo storage si è pensato quindi di applicare il concetto di latenze diverse a quello di

elaborazione dei dati.

I tre livelli di questa architettura sono i seguenti: ONLINE PROCESSING,

NEARLINE PROCESSING, OFFLINE PROCESSING.

ONLINE PROCESSING

Questo livello si occupa della ricezione real-time dei dati, della loro elaborazione e

dell’emissione, sempre real-time, dei risultati. La caratteristica fondamentale di questo

livello è quello della velocità di elaborazione ed emissione, per cui generalmente non

gestisce dati troppo grandi e lavora con algoritmi snelli e semplici.

NEARLINE PROCESSING

Il Nearline è un livello Database-oriented; generalmente infatti esso si occupa dello

storage dei dati, che possono venir usati per sia per le computazioni online che per

quelle online. Può anche contenere un proprio stadio di computazione, in cui gli

algoritmi sono più complessi del livello Online e per questo serve risultati con velocità

minore.

30

CAPITOLO 2 BIG DATA

OFFLINE PROCESSING

In questo livello è prevista l’elaborazione batch dei dati, attraverso jobs pesanti e con

latenza più estesa che negli altri livelli. Gli algoritmi usati Offline possono essere molto

complessi, con pontenzialmente nessuna limitazione alla grandezza dei dati da

processare. A questo livello è riservato il compito di creare nuovi patterns e modelli di

gestione dei dati e di servire da strato di backup computazionale in assenza del livello

Online.

Perché una elaborazione dei dati a 3 livelli?

La sola elaborazione batch/offline dei dati fa correre il rischio di avere dati stantii ed

inoltre le applicazioni che le useranno non avranno gli input più recenti da elaborare.

L’ architettura a 3 livelli per la Big Data Analytics è già comune tra diverse realtà, che

con sfumature diverse e adattandola alle proprie esigenze e necessità, la usano per la

gestione delle grandi moli di dati. Di seguito alcuni interessanti casi d’uso

dell’architettura.

- NETFLIX

Netflix è una società statunitense che offre, tra gli altri, un servizio di streaming online

on demand di media e prodotti cinematografici. Usando l’architettura a 3 livelli [14],

Netflix elabora i dati in modi diversi, a seconda della velocità con cui i risultati devono

essere serviti ai clienti o alla valutazione interna. Con la propria architettura software di

analisi dei Big Data, questa azienda si pone l’obiettivo di essere sensibile

all’interazione degli utenti arricchendola con nuovi strumenti dati proprio da questo tipo

di analisi, come un sistema di raccomandazione e di advertising personalizzato.

Tutta l’architettura, i software e lo storage di Netflix sono ospitati sulla piattaforma di

Cloud Computing Amazon Web Services (AWS).

31

CAPITOLO 2 BIG DATA

Figura 2.2: Architettura a 3 livelli di Netflix

Nella figura 2.2, lo schema del sistema globale dell’architettura a 3 livelli usata da

Netflix, in cui gli strati di elaborazione Online, Nearline e Offline concorrono a

migliorare l’esperienza dell’utente gestendo e analizzando i Big Data.

32

CAPITOLO 2 BIG DATA

Una delle questioni chiave di questo tipo di architettura è quella di combinare e gestire i

diversi tipi di computazione in modo smart e continuativo.

Il livello Online dell’architettura Netflix risponde rapidamente agli eventi e utilizza i

dati più recenti. Uno use case delle funzionalità Online è ad esempio quello di generare

e suggerire al cliente una galleria di film in base alle ultime selezioni effettuate.

All’altra estremità dell’architettura, il livello Offline consente scelte algoritmiche più

complesse e quasi nessuna limitazione sulla quantità di dati da utilizzare. Un esempio

dell’uso di questo livello è quello di stilare periodicamente delle statistiche aggregate

sulla base di tutti i film visti e compilare metriche di popolarità di base da usare nei

suggerimenti da dare all’utente.

Il livello Nearline può essere visto come un compromesso tra i due livelli precedenti. In

questo caso, i risultati della computazione non hanno la necessità di essere emessi in

modo real-time, ma possono essere memorizzati in sistemi di storage per poter anche

essere usati in future elaborazioni online o offline. Questo permette un calcolo più

complesso ed algoritmi maggiormente elaborati: un esempio è quello di riuscire ad

aggiornare le proposte all’utente sulla base delle ultime scelte degli altri clienti.

Un importante concetto presente in questa architettura è quello di Machine Learning.

Algoritmi di apprendimento automatico e personalizzazione basata sui dati ricevuti sono

presenti in tutti i livelli della computazione, anche se la maggior parte del lavoro in tal

senso viene svolta Offline. La loro esecuzione è programmata per essere svolta

periodicamente e non ha bisogno di essere sincrona con la presentazione dei risultati.

L’attività che rientra in questa categoria sono il Model Training. Durante i jobs di

Model Training, vengono raccolti dati pertinenti e attraverso un algoritmo di Machine

Learning si producono una serie di parametri che costituiranno il modello. Quest’ultimo

di solito è codificato e memorizzato in un file per un uso successivo. Sebbene la

maggior parte dei modelli siano generati Offline in modalità batch, anche a livello

33

CAPITOLO 2 BIG DATA

Online e Nearline vengono eseguiti degli algoritmi di Machine Learning,

principalmente di tipo incrementale. La computazione batch si serve dei modelli

generati Offline e dei dati corrispondenti che li hanno generati per elaborare i risultati.

I dati da processare hanno bisogno di essere raffinati, per cui generalmente si usano

delle query. Dal momento che queste query devono essere eseguite su una enorme

quantità di dati, può essere utile eseguirle in modo distribuito attraverso degli strumenti

come Apache Hive (infrastruttura di data warehouse per effettuare query e analisi di

dati) e Apache Pig (piattaforma ad alto livello per la creazione di software MapReduce)

accoppiati ad Apache Hadoop (framework che supporta applicazioni distribuite con

elevato accesso di dati).

Una volta eseguite le query, è necessario un meccanismo di pubblicazione dei risultati,

che notifichi l’ottenimento degli stessi, si occupi del loro storage, gestisca gli errori

permettendo il monitoraggio. Netflix sotto questo punto di vista usa una soluzione

software interna, Hermes.

Figura 2.3: Tipi di input gestiti dall’architettura Netflix34

CAPITOLO 2 BIG DATA

I tipi di input che l’architettura Netflix gestisce rientrano in tre categorie: modelli, dati

e segnali. I modelli sono, come già visto, file di parametri creati generalmente Offline; i

dati sono le informazione precedentemente elaborati e conservati a livello Nearline nelle

piattaforme di storage (ad esempio metadati sui film o sulla popolarità degli stessi). I

segnali si riferiscono alle nuove informazioni, provenienti dal livello Online e che sono

relative all’interazione dell’utente (che film ha visto di recente, da che dispositivo, a che

ora è stato visto, ecc..).

Il sistema di storage di Netflix è contenuto nel livello Nearline, e consiste in varie

repository: MySQL, Apache Cassandra, EVCache.

MySQL consente la memorizzazione di dati strutturati relazionali: tuttavia i Big Data

possono essere anche non strutturati, e per la loro gestione è necessario lavorare con

soluzioni distribuite e database scalabili. Cassandra in questo senso viene in aiuto,

trattandosi di uno dei più diffusi DBMS non relazionali ottimizzato per gestire grandi

quantità di dati in modo distribuito. Nel caso di operazioni di scrittura intense e costanti

Netflix usa una soluzione interna di data store, EVCache.

L’obiettivo di Netflix è quello di utilizzare i dati dell’interazione utente in informazioni

utili per migliorare l’esperienza del cliente stesso. Per fare ciò è necessario catturare

quanti più eventi possibile da tale interazione attraverso le interfacce utente (smart tv,

tablets, console di gioco): dati di navigazione, di visualizzazione, o anche i semplici

click effettuati. Come descritto, attraverso algoritmi di Machine Learning l’obiettivo è

quello di lavorare i dati provenienti dall’utente per offrirgli soluzioni personalizzate.

Queste soluzioni possono provenire da liste precedente calcolate sull’esperienza di altri

utenti (esempio di Offline Processing) o generati real-time attraverso gli algoritmi

Online.

35

CAPITOLO 2 BIG DATA

- LINKEDIN

LinkedIn è un social network business-oriented impiegato principalmente per lo

sviluppo di contatti professionali.

E’ un servizio molto diffuso che ha raggiunto numeri ragguardevoli: 200 milioni di

utenti in tutto il mondo, 2 nuovi utenti al secondo, 100 milioni di visitatori al mese.

L’enorme afflusso di dati che continuamente transitano e vengono inseriti sui propri

server ha posto LinkedIn davanti alla challenge della gestione dei Big Data generati dal

servizio.

Anche questa azienda adotta, per la gestione e l’analisi dei Big Data, una architettura a 3

livelli, o meglio secondo il concept di LinkedIn a 3 fasi: sistemi Online, Nearline e

Offline, ciascuno progettato per carichi di lavoro specifici [15]. L’obiettivo nella

costruzione dell’architettura è stato quello di creare piattaforme e soluzioni per

bilanciare i costi con la complessità dei dati e semplificare il continuum dei dati

attraverso le tre fasi di elaborazione. Tutto questo per fornire all’utente servizi

differenziati a diversi gradi di latenza nel modo più efficiente possibile.

La gestione dei profili utente richiede grandi dataset ma deve contemporaneamente

consentire alte velocità di accesso e di aggiornamento dei dati; servizi come “People

You May Know” (Persone che potresti conoscere), in cui LinkedIn suggerisce all’utente

i contatti, si basa su algoritmi che lavorano su grandi quantità di dati e richiedono molte

risorse di computazione per fornire accessi veloci; LinkedIn Today, servizio di news

sharing, è sviluppato su dataset distribuiti e l’aggiornamento delle notizie deve essere

costante.

Esigenze diverse per servizi diversi: questo ciò che ha portato LinkedIn ha sviluppare la

propria architettura di Big Data Analytics su più livelli.

36

CAPITOLO 2 BIG DATA

Figura 2.4: Infrastruttura per gestione Big Data di LinkedIn

In figura 2.4 è rappresentata l’astrazione high-level delle tre fasi con cui LinkedIn

gestisce l’architettura. Come Netflix e come previsto da questo tipo di concept, la

differenziazione è mappata sulle diverse latenze e le diverse tempistiche richieste per

l’ottenimento dati. Gli obiettivi da raggiungere sono complessi e poche tecnologie a sé

stanti non possono affrontarle, così questa architettura si configura come una

combinazione di frameworks e tecnologie per soddisfare i requisiti richiesti.

Nello stack Online vengono gestite le interazione real-time dell’utente, attraverso

database relazionali come Oracle e un data store distribuito e document-oriented

costruito internamente all’azienda chiamato Espresso. Fa largo uso di indici ed è dotato

di strumenti per modificare le funzionalità e i target di raccolta dei dati. Rientrano in

questo livello la gestione dei profili utente e dei profili azienda, nonché altre

funzionalità come i messaggi.

37

CAPITOLO 2 BIG DATA

Il livello Nearline si occupa di servizi come la ricerca, le news, i suggerimenti

all’utente, i Social Graph che vengono aggiornati quasi costantemente. Il framework di

punta utilizzato in questo stack è Voldemort, sistema di storage distribuito ed altamente

scalabile anche questo autoprodotto da LinkedIn.

Elaborazione batch e ingenti carichi di lavoro analitici sono competenza dello stack

Offline, costituito principalmente da warehouse Hadoop e Teradata. Attraverso

algoritmi di Machine Learning vengono gestiti i dati e organizzati per ranking e

pertinenza.

Non è considerato un livello ma è molto importante nell’architettura di LinkedIn la

Pipeline, ovvero il sistema di interconnessione e comunicazione tra gli stack.

Messaggistica, monitoring, affidabilità, coerenza e bassa latenza sono le caratteristiche

della Pipeline, costruita attraverso un software creato internamente all’azienda, Databus,

in grado di modificare i flussi di acquisizione dati, e Apache Kafka, sistema di

messaggistica open source a bassa latenza ed alta produttività.

A diversi livelli lavorano altri componenti software sviluppati da Linkedin, come ad

esempio Helix, framework per gestione dei cluster che si occupa delle risorse distribuite

e su un cluster di nodi e della loro gestione automatica.

Azkaban è un altro software creato in azienda ed usato per la schedulazione, il

monitoraggio e la configurazione dei workflow, che permette l’associazione di processi

indipendenti in un unico workflow che viene programmato ed eseguito periodicamente.

38

CAPITOLO 2 BIG DATA

2.3.2 Lambda Architecture

L’architettura Lambda [16] per l’analisi dei Big Data è stata originariamente pensata da

Nathan Marz, noto nella community per il suo lavoro nel progetto Storm, che verrà

presentato più avanti.

Questo tipo di architettura propone un paradigma studiato per gestire la complessità

dell’analisi di grandi moli di dati pur essendo in grado di memorizzarli ed elaborarli

efficacemente. Mira infatti a soddisfare le esigenze di un sistema robusto che sia fault-

tolerant e che sia in grado di gestire una vasta gamma di carichi di lavoro e di casi

d’uso, in cui accessi ai dati a bassa latenza e frequenti aggiornamenti sono necessari. Il

risultato è quello di avere una architettura linearmente ed orizzontalmente scalabile e

distribuita. I principi alla base dell’architettura Lambda sono tre:

Human fault-tolerance: il sistema non deve essere soggetto a perdite o

corruzione di dati dovuti a errori umani o a guasti hardware. Data immutability: i dati vengono immagazzinati nella loro totalità ma

soprattutto nella loro forma iniziale e grezza, e conservati indefinitamente. Per

fare un’analogia con i sistemi di database relazionale, le operazioni consentite

nello storage dei dati non prevedono una forma di update o di delete dei record

inseriti, ma solo l’insert di nuovi o il select di quelli esistenti. Recomputation: a causa al sistema fault-tolerance e all’immutabilità dei dati,

deve essere sempre possibile rielaborare i risultati di un precedente calcolo

eseguendo delle query sui dati raw salvati nello storage.

I tre principi sopra esposti si possono riassumere in un’unica equazione che secondo il

concept di questa architettura deve essere alla base di ogni sistema di Big Data

Analytics: query = function (all data). Le query di analisi devono sempre essere

funzione di tutti i dati inseriti e a disposizione del sistema.

39

CAPITOLO 2 BIG DATA

Figura 2.4: Schema high-level dell’architettura Lambda

L’architettura Lambda è divisa in tre livelli, come l’architettura precedentemente

analizzata. A differenza della precedente, il concept e gli scopi perseguiti dalla Lambda

sono diversi e i dati vengono analizzati differentemente. Come descritto in figura 2.4,

non è presente un livello Nearline, in quanto i livelli di latenza comtemplati sono solo

due: Speed (analogo alla Online) e Batch (Offline). Il sistema di storage presente nel

livello intermedio qui viene diviso tra i due livelli Speed e Batch, in cui sono presenti

due diversi sistemi di database, per gestire rispettivamente solo i dati recenti nel livello

Speed e tutti i dati, precedenti e nuovi, nello loro totalità ed immutabilità nel livello

Batch.

40

CAPITOLO 2 BIG DATA

L’architettura Lambda inoltre si basa fortemente sul concetto di Precomputing, simile

al concetto di Model Training della precedente ma differente in termini di workflow e di

trattamento dei risultati.

Di seguito vengono analizzati i livelli dell’Architettura Lambda.

Batch Layer

Il livello Batch è responsabile di due compiti. Il primo di immagazzinare il master

dataset, immutabile e in costante crescita (generalmente viene usato lo storage HDFS di

Hadoop), il secondo di elaborare della views (precomputing) da questo dataset

attraverso algoritmi MapReduce (Hadoop). L’elaborazione di queste views è un

processo continuativo: all’arrivo di nuovi dati essi sono inseriti nello storage e

aggregati nelle views che vengono rielaborate costantemente.

Seguendo la filosofia dell’architettura (query = function (all data)) le views batch sono

generate dall’intero dataset a disposizione, per cui la loro frequenza di aggiornamento

non può essere molto alta. Dipendentemente dalla dimensione del set di dati, ogni nuova

interazione MapReduce che genera una rielabora le views potrebbe anche richiedere

ore.

Speed Layer

Come nello strato Batch, anche nello Speed vengono elaborate delle views dai dati

ricevuti. Compito di questo livello è quello di compensare l’alta latenza del livello

Batch e ciò viene fatto elaborando le views in real-time. Per ottenere questo, le views

real-time si basano solo sui nuovi dati ricevuti, non sulla totalità. Mentre il lato batch è

stato progettato per ricalcolare continuamente le views da zero, le views real-time usano

un modello incrementale: le views non vengono ricreate, ma solo incrementate con il

nuovo contenuto basato sui dati più recenti. Queste views sono intese per essere

41

CAPITOLO 2 BIG DATA

transitorie: non appena i nuovi dati sono stati propagati agli altri livelli, le views relative

a questi dati possono essere scartate. Ciò va a vantaggio della complessità del sistema.

Il framework che soddisfa appieno le esigenze di questo stack è senza dubbio Apache

Storm, sviluppato dallo stesso ideatore dell’architettura Lambda, Nathan Marz, e che

sarà parte integrante in questo lavoro di tesi.

Serving Layer

L’output dello strato batch è un set di file che contengono le views pre-elaborate.

Compito dello strato di Serving di indicizzare e fornire le views al sistema di query, il

quale interrogerà sia le views batch che quelle real-time, unendo i risultati.

Un esempio di software che è possibile utilizzare in questo strato è Cloudera Impala,

un open source SQL query engine per Hadoop.

Figura 2.5: Esempio di implementazione dell’architettura Lambda

42