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 Netflix
34
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 faulttolerant 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
