Upload
francesco-cardinale
View
536
Download
13
Embed Size (px)
Citation preview
Università degli Studi del Sannio
Dipartimento di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea
Big Data processing: un sistema scalabile per la
Sentiment Analysis
Luglio 2014
Relatore Prof. Eugenio Zimeo
Correlatore Dott. Guido Anzuoni
Candidato Francesco Cardinale
Matr. 195001566
A chi insegue un sogno nella vita
ai tenaci, ai testardi, agli ostinati
a chi cade e si rialza
a chi ci prova sempre e a chi non molla mai.
Perché loro sono quelli che guardano avanti
quelli che sperimentano sempre
quelli che credono nel futuro e non smettono mai di sognare.
Quelli che si sentiranno vecchi
solo quando i rimpianti saranno superiori ai sogni.
Quando si giunge ad un traguardo così importante nella vita, bisogna voltarsi indietro ed avere il coraggio, o forse il buon senso, di ammettere che: sulla strada dei gradi traguardi non si è mai soli.
Mi guardo indietro: salite, sorrisi, amici. Guardo avanti: nuove salite, altri sorrisi, gli stessi amici.
Molte sono le persone a cui devo molto e da cui ho appreso tanto. A loro vanno tutta la mia gratitudine ed ammirazione.
Dedico questo lavoro principalmente alla mia famiglia, in particolare ai miei genitori, per tutti i sacrifici che hanno fatto per darmi la possibilità di realizzare i miei sogni. Ai miei nonni, per la loro fiducia riposta in me. A mio fratello e alla mia sorellina, sempre disponibili a regalarmi un sorriso. A loro vanno tutta la mia stima, il mio rispetto e la mia riconoscenza.
Agli amici di sempre, quelli su cui si può sempre contare, quelli a cui basta un semplice sguardo. Capisci l’importanza di averli quando pensi ai momenti più belli della tua vita e li vedi al tuo fianco.
A tutti i fantastici ragazzi di ITD Solutions, ai loro consigli e ai loro sorrisi. Da ognuno di loro ho appreso qualcosa, un qualcosa che custodirò gelosamente. Mi hanno accolto come se facessi da sempre parte dell’azienda. In particolare, ringrazio la Dott.sa C. Ruocco e il Dott. L. Ristoratore che, come fratelli maggiori mi hanno insegnato tanto, anche dal punto di vista umano.
Al Dott. G. Anzuoni che mi ha dato la possibilità di entrare a far parte di questo gruppo. Mi ha dato più di quanto possa immaginare, mi ha dato un modello a cui aspirare. Grazie e lui ho scoperto questo affascinante mondo di Hadoop e della Sentiment Analysis.
Al Prof. E. Zimeo, sempre disponibile nel dispensare consigli e soluzioni, a qualsiasi ora. Grazie a lui ho avuto la possibilità di vivere questa splendida esperienza e di venire a conoscenza di questo nuovo mondo.
Francesco Cardinale
Indice
Indice
Indice delle Figure .................................................................................................... vi
Indice delle Tabelle .................................................................................................. vii
Sommario ................................................................................................................ viii
Introduzione .............................................................................................................. ix
Capitolo 1 – MapReduce ............................................................................................ 1
1.1 Introduzione ........................................................................................................................ 1
1.1.1 Panoramica ................................................................................................................ 2
1.1.2 Confronto tra RDBMS e MapReduce ................................................................. 2
1.2 Fondamenti di Hadoop MapReduce .......................................................................... 3
1.2.1 Rapida terminologia ............................................................................................... 4
1.2.2 Flusso di dati .............................................................................................................. 5
1.3 Modello di programmazione ........................................................................................ 6
1.3.1 Tipi e formato dei dati ............................................................................................ 6
1.3.2 Esempio ....................................................................................................................... 7
1.4 Per Big Data servono “Big ideas” ................................................................................. 8
1.4.1 I guasti sono frequenti ........................................................................................... 8
1.4.2 Elaborazione sequenziale dei dati, non casuale ........................................... 9
1.4.3 Concentrare l’elaborazione sui dati ................................................................... 9
1.4.4 Semplice scalabilità .............................................................................................. 10
1.4.5 Parallelizzazione implicita .................................................................................. 10
1.4.6 Architettura Scale-out ......................................................................................... 10
1.5 Quando usare MapReduce? ........................................................................................ 11
Capitolo 2 – Apache Hadoop .................................................................................. 12
2.1 Panoramica ........................................................................................................................ 13
2.1.1 Origini del progetto e diffusione attuale ...................................................... 15
2.1.2 Senza Hadoop? ...................................................................................................... 15
2.1.3 Caratteristiche salienti ........................................................................................ 16
2.2 HDFS ..................................................................................................................................... 16
2.2.1 NameNode e DataNode ..................................................................................... 17
iii
Indice
2.2.2 Blocchi e replicazione .......................................................................................... 19
2.3 Hadoop MapReduce ...................................................................................................... 20
2.3.1 Java MapReduce ................................................................................................... 21
2.3.2 Esecuzione di un job MapReduce ................................................................... 23
2.3.3 Shuffle e Sort .......................................................................................................... 25
2.4 Hadoop Streaming .......................................................................................................... 26
2.5 YARN ..................................................................................................................................... 27
2.6 ZooKeeper .......................................................................................................................... 29
2.7 Pig .......................................................................................................................................... 30
2.8 Hive ....................................................................................................................................... 31
2.8.1 Il modello dati ........................................................................................................ 33
2.8.2 Creazione di tabelle ............................................................................................. 34
2.8.3 SerDe ......................................................................................................................... 34
2.8.4 Funzioni definite dall’utente ............................................................................. 35
2.9 HBase .................................................................................................................................... 36
2.10 Flume ................................................................................................................................... 38
2.11 Oozie .................................................................................................................................... 40
Capitolo 3 – Sentiment Analysis ............................................................................. 42
3.1 Il Web ai tempi del Social Media ................................................................................ 42
3.1.1 Applicazioni della sentiment analysis ........................................................... 43
3.1.2 Un case study: La campagna presidenziale di Obama ............................. 44
3.2 Complessità della Sentiment Analysis ..................................................................... 44
3.2.1 Modalità di analisi ................................................................................................. 45
3.2.2 Il vocabolario e i relativi problemi ................................................................... 46
3.2.3 I problemi dell’elaborazione del linguaggio naturale ............................. 47
3.2.4 Il problema dello spam ....................................................................................... 47
3.3 Definizione del problema ............................................................................................. 47
3.3.1 Task basilari della Sentiment Analysis ........................................................... 48
3.3.2 Definizione formale di opinione ...................................................................... 48
3.4 Classificazione di un documento .............................................................................. 49
3.4.1 Supervised Learning ............................................................................................ 50
3.4.2 Unsupervised Learning ....................................................................................... 51
3.4.3 Limiti della classificazione per documento ................................................. 52
3.5 Classificazione a livello di frase .................................................................................. 52
3.6 Espansione del vocabolario ......................................................................................... 53
iv
Indice
3.7 Classificazione dei singoli aspetti .............................................................................. 54
3.7.1 Estrazione degli aspetti ...................................................................................... 54
3.7.2 Classificazione della polarità ............................................................................. 55
Capitolo 4 – Sistema per la Sentiment Analysis .................................................... 57
4.1 Panoramica del sistema sviluppato .......................................................................... 57
4.2 Twitter .................................................................................................................................. 58
4.2.1 Twitter API ............................................................................................................... 59
4.2.2 Formato dei dati .................................................................................................... 60
4.2.3 Perché Twitter? ...................................................................................................... 61
4.3 Acquisizione e memorizzazione dei tweet ............................................................ 62
4.3.1 Source ....................................................................................................................... 62
4.3.2 Configurazione dell’Agent................................................................................. 63
4.3.3 Channel .................................................................................................................... 64
4.3.4 Sink ............................................................................................................................ 64
4.4 Analisi dei dati .................................................................................................................. 65
4.4.1 Interpretazione dei dati ...................................................................................... 65
4.4.2 Determinazione del Sentiment ........................................................................ 67
4.4.3 Tabella di output ................................................................................................... 74
4.5 Automatizzazione del Sistema ................................................................................... 74
4.6 Accuratezza del Sistema ............................................................................................... 75
4.7 Analisi dei risultati ........................................................................................................... 77
4.7.1 Intervalli temporali ............................................................................................... 78
4.7.2 Geolocalizzazione del sentiment .................................................................... 82
Capitolo 5 – Conclusioni e sviluppi futuri .............................................................. 84
Appendice A – Cloudera .......................................................................................... 86
Appendice B – Classificazione bayesiana .............................................................. 88
B.1 Classificatore Naïve Bayes ............................................................................................ 88
B.2 Classificatori Naïve Bayes in Weka ............................................................................ 89
B.2.1 Multinomial Naïve Bayes .................................................................................... 89
B.2.2 Naïve Bayes ............................................................................................................. 90
Appendice C – Pentaho ........................................................................................... 91
Bibliografia e Sitografia .......................................................................................... 92
v
Indice delle Figure
Indice delle Figure
Figura 1.1 – Vista semplificata dell’architettura di MapReduce ................................ 4
Figura 1.2 – Flusso dei dati in un job MapReduce ................................................... 5
Figura 1.3 – Esempio WordCount: passi di un job MapReduce ............................... 8
Figura 2.1 – Architettura di Hadoop ......................................................................14
Figura 2.2 – Architettura di HDFS .........................................................................18
Figura 2.3 – Come Hadoop esegue un job MapReduce ...........................................23
Figura 2.4 – Operazioni di Shuffle e Sort in MapReduce .........................................25
Figura 2.5 - Architettura di YARN .........................................................................28
Figura 2.6 – Architettura di Hive ...........................................................................32
Figura 2.7 – Struttura di HBase..............................................................................38
Figura 2.8 – Architettura di Flume .........................................................................39
Figura 4.1 – Architettura del sistema per la Sentiment Analysis ...............................58
Figura 4.2 – Architettura del sistema di acquisizione dei tweet ................................62
Figura 4.3 – Distribuzione percentuale delle polarità ..............................................78
Figura 4.4 – Trend del sentiment su intervallo temporale di 24 ore .........................79
Figura 4.5 – Trend del sentiment su scala oraria in relazione alla prima partita. .......80
Figura 4.6 – Trend del sentiment su scala oraria in relazione alla seconda partita. ...81
Figura 4.7 – Trend del sentiment su scala oraria in relazione alla terza partita. ........82
Figura 4.8 – Distribuzione dei tweet positivi per ogni regione. ................................83
vi
Indice delle Tabelle
Indice delle Tabelle
Tabella 1.1 – Confronto tra RDBMS tradizionali e MapReduce ............................... 3
Tabella 2.1 – Funzionalità delle componenti dell’ecosistema Hadoop .....................14
Tabella 2.2 – Formati di input di MapReduce ........................................................22
Tabella 2.3 – Formati di output di MapReduce ......................................................22
Tabella 2.4 – Confronto tra RDBMS e Hive ...........................................................31
Tabella 4.1 – Parole chiave del mondo Twitter .......................................................59
Tabella 4.2 – Matrice di Confusione del sistema.....................................................76
Tabella 4.3 – Dati relativi alle tre partite dell'Italia nel Mondiale 2014 ....................79
vii
Sommario
Sommario
“Per natura, all'opinione piace opinare.”
– Platone
I social media sono i luoghi virtuali dove si concretizzano le comunicazioni
interpersonali, dove le opinioni prendono forma e si diffondono. Mentre il passaparola
tradizionale è difficile da misurare, le discussioni online sono normalmente visibili e
persistenti e dunque possono essere ascoltate, comprese ed analizzate, sia al fine di
individuare trend emergenti che per progettare efficaci azioni di comunicazione,
pubbliche relazioni e marketing, così come per esaminare gli umori degli utenti.
La progressiva diffusione dei social network, sia generalisti (quali Twitter, Facebook o
Google+) che specializzati (ad esempio le comunità professionali di LinkedIn), ha reso
disponibile una massiccia e inedita quantità di dati, utilizzabile in tempo reale. Questi
dati custodiscono una visione d’insieme sull’atteggiamento – meglio conosciuto come
sentiment – degli utenti verso un prodotto, un servizio, un’azienda o una singola
persona.
Il sentiment è quindi il pensiero espresso dagli utenti attraverso i mezzi di
comunicazione attualmente disponibili nel Web. L'analisi del sentiment – meglio
conosciuta come Sentiment Analysis – è l'insieme delle operazioni con le quali si
ascolta il web per rilevare le opinioni, gli umori, i punti di vista degli utenti.
Con un approccio basato sulla combinazione di un dizionario dei termini e di un
classificatore automatico, si è realizzato un sistema, intrinsecamente scalabile,
affidabile e automatizzato, grazie all’utilizzo degli strumenti messi a disposizione da
Hadoop, per la determinazione del sentiment degli italiani, sulla base delle loro
opinioni espresse su Twitter durante tutto l’arco temporale che ha visto protagonista,
nel bene e nel male, la Nazionale Italiana nel Mondiale di calcio brasiliano del 2014.
I risultati finali, riportati graficamente tramite Pentaho, consentono di ottenere una
visione degli umori e delle emozioni degli italiani sia sulla base di un intervallo
temporale variabile, la cui unità minima di tempo è definita su una singola ora, che
sulla base di una mappa geografica dell’Italia per ottenere un grafico geolocalizzato.
viii
Introduzione
Introduzione
“Al pari di Google, tutta una serie di social media, come Facebook, Twitter, LinkedIn,
Foursquare e altri, siedono letteralmente su una montagna di informazioni datizzate che,
una volta analizzate, faranno luce sulle dinamiche sociali a tutti i livelli, dall’individuo
alla società nel suo complesso”
– Viktor Mayer-Schönberger e Kenneth Cukier
iviamo nell’era dei dati, o meglio dei Big Data1! In un’era in cui l’analisi di grandi
moli di dati destrutturati diventa fondamentale, non solo per gli aspetti
puramente commerciali e civili, in quanto i dati possono essere d'ausilio anche alla
singola persona fisica, i social network diventano un bacino insostituibile di
reperimento di informazioni, aprendo innumerevoli opportunità per le aziende.
La quantità di informazioni digitali che si generano ogni giorno sta assumendo
proporzioni colossali, dal segnale GPS dei telefonini alle strisciate di bancomat e carte
di credito, dai Tweet alle chiacchere su Facebook. Non si entra più in Internet, ci
viviamo dentro.
Fino al 2003 tutti gli strumenti connessi alla rete hanno prodotto 5 miliardi di
gigabytes, nel 2010 erano già diventati 80 miliardi, oggi tale quantità viene raggiunta
in due giorni. All’origine si tratta di semplici numeri, pura matematica, poi, quando
vengono accorpati, letti e interpretati, diventano informazioni. Se elaborati e
contestualizzati si trasformano in conoscenza.
Gestire ed elaborare queste grandi quantità di dati risulta però complesso. Il diminuire
dei costi di memorizzazione, e quindi le dimensioni delle memorie di massa, non è
andato di pari passo con le possibilità di accedervi. Ad esempio, nel 1990 un tipico
disco2 aveva la capacità di 1370 MB abbinato ad una velocità di trasferimento di
4,5 MB/s, rendendo possibile leggere l'intero contenuto in circa 5 minuti. Al giorno
d'oggi, dopo più di 20 anni, dischi di capacità intorno al terabyte sono la norma: la
capacità è aumentata di un fattore 1000. Le velocità di trasferimento attuali sono
1 Big data indica i dati prodotti in grande quantità, con notevole rapidità e nei formati più diversi, la cui elaborazione richiede strumenti differenti da quelli convenzionali, in tutte le fasi del processo: dall'acquisizione, alla gestione e all’archiviazione passando per condivisione, analisi e visualizzazione.
2 Le specifiche si riferiscono al modello Seagate ST-41600n.
V
ix
Introduzione
invece aumentate solo di un fattore 25 e si assestano nell'ordine dei
100 MB/s, rendendo quindi necessarie più di due ore e mezzo per accedere all'intero
contenuto del disco.
In molti contesti è emersa la necessità di svolgere elaborazioni di grandi quantità di
dati. Agli albori dello sviluppo della rete Internet, e anche per alcuni decenni a seguire,
non ci si ponevano queste problematiche proprio perché i mezzi fisici, i computer, non
avevano una grande diffusione presso privati e quindi nella casa – o addirittura nelle
tasche – di ogni cittadino del mondo economicamente sviluppato. Oggi invece la
situazione si è ribaltata e sempre più persone sono in grado di essere loro stessi dei
creatori di informazioni oppure collaborano alla creazione delle stesse e in più possono
occuparsi della loro promozione e condivisione.
Nella realtà contemporanea c’è quindi una grande mole di informazioni disponibili e
in costante aumento, alla quale gli utenti accedono e contribuiscono a mantenere in
vita e far sviluppare. Ciò anche grazie a strumenti hardware e software di grande
diffusione come macchine fotografiche digitali e programmi di fotoritocco,
smartphone, piattaforme di facile utilizzo per la gestione di blog, ecc. Si tratta di
informazioni e messaggi che una volta generati possono essere modificati e diffusi in
rete da chiunque.
Nell’economia della rete è informazione tutto ciò che questa è in grado di generare e
può essere provato come tale: non solo la semplice notizia, ma anche il fatto che una
persona che reputa interessante un video, un’immagine, una notizia, un post, e così
via, e decida di condividerlo sulla propria bacheca di Facebook e lì aggiungere un
commento per innescare un confronto con gli amici, anche attraverso l’utilizzo di
ulteriori strumenti di comunicazione (ad esempio, pubblicando l’articolo in un tweet).
È comprensibile quindi come il concetto di informazione assuma una forte dimensione
pubblica e collettiva, secondo i canoni propri di Internet. Ed è evidente che quando si
parla di informazione non si può riduttivamente intendere solo ciò che l’utente ricerca,
ma anche qualsiasi altra azione egli faccia in rete. Quali parole usa per interrogare un
motore di ricerca, quanto resta in un pagina, se usa i link, se clicca sulla pubblicità,
quale pubblicità, se condivide un contenuto, se carica video su Youtube, quali video
vede, e in generale tutto ciò che decide di condividere.
Inoltre, la gran mole di dati che produciamo non trae origini solo dalla rete Internet,
comunemente nota. Oggi oltre che attraverso i PC e i classici mezzi di comunicazione,
l’informazione viene generata e propagata anche da una moltitudine di piccoli
x
Introduzione
dispositivi che supportano, quotidianamente, le nostre attività: navigatori satellitari,
telecamere, sensori urbani, telepass, ecc.
Le aziende si trovano ad affrontare la sfida posta da questa sempre crescente mole di
dati che devono essere catturati, archiviati e utilizzati ai fini di una successiva
elaborazione, sia per scopi di business che per produrre nuova conoscenza. L’ulteriore
sfida è posta dalla natura stessa di questi dati che sta cambiando, arricchendosi sempre
più di dati di provenienza varia. I dati non strutturati costituiscono ora una parte molto
consistente della totalità delle informazioni disponibili e le aziende stanno rapidamente
valutando tecnologie che permettano di analizzarli per ottenerne un vantaggio
competitivo.
Per molti, i dati non strutturati rappresentano una potente risorsa ancora tutta da
scoprire e sfruttare, una risorsa capace di fornire una conoscenza più approfondita su
clienti ed operazioni che può quindi trasformarsi in un vantaggio competitivo. Ma
questi dati non possono essere facilmente gestiti con database relazionali tradizionali
o con strumenti di business intelligence, concepiti per gestire solo dati strutturati.
Il problema viene ulteriormente complicato dalla rapidità con cui crescono volume e
velocità dei dati strutturati e non strutturati, il che costringe le aziende a cercare modi
nuovi per acquisire, organizzare, gestire e analizzare questi dati.
L’insieme di questi elementi ha portato allo sviluppo di nuovi modelli di elaborazione
distribuita e di tecnologie analitiche quali Hadoop, NoSQL3 e altre adatte a gestire i
dati non strutturati nella loro forma originaria. Queste tecnologie permettono alle
aziende di studiare soluzioni per diventare più efficienti, ridurre il TCO4 (Total Cost
of Ownership) e migliorare la flessibilità dell’infrastruttura IT di supporto.
Naturalmente, sarebbe anche tecnicamente possibile convertire i dati non strutturati
in una forma strutturata e poi utilizzare sistemi di gestione di database relazionali per
manipolarli. Il processo di conversione, tuttavia, richiede una considerevole quantità
di tempo, incrementando i costi e ritardando il raggiungimento del risultato finale.
È evidente, quindi, che per trattare questa grande mole di dati ci sia bisogno di un
approccio infrastrutturale ad hoc, più efficiente in termini di costi. In molte situazioni,
la piattaforma più idonea è basata sulla presenza di tante commodity server di
3 Il termine NoSQL identifica tutti quei database che si discostano dalle regole che caratterizzano i database relazioni (RDBMS). Essi sono spessi utilizzati per immagazzinare grandi quantità di dati e sono altamente scalabili. Si consiglia di visitare il sito http://nosql-database.org/, che si pone come guida di riferimento del movimento NoSQL, per ulteriori approfondimenti in merito.
4 Total Cost of Ownership (TCO), in italiano costo totale di proprietà o costo totale di possesso, è un approccio utilizzato per calcolare tutti i costi del ciclo di vita di un’apparecchiatura informatica IT, per l’acquisto, l’installazione, la gestione, la manutenzione e il suo smantellamento.
xi
Introduzione
dimensioni più piccole, anziché di piattaforme di classe enterprise, e le risorse di
storage vengono gestite localmente, a livello di singolo server, anziché essere
centralizzate e condivise. Questo approccio distribuito, infatti, presenta numerosi
vantaggi. Per esempio, garantisce flessibilità in termini di costi grazie alla potenzialità
di rapida scalabilità orizzontale che consente di introdurre anche migliaia di server di
fascia bassa, anziché dover effettuare un costoso aggiornamento di server enterprise e
apparecchiature di storage. E per quanto riguarda le performance, il modello
“shared-nothing”, in cui appunto ciascun nodo dispone di risorse a esso dedicate,
elimina la necessità di incanalare i dati attraverso un numero limitato di dischi
condivisi, eliminando il rischio di potenziali colli di bottiglia che potrebbero incidere
significativamente sulle performance in caso di ingenti quantità di dati da elaborare.
Tra i numerosi metodi emersi in questi anni per analizzare i Big Data, quello che
presenta le suddette caratteristiche è senza dubbio MapReduce e in particolare la sua
implementazione open source che ha riscosso maggiore successo, anche per numero
di installazioni, Hadoop.
Panoramica su Hadoop
Hadoop è un framework open source, affidabile e scalabile, finalizzato all’analisi,
all'archiviazione e all'elaborazione distribuita di grandi quantità di dati strutturati e
non strutturati. Permette alle applicazioni di lavorare con migliaia di nodi e petabyte
di dati. Fornisce un filesystem distribuito (HDFS) in grado di memorizzare i dati su
migliaia di server, e un modo per eseguire computazioni (detti job Map/Reduce)
distribuite su tali macchine, in prossimità dei dati.
Hadoop è un progetto Apache di alto livello, e Yahoo! rappresenta il più grande
contributore, e ne fa fortemente uso. Hadoop è usato anche da: Ebay, Facebook, IBM,
ImageShack, Linkedin, Spotify, The New York Times, Twitter, e tanti altri.
Fondamentalmente si tratta di una tecnologia in grado di distribuire i carichi di lavoro
tra più computer (partizionando opportunamente il dataset), al fine di suddividere
l’analisi dei dati in più task paralleli per produrre i risultati in maniera più rapida.
Sempre più organizzazioni si rendono conto della necessità di disporre di una nuova
piattaforma sviluppata sulla base di tecnologie come Hadoop che, oltre a ospitare i
flussi di dati correnti, sia i grado di assorbire i nuovi flussi di dati che, inevitabilmente,
arriveranno sulla scia del successo iniziale del progetto. Una tale piattaforma facilita
notevolmente le attività di utilizzo, analisi e sperimentazione dei flussi di dati
xii
Introduzione
eterogenei (strutturati e non strutturati), adeguandosi perfettamente al concetto dei
Big Data.
Panoramica sulla Sentiment Analysis
La Sentiment Analysis si propone di analizzare le opinioni espresse dagli utenti sui
social media relativamente a prodotti e servizi e alle loro caratteristiche. Trae origine
dalla Natural Language Processing (ovvero, l’analisi del linguaggio naturale), dalla
linguistica computazionale5 e dal social media analytics, la disciplina che studia e
analizza i dati sociali, e trova applicazione in svariati settori che vanno da quello
turistico, alla military intelligence 6, alle strategie di real-time marketing7 basati su
contenuti sociali. Alcuni esempi sono il monitoraggio e l’analisi dei fenomeni sociali,
l’analisi delle opinioni riferite a un particolare prodotto o un determinato servizio della
pubblica amministrazione, o ancora l’analisi delle intenzioni di voto, come è stato fatto
negli Stati Uniti durante il confronto elettorale tra i due candidati Obama e Romney8.
Attraverso le reti sociali, gli utenti possono comunicare condividendo informazioni
legate ai propri interessi e attività, ed esprimere opinioni riguardanti il proprio stile di
vita, le proprie necessità e desideri. Le scelte dei consumatori sono sempre più
influenzate dai pareri espressi sui social media attraverso il passaparola sul web – word
of mouth – e il feedback degli utenti a prescindere dal bene di consumo, dal prodotto
o dal servizio.
Le recenti analisi di mercato evidenziano la tendenza dei consumatori a utilizzare i
social media per la prenotazione di un albergo, per l’acquisto di beni, cellulari,
automobili, per decidere che film vedere o ancora relativamente a temi di politica e
attualità. I contenuti, generati dagli utenti sotto forma di recensioni di prodotti e/o
opinioni su blog, forum, gruppi di discussione e social network crescono rapidamente
e si stanno rivelando una risorsa di considerevole importanza. Le opinioni sono lette e
seguite dalla gente comune, dalle compagnie e dalle imprese, ma accedervi sta
gradualmente diventando sempre più complesso a causa della crescita del numero delle
5 La linguistica computazionale si concentra sullo sviluppo di formalismi descrittivi del funzionamento del linguaggio naturale, tali che si possano trasformare in programmi eseguibili dai computer. I problemi che affronta la linguistica computazionale consistono nel trovare una mediazione fra un oggetto di studio in costante evoluzione (il linguaggio umano) e le capacità di comprensione della macchina, limitate a quanto può essere descritto tramite regole formali.
6 La military intelligence si occupa della raccolta, analisi e distribuzione di informazioni rilevanti per le operazioni militari.
7 La real-time marketing si occupa di determinare “in tempo reale” un approccio adeguato o ottimale per un determinato cliente in un determinato momento e/o luogo.
8 Per approfondimenti si veda il Paragrafo 3.1.2.
xiii
Introduzione
conversazioni virtuali. L’abilità di ascoltare le opinioni e la disponibilità di programmi
in grado di processarle in modo automatico rappresentano elementi sempre più
apprezzati, specialmente dalle grandi organizzazioni che sfruttano l’opinione del
consumatore per ricavarne informazioni utili per le proprie decisioni e per la
definizione di scelte di strategia aziendale e di marketing.
Mentre la prima generazione di prodotti dedicati alla social media analytics forniva
strumenti in grado di contare citazioni di brand, marchi o prodotti, attualmente si
stanno diffondendo strumenti più efficienti in grado di effettuare un monitoraggio più
accurato delle informazioni riferite ai prodotti e servizi di interesse. Analogamente per
quanto riguarda l’analisi dei contenuti esistono diversi strumenti in grado di lavorare
sui testi attraverso approcci statistici o linguistici. I primi basati su funzioni che
operano in base alla frequenza dei termini e i secondi basati su risorse linguistiche che
permettono l’analisi sintattica e semantica dei contenuti. Entrambi gli approcci sono
utilizzati nella Sentiment Analysis ma con evidenti differenze di comportamento e di
dettaglio di analisi.
Attualmente il principale obiettivo della ricerca nell’ambito della Sentiment Analysis è
quello di spostare la frontiera, passando dalla semplice valutazione della polarità delle
opinioni espresse ad una in cui le opinioni sono analizzate in modo sempre più
dettagliato, al fine di coglierne le correlazioni, legarle al contesto e possibilmente
geo-referenziarle. A tal proposito, le attuali ricerche prevedono lo sviluppo di algoritmi
e applicazioni basati su un approccio linguistico del tipo Natural Language Processing.
In particolare, possono essere individuate come fasi principali lo sviluppo di risorse
linguistiche, la classificazione basata sullo stato emotivo espresso nelle opinioni e la
sommarizzazione dei risultati ottenuti, che consiste nell’aggregazione e
rappresentazione dei risultati elaborati.
La preparazione dei dati in un sistema di Sentiment Analysis coinvolge l’utilizzo di
diverse risorse linguistiche. L’insieme delle attività coinvolte nell’analisi sintattica e
semantica dei testi sono processi basati su WordNet 9, che rappresenta la risorsa
linguistica più ampiamente diffusa nell’ambito della NLP e sviluppata presso
l’Università di Princeton, oppure MultiWordNet10 per lingue diverse dall’inglese.
La classificazione del sentiment contempla lo sviluppo di algoritmi e di applicazioni
basati su diversi approcci, mediante un dizionario dei termini, tecniche di machine
learning o metodologie tipiche della NLP. L’elaborazione dei testi include fasi
9 Sito web: http://wordnet.princeton.edu/. 10 Sito web: http://multiwordnet.fbk.eu/english/home.php.
xiv
Introduzione
successive di analisi dei dati: si spazia dall’analisi sintattica, che determina la struttura
grammaticale di un testo attraverso l’identificazione delle parti del discorso 11 , in
inglese part-of-speech (POS), all’analisi semantica che assegna il significato più
probabile alle POS per risolvere automaticamente l’ambiguità intrinseca nei termini e
permette di estrarre il significato espresso nel testo. Se si è interessati ai testi che
parlano di “calcio”, è necessario selezionare il significato preciso di tale parola. Se
l’interessa riguarda l’attività sportiva, si vogliono selezionare tutti i testi in cui una
parola è presente proprio con questa accezione, e quindi escludere automaticamente,
attraverso la tecnica della disambiguazione che considera il contesto in cui le parole
sono inserite, tutti i risultati che riportano il termine calcio con altri significati
(elemento chimico, comune in provincia di Bergamo, componente di una pistola, ecc.).
L’utilizzo della risorsa linguistica è necessario anche nelle fasi successive per correlare
le opinioni espresse dagli utenti alle considerazioni sui prodotti o servizi su cui si
esprime un’opinione. L’attività di estrazione delle feature (caratteristiche o aspetti),
anche nota come features o aspects extraction, fa parte dell’opinion extraction e
prevede l’identificazione degli aspetti relativi al prodotto o servizio a cui le opinioni
sono riferite. Per esempio, se si parla di un hotel alcune delle sue caratteristiche
possono essere: camera, stanza da bagno, letto, prezzi, piscina, ristorante, igiene, ecc.
L’analisi delle opinioni viene riferita alle caratteristiche e complessivamente al
prodotto o al servizio da esse descritto.
Al fine di riferire correttamente le opinioni alle caratteristiche è necessario poi, isolare
le frasi aventi valore soggettivo, che esprimono cioè una opinione. Le frasi contenute
nelle opinioni sono infatti distinte in frasi oggettive e frasi soggettive. Queste ultime
esprimono stati mentali ed emozioni quali valutazioni, sensazioni, sentimenti, ecc.
Una frase soggettiva esprime ad esempio un apprezzamento: “la camera era molto
accogliente”, mentre una frase oggettiva descrive semplicemente un fatto: “sono
andato in vacanza con un’amica, in camera doppia”.
Isolare tali frasi, attraverso un sistema di classificazione, consente di ridurre il
“rumore” causato dalla presenza di affermazioni e valutazioni non pertinenti e di
impostare la fase di sommarizzazione, durante la quale si aggregano i risultati elaborati
precedentemente, limitatamente alle frasi esprimenti giudizi sulle caratteristiche
identificate secondo schemi e grafici di facile lettura.
11 La grammatica italiana distingue tradizionalmente le seguenti parti del discorso: sostantivo, verbo, aggettivo, articolo, avverbio, preposizione, numerali, pronome, interiezione.
xv
Introduzione
Obiettivo del lavoro di Tesi
In questo lavoro di Tesi si intende creare un sistema per la Sentiment Analysis, che sia
efficiente, affidabile e scalabile, tramite l’utilizzo delle funzionalità offerte da Hadoop
e dalle relative componenti.
Il lavoro svolto prevede attività che caratterizzano varie fasi della Sentiment Analysis.
Nella prima fase si procede all’estrazione dei dati da una sorgente che in questo lavoro
è rappresentata dal Social Network Twitter. Sulla base di un insieme di parole chiave
sono prelevati tramite un estrattore, quale Flume (una componente di Hadoop), i tweet
riferiti ad un argomento prestabilito, quale la Nazionale Italiana di Calcio.
Una volta estratti e memorizzati i dati su HDFS, si procede alla classificazione del
sentiment. In questo lavoro si procederà sia sulla base di un classificatore automatico
che sulla base di un dizionario dei termini, dove a ciascun termine viene associato un
valore numerico che ne specifica la polarità positiva o negativa del sentiment. Per la
fase di classificazione è possibile sfruttare le potenzialità di Hive, una componente di
Hadoop che permette di utilizzare un linguaggio simile a SQL, e di integrarlo con
funzioni definite dall’utente (UDF), e allo stesso tempo, convertendo automaticamente
le query in elaborazioni MapReduce, ne assicura la scalabilità.
I dati prodotti possono essere poi elaborati e presentati secondo diverse dimensioni,
utilizzando tool di business intelligence come Pentaho, in modo da ottenere grafici e
report relativi al sentiment, sia in riferimento ad un determinato intervallo temporale,
che ad una particolare area geografica.
Ai fini del lavoro di tesi si prevede anche di automatizzare tutte le operazioni,
sfruttando orchestratori/scheduler come Oozie di Hadoop.
Struttura della Tesi
Nel Capitolo 1 viene presentata una panoramica riguardante il paradigma MapReduce,
su cui si basa indirettamente l’intero sistema, sia dal punto di vista concettuale, sia
analizzandone le principali funzionalità implementate in Hadoop. Nel Capitolo 2 viene
descritto il framework Hadoop, e tutte le relative componenti più importanti. Nel
Capitolo 3 sono presentati i diversi approcci, e quindi lo stato dell’arte, nel campo della
Sentiment Analysis. Nel Capitolo 4 viene presentato il sistema sviluppato per la
Sentiment Analysis, i risultati ottenuti in termini di accuratezza e i report relativi alle
analisi effettuate. Nel Capitolo 5 sono descritti gli sviluppi futuri, relativi sia
all’aumento delle performance che al miglioramento dell’accuratezza del sistema.
xvi
Capitolo 1 MapReduce
MapReduce
“MapReduce è un modello di programmazione e una relativa implementazione per
elaborare e generare insiemi di dati di grandi dimensioni. […] I programmi che adottano
questo stile funzionale vengono automaticamente gestiti in una logica parallela ed eseguiti
su cluster di macchine a tecnologia commodity. Il sistema run time si occupa nel dettaglio
del partizionamento dei dati di input, pianificando l’esecuzione del programma attraverso
una serie di macchine, gestendone gli eventuali guasti e la comunicazione che ha luogo tra
esse. Tutto questo permette a programmatori senza alcuna esperienza in sistemi paralleli e
distribuiti di utilizzare con molta semplicità le risorse di un grande sistema distribuito.”
– Jeffrey Dean e Sanjay Ghemawat
apReduce è un framework1 software brevettato e introdotto da Google per
supportare la computazione distribuita di grandi quantità di dati su cluster2
di computer, in modalità batch3.
MapReduce lavora secondo il principio divide et impera. Un problema complesso, che
utilizza una gran mole di dati, è suddiviso, assieme ai dati stessi, in piccole parti
processate in modo autonomo e, una volta che ciascuna parte del problema è stata
calcolata, i vari risultati parziali sono “ridotti” a un unico risultato finale.
1.1 Introduzione MapReduce permette di processare, in modalità batch, query ad hoc riguardanti
l’intero insieme di dati, o una buona porzione di esso, per poi produrre un risultato in
1 Un framework è una struttura di supporto su cui un software può essere organizzato e progettato. Un framework, in generale, include software di supporto, librerie, un linguaggio per gli script e altri software che possono aiutare a mettere insieme le varie componenti di un progetto.
2 Un cluster è un insieme di computer connessi tramite una rete telematica. 3 Tutta la sequenza di operazioni e dati necessari per svolgere un particolare compito vengono preparati
in anticipo e memorizzati su un adeguato supporto creando una procedura. La procedura viene poi eseguita dal sistema come un blocco unico, cioè senza che sia necessario, o possibile, un intervento umano prima che sia terminata.
CAPITOLO 1
M
1
Capitolo 1 MapReduce
un tempo ragionevolmente breve. Il termine MapReduce viene utilizzato sia per
indicare il modello computazionale, sia il framework concettuale necessario, sia le
specifiche implementazioni.
1.1.1 Panoramica Un anno dopo la pubblicazione di un documento nel quale si descriveva l’architettura
del filesystem distribuito4 utilizzato da Google, detto GFS (Google File System)5, nel
2004 Google rilascia un altro documento che introduce MapReduce6 al mondo. Le
forti esigenze di parallelizzazione hanno portato l’azienda a creare un’astrazione che
potesse accelerare lo sviluppo di applicazioni parallele, relegando i dettagli relativi alla
parallelizzazione, gestione dei guasti e distribuzione dei dati ad una libreria.
MapReduce è un framework utile alla creazione di applicazioni in grado di elaborare
grandi quantità di dati in parallelo, basato sul concetto di programmazione funzionale.
L’implementazione classica del calcolo parallelo è basata sulla programmazione
multithreading, che prevede la suddivisione del lavoro in più parti distinte, i thread,
condividendo la memoria ed altre risorse. La programmazione multithreading presenta
una certa complessità proprio nel coordinare l’accesso alle risorse condivise. Nella
programmazione funzionale, invece, la condivisione dei dati è eliminata, e con essa,
anche i relativi problemi di coordinazione. I dati sono invece passati tra le funzioni
come parametri o valori di ritorno.
1.1.2 Confronto tra RDBMS e MapReduce MapReduce è davvero essenziale? Oppure è possibile utilizzare database distribuiti su
più dischi per effettuare delle analisi batch su larga scala?
I Big Data sono disponibili in enormi volumi, si presentano con formati destrutturati e
caratteristiche eterogenee e, spesso, sono prodotti con estrema velocità. Volume,
variabilità e velocità sono dunque le caratteristiche che li identificano.
Velocità. Il Seek time è il tempo necessario per spostare la testina del disco sopra la
traccia desiderata, per leggere o scrivere una particolare porzione del disco. Esso
sostanzialmente caratterizza il tempo di accesso al disco, dato che il tempo di
4 Il termine file system indica, informalmente, un modello con il quale i file sono posizionati e organizzati su un supporto di archiviazione. Un file system distribuito è un particolare file system che permette la memorizzazioni di file e risorse in dispositivi di archiviazione distribuiti in una rete informatica.
5 Si veda http://research.google.com/archive/gfs.html. 6 Si veda http://research.google.com/archive/mapreduce.html.
2
Capitolo 1 MapReduce
trasferimento di un blocco di bit è relativamente più basso. Per cui, risulta molto
più conveniente limitare quanto più possibile il seek time, evitando di accedere di
volta in volta a diverse porzioni del disco. E questo è ciò che avviene con
MapReduce, che esprime tutte le sue qualità quando si tratta di analizzare l’intero
dataset in modo sequenziale, a differenza dei database relazionali, utili soprattutto
per aggiornamenti di piccole porzioni di dati.
Variabilità. La caratteristica della variabilità, che si traduce nella mancanza di una
struttura ben definita, rende difficile la rappresentazione di tali dati in un sistema
relazionale, che preferisce operare su dati strutturati, organizzati in schemi
predefiniti. MapReduce, invece, è in grado di lavorare su qualsiasi formato di dati,
essendo progettato per interpretare i dati.
Volume. Per quanto riguarda il volume dei dati, MapReduce presenta un modello
quasi linearmente scalabile. Idealmente, la velocità di elaborazione è direttamente
proporzionale al numero dei nodi del cluster e inversamente proporzionale alle
dimensioni dei dati da analizzare. Per cui, raddoppiando il numero dei nodi,
raddoppia la velocità. Raddoppiando le dimensioni del dataset, si dimezza la
velocità di elaborazione. E questo non sempre è vero per i database relazionali.
Tabella 1.1 – Confronto tra RDBMS tradizionali e MapReduce
RDBMS Tradizionale MapReduce
Dimensione dei dati Gigabyte Petabyte
Accesso Interattivo e Batch Batch
Aggiornamenti Scritto e Letto più volte Scritto una volta, letto più volte
Struttura Schema statico Schema dinamico
Integrità Alta Bassa
Scalabilità Non lineare Lineare
1.2 Fondamenti di Hadoop MapReduce Il framework MapReduce è anche una componente centrale dell’ecosistema Hadoop,
che sarà trattato in dettaglio nel prossimo capitolo. Per ora è sufficiente sapere che
Hadoop è una piattaforma software open source, affidabile e scalabile, finalizzata al
calcolo distribuito, cioè al calcolo che avviene su un sistema di computer indipendenti,
ma collegati tra loro in rete. Il nucleo centrale di Hadoop è essenzialmente costituito
dal framework MapReduce e da HDFS, un file system distribuito che fornisce
3
Capitolo 1 MapReduce
un’efficace modalità di accesso ai dati. HDFS garantisce che i dati siano ridondanti nel
cluster rendendo le operazioni sui dati stessi immuni da un eventuale guasto o
malfunzionamento di un nodo. HDFS, inoltre, accetta dati in qualsiasi formato,
strutturato, semistrutturato o non strutturato.
1.2.1 Rapida terminologia Prima di immergersi nelle funzionalità di MapReduce, è necessario esplicitare il
significato dei termini che lo caratterizzano.
Un job è un’unità di lavoro destinata all’esecuzione, sottoposta dal client Hadoop. Si
compone dei dati di input, un programma MapReduce, informazioni di
configurazione. Hadoop esegue il job dividendolo in task, che sono di due tipi: map
task e reduce task.
A livello architetturale, MapReduce presenta due tipi di nodi, in una struttura
master/slave, che controllano il processo di esecuzione di un job: un JobTracker e
diversi TaskTracker. Il JobTracker si occupa della gestione delle risorse (CPU e
Memoria) e del ciclo di vita del job MapReduce. Inoltre, coordina tutti i job eseguiti
sul sistema, schedulando i task che devono essere eseguiti sui TaskTracker. I
TaskTracker, che girano sui singoli nodi, eseguono i task sotto la direzione del
JobTracker, e inviano di tanto in tanto dei report sullo stato del processo ai JobTracker.
Figura 1.1 – Vista semplificata dell’architettura di MapReduce
4
Capitolo 1 MapReduce
1.2.2 Flusso di dati L’input di un job MapReduce è diviso da Hadoop in blocchi di dimensione fissa, detti
split. Successivamente, Hadoop crea un map task per ogni split, che esegue la
particolare funzione map definita dall’utente per ogni record nello split.
In generale, è consigliabile avere degli split sufficientemente piccoli per avere un carico
di lavoro bilanciato tra i diversi nodi, anche se la dimensione non deve essere inferiore
ad una certa soglia, altrimenti l'overhead per gestirli diventa più rilevante del tempo
totale per eseguire l'operazione vera e propria. Generalmente, la migliore scelta è quella
di avere la dimensione di uno split corrispondente alla grandezza di un blocco HDFS.
Nel processo di map i dati in input sono letti da HDFS, mentre i dati di output sono
scritti sul filesystem locale in quanto si tratta di risultati parziali che dovranno essere
rielaborati in seguito dai reducer per produrre l’output finale. Invece l’output finale
prodotto dai reducer è normalmente archiviato su HDFS per garantire l’affidabilità.
Nella Figura 1.2 è rappresentato il flusso di dati in un job MapReduce, con multipli
map task e reduce task. Le caselle tratteggiate indicano i nodi, le frecce tratteggiate
denotano i trasferimenti di dati in uno stesso nodo, mentre le altre frecce evidenziano
i trasferimenti di dati tra nodi diversi.
Figura 1.2 – Flusso dei dati in un job MapReduce
I map task partizionano gli output, creando una partizione per ogni reduce task. In
ogni partizione potrebbero esserci diverse chiavi (e relativi valori), ma i record per ogni
specifica chiave, relativi ad uno specifico split in input, sono tutti in una singola
partizione. In ogni partizione è eseguito un ordinamento – fase sort – per chiave. Una
5
Capitolo 1 MapReduce
volta terminata la fase di map, i TaskTracker notificano al JobTracker il
completamento del loro lavoro e, a questo punto, i dati di input sono stati trasformati
in una lista di coppie chiave/valore.
Successivamente le partizioni sono copiate nei nodi dove risiedono i reducer e il
JobTracker può attivare la fase di reduce, nella quale i TaskTracker aggregano – fase
merge – i risultati dei mapper, conservando l’ordinamento per chiave. Le fasi di sort e
merge, implicite e gestite dal sistema, costituiscono congiuntamente la fase di shuffle.
Infine, i TaskTracker eseguono la funzione reduce al fine di produrre l’output, salvato
in un file diverso per ciascun TaskTracker. La fase reduce, per ogni chiave, elabora i
valori a essa associati e crea, come output, una o più coppie chiave/valore.
È anche possibile definire una funzione combiner, che si posiziona nel flusso di lavoro
tra i mapper e i reducer. In pratica svolge lo stesso lavoro dei reducer, ma limitatamente
ad un singolo nodo. L’utilizzo di combiner consente di ridurre notevolmente il traffico
di rete, poiché l’attività di aggregazione è svolta prima di inviare i dati ad altri nodi.
Inoltre, il processo di esecuzione può anche essere più articolato rispetto a quello
proposto, poiché è possibile che si susseguano più fasi MapReduce: l’output di un job
diventa l’input del job successivo, finché non si giunge al risultato finale. La
concatenazione di più job si rende necessaria per la soluzione di problemi complessi.
1.3 Modello di programmazione MapReduce presenta un semplice modello di elaborazione dati: la computazione
riceve in ingresso un insieme di coppie chiave/valore e produce in uscita un insieme di
coppie chiave/valore. Lo sviluppatore dovrà solo farsi carico di esprimere la
computazione attraverso due funzioni: map e reduce.
1.3.1 Tipi e formato dei dati La funzione map riceve in input una coppia chiave/valore e produce una lista di coppie
chiave/valore intermedie:
map: (k1, v1) list(k2, v2)
La funzione map è applicata in parallelo ad ogni coppia dell’insieme dei dati in ingresso.
Essa produce una lista di coppia per ogni chiamata. Successivamente, il framework
MapReduce si occupa di raggruppare tutti i valori intermedi associati alla stessa chiave
6
Capitolo 1 MapReduce
intermedia, creando quindi una lista di valori per ogni chiave e trasferisce il tutto alla
funzione reduce.
La funzione reduce riceve in input la chiave intermedia e, per ognuna di essa, una lista
corrispondente di valori, generando in uscita una lista di coppie chiave/valore:
reduce: (k2, list(v2)) list(k3, v3)
I tipi di dato delle chiavi e dei valori, il formato di input – che determina la modalità di
lettura dei dati e ciò che è passato alla funzione map come chiave e valore – e il formato
di output sono definiti dallo sviluppatore.
In generale, i tipi di dato in ingresso (k1 e v1) alla funzione map sono differenti da quelli
in uscita (k2 e v2). Tuttavia, i tipi di dato in ingresso alla funzione reduce devono
coincidere con quelli in uscita dalla funzione map, e quelli in uscita dalla funzione
reduce potrebbero essere ancora differenti (k3 e v3).
1.3.2 Esempio Il WordCount è un classico esempio utilizzato per descrivere il funzionamento di
MapReduce. L’obiettivo è quello di contare il numero di occorrenze di ogni parola
all’interno di una collezione di documenti. L’input della funzione map è una coppia
chiave/valore, dove la chiave rappresenta il nome del documento e il valore il testo del
documento, mentre l’output della funzione reduce è una lista di coppie chiave/valore,
che rappresentano la parola e il relativo numero di occorrenze.
Ecco lo pseudocodice delle due funzioni Map e Reduce per l’esempio in questione:
function map(String key, String value): // key: nome del documento // value: testo del documento for each word w in value: emit (w, 1) function reduce(String key, Iterator values): // key: una parola // values: una lista di valori sum = 0 for each v in values: sum += ParseInt(v) emit (key, sum)
La funzione map suddivide il testo del documento nelle parole che lo compongono e
associa il valore 1 a ciascuna parola, creando così le coppie (“parola”, 1) da restituire
7
Capitolo 1 MapReduce
in output. La funzione reduce somma il contenuto della lista di valori – in questo caso
tutti ‘1’ – che sono associati alla chiave.
Si suppone, per esempio, di avere due file costituiti l’uno dalla frase “Efficienza
significa fare le cose nel modo giusto” e l’altro dalla frase “Efficacia significa fare le
cose giuste”. Nella Figura 1.3 sono rappresentati i vari step del job MapReduce.
Figura 1.3 – Esempio WordCount: passi di un job MapReduce
1.4 Per Big Data servono “Big ideas” Appositamente sviluppato per affrontare carichi di lavoro su larga scala, MapReduce
presenta delle caratteristiche che non sono del tutto innovative. Tuttavia, la genialità
degli ingegneri di Google non è stata solo nel riuscire ad implementare le potenzialità
di queste grandi idee, ma anche nel concatenarle tra loro in un modo molto efficiente.
1.4.1 I guasti sono frequenti I guasti non sono un’eccezione, sono la norma. In cluster di medie/grandi dimensioni,
la probabilità che qualche nodo sia irraggiungibile è molto alta, sia per guasti
hardware, sia per guasti di connettività o semplicemente per manutenzione. A maggior
ragione questo risulta vero utilizzando macchine di classe server low-end. Affinché
possa essere efficace, un servizio di calcolo distribuito non può prescindere dalla
gestione dei guasti. In particolare, occorre fare in modo che questi non impattino sulla
8
Capitolo 1 MapReduce
qualità del servizio. Nel caso di computazioni batch, mentre un ritardo limitato può
essere ammissibile, sicuramente non lo è la corruzione o la perdita dei dati.
Nella filosofia di MapReduce, l’irraggiungibilità di un numero limitato di nodi prima
della fase di esecuzione è facilmente sopportabile a livello di calcolo, grazie
all’astrazione tra algoritmo e piattaforma. Lo stesso vale per la disponibilità dei dati:
l’irraggiungibilità di specifici nodi può essere superata aggiungendo delle repliche
dislocate dei dati a livello di filesystem distribuito.
Nel caso si verifichi un guasto durante l’esecuzione di un calcolo, il sistema deve essere
in grado di portarlo ugualmente a compimento. La strategia suggerita in questo caso è
la riesecuzione: nel caso un nodo diventi irraggiungibile, le parti di calcolo assegnate a
quel nodo (nella forma di esecuzioni di chiamate alle funzioni map o reduce) vengono
riassegnate ad altri nodi.
1.4.2 Elaborazione sequenziale dei dati, non casuale MapReduce è stato concepito per elaborare, in modalità batch, enormi quantità di dati
che risiedono necessariamente nei dischi, essendo troppo grandi da tenere in memoria.
Come già detto nel Paragrafo 1.1.2, il seek time costituisce il limite maggiore quando
si tenta di accedere al disco in maniera random. Di conseguenza, MapReduce tenta di
evitare il più possibile l’accesso casuale, preferendo l’accesso ai dati in modo
sequenziale. Trattandosi di computazioni batch, l’idea di MapReduce è quella di
favorire il throughput7 a scapito della latenza8, sfruttando la banda aggregata dei dischi
di un cluster.
1.4.3 Concentrare l’elaborazione sui dati In alcuni sistemi di calcolo ad alte prestazioni è comune disporre di supercomputer
dove vi è una distinzione tra nodi di calcolo e nodi di memorizzazione, collegati da
interconnessioni ad elevato throughput. In tali sistemi, l’elaborazione di enormi moli
di dati può portare ad un inevitabile collo di bottiglia, costituito dalle interconnessioni.
In MapReduce, invece, ciascun nodo svolge entrambi le funzioni, sia di
memorizzazione e sia di calcolo. Questo permette di ridurre notevolmente la quantità
di dati trasferiti da un nodo all’altro, eseguendo la funzione map direttamente sul nodo
dove risiedono i dati di input, sfruttando in questo modo il principio di località dei
7 Il throughput indica il numero di operazioni processate per unità di tempo. 8 La latenza è il tempo richiesto da una singola operazione per essere processata dall’inizio alla fine.
9
Capitolo 1 MapReduce
dati. Ovviamente ciò è possibile in cooperazione con il filesystem distribuito,
responsabile della gestione dei dati sui quali opera MapReduce.
1.4.4 Semplice scalabilità Un algoritmo ideale in grado di elaborare grandi quantità di dati deve essere
linearmente scalabile, sia in riferimento ai dati da elaborare, sia in riferimento alle
risorse hardware a disposizione. Se un algoritmo richiedesse 1 ora per elaborare un
particolare insieme di dati su una singola macchina, allora in un cluster di 100
macchine lo stesso algoritmo su un insieme di dati 100 volte maggiore idealmente
dovrebbe richiedere lo stesso tempo, ossia 1 ora.
Uno degli aspetti di maggior rilievo di MapReduce è proprio il fatto di riuscire ad
avvicinarsi il più possibile a tale caratteristica di scalabilità lineare.
1.4.5 Parallelizzazione implicita È noto come lo sviluppo di applicazioni parallele sia un compito alquanto complesso,
in quanto le problematiche relative a fenomeni quali deadlocks e race conditions sono
intrinsecamente difficili da individuare, isolare e risolvere. Sebbene esistano molte
tecniche e design patterns che possono parzialmente sopperire a questa difficoltà, la
programmazione distribuita e parallela rimane una sfida non semplice da affrontare.
MapReduce si fa carico di gestire queste problematiche, in questo modo il
programmatore potrà concentrarsi solo sulla progettazione delle due funzioni map e
reduce, la cui esecuzione parallela è garantita dal framework MapReduce.
1.4.6 Architettura Scale-out La scalabilità indica la capacità di un sistema di evolvere in potenza, aggiungendo o
sostituendo un componente. Il concetto dietro alla scalabilità orizzontale – approccio
scaling out – è quello di usare hardware commodity, ossia facile da reperire e dal costo
limitato. A differenza della scalabilità verticale – approccio scaling up – in cui si
installano server sempre più potenti, nel caso di quella orizzontale si possono
aumentare le performance del sistema aumentando il numero di server di classe media,
suddividendo le risorse in tanti piccoli nodi low-end interconnessi fra di loro.
L’obiettivo è quello di poter creare un cluster di nodi che per potenza di calcolo,
throughput e scalabilità offra maggiori garanzie di un sistema tradizionale ma a costi
più ridotti. Una tale architettura è anche definita shared-nothing, poiché ciascun nodo
10
Capitolo 1 MapReduce
dispone di risorse a esso dedicate, suddividendo l’esecuzione di un’operazione in più
task paralleli e indipendenti.
MapReduce è stato concepito per sfruttare questo tipo di architettura, favorendo la
località dei dati, per minimizzare quanto più possibile onerosi trasferimenti di dati tra
diversi nodi della rete. Il programma, infatti, viene suddiviso in task in base a dove
sono localizzati i dati. Viene data priorità all’esecuzione dei map task sulla stessa
macchina su cui risiedono fisicamente i dati, o almeno nello stesso rack.
1.5 Quando usare MapReduce? I programmi MapReduce non hanno la garanzia di essere veloci. Il maggiore beneficio
di questo modello di programmazione è quello di distribuire le operazioni in modo
ottimale sull’hardware a disposizione, cosicché il programmatore possa concentrarsi
solo sui requisiti funzionali e quindi nella scrittura del codice riguardante le funzioni
map e reduce. Tuttavia, tener conto della funzione di partizione e della quantità di dati
scritta dalla funzione map potrebbe avere un grande impatto sulle prestazioni.
Funzionalità aggiuntive, come la funzione combiner, possono inoltre contribuire a
ridurre la quantità di dati scritti sul disco e trasmessi da un nodo all’altro sulla rete.
Nel progettare un algoritmo MapReduce, il programmatore dovrà scegliere un buon
compromesso tra velocità di computazione e overhead dovuto alle comunicazioni,
dato che molte implementazioni MapReduce sono progettare per registrare tutte le
comunicazioni sul file system per favorire il successivo recupero dai guasti.
Per i processi che terminano velocemente, e per quelli dove la quantità di dati è
relativamente piccola, tale da essere contenuta nella memoria principale di una singola
macchina o di un piccolo cluster, l’utilizzo del framework MapReduce generalmente
non è efficace: dal momento che il framework è progettato per facilitare il ripristino in
caso di guasti di un nodo qualsiasi durante la computazione, esso scrive i risultati
intermedi sul file system distribuito. Tale meccanismo di ripristino risulta costoso, e
paga solo quando la computazione coinvolge molti computer e calcoli elaborati – una
computazione che termina in pochi secondi può solo essere riavviata in caso di errore;
la probabilità che si verifichi almeno un guasto aumenta rapidamente con la
dimensione del cluster. Per tali problemi, le implementazioni mantengono tutti i dati
in memoria e semplicemente riavviano la computazione in caso di guasto di un nodo,
oppure – quando la dimensione dei dati è abbastanza piccola – soluzioni non
distribuite risultano spesso più veloci di un sistema MapReduce.
11
Capitolo 2 Hadoop
Apache Hadoop
“Al tempo dei pionieri questi usavano i buoi per trainare i carichi pesanti, e quando un
bue non riusciva a tirare un tronco essi non tentavano di allevare buoi più grossi. Noi non
dobbiamo provare a costruire computer più grandi, ma sistemi di più computer”
– Grace Hopper
adoop è una piattaforma software open source, affidabile e scalabile, finalizzata
al calcolo distribuito, cioè al calcolo che avviene su un sistema di computer
indipendenti, ma collegati tra loro in rete; permette alle applicazioni di lavorare con
migliaia di nodi e petabyte di dati.
Apache Hadoop consente di archiviare e analizzare i dati e costituisce il modo per
creare valore dai cosiddetti Big Data. Tutti sanno che i dati sono in crescita
esponenziale. Cosa non è così chiaro è il modo di sbloccare il valore che detengono.
Hadoop è la risposta. Sviluppato da Doug Cutting di Cloudera, Hadoop è un
framework che consente di distribuire l'elaborazione parallela di grandi quantità di dati
su hardware commodity, relativamente poco costoso.
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,
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 trarne vantaggio in futuro.
Con Hadoop i dati non sono mai troppo grandi. In un mondo in cui le persone, le
imprese e le macchine creano dati continuativamente, la capacità di Hadoop di
crescere praticamente senza limiti permette di sbloccarne il potenziale valore.
Una curiosità: il nome Hadoop proviene da un elefante giallo di peluche del figlio di
Doug Cutting, il quale lo ha scelto perché è semplice da scrivere e pronunciare, privo
di significato e non usato altrove.
CAPITOLO 2
H
12
Capitolo 2 Hadoop
2.1 Panoramica La crescita impressionante dei dati osservata negli ultimi anni, e destinata a proseguire
nel futuro, ha fatto nascere molti progetti indirizzati a trovare delle soluzioni il più
possibile semplici ed economiche sia per archiviare tali informazioni, sia per eseguire
delle elaborazioni su moli di dati fino a poco tempo fa impensabili. Poiché la gran parte
delle informazioni oggi generate è di tipo non strutturato, è in questa direzione che
molti dei progetti si sono mossi e tra questi anche Hadoop.
Hadoop nasce come progetto per l’analisi distribuita di grandi insiemi di dati
attraverso un semplice modello di programmazione. L’architettura, realizzata in Java,
permette di poter scalare da pochi server fino a migliaia di sistemi: ogni server
contribuisce con le proprie risorse di calcolo e la propria capacità di memorizzare i
dati, e quindi aggiungendo server, chiamati anche nodi, è possibile far crescere un
sistema Hadoop in modo quasi lineare.
L’alta affidabilità, e dunque la protezione dei dati, viene realizzata non basandosi sulle
caratteristiche hardware dei server, bensì a livello software: sono le librerie di Hadoop
che si occupano di identificare se e quali componenti presentino un
malfunzionamento, intervenendo per ripristinare le operazioni, ad esempio creando
una nuova copia dei dati contenuti in un server. È evidente che nella scala dei petabyte
le soluzioni di backup tradizionali non sono utilizzabili, quindi è proprio la
distribuzione dei dati su diversi nodi la chiave per salvaguardare le informazioni anche
di fronte ad un guasto di uno dei nodi.
Le componenti costituenti il nucleo centrale di Hadoop sono:
Hadoop common. Uno strato di software comune che fornisce funzioni di
supporto agli altri moduli.
HDFS. Il file system distribuito che fornisce un’efficace modalità di accesso ai
dati. Garantisce ridondanza e affidabilità. Accetta dati in qualsiasi formato.
YARN. Un framework che consente di creare applicazioni o infrastrutture per il
calcolo distribuito. Si occupa della gestione delle risorse del cluster.
MapReduce. Il sistema di elaborazione parallela dei dati (basato su YARN a
partire della versioni 0.23.X e 2.X.X di Hadoop).
Al nucleo centrale, “sopra” HDFS e MapReduce, si aggiungono altri moduli che fanno
parte dell’ecosistema, estendendone le funzionalità. La Figura 2.1 mostra l’insieme
13
Capitolo 2 Hadoop
delle componenti dell’ecosistema Hadoop e nella Tabella 2.1 sono elencate in breve le
relative funzionalità.
Figura 2.1 – Architettura di Hadoop
Tabella 2.1 – Funzionalità delle componenti dell’ecosistema Hadoop
Componente Descrizione
HDFS Hadoop Distributed File System. Garantisce l’accesso ai dati in un qualsiasi nodo del cluster Hadoop. Accetta dati in un qualsiasi formato, strutturato o non strutturato.
YARN Sistema di gestione delle risorse del cluster, che consente di creare applicazioni o infrastrutture per il calcolo distribuito.
MapReduce Piattaforma software per la creazione di applicazioni che processano grandi moli di dati in parallelo su cluster di molti nodi.
Hive Sistema di data warehousing costruito su Hadoop, che consente di aggregare dati, eseguire query e analizzare grandi dataset. Hive utilizza il linguaggio HiveQL, simile sintatticamente a SQL.
R (connettori) R è un software statistico in grado di utilizzare Hadoop attraverso i plug-in (connettori) RHive e RHadoop.
Pig Libreria che semplifica la creazione di job di trasformazione dei dati. Pig, con il suo linguaggio chiamato Pig Latin, consente di scrivere sequenze di operazioni di trasformazione in maniera piuttosto semplice, che Pig stesso converte in job MapReduce.
Mahout Libreria di Machine Learning e Data Mining
HBase È un database column oriented, distribuito e scalabile, che si basa su HDFS.
Oozie Strumento di gestione del workflow delle operazioni.
Zookeeper Strumento di coordinamento e sincronizzazione delle risorse per applicazioni distribuite.
Flume Sistema per la movimentazione di grandi quantità di dati da fonti di diverso tipo verso HDFS (o altre destinazioni). Presenta un’architettura semplice e flessibile basata sullo streaming di flussi di dati.
Sqoop Libreria per il trasferimento di dati tra database relazionali e Hadoop.
Ambari Strumenti di monitoraggio e amministrazione del cluster Hadoop.
14
Capitolo 2 Hadoop
2.1.1 Origini del progetto e diffusione attuale Hadoop nasce per sopperire a un problema di scalabilità di Nutch1, un crawler2 open
source. Doug Cutting e Michael J. Caffarella hanno lavorato su un embrione di
Hadoop a partire dal 2004, anno in cui furono pubblicati documenti tecnici riguardanti
Google File System e Google MapReduce, tecnologie da cui Hadoop ha attinto.
Inizialmente si trattava di un componente di Nutch, in grado di migliorarne la
scalabilità e le prestazioni. Nel 2008 nasce la prima release come progetto open source
indipendente di Apache, realizzata anche grazie all’assunzione da parte di Yahoo! di
Cutting, al quale fu messo a disposizione un team di sviluppo.
Hadoop è ormai riconosciuto come una delle più promettenti soluzioni
general-purpose per i Big Data, capace di memorizzare grandi quantità di dati e fornire
una semplice ma potente piattaforma di analisi: numerose distribuzioni di Hadoop
sono oggi messe a disposizione da aziende storiche dell’IT quali EMC, IBM e
Microsoft, oltre che da realtà specializzate sulle tecnologie Hadoop quali Cloudera.
Ebay, Facebook, LinkedIn, Twitter e AOL sono solo alcune tra le più importanti realtà
che attualmente fanno uso di Hadoop3.
2.1.2 Senza Hadoop? Prima dell’affermazione di Hadoop, le elaborazioni su grandi quantitativi di dati erano
realizzate esclusivamente da sistemi di High Performance Computing4 (HPC) e Grid
Computing5, tramite l’utilizzo di API quali, per esempio, Message Passing Interface
(MPI), un protocollo di comunicazione tra nodi appartenenti a un cluster di computer
che eseguono un programma parallelo sviluppato per sistemi a memoria distribuita.
Gli HPC suddividono il lavoro su molti computer in cluster, che utilizzano un file
system condiviso, cioè un insieme di dischi raggiungibili da tutti i nodi del cluster. Se
l’attività è processor-intensive, il sistema funziona bene, ma qualora occorresse
1 Nutch è un progetto finalizzato alla costruzione di un motore di ricerca open source. È basato su Lucene, una libreria di ricerca e di indicizzazione che inizialmente non conteneva un crawler, mancanza poi sopperita da Nutch.
2 I crawler, detti anche spider o robot, sono componenti dei motori di ricerca che analizzano i contenuti di una rete (o di un database) in un modo metodico e automatizzato, recuperando i contenuti delle pagine e fornendoli al motore di ricerca per l’indicizzazione.
3 Al link http://wiki.apache.org/hadoop/PoweredBy sono indicati i maggiori utilizzatori di Hadoop. 4 Il termine High Performance Computing si riferisce alle tecnologie utilizzate da computer cluster per
creare dei sistemi di elaborazione in grado di fornire delle prestazioni molto elevate, ricorrendo tipicamente al calcolo parallelo.
5 I Grid Computing sono un’infrastruttura di calcolo distribuito, utilizzati per l’elaborazione di grandi quantità di dati, mediante l’uso di una vasta quantità di risorse.
15
Capitolo 2 Hadoop
accedere a grandi moli di dati, le performance non sarebbero ottimali a causa di
problemi di rete: l’accesso di tutti i nodi del cluster alla risorsa di storage condivisa
costringerebbe i nodi stessi ad attendere l’arrivo dei dati. Inoltre le MPI sono librerie
di basso livello, piuttosto complesse.
Al contrario, Hadoop con HDFS e MapReduce offre librerie di alto livello, più semplici
da utilizzare. Inoltre la ripartizione dei dati direttamente sui nodi di calcolo permette
di minimizzare i tempi di accesso, poiché i dati sono immediatamente disponibili alle
procedure, senza onerosi trasferimenti di rete.
2.1.3 Caratteristiche salienti Hadoop è un sistema altamente affidabile: esso gestisce gli eventuali problemi del
sistema a livello applicativo, invece di sfruttare sistemi hardware di alta disponibilità.
Hadoop, infatti, è pensato per sfruttare cluster di commodity hardware, che può essere
frequentemente soggetto a problemi e che non prevede meccanismi di fail-over6.
Un’altra importante caratteristica di Hadoop è la scalabilità, che è realizzabile
semplicemente aggiungendo nodi al cluster. Ciò concorre a limitare i costi rispetto ad
una soluzione basata su database tradizionale, dove spesso la scalabilità si realizza
sostituendo l’hardware esistente con macchine più potenti ed estremamente costose.
Hadoop nasce per la gestione di calcoli ed elaborazioni su grandi moli di dati, caricati
nel sistema e utilizzati, in lettura, da una o più procedure. Tale utilizzo è nettamente
all’opposto rispetto a un database relazionale OLTP7 (Online Transaction Processing),
nel quale le singole transazioni interessano soltanto pochi record. L’utilizzo di Hadoop
in tali scenari non sarebbe efficiente e non avrebbe senso, poiché si tratta di attività
gestite in modo ottimale dagli RDBMS.
2.2 HDFS HDFS (Hadoop Distributed File System)8 è un file system distribuito appositamente
progettato per poter utilizzare commodity hardware, dato che è altamente
fault-tolerant. HDFS è in grado di gestire un numero elevatissimo di file, anche di
6 Il meccanismo di fail-over implica il monitoraggio continuo del sistema, e consente di far fronte a malfunzionamenti che si verificano su un nodo, spostandone le attività su altri nodi.
7 Un database OLTP presenta un modello dati fortemente normalizzato per favorire non tanto le letture e l’analisi di grandi quantità di record, quanto le attività transazionali, quali inserimenti, cancellazioni e modifiche di porzioni di dati.
8 Al link http://goo.gl/kCnIht è possibile trovare vignette autoesplicative sul funzionamento di HDFS.
16
Capitolo 2 Hadoop
dimensioni ragguardevoli (dell’ordine dei gigabyte o terabyte), attraverso la
realizzazione di cluster che possono contenere migliaia di nodi.
L’utilizzo di hardware a buon mercato e la possibilità di configurare cluster con
moltissimi elementi comportano una certa probabilità di avere guasti frequenti che
possono rendere indisponibili uno o più nodi. Per questo la capacità di identificare
problemi e di effettuare operazioni di recovery automatiche è una delle caratteristiche
principali del file system di Hadoop.
Rispetto ai file system general purpose (come NFS 9 o CIFS 10), HDFS è costruito
attorno all’idea di un utilizzo dei dati in modalità write-once, read-many. Questo
ovviamente non significa che i dati non possano essere modificati, ma indica un
approccio differente all’utilizzo dei dati stessi: come è tipico del mondo Big Data, non
ci si aspetta di accedere in modo chirurgico ad un singolo file o ad una porzione di
questo, ma piuttosto è previsto che le analisi operino su una gran parte dei dati
memorizzati (se non tutti). HDFS, infatti, supporta solo un limitato insieme di
operazioni sui file, quali letture, scritture, eliminazioni ma non aggiornamenti e, per di
più, non fornisce un meccanismo di caching locale dei dati. L’overhead dovuto al
caching, su grandi insiemi di dati, diventa talmente rilevante che la rilettura dei dati
dalla sorgente è la soluzione migliore dal punto di vista della prestazioni.
HDFS, inoltre, è stato pensato per operazioni che attraversino una porzione
importante dei dati disponibili, con un focus sulla scalabilità di questo percorso di
accesso: profili di accesso ai dati sensibili alla latenza (qualche millisecondo) non sono
adatti ad essere ospitati in HDFS. Per cui, HDFS non è la soluzione migliore in caso di
applicazioni che richiedano un accesso ai dati in tempi molto ridotti, dato che il
throughput è ottimizzato a spese della latenza.
2.2.1 NameNode e DataNode HDFS presenta i file organizzati in una struttura gerarchica di directory, come qualsiasi
altro file system. Come mostrato nella Figura 2.2, i file sono organizzati come sequenze
di blocchi della stessa dimensione, memorizzati nel cluster Hadoop. Un file può essere
costituito da diversi blocchi, che sono memorizzati su differenti DataNode, ossia
applicazioni che girano sugli altri nodi del cluster, generalmente una per nodo, e
9 Network File System. Consente ai computer di utilizzare la rete per accedere agli hard disk remoti come fossero dischi locali.
10 Common Internet File System. Permette un accesso unificato e parallelo ai file remoti presenti su diversi sistemi operativi.
17
Capitolo 2 Hadoop
gestiscono fisicamente lo storage di ciascun nodo. In pratica eseguono le operazioni di
lettura e scrittura richieste dai client e gestiscono fisicamente la creazione,
cancellazione o replica dei blocchi di dati.
Figura 2.2 – Architettura di HDFS
Il DataNode memorizza ogni blocco di dati HDFS in un file separato sul proprio
filesystem locale, senza nessuna conoscenza circa i file stessi. Per migliorare il
throughput, il DataNode non crea tutti i file nella stessa directory, ma utilizza delle
euristiche per determinare il numero ottimale di file per directory, e crea sottodirectory
in modo appropriato.
Uno dei requisiti per un tale filesystem strutturato a blocchi è la capacità di
memorizzare, gestire ed accedere ai metadati11 del file in modo affidabile e veloce.
Diversamente dagli stessi file HDFS, il cui accesso è regolato dal paradigma write-once
e read-many, la struttura dei metadati può essere modificata da un numero
considerevole di client in modo concorrente. È fondamentale che tali informazioni
siano sempre sincronizzate. A tal proposito, HDFS si avvale di un’applicazione che gira
sul server principale, ossia il NameNode, che memorizza i metadati per il filesystem.
Questo significa che HDFS presenta un’architettura master/slave. Un singolo
NameNode gestisce il namespace, ovvero l’elenco dei nomi dei file e dei blocchi e
regola l’accesso ai file da parte dei client. L’esistenza di un singolo master nel cluster
semplifica notevolmente l’architettura del sistema.
Dato che la quantità di metadati per file è relativamente limitata, il NameNode
memorizza tutti questi dati nella memoria principale, permettendo in tal modo un
11 I metadati sono informazioni che descrivono caratteristiche e proprietà dei file e dei blocchi.
18
Capitolo 2 Hadoop
accesso random molto veloce. Poiché la memoria è progettata per essere compatta, un
NameNode con 4 GB di RAM è in grado di supportare un gran numero di file e
directory.
Inoltre, la memoria dei metadati è anche persistente. L’intero namespace del filesystem
è contenuto in un file chiamato FsImage memorizzato nel filesystem locale del
NameNode. Il NameNode utilizza anche un log dei cambiamenti avvenuti al
namespace a partire dall’ultima volta in cui il file FsImage è stato aggiornato. Tali
cambiamenti sono registrati in un file detto EditLog. Quando il NameNode parte,
unisce questi due file in modo da produrre uno snapshot12 dell’ultima situazione. A
questo punto il file FsImage è sovrascritto con lo snapshot.
L’approccio master/slave di HDFS semplifica l’architettura, ma comporta
inevitabilmente un’importante criticità: un problema al NameNode implicherebbe
l’indisponibilità dell’intero cluster. Per attenuare questo problema è stato
implementato il Secondary NameNode, detto anche CheckPoint Node.
Il Secondary NameNode non è un nodo di backup, non si fa carico delle funzioni del
NameNode. Si occupa, invece, di scaricare periodicamente il file FsImage e il log dei
cambiamenti dal NameNode, di unirli in un unico snapshot, che è poi restituito al
NameNode e potrebbe essere utilizzato in caso di problemi su quest’ultimo. La sua
copia però non è aggiornata. Per questo, recentemente è stato introdotto anche il
Backup Node, che mantiene una copia read-only del NameNode, sincronizzata in
tempo reale.
Inoltre, a partire dalle versioni di Hadoop marcate come 2.X.X, due diversi server sono
configurati come NameNode: uno di essi è attivo, mentre l’altro è in standby, pronto
a subentrare in caso di problemi al primo nodo.
2.2.2 Blocchi e replicazione Affinché la memoria necessaria al NameNode rimanga gestibile, la dimensione di
default di un blocco HDFS è 64 MB (o 128 MB), molto più grande rispetto alla
dimensione dei blocchi di un tipico filesystem, che comunemente si assesta su pochi
kilobyte. Tali dimensioni, inoltre, permettono che grandi quantità di dati siano
memorizzate sequenzialmente sul disco, minimizzando in tal modo il seek time per
consentire letture veloci in streaming.
12 Uno snapshot rappresenta un’istantanea dello stato di un oggetto o del sistema in un particolare momento.
19
Capitolo 2 Hadoop
Per assicurare l’alta disponibilità, HDFS replica ogni blocco su un certo numero di
nodi – tre, per default. Tali repliche sono utilizzate sia per garantire l’accesso a tutti i
dati anche in presenza di problemi ad uno o più nodi, sia per migliorare il recupero dei
dati. In HDFS, infatti, per le richieste di lettura dati, sono scelti i nodi più vicini al client
che effettua la lettura. In presenza di dati ridondanti è in tal modo più semplice
soddisfare questo requisito.
Una strategia di replica consiste nel copiare un blocco su altri DataNode, appartenenti
a rack13 diversi. In tal modo si minimizzano i rischi legati ai guasti (sia del rack, sia dei
nodi), si massimizzano le performance di lettura, poiché può essere utilizzata la banda
di rete di rack differenti, ma si appesantiscono le scritture, dato che occorre spostare
dati su diversi rack.
Tipicamente, la banda di rete, e conseguentemente le performance della rete, tra
macchine nello stesso rack è maggiore della banda di rete tra macchine in rack
differenti. Per questo motivo, è possibile migliorare le performance relative al
trasferimento dati utilizzando un numero di rack minore del numero di repliche. Per
esempio, quando il fattore di replicazione è tre, due repliche sono posizionate su un
rack, e la terza su un rack differente. In questo modo si ottiene un incremento delle
performance relative alla scritture delle diverse repliche.
Per minimizzare il consumo di banda globale e la latenza di lettura, HDFS tenta di
soddisfare una richiesta di lettura dalla replica più vicina, meglio se dallo stesso rack.
2.3 Hadoop MapReduce Il motore di elaborazione fondamentale di un sistema Hadoop è MapReduce. Fornisce
tutte le funzionalità necessarie per partizionare i Big Data in blocchi gestibili, elaborare
i dati in parallelo su cluster distribuiti, e quindi rendere i dati disponibili all’utente o
pronti per ulteriori elaborazioni. E fa tutto questo lavoro in un ambiente altamente
resiliente14 e tollerante ai guasti.
Con MapReduce e Hadoop, i calcoli sono eseguiti sul nodo in cui sono presenti i dati.
Inoltre, lavorando in tandem con HDFS, MapReduce assicura che la memorizzazione
e l’elaborazione dei dati coesistano sullo stesso nodo fisico nel cluster, limitando
13 I rack sono strutture simili ad armadi che ospitano apparati di rete, quali server, switch, router, ecc. 14 Il termine resilienza indica la capacità di un sistema di adattarsi alle condizioni d'uso e di resistere
all'usura in modo da garantire la disponibilità dei servizi erogati. Tali obiettivi si possono raggiungere mediante tecniche di ridondanza o distribuendo un'applicazione su più calcolatori in modo da assorbire i carichi elaborativi.
20
Capitolo 2 Hadoop
notevolmente i colli di bottiglia tradizionali, quali la larghezza di banda di rete, dovuti
a trasferimenti di grosse quantità di dati.
Per cui, MapReduce combina computazione parallela, distribuita e sequenziale,
mescolando semplicità, potenza e scalabilità in un unico cocktail.
Numerosi problemi pratici – come analisi dei log, ordinamento dei dati, analisi dei
grafi, calcoli matematici complessi, operazioni del mondo relazionale, creazione di
inverted index15, e tantissimi altri – sono stati risolti utilizzando MapReduce.
2.3.1 Java MapReduce La scrittura di un programma MapReduce comporta fondamentalmente la creazione
di una funzione map, una funzione reduce, e del codice addizionale per eseguire il job.
La funzione map è rappresentata dalla classe Mapper, che dichiara un metodo astratto
map(). La classe Mapper è di tipo generico, con quattro tipi formali di parametri che
specificano i tipi della chiave di input, del valore di input, della chiave di output e del
valore di output della funzione map.
I tipi dato delle chiavi e dei valori sono oggetti che implementano una specifica
interfaccia chiamata Writable, che consente ad Hadoop di scrivere (e leggere) i dati su
(o da) file e sono ottimizzati per la serializzazione16 di rete. Alcuni tipi di dato tra i più
comuni sono Text, IntWritable, LongWritable, FloatWritable, BooleanWritable,
ByteWritable, ArrayWritable e così via.
Il metodo map() fornisce un’istanza di Context, destinata a contenere l’output della
funzione map, ossia una collezione di chiavi e valori.
La funzione reduce è similmente definita utilizzando la classe Reducer. In modo del
tutto simile a quanto accade per la funzione map, anche questa classe ha un metodo,
chiamato reduce(), che svolge il lavoro. Anche in questo caso si hanno quattro
parametri formali che specificano input e output della funzione reduce. I tipi di input
della funzione reduce devono combaciare con i tipi di output della funzione map.
15 Gli inverted index sono strutture dati che memorizzano un mapping tra il contenuto – come parole o numeri – e la relativa locazione in un documento o un insieme di documenti. Sono utilizzati soprattutto per agevolare la ricerca full-text e sono componenti centrali di un tipico motore di ricerca.
16 La serializzazione è un processo per salvare un oggetto in un supporto di memorizzazione lineare (ad esempio, un file o un'area di memoria), o per trasmetterlo su una connessione di rete. La serializzazione può essere in forma binaria o può utilizzare codifiche testuali (ad esempio il formato XML) direttamente leggibili dagli esseri umani. Lo scopo della serializzazione è di trasmettere l'intero stato dell'oggetto in modo che esso possa essere successivamente ricreato nello stesso identico stato dal processo inverso, chiamato deserializzazione.
21
Capitolo 2 Hadoop
Alla funzione reduce giungono, quindi, le coppie chiave/valore già ordinate e separate
in partizioni, attraverso un processo chiamato shuffling, che assegna un certo
intervallo di chiavi a ciascun nodo reducer.
La classe Mapper e la classe Reducer non sono sufficienti alla definizione di un
programma MapReduce. Occorre infatti creare un’ulteriore classe, chiamata Driver,
che ha il compito di inizializzare il job, passare i parametri di input, definire dove
posizionare l’output, e altre configurazioni opzionali. Tale classe imposta il nome del
job, le classi che costituiscono i tipi di dati per le chiavi e i valori di output, la classe
Mapper, la classe Reducer, la classe Combiner (di cui si è parlato nel Paragrafo 1.2.2) e i
formati dell’input e dell’output. Inoltre, il driver imposta i percorsi di input e di output,
ricevuti come parametri, ed è possibile configurare il numero di mapper e reducer.
Il compito finale del driver, una volta impostate tutte le necessarie configurazione, è
quello di lanciare il job MapReduce. Ciò avviene attraverso una singola chiamata al
metodo submit() su un oggetto Job, oppure è possibile chiamare il metodo
waitForCompletion() che ritorna un valore booleano indicante il successo o il
fallimento del job.
Il formato di input determina la modalità di lettura dei dati e ciò che è passato al
mapper come chiave e valore. La tabella 2.2 riassume i formati di input.
Tabella 2.2 – Formati di input di MapReduce
Nome formato Descrizione Chiave Valore
TextInputFormat È il formato di default e determina la lettura di intere righe da un file.
La chiave è l’offset della riga. Il valore è l’intera riga.
KeyValueInputFormat Suddivide le righe lette in chiavi e valori.
La chiave è ciò che si trova a partire dall’inizio della riga fino al primo carattere Tab.
Il valore è il resto della riga.
SequenceFileInputFormat Formato binario di Hadoop. Definita dall’utente. Definito dall’utente.
Nella tabella 2.3 sono invece riassunti i formati di output.
Tabella 2.3 – Formati di output di MapReduce
Nome formato Descrizione
TextOutputFormat È il formato di default. Genera righe nel formato chiave valore, separati dal carattere Tab.
KeyValueOutputFormat Non genera alcun output. È utilizzato quando lo sviluppatore crea, direttamente nella funzione reduce, il proprio output.
SequenceFileOutputFormat Formato binario di Hadoop, utilizzato per passare dati tra job MapReduce.
22
Capitolo 2 Hadoop
2.3.2 Esecuzione di un job MapReduce Come detto nel Paragrafo precedente, è possibile eseguire un job MapReduce
attraverso una singola chiamata al metodo submit() su un oggetto Job. Dietro a questa
semplice chiamata si nasconde una grande quantità di elaborazione.
La figura 2.3 illustra i passi di esecuzione di un job MapReduce. Al livello più alto, ci
sono quattro entità indipendenti:
Il client, che sottopone il job MapReduce.
Il JobTracker, che coordina l’esecuzione del job.
Il TaskTracker, che esegue i task nei quali è stato splittato il job.
Il Filesystem distribuito (normalmente HDFS), che è usato per la condivisione dei
file del job tra le diverse entità.
Figura 2.3 – Come Hadoop esegue un job MapReduce
Il metodo submit() sul Job crea un’istanza interna JobSubmmitter e chiama
submitJobInternal() su esso (step 1 in Figura 2.3). Il JobSubmmitter interroga il
JobTracker per ottenere un nuovo job ID (step 2). Inoltre, copia le risorse necessarie
23
Capitolo 2 Hadoop
all’esecuzione del job sul filesystem del JobTracker, incluso il file JAR del job, il file di
configurazione e gli input split che calcola (step 3). Infine, avvisa il JobTracker che il
job è pronto per l’esecuzione (step 4).
Quando il JobTracker viene informato che il job è pronto, esso lo pone in una coda
interna da dove il job scheduler lo raccoglie e lo inizializza. L’inizializzazione implica
la creazione di un oggetto che rappresenta il job, in cui vengono incapsulati i relativi
task e informazioni per tenere traccia dello stato e dei progressi dei task (step 5).
Per creare una lista di task da eseguire, il job scheduler recupera dal filesystem
condiviso gli input split calcolati dal client (step 6). Successivamente crea un map task
per ogni split. Il numero dei reduce task da creare è invece determinato dalla proprietà
mapred.reduce.tasks definita nel Job.
I TaskTracker eseguono un semplice loop con cui periodicamente interrogano il
JobTracker. Queste periodiche interrogazioni permettono anche al JobTracker di
sapere che il TaskTracker è “vivo” e attivo. Un TaskTracker potrebbe inoltre informare
il JobTracker di essere pronto per l’esecuzione di un nuovo task e, in tal caso, il
JobTracker gli alloca il nuovo task, comunicandoglielo attraverso lo stesso flusso di
comunicazione (step 7).
Al momento della scelta del nuovo task da eseguire, se si tratta di un reduce task il
JobTracker sceglie semplicemente il prossimo nella lista. Se si tratta di un map task,
tuttavia, il JobTracker tiene conto della locazione di rete del TaskTracker, scegliendo
un task il cui input split sia quanto più vicino possibile al nodo TaskTracker.
Una volta che è stato assegnato il task al TaskTracker, il prossimo passo è quello di
eseguire tale task. Per prima cosa, il TaskTracker copia dal filesystem condiviso al
filesystem locale tutte le risorse necessarie all’esecuzione del job, come il JAR del job e
qualsiasi altro file essenziale (step 8). Successivamente, crea una directory di lavoro
locale per il task, e estrae il contenuto del JAR in tale directory. Dopodiché crea un
istanza di TaskRunner per eseguire il task.
TaskRunner lancia una nuova Java Virtual Machine (step 9) per eseguire ogni task (step
10), cosicché qualsiasi bug nelle funzioni map e reduce definite dall’utente non
influiscano sul TaskTracker (causando un blocco o un crash, per esempio).
Infine, quando il JobTracker riceve una notifica che l’ultimo task per il job è stato
completato, cambia lo stato per il job in “successful”. Di conseguenza, quando il Job
verifica lo stato, apprende che il job è stato completato con successo, e quindi stampa
un messaggio per informare l’utente.
24
Capitolo 2 Hadoop
2.3.3 Shuffle e Sort MapReduce assicura che l’input di ogni reducer sia ordinato per chiave. Il processo
con cui il sistema esegue l’ordinamento – e trasferisce gli output del map ai reducer
come input – è detto shuffle. La fase di shuffle costituisce sostanzialmente il cuore di
MapReduce.
L’output della funzione map non viene semplicemente scritto su disco. Il processo è
più complicato, e si avvale di scritture temporanee in memoria e preordinamenti per
ragioni di efficienza. La Figura 2.4 mostra ciò che avviene.
Figura 2.4 – Operazioni di Shuffle e Sort in MapReduce
Ogni map task ha un buffer di memoria circolare in cui scrive gli output. Quando il
buffer raggiunge un certo valore di soglia predefinito, un thread in background
comincerà a riversarne il contenuto sul disco.
Prima di scrivere sul disco, il thread divide i dati in un numero di partizioni
corrispondente al numero di reducer, a cui successivamente saranno inviate. In ogni
partizione, il thread in background esegue un ordinamento per chiave, e se è stata
impostata una funzione combiner, essa sarà eseguita sull’output ottenuto in seguito
all’ordinamento. L’esecuzione della funzione combiner permette di rendere l’output
più compatto, in modo tale che ci siano meno dati da scrivere sul disco locale e da
trasferire successivamente ai reducer.
Ogni qual volta il buffer di memoria raggiunge il valore di soglia, viene generato un
nuovo spill file, cosicché dopo che il map task ha scritto il suo ultimo record di output
potrebbero esserci diversi spill file, opportunamente partizionati e ordinati. Tali spill
file sono uniti – operazione di merge – per formare il file di output finale, che sarà
ordinato per partizioni, dove ogni partizione sarà ordinata per chiave.
25
Capitolo 2 Hadoop
Prodotto il file finale, ogni partizione sarà inviata ad un diverso reducer. Dato che ogni
map task potrebbe produrre gli output in tempi differenti, i reduce task iniziano a
copiare – fase copy – i loro output non appena sono completati. Ogni reduce task ha
un certo numero di thread addetti alla copia cosicché possano prelevare – fetch – gli
output dei mapper in parallelo.
Se gli output del map sono sufficientemente piccoli, saranno copiati in memoria,
altrimenti sul disco. Se il buffer di memoria raggiunge una certa grandezza di soglia,
oppure un numero preimpostato di map output, essi sono uniti e riversati sul disco.
Anche in questo caso, una funzione combiner, se specificata, potrebbe ridurre la
quantità di dati scritti su disco.
Quando tutti gli output del map sono stati copiati, avviene la fase sort, in cui vengono
uniti – merge – gli output del map, mantenendo il loro ordinamento. Successivamente,
durante la fase reduce, si ha un’ultima unione dei segmenti provenienti sia dal disco
che dalla memoria.
Durante la fase reduce, la funzione reduce è invocata per ogni chiave nell’output
ordinato. L’output di questa fase è scritto direttamente sul filesystem di output,
tipicamente HDFS. Nel caso di HDFS, dato che il nodo TaskTracker sta anche
eseguendo un DataNode, la prima replica sarà scritta sul disco locale.
2.4 Hadoop Streaming Hadoop Streaming è una utility grazie alla quale è possibile utilizzare programmi
eseguibili oppure script come mapper e reducer. Con Hadoop MapReduce è necessario
implementare delle classi Java – principalmente tre: mapper, reducer e driver – con
alcune caratteristiche sostanzialmente predefinite17. Con Hadoop Streaming, invece, è
sufficiente creare due programmi in grado di leggere dallo standard input e scrivere
sullo standard output. Il programma può essere scritto in un qualsiasi linguaggio di
programmazione ed è compito dell’utility la creazione del job MapReduce, la sua
esecuzione e il relativo monitoraggio.
Le righe lette dall’input sono suddivise tra chiave e valore con il seguente criterio: i
caratteri fino al primo Tab sono considerati chiave, mentre il resto della riga è il valore.
Se non esiste un carattere Tab, la riga è considerata tutta come chiave, e il valore sarà
nullo. Ovviamente è possibile specificare un altro separatore di campi attraverso alcuni
17 Per approfondimenti sulle caratteristiche di un programma MapReduce in Java si consiglia di visitare la documentazione al link seguente: http://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html
26
Capitolo 2 Hadoop
parametri dell’utility. Inoltre, è possibile specificare una lista arbitraria di campi sia per
le chiavi sia per i valori di output della funzione map e/o della funzione reduce.
2.5 YARN L’implementazione dell’infrastruttura di MapReduce, come discusso fin qui, è
piuttosto rigida, e il maggiore componente di tale implementazione è il JobTracker,
che è responsabile sia della gestione delle risorse, sia dello scheduling18 del job e del
relativo monitoraggio. Il complesso lavoro svolto dal JobTracker può portare ad alcuni
inconvenienti, come un maggiore consumo di memoria, un modello di threading
rigido, e vari problemi legati alla scalabilità, affidabilità e prestazioni.
Per questi motivi, con le versioni 0.23.X e 2.X.X è stata introdotta in Hadoop una
nuova componente, chiamata YARN, acronimo di Yet-Another-Resource-Negotiator.
YARN è un framework che consente di creare applicazioni o infrastrutture per il
calcolo distribuito di qualsiasi tipo. Il framework si prende carico della gestione delle
risorse, quali la memoria o la CPU, e monitora l’esecuzione delle applicazioni. YARN
è un sistema molto più generico rispetto a MapReduce delle versioni precedenti (MR1,
cioè MapReduce prima versione). MapReduce, nella sua nuova versione chiamata
MR2 (MapReduce seconda versione) è stato riscritto come applicazione YARN.
Nella nuova architettura le due funzioni del JobTracker sono state suddivise in
componenti separati:
Il Resource Manager (RM) globale che si occupa dell’assegnazione delle risorse
alle applicazioni.
L’Application Master (AM) che gestisce la singola applicazione (sia un singolo
job che una successione predefinita di job MapReduce), facendola partire,
monitorandola ed eventualmente gestendone la ripartenza in caso di errore.
La suddivisione delle funzionalità del JobTracker fornisce più flessibilità e migliori
performance.
La gestione delle risorse di YARN è basata su un modello di risorse molto generale per
le applicazioni. Le risorse (memoria, CPU, e così via) sono organizzate in container.
Come qualsiasi altra componente di Hadoop, la gestione delle risorse di YARN e il
18 Lo scheduling è la gestione dei processi, e nel caso specifico i job, in attesa di esecuzione ad opera di un componente, quale lo scheduler. Lo scheduler decide quando mandare in esecuzione un determinato processo, eventualmente fermandone temporaneamente un altro, ed eseguendo una serie di operazioni (note come cambio di contesto) per rendere possibile tale esecuzione.
27
Capitolo 2 Hadoop
relativo framework di esecuzione sono implementati secondo un’architettura
Master/Slave. Gli Slave sono costituiti dai Node Manager (NM), eseguiti su ogni nodo,
che fondamentalmente hanno il compito di gestire i processi. In pratica, essi gestiscono
i container su uno specifico nodo, monitorano l’esecuzione del nodo, e riferiscono al
Master – ossia il Resource Manager – l’attuale disponibilità delle risorse. In base alle
comunicazioni ricevute dagli Slave, il Master distribuisce le risorse tra le applicazioni
nel sistema.
L’esecuzione di una specifica applicazione è controllata dall’Application Master. Esso
è completamente distribuito – vi è un’istanza di un Application Master in esecuzione
su ogni nodo. L’Application Master è responsabile della suddivisione di
un’applicazione in più task e della negoziazione con il Resource Manager in relazione
alle risorse di esecuzione (container). Una volta che le risorse sono allocate,
l’Application Master interagisce con il/i Node Manager per disporre, eseguire e
monitorare un singolo task dell’applicazione.
Figura 2.5 - Architettura di YARN
Il flusso complessivo dell’applicazione è mostrato in Figura 3.5, dove sono
rappresentati i seguenti step:
1. Un programma client sottopone l’applicazione, includendo le specifiche necessarie
per lanciare l’Application Master specifico per l’applicazione. Inoltre, il client
fornisce le informazioni sufficienti al Resource Manager per lanciare il primo
28
Capitolo 2 Hadoop
container dell’applicazione – l’Application Master. Tali informazioni includono
file/jar locali che devono essere disponibili all’applicazione da lanciare in
esecuzione, i comandi che devono essere eseguiti, e così via.
2. Il Resource Manager alloca il container richiesto per un Application Master, e poi
lancia l’Application Master.
3. Durante la fase di startup, l’Application Master viene registrato dal Resource
Manager. Questo permette al programma client di interrogare il Resource Manager
riguardo i dettagli dell’Application Master, tra i quali il suo indirizzo. Ottenuti
questi dettagli, un client può comunicare direttamente con il proprio Application
Master.
4. Una volta che l’Application Master è in esecuzione, esso esamina le richieste
dell’applicazione e negozia i container di risorse appropriati per l’esecuzione
dell’applicazione.
5. Una volta che i container richiesti sono allocati, l’Application Master li lancia,
fornendo le relative specifiche al Node Manager.
6. Durante l’esecuzione, il codice dell’applicazione fornisce le informazioni necessarie
(progresso, stato, e così via) al proprio Application Master. Tali informazioni sono
anche disponibili al client, che comunica direttamente con l’Application Master.
7. Una volta che l’applicazione ha terminato, l’Application Master rilascia le risorse,
si deregistra, si arresta e rilascia il proprio container.
È importante notare che YARN non cambia l’attuale modello di programmazione
MapReduce (nonostante il nome MapReduce 2 potrebbe sottintendere diversamente)
o le API utilizzate dagli sviluppatori. Esso semplicemente fornisce un nuovo modello
di gestione delle risorse e la relativa implementazione utilizzata per eseguire job
MapReduce. Per cui, i programmi creati per MR1 sono perfettamente compatibili con
MR2, poiché non sono state modificate le interfacce.
2.6 ZooKeeper Apache ZooKeeper è uno strumento per la gestione del cluster che offre le seguenti
garanzie di funzionamento:
Consistenza sequenziale. Gli aggiornamenti inviati da un client sono applicati
nell’ordine in cui sono mandati.
29
Capitolo 2 Hadoop
Atomicità. Gli aggiornamenti vanno a buon fine interamente oppure non sono
applicati del tutto.
Immagine singola del sistema. Un client ottiene sempre la stessa vista del servizio
indipendentemente dal server a cui si connette.
Affidabilità. Una volta che un aggiornamento è stato applicato con successo, esso
rimane tale finché un altro aggiornamento non lo sovrascrive.
Tempestività. Ai client è garantita una vista aggiornata del sistema entro un lasso
di tempo predefinito.
ZooKeeper fornisce un’infrastruttura centralizzata e una serie di servizi che consentono
la sincronizzazione di “oggetti” comuni nel cluster. Tali oggetti comuni sono, per
esempio, le configurazioni, che devono essere presenti su tutti i nodi e che, ovviamente,
devono rimanere necessariamente sincronizzate.
2.7 Pig Apache Pig è un motore di analisi di grandi dataset, corredato da un linguaggio per la
gestione e l’elaborazione dei flussi di dati, chiamato Pig Latin19. L’infrastruttura di Pig
è costituita da un compilatore che, a partire da istruzioni Pig Latin, produce una serie
di programmi MapReduce.
Rispetto all’utilizzo diretto di MapReduce, Pig offre diversi vantaggi. In primo luogo,
la creazione di un programma Pig è più semplice rispetto all’implementazione di classi
MapReduce, sia per il linguaggio, sia per la modalità di programmazione: i flussi di
dati complessi diventano essenzialmente sequenze di semplici operazioni di
movimentazione e trasformazione dei dati, rendendo Pig piuttosto simile ad uno
strumento ETL20. Un’altra importante caratteristica di Pig consiste nella capacità del
sistema di ottimizzare l’esecuzione delle sequenze di operazioni. L’utente che scrive
procedure Pig non deve preoccuparsi delle performance, ma può concentrarsi
sull’attività di gestione dei dati.
Pig è una piattaforma estensibile: chiunque, infatti, può arricchirlo scrivendo funzioni
in linguaggio Java, utilizzando le librerie di Pig e creando dei file JAR da importare
negli script.
19 Per approfondimenti si veda: http://pig.apache.org/docs/r0.12.1/basic.html. La pagina include anche la descrizione, con esempi, delle funzioni e degli statement.
20 Un sistema ETL (acronimo di Extract, Transform, Load) si occupa dell’estrazione, trasformazione e caricamento di dati in un sistema di sintesi (come il Data Warehouse).
30
Capitolo 2 Hadoop
2.8 Hive Hive è uno strumento di data warehousing21 in grado di manipolare grandi quantità di
dati presenti in sistemi distribuiti. Apache Hive costituisce di fatto lo standard per
query SQL su petabyte di dati in Hadoop.
Le funzionalità di Hive possono essere riassunte nei punti seguenti:
ETL (Extract, Transform, Load): in Hive sono presenti strumenti per il
caricamento e la manipolazione dei dati.
Con Hive è possibile dare ai dati una struttura (simile alle tabelle dei database
relazionali).
Accesso ai dati presenti in HDFS o in altri sistemi quali HBase.
Utilizzo del framework MapReduce per l’esecuzione delle query.
Indicizzazione, per ottenere migliori performance di esecuzione.
Estensibilità, attraverso funzioni create dall’utente.
Linguaggio simile a SQL, chiamato HiveQL (acronimo di Hive Query Language).
Nonostante il linguaggio presenti una sintassi simile a SQL, Hive è un sistema per la
creazione di job che lavorano su grandi moli di dati e non è uno strumento che può
rimpiazzare SQL e i database relazionali nell’esecuzione di attività transazionali.
Nella tabella 2.4 sono mostrate alcune differenze tra Hive e un RDBMS.
Tabella 2.4 – Confronto tra RDBMS e Hive
RDBMS Hive
Linguaggio Aderisce almeno allo standard SQL-92. Sottoinsieme di SQL-92 con comandi specifici di Hive.
Modifiche ai dati INSERT / UPDATE / DELETE. (Multitable) INSERT (OVERWRITE). Non esiste la possibilità di eseguire update.
Indici Pieno supporto. Supporto limitato.
Supporto alle transazioni Presente in tutte le implementazioni. Assente.
Velocità di esecuzione Anche pochi millisecondi. Secondi o minuti.
Quantità di dati GB e TB. TB o PB.
Programmabilità Alcuni RDBMS consentono la scrittura di procedure o funzioni in linguaggi come Java, C# e C++.
User Defined Function (UDF) e User Defined Aggregate Function (UDAF).
Esecuzione di job MapReduce.
21 Il Data Warehouse è sostanzialmente una collezione di dati subject oriented, non volatile, integrata, tempo variante e opportunamente strutturata per effettuare query e analisi. Il linea generale il Data Warehousing costituisce, quindi, un sistema di supporto del processo decisionale, attraverso i dati opportunamente archiviati e gestiti, relativi alle diverse aree delle aziende e organizzazioni.
31
Capitolo 2 Hadoop
La differenza principale tra un DBMS tradizione e Hive è data dal fatto che in un DBMS
tradizionale lo schema di una tabella è fissato a priori, e se i dati non sono conformi a
tale schema sono rifiutati. Questa caratteristica è definita come schema on write, dato
che i dati sono verificati in relazione allo schema quando vengono caricati nel database.
Hive, invece, non verifica i dati al momento del caricamento, ma solo quando vengono
eseguite le query su di essi. Questo è detto schema on read.
La Figura 2.6 illustra l’architettura di Hive, evidenziandone il funzionamento.
Figura 2.6 – Architettura di Hive
La figura mostra come i punti di accesso ad Hive siano tre: l’interfaccia Web, la shell
dei comandi e il server. Le applicazioni esterne che utilizzano client Thrift22, driver
ODBC23 o JDBC24, comunicano attraverso il server Hive, mentre l’accesso diretto da
22 Apache Thrift è un linguaggio di definizione di interfaccia e un protocollo di comunicazione binario, utilizzato per definire e creare servizi (ossia, insiemi di funzionalità correlate del software che possono essere riutilizzati per diversi scopi) per diversi linguaggi di programmazione. È utilizzato come framework per chiamate di procedure remote – RPC (si veda nota 30 per approfondimenti).
23 Open DataBase Connectivity (ODBC) è una API standard per la connessione dal client al DBMS. È sostanzialmente un’interfaccia che permette ai programmi di inviare ai database stringhe SQL senza che ci sia bisogno di conoscerne le API proprietarie. Genera automaticamente richieste che il sistema di database utilizzato sia in grado di comprendere.
24 Java DataBase Connectivity (JDBC) è un connettore per database che consente l’accesso e la gestione della persistenza dei dati sulle basi di dati da qualsiasi programma scritto con il linguaggio Java. È costituito da un API che serve ai client per connettersi ad un database. Fornisce metodi per interrogare e modificare i dati. È orientato ai database relazioni ed è Onject Oriented.
32
Capitolo 2 Hadoop
parte dell’utente avviene con la shell, oppure con l’interfaccia web. Le istruzioni sono
poi compilate, ottimizzate e quindi eseguite sotto forma di una serie di job MapReduce.
Di fatto l’output del compilatore è proprio questo: un insieme, o meglio, un grafo
(direzionato o aciclico) di job MapReduce.
Il compilatore utilizza le informazioni contenute in una componente di Hive chiamata
metastore. Si tratta di un repository in cui Hive salva i metadati di ciascuna tabella.
Fisicamente si tratta di un motore database realizzato in Java, chiamato Derby. Derby
ha il limite di non poter funzionare in un ambiente multiutente. Per questo, è possibile
configurare Hive affinché il metastore utilizzi un altro motore di database, come per
esempio MySQL.
2.8.1 Il modello dati Il modello dati di Hive prevede una gerarchia di meta-oggetti simile a quella di un
RDBMS. Partendo dall’oggetto di più alto livello, abbiamo i seguenti livelli.
1. Database. Il database funge da namespace e al suo interno gli oggetti devono avere
nomi univoci.
2. Tabella. Le tabelle sono contenitori di dati omogenei, cioè di dati che hanno lo
stesso schema. Ciascuna riga all’interno della tabella ha quindi lo stesso numero di
colonne.
3. Partizione. Ogni tabella può avere una o più chiavi di partizionamento che
determinano come i dati sono salvati. Per ciascun valore della chiave di
partizionamento è creata una partizione. Le chiave di partizionamento non sono
parte dei dati della tabella, ma sono definite e create al momento del caricamento.
Le partizioni consentono di velocizzare le query, poiché è possibile utilizzare le
chiavi di partizionamento nelle istruzioni SELECT e, in questo modo, ottenere
l’accesso soltanto alle partizioni specificate.
4. Bucket (o cluster). I dati in ciascuna partizione possono essere ulteriormente
suddivisi in unità più piccole – bucket – utilizzando una funzione di hashing su una
colonna della tabella.
Le colonne delle tabelle sono definite attraverso il nome e il tipo di dati. I tipi di dati di
base, detti primitivi, possono essere utilizzati per definire nuovi tipi di dati chiamati
complessi25.
25 Al link https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types è presente la documentazione ufficiale riguardante i tipi di dato disponibili in Hive.
33
Capitolo 2 Hadoop
2.8.2 Creazione di tabelle È possibile creare una tabella Hive attraverso il comando CREATE TABLE. Tra le tante
opzioni disponibili 26 , la più interessante è la possibilità di creare tabelle interne
(definite anche managed) o esterne.
Creando una tabella interna, Hive controlla il ciclo di vita dei dati, memorizzandoli in
una directory di default. Nel caso si elimini una tale tabella, Hive eliminerà anche i dati
in essa contenuti. Tuttavia, le tabelle interne sono meno convenienti per la
condivisione con altri strumenti. Per esempio, se i dati vengono creati e utilizzati
principalmente da Pig o altri strumenti, e si desidera eseguire alcune query su di essi,
senza che Hive ne diventi il “proprietario” assumendone la titolarità, è possibile
definire una tabella esterna che fa riferimento a tali dati.
Le tabelle esterne, ossia al di fuori del percorso di default, si possono creare attraverso
la parola chiave EXTERNAL. Il percorso è specificato attraverso la parola chiave
LOCATION. In tal modo è possibile specificare un percorso che punti a un file o un
insieme di file già esistenti. Hive, in tal caso, non diventa il proprietario dei dati, per
cui eliminando la tabella, saranno eliminati solo i relativi metadati, ma non i dati.
2.8.3 SerDe Hive è un tool eccezionale per eseguire query in stile SQL su dati che spesso non sono
appropriati per un database relazionale. Per esempio, dati semistrutturati e non
strutturati possono essere elegantemente interrogati attraverso Hive, principalmente
per mezzo di due caratteristiche centrali. La prima è data dal fatto che Hive supporta
tipi di dati complessi, come struct, array e union, in aggiunta ai diversi tipi di dati
comuni nella maggior parte dei database relazionali. La seconda è l’interfaccia SerDe.
L’interfaccia SerDe (Serializer/Deserializer) permette di informare Hive su come un
record dovrebbe essere elaborato. La SerDe è una combinazione di un serializzatore e
un deserializzatore. L’interfaccia Deserializer prende una stringa o una
rappresentazione binaria di un record, e lo traduce in un oggetto Java che Hive possa
manipolare. L’interfaccia Serializer, invece, prende un oggetto Java che Hive ha già
elaborato e lo traduce in qualcosa che Hive possa scrivere su HDFS o qualsiasi altro
supporto di sistema. Generalmente, i deserializzatori sono utilizzati nel momento in
cui sono eseguite query come SELECT, mentre i serializzatori sono utilizzati al momento
della scrittura dei dati, per esempio attraverso uno statement INSERT-SELECT.
26 Si veda https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL.
34
Capitolo 2 Hadoop
L’interfaccia SerDe è estremamente potente per quanto riguarda la gestione dei dati
con uno schema complesso. Con l’utilizzo di una tale interfaccia, qualsiasi insieme di
dati può essere reso interrogabile attraverso Hive.
2.8.4 Funzioni definite dall’utente Le funzioni definite dall’utente (User-Defined Functions) sono una caratteristica molto
importante di Hive: permettono all’utente di estendere il linguaggio HiveQL.
Hive permette agevolmente di inserire il proprio codice, e quindi funzioni che possono
svolgere calcoli, aggregazioni, generare un risultato tabellare, o qualsiasi altro tipo di
trasformazione e/o computazione che non sono implicitamente implementate in Hive,
e richiamarlo successivamente da una query Hive.
Ci sono tre tipi di UDF in Hive: UDF (regolari), UDAF (User-Defined Aggregate
Functions) e UDTF (User-Defined Table-Generating Functions). Si differenziano dal
numero di righe che accettano come input e che producono come output:
Una UDF opera su una singola riga e produce una singola riga come output.
Molte funzioni, come funzioni matematiche e funzioni che manipolano stringhe,
sono di questo tipo.
Una UDAF lavora su multiple righe di input e crea una singola riga di output.
Funzioni di aggregazioni includono queste funzioni, come COUNT e MAX.
Una UDTF opera su una singola riga e produce multiple righe – una tabella –
come output.
Tali funzioni possono essere create implementando classi che derivino da specifiche
classi base e che implementino specifiche interfacce. Sono scritte in Java, lo stesso
linguaggio in cui lo stesso Hive è scritto, ma è possibile anche scriverle in altri
linguaggi27.
La scrittura di una UDF28 deve sostanzialmente soddisfare due proprietà:
1. Una UDF deve essere una sottoclasse di org.apache.hadoop.hive.ql.exec.UDF.
2. Una UDF deve implementare almeno un metodo evaluate().
Il metodo evaluate() non è definito da un’interfaccia dato che accetta un numero
indefinito di argomenti di tipo arbitrario, e ritorna un valore anch’esso di tipo
27 È possibile tramite la clausola SELECT TRANSFORM. In tal modo si possono richiamare programmi o script esterni secondo la logica di Hadoop Streaming.
28 La scrittura delle UDAF e UDTF non sarà trattata, dato che non sono state utilizzate nel sistema sviluppato, presentato nel Capitolo 4.
35
Capitolo 2 Hadoop
arbitrario. Hive esamina la UDF per trovare il metodo evaluate() appropriato, che
corrisponde alla funzione Hive che è stata invocata.
Per utilizzare la UDF in Hive, è necessario compattare la classe Java compilata in un
file JAR e registrare il file in Hive, tramite lo statement:
ADD JAR /path/to/my_jar.jar
Successivamente è necessario creare un alias per il nome della classe Java:
CREATE TEMPORARY FUNCTION function_name AS class_name
Questo statement permette di definire una funzione che è implementata dalla
class_name. La parola chiave TEMPORARY evidenzia il fatto che una tale funzione UDF
è definita solo per la durata della sessione Hive (non è persistente nel metastore). In
pratica, questo implica che bisogna aggiungere il file JAR, e definire la funzione
all’inizio di ogni script o sessione. Questo era necessario fino alla versione 0.12 di Hive.
Dalla versione 0.13 di Hive è possibile registrare le funzioni UDF come permanenti sia
nel database corrente che in uno specifico database. Esse quindi diventano persistenti
nel metastore, in modo tale che possano essere referenziate in una query senza la
necessità di creare una funzione temporanea per ogni sessione. Lo statement necessario
per la creazione di una funzione permanente è il seguente:
CREATE FUNCTION [db_name.]function_name AS class_name [USING JAR|FILE|ARCHIVE 'file_uri' [, JAR|FILE|ARCHIVE 'file_uri'] ]
Questo statement permette di definire una funzione che è implementata dalla
class_name. Eventuali Jar, File o Archivi che devono essere aggiunti all’ambiente
possono essere specificati utilizzando la clausola USING; quando la funzione è
referenziata per la prima volta da una sessione Hive, queste risorse saranno aggiunte
all’ambiente come se fosse stato utilizzato lo statement ADD JAR/FILE.
2.9 HBase Apache HBase è un database column-oriented distribuito, la cui realizzazione ha preso
spunto da BigTable29. Dispone di un meccanismo di gestione della granularità delle
29 BigTable è il database utilizzato da Google. In esso i valori sono identificati da un indirizzo composto da chiave della riga, chiave della colonna e timestamp. Per ciascuna tabella, le colonne sono organizzate in column family, che costituiscono l’unità di base per la gestione degli accessi e per la compressione dei dati. Per ulteriori approfondimenti si consiglia il paper ufficiale al link: http://research.google.com/archive/bigtable.html.
36
Capitolo 2 Hadoop
transazioni molto elaborato e pensato per gestire tabelle sparse, ossia dove è molto
frequente che una cella non contenga alcun valore.
Il modello dati di HBase comprende il concetto di tabella e di column family, proprio
come BigTable. Una tabella può contenere una o più column family, che a loro volta
possono contenere una o più colonne. In una tabella ciascuna riga è contrassegnata da
un rowId, mentre ciascun valore è contenuto in una cella, identificata dalle coordinate
(row, column, version), dove version è un timestamp. Se nulla è specificato al
momento di estrarre i valori dalla tabella, è recuperato il valore più recente di ciascuna
colonna. I nomi delle colonne sono composti secondo la sintassi:
nome_column_family:nome_colonna
Ad esempio, anagrafica_clienti:nome e anagrafica_clienti:cognome.
Inoltre, le righe possono contenere valori per tutte le colonne o soltanto per alcune.
Sul modello dati sono possibili le seguenti operazioni:
Get: estrazione dei valori di una singola riga.
Scan: estrazione dei valori di più righe.
Put: inserimento di una nuova riga (o aggiornamento di una riga esistente).
Delete: cancellazione di una riga.
Quanto all’architettura, HBase è un sistema distribuito, ed è basato su HDFS. In
corrispondenza del NameNode e dei DataNode di HDFS sono presenti le istanze
rispettivamente del servizio Master e dei RegionServer. Il Master si occupa del
monitoraggio di tutti i RegionServer e costituisce il punto di passaggio di tutti i
cambiamenti ai metadati. In un ambiente multi-master, esistono più istanze che
competono per il ruolo di Master. Se il Master diventa indisponibile, una delle restanti
istanze ne assume le funzionalità.
I RegionServer gestiscono le cosiddette Region, cioè gli elementi di base per la
disponibilità e la distribuzione delle tabelle. Il punto più alto della gerarchia degli
elementi di organizzazione dei dati, è rappresentato dalle Table. Ogni Table è suddivisa
orizzontalmente in Region, ciascuna delle quali è assegnata a un RegionServer. In ogni
Region si hanno uno o più Store, ognuno dei quali corrisponde ad una column family
per una certa Region e per una certa Table, e il Log in cui si registrano tutti i
cambiamenti ai dati. Lo Store contiene un MemStore, che conserva in memoria le
modifiche allo Store, e zero o più StoreFile, che contengono i dati. Gli StoreFile sono
sostanzialmente wrapper che contengono i file (HFile) in cui sono archiviati i dati. I
37
Capitolo 2 Hadoop
file sono costituiti da blocchi, la cui dimensione è definita al momento della creazione
di ciascuna column family. La compressione dei dati avviene a livello di blocco.
L’installazione distribuita di HBase dipende da un cluster ZooKeeper che, come visto
nel Paragrafo 2.6, è un servizio centralizzato per il mantenimento delle informazioni di
configurazione e per la sincronizzazione dei servizi distribuiti. L’architettura di HBase,
con tutte le sue componenti è rappresentata nella Figura 2.7.
Figura 2.7 – Struttura di HBase
HBase è utilizzato in numerose realtà in cui la mole di dati raggiunge svariate centinaia
di milioni di record per tabella. Un caso di utilizzo è rappresentato dal sistema di
messaggistica di Facebook, che utilizza HBase per il salvataggio di oltre 130 miliardi di
messaggi al mese. HBase è particolarmente efficiente sia nel gestire un alto tasso di
modifiche anche su basi di dati enormi, sia nel recupero di dati per chiave, sia nella
scansione di un intervallo di chiavi e nella contestuale applicazione di filtri.
2.10 Flume Apache Flume è un sistema per la movimentazione di grandi quantità di dati da fonti
di diverso tipo verso HDFS (o altre destinazioni). Flume presenta un’architettura
semplice e flessibile basata sullo streaming di flussi di dati. Un utilizzo piuttosto
frequente consiste nel recuperare i dati di log da più web server e salvarli su HDFS,
dopo averli aggregati. Le fonti dati da cui Flume può attingere sono molteplici:
File di testo letti una sola volta, generando un evento per ogni riga.
38
Capitolo 2 Hadoop
Comando tail: in Unix (ma esiste anche un’implementazione per Windows) il
comando tail legge un file e genera un output per ogni riga aggiunta al file stesso.
Porte TCP o UDP.
Fonti dati personalizzate, create ad hoc attraverso le classi Java fornite nella
libreria di Flume.
Fonte Avro (Avro è un sistema di Remote Procedure Call 30 e serializzazione
sviluppato all’interno del progetto Hadoop).
Anche le destinazioni sono molteplici:
HDFS
HBase
Logger (log di log4j).
Destinazione Avro
Destinazione personalizzata
Il sistema ha un meccanismo di fail-over e recovery31 che lo rende altamente affidabile.
Nella Figura 2.8 è mostrata l’architettura di Flume.
Figura 2.8 – Architettura di Flume
30 Il Remote Procedure Call (RPC) è un protocollo di comunicazione tra processi che consente a un programma di eseguire una procedura in una locazione remota, ovvero all’interno di un altro processo, magari situato su un altro computer.
31 Il sistema di recovery consente di evitare o minimizzare la perdita di dati in seguito ad un evento di malfunzionamento del sistema.
39
Capitolo 2 Hadoop
L’architettura di Flume è basata sul concetto di agent, cioè una componente software
che al suo interno compie le seguenti operazioni:
La raccolta dei dati provenienti dall’esterno attraverso una
Source (sottocomponente dell’agent stesso).
Il passaggio dei dati attraverso un canale (Channel). I dati rimangono nel canale
finché non vengono “consumati” dalla terza sottocomponente (ossia il Sink).
La lettura dei dati del canale e l’istradamento verso la destinazione, operati dalla
sottocomponente chiamata Sink.
La configurazione di ogni singolo agent avviene tramite un file di testo, nel quale sono
espressi i parametri del source, del channel e del sink.
Esistono diverse possibilità di utilizzo di Flume, che dipendono dalla complessità dello
scenario da gestire:
Un unico agent che collega fonte e destinazione (come nel caso della Figura 2.8).
Più agent che raccolgono dati da fonti diverse e, come destinazione hanno un
altro agent che riceve i dati e li scrive sulla destinazione finale (consolidamento).
Più agent che leggono dalla stessa fonte e scrivono in destinazioni
diverse (multiplexing).
2.11 Oozie Apache Oozie è un motore di workflow (sequenza di operazioni concatenate),
specializzato nell’esecuzione di job MapReduce, Pig, Hive o operazioni HDFS. In
Oozie il workflow è un insieme di azioni organizzate in un grafo di tipo Directed
Acyclic Graph32, nel quale nessuna azione può essere eseguita se quella precedente non
è ancora terminata. I workflow di Oozie eseguono job di Hadoop in remoto. Una volta
che il job è completato il sistema remoto notifica a Oozie il completamento dell’azione,
in modo che il workflow possa proseguire con il passo successivo.
Oozie utilizza un linguaggio chiamato Process Definition Language (hPDL), un XML
che permette di definire nodi di controllo e nodi di azione: i primi definiscono l’inizio
(nodo start) e la fine di un workflow (nodi end e fail), oltre a fornire meccanismi di
32 In matematica un grafo è un insieme di nodi connessi attraverso collegamenti. In un grafo diretto (detto anche orientato, in inglese directed graph) i collegamenti presentano un orientamento, cioè un verso in cui ci si muove da un nodo all’altro. In un grafo aciclico, poi, da qualsiasi nodo si parta, non è possibile, seguendo i collegamenti orientati, ritornare al punto di partenza. Per ulteriori informazioni si veda: http://en.wikipedia.org/wiki/Directed_acyclic_graph.
40
Capitolo 2 Hadoop
controllo dell’esecuzione, come per esempio istruzioni decisionali. I nodi di azione
contengono le chiamate ai job veri e propri. È possibile passare parametri al workflow,
attraverso variabili identificate in hPDL con la sintassi $(nome_variabile).
Un’altra importante funzionalità di Oozie è rappresentata dalla possibilità di definire
ed eseguire workflow periodici e interdipendenti, attraverso l’implementazione di un
Coordinator33. In tal modo è possibile eseguire job ad intervalli regolari, oppure a
seconda della disponibilità dei dati, o magari in seguito ad un evento esterno. Ciò
richiede di esprimere la condizione (o le condizioni) che innesca (innescano) un
workflow attraverso un predicato, e solo dopo che tale predicato sarà soddisfatto verrà
eseguito il workflow.
Con questa funzionalità è inoltre possibile connettere workflow dipendenti, eseguiti
regolarmente, ma in tempi diversi. Gli output di una sequenza di workflow, eseguiti
ad intervalli periodici, possono diventare gli input di un altro workflow successivo,
eseguito ad intervalli temporali più ampi.
33 Si veda: https://oozie.apache.org/docs/3.1.3-incubating/CoordinatorFunctionalSpec.html.
41
Capitolo 3 Sentiment Analysis
Sentiment Analysis
“Ogni nostra cognizione, principia dai sentimenti.”
– Leonardo da Vinci
e opinioni sono al centro di quasi tutte le attività umane e influenzano i nostri
comportamenti. Le nostri convinzioni e percezioni della realtà, e le scelte che
facciamo, sono in gran parte condizionate da come gli altri vedono e valutano il
mondo. Per questo motivo, quando abbiamo bisogno di prendere una decisione spesso
cerchiamo e valutiamo le opinioni altrui. Questo non è vero solo per il singolo
individuo, ma è altrettanto vero per le organizzazioni.
Le opinioni e i relativi concetti quali sentimenti, valutazioni, espressioni ed emozioni
sono le materie di studio della Sentiment Analysis – anche detta Opinion Mining.
L’origine e la rapida crescita di questa disciplina vanno di pari passo con lo sviluppo
dei Social Media sul Web, ad esempio Blog, Microblog, Forum di discussioni, Siti di
recensioni e Social Network, perché per la prima volta nella storia dell’umanità siamo
in possesso di un’enorme mole di dati, in formato digitale, intrisa di sentimenti.
Dall’inizio del nuovo millennio, con l’avvento del Web 2.0, la Sentiment Analysis si è
sviluppata a tal punto da diventare una delle aree di ricerca più attive nello studio del
linguaggio naturale, diffondendosi anche in altri campi, oltre l’informatica, in
conseguenza dell’importanza sempre più rilevante che ricopre nell’attuale società.
3.1 Il Web ai tempi del Social Media La Sentiment Analysis è il campo di studio che analizza le opinioni, i sentimenti, le
valutazioni, le considerazioni, il pensiero e le emozioni delle persone nei riguardi di
entità come prodotti, servizi, organizzazioni, individui, problemi, eventi, argomenti e
le loro caratteristiche. La Sentiment Analysis, in sostanza, si focalizza sulle opinioni
che includono, implicitamente o esplicitamente, sentimenti positivi o negativi.
CAPITOLO 3
L
42
Capitolo 3 Sentiment Analysis
Decine di milioni di utenti utilizzano strumenti come Blog, Forum e Social Network
per esprimere le proprie opinioni e le proprie sensazioni, producendo imponenti
volumi di dati testuali non strutturati. Questi dati rappresentano una fonte
d’inestimabile valore per chiunque voglia conoscere la reputazione online di un brand
di qualunque natura, dai prodotti ai servizi, dalle città alle persone.
Saper interpretare la qualità e la contestualità di questi dati è fondamentale per
raccogliere informazioni sulle tendenze di categorie di utenti: si possono in questo
modo pianificare determinate strategie di marketing, migliorare le funzionalità di un
prodotto o un servizio in base alle esigenze dei consumatori, monitorare, in tempo
reale, il gradimento di uno spettacolo televisivo, analizzare il gradimento di una certa
idea politica, esaminare il pensiero degli elettori durante una campagna elettorale.
Tra la miriade d’informazioni disponibili, dunque, diventa utile il “sentimento”, o
opinione, che le persone esprimono nei confronti di un soggetto. Si tratta spesso di
opinioni personali o di esperienze in merito ad un particolare soggetto di discussione,
che nel loro complesso, oltre a rappresentare un ampio campione statistico di giudizi
sul soggetto, sono anche le stesse informazioni che andranno ad influenzare gli altri
naviganti, secondo le dinamiche tipiche del passaparola. Per questi motivi molte
aziende ed enti stanno decidendo sempre più spesso di affidarsi ad applicazioni di
Sentiment Analysis per monitorare la reputazione online di cui gode il loro brand, in
alternativa ai tradizionali sondaggi e interviste dispendiosi in termini di tempi e costi.
Inoltre, tramite tecniche di Sentiment Analysis abbiamo molta più autenticità
informativa: le persone non sono obbligate ad esprimere opinioni, al contrario, queste
fluiscono liberamente senza alcuna costrizione.
3.1.1 Applicazioni della sentiment analysis I dati ricavati dai social media consentono alle aziende di creare modelli che analizzano
i comportamenti d’acquisto e le opinioni nei confronti dei prodotti, dell’azienda stessa
o dei propri competitor. Tali analisi sono finalizzate sia ad aumentare la fidelizzazione
del cliente sia a mettere in atto politiche di cross-selling sui clienti già acquisiti, ossia
proponendo loro prodotti o servizi in qualche modo collegati con la scelta d'acquisto
iniziale, ma anche a potenziare le attività di acquisizione di nuova clientela, attraverso
azioni di marketing quali campagne e pubblicità mirate, offerte speciali e così via.
Blog, tweet, discussioni e commenti sui social media permettono alle persone di
esprimere le proprie idee e percezioni sui prodotti o servizi, fornendo così un
importante feedback alle aziende.
43
Capitolo 3 Sentiment Analysis
Non solo le imprese, ma anche i governi, le agenzie governative e i servizi di pubblica
sicurezza possono trarre valore dalla Sentiment Analysis. Il monitoraggio automatico
di contenuti, in qualsiasi lingua e formato, su siti web e social network potrebbe essere
utile per individuare possibili minacce alla sicurezza, così come le forze di polizia
potrebbero trarne informazioni utili per la lotta contro la criminalità.
Il settore pubblico attraverso il sentiment degli individui potrebbe monitorare le
performance dei ministeri, dipartimenti ed enti, per identificare inefficienze o sprechi.
3.1.2 Un case study: La campagna presidenziale di Obama Nella campagna elettorale di Barack Obama del 2008 e, più sistematicamente, in quella
del 20121 è stato fatto abbondantemente uso delle tecniche di Sentiment Analysis per
monitorare le reazioni dei votanti per poi reagire, quasi in tempo reale, a cambiamenti
del sentiment. Avere costantemente a disposizione il polso e il “cuore” dei gruppi
sociali attivi sul Web ha permesso ad Obama di modulare il messaggio elettorale, in
un continuo e costante dialogo con il proprio elettorato. Lo staff di Obama ha puntato
sulla creazione di una singola enorme base di dati che raccogliesse dati attraverso
sondaggi, incrociando informazioni provenienti dai volontari che si occupavano di
raccolta fondi e di attività di campo, dai social network e dalle anagrafiche dei
sostenitori Democratici. Una volta raccolti, i dati sono stati utilizzati non soltanto per
trovare in modo mirato potenziali votanti e, naturalmente, convincerli a concedere il
proprio voto, ma anche per effettuare simulazioni e analisi predittive per cercare di
capire quali tecniche fossero le più adatte per un certo target di elettori. Simulazioni di
numerosi scenari erano eseguite ogni notte in modo da avere, al mattino, le probabilità
di vittoria in ciascuno Stato e, in base a esse, allocare sforzi e risorse.
3.2 Complessità della Sentiment Analysis Valutare il sentiment non è semplice, nemmeno per un essere umano. Sono molte le
problematiche da affrontare, in quanto nell’esprimere opinioni e sentiment
generalmente si ricorre a una estrema varietà di sofisticati mezzi espressivi, tra cui la
metafora, l’ironia, il sarcasmo, l’allusione, ecc., dove l’interpretazione del significato è
strettamente soggettiva a tal punto che, anche due esseri umani potrebbero trovarsi in
disaccordo sul reale sentiment che essa esprime.
1 Si veda: http://www.journalism.org/2012/08/15/how-presidential-candidates-use-web-and-social-media/, e anche https://business.twitter.com/success-stories/barack-obama.
44
Capitolo 3 Sentiment Analysis
3.2.1 Modalità di analisi La Sentiment Analysis sostanzialmente si concentra su tre livelli. Con l’aumentare della
granularità, aumenta la complessità.
Livello di documento. Il compito a questo livello è quello di classificare se l’opinione
dell’intero documento esprima un sentimento positivo o negativo. Per esempio,
data una recensione di un prodotto, il sistema determina se la recensione esprime
complessivamente un’opinione positiva o negativa su tale prodotto. Questo livello
di analisi assume che ogni documento esprima opinioni su una singola entità (es.
un singolo prodotto o servizio), pertanto non è applicabile a documenti che
valutano o comparano multiple entità.
Livello di singola frase. A questo livello si determina se ogni frase esprima un’opinione
positiva, negativa o neutrale. Neutrale generalmente significa nessuna opinione.
Questo livello di analisi è strettamente legato alla classificazione soggettiva, che
distingue frasi che esprimono solamente informazioni oggettive da frasi che
esprimono opinioni soggettive. Tuttavia, bisogna tener conto che frasi soggettive
non necessariamente esprimono sentiment così come frasi oggettive possono
includere opinioni e sensazioni. La frase “Ho comprato la macchina il mese scorso
e sono già rimasto a piedi” manifesta un sentimento negativo in relazione alla
macchina, ma non in modo esplicito.
Livello di singoli aspetti di oggetti. L’analisi a livello di documento, così come quella a
livello di frase non consentono di scoprire con esattezza cosa alla gente piace o non
piace. Il livello di singoli aspetti – definiti anche feature – di un oggetto inteso in
modo generale si concentra invece sull’opinione stessa. È basato sull’idea che
un’opinione consiste di un sentimento (positivo o negativo) e un target
(dell’opinione). Ad esempio, la frase “anche se il servizio non è eccezionale, amo
questo ristorante” denota chiaramente un tono positivo, ma non si può dire che la
frase sia interamente positiva. Infatti, la frase è positiva in relazione al ristorante,
ma esprime un sentimento negativo sul relativo servizio. Per cui, l’obiettivo di
questo livello di analisi è quello di scoprire i sentimenti riferiti a singole entità e/o
alle loro caratteristiche.
L’esistenza di due diversi tipi di opinioni, quali regolari e comparative, rende le cose
ancora più articolate e complesse. Un’opinione regolare esprime un sentimento solo
su una particolare entità o su un aspetto dell’entità, come nella frase “La Ferrari è
bellissima”. Un’opinione comparativa paragona multiple entità sulla base delle loro
caratteristiche condivise, come nella frase “La Ferrari è più bella della Lamborghini”.
45
Capitolo 3 Sentiment Analysis
3.2.2 Il vocabolario e i relativi problemi Gli indicatori più importanti del sentiment sono, senza sorpresa, le cosiddette
sentiment word, ossia parole singole (“gioire”), sintagmi2 (“mancanza di rispetto”,
“con cura”), modi di dire (“toccare il cielo con un dito”), espressioni multiparola (“fare
acqua”, “dalla padella alla brace”, “parlare alle spalle”) appartenenti al linguaggio
naturale che solitamente indicano sentimenti, opinioni e stati d’animo. Una lista di tali
parole costituisce un vocabolario – sentiment lexicon – di espressioni generalmente
utilizzate per esternare opinioni e stati d’animo.
Anche se le sentiment word sono molto importanti per la Sentiment Analysis, da sole
non sono sufficienti. Il problema è molto più complesso, per i seguenti motivi:
Una stessa sentiment word potrebbe avere polarità opposta in domini o contesti
differenti. Per esempio, la frase “È silenzioso!” assume un’accezione positiva se
riferita al motore di un’automobile, ma indica una critica se associata
all’altoparlante di un telefono.
Una frase contenente sentiment word potrebbe non esprimere alcun sentimento.
Si verifica molto spesso in frasi interrogative o condizionali, ma non solo. Un
esempio è rappresentato dalla frase “Puoi consigliarmi un bel film?”.
L’ironia e il sarcasmo, come nella frase “Grande macchina! Sono rimasto a piedi
dopo 2 giorni”, rende molto difficoltosa l’analisi automatica.
Molte frasi senza sentiment word possono anche esprimere un’opinione. La frase
“Il telefono si è rotto alla prima accensione!” denota chiaramente un sentimento
negativo, ma non è legato a nessuna sentiment word.
Le negazioni costituiscono un altro problema dell’analisi, perché spesso
cambiano la polarità dell’opinione. Ad esempio, la frase “Quella moto è bella!”
ha un’accezione chiaramente positiva. Con una negazione, “Quella moto non è
bella!” la frase diventa negativa. Tuttavia, il vero problema è dato dal fatto che le
negazioni non implicano necessariamente l’inversione della polarità. Ad esempio,
la frase “Quella moto non è bella, di più!”, ha un’accezione chiaramente positiva
nonostante la negazione.
Questi problemi rappresentano le maggiori sfide della Sentiment Analysis, ma
costituiscono solo una parte delle difficoltà presenti in questa disciplina.
2 Il sintagma è una Combinazione di due o più elementi linguistici (o, al limite, anche un solo elemento), che costituisca un'unità sintattica dotata di una specifica funzione nella struttura della frase. Per esempio, mio cugino Andrea [s. nominale, che si fonda su un nome] è uscito [s. verbale].
46
Capitolo 3 Sentiment Analysis
3.2.3 I problemi dell’elaborazione del linguaggio naturale L’elaborazione del linguaggio naturale, detta anche NLP (dall'inglese Natural
Language Processing) è il processo di trattamento automatico mediante un calcolatore
elettronico delle informazioni scritte o parlate nel linguaggio umano o naturale. Questo
processo è reso particolarmente difficile e complesso a causa delle insite caratteristiche
di ambiguità del linguaggio umano.
La Sentiment Analysis è intrinsecamente legata alla NLP. Tocca ogni aspetto della
NLP, come la risoluzione di coreferenze, il trattamento delle negazioni, la
disambiguazione del senso delle parole, che aggiungono maggiore difficoltà dato che
si tratta di problemi non completamente risolti in NLP. Tuttavia, dato che la Sentiment
Analysis si propone di valutare solo alcuni aspetti di una frase o un documento, per
determinarne la polarità positiva o negativa, non necessita di comprenderne appieno
la semantica. Ovviamente, progressi futuri nel campo della NLP implicheranno, di
conseguenza, progressi nel campo della Sentiment Analysis.
3.2.4 Il problema dello spam Una caratteristica chiave dei social media è il fatto di consentire a chiunque da qualsiasi
parte del mondo di esprimere liberamente i propri punti di vista e le proprie opinioni,
senza la necessità di rivelare la propria vera identità.
Questa anonimia tuttavia ha un prezzo: chiunque può pubblicare delle opinioni false.
Possiamo classificare al meglio delle nostre possibilità, utilizzare tutte le tecniche
possibili per migliorare l’efficienza del nostro sistema di classificazione ma non
potremmo mai sapere se il sentimento che rileviamo sia realmente vero e sincero o
invece frutto di speculazioni personali o economiche. Ad ogni modo, esistono tecniche
che mirano all’individuazione degli utenti spammer tramite metodologie di analisi del
testo e studio dello stile comportamentale degli utenti.
3.3 Definizione del problema La Sentiment Analysis si basa sostanzialmente sullo studio delle opinioni, ossia
espressioni soggettive che esprimono, implicitamente o esplicitamente, sentimenti,
pensieri e punti di vista, positivi o negativi, riguardanti una certa entità e relative
proprietà. Contrariamente alle opinioni, i fatti rappresentano espressioni indicanti
47
Capitolo 3 Sentiment Analysis
caratteristiche oggettive di entità e rispettive proprietà. Ai minimi termini, la Sentiment
Analysis, si riduce ad un problema di classificazione.
3.3.1 Task basilari della Sentiment Analysis In linea generale, sono essenzialmente due le fasi necessarie alla classificazione testuale:
Classificazione di soggettività. Si distinguono i testi che possiedono, oppure no,
contenuti soggettivi. Una frase oggettiva presenta informazioni – fatti – riguardo il
mondo, mentre una frase soggettiva esprime emozioni, pensieri o opinioni. Ad
esempio la frase: “Offerta eccezionale! Cover per qualsiasi smartphone a soli 5 €” è
evidentemente oggettiva in quanto non esprime nessuna opinione ma si limita ad
esporre un fatto.
Classificazione della polarità. Nel caso in cui il testo fornisca un’informazione
soggettiva, se ne determina l’orientamento – positivo o negativo. Ad esempio la
frase “Pulp Fiction è un film bellissimo, più lo vedo più mi piace!” è soggettiva ed
esprime chiaramente un’opinione positiva.
3.3.2 Definizione formale di opinione Si definisce con il termine entità un prodotto, un servizio, un individuo, un argomento,
un evento o un’organizzazione. L’entità è descritta da una coppia, e: (T, W), dove T
rappresenta un oggetto – su chi o cosa si esprime l’opinione – mentre W rappresenta
l’insieme degli attributi, o caratteristiche, di e. Ogni oggetto può essere visto come
appartenente ad una gerarchia, nella quale ogni livello ha il proprio insieme di attributi.
Ad esempio, un particolare modello di una fotocamera è un entità, come la “Nikon
D4”. Essa ha un insieme di attributi, quali altezza, risoluzione, larghezza e un insieme
di componenti, come batteria, mirino, lente. La batteria ha il proprio insieme di
attributi, come durata, peso, larghezza.
La definizione essenzialmente descrive una decomposizione gerarchica di un’entità
basata sulla relazione parte-di. Il nodo radice è il nome dell’entità. Tutti gli altri nodi
sono componenti e sotto-componenti, ecc. Ad ogni nodo è associato un insieme di
attributi. Un’opinione può essere espressa su qualsiasi nodo o attributo del nodo.
In realtà, dato che in questo modo le analisi potrebbero diventare molto complesse, si
preferisce semplificare la gerarchia a due livelli e usare il termine aspetto per indicare
sia le parti che gli attributi. In questo modo, un’entità può essere più facilmente
48
Capitolo 3 Sentiment Analysis
definita da una coppia e: (N, A), dove N è il nome dell’entità e A è il relativo aspetto.
Volendo, per esempio, indicare la durata della batteria della fotocamera presa in
esempio in precedenza, avremmo l’entità e: (Nikon D4, durata_batteria).
A questo punto è possibile definire in modo più formale un’opinione come una
quintupla (𝑒𝑒𝑖𝑖 ,𝑎𝑎𝑖𝑖𝑖𝑖 , 𝑜𝑜𝑜𝑜𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖,ℎ𝑖𝑖, 𝑡𝑡𝑖𝑖) dove:
𝑒𝑒𝑖𝑖 è il nome di un entità,
𝑎𝑎𝑖𝑖𝑖𝑖 è un aspetto dell’entità 𝑒𝑒𝑖𝑖,
𝑜𝑜𝑜𝑜𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 è l’orientamento dell’opinione espressa sull’aspetto 𝑎𝑎𝑖𝑖𝑖𝑖 dell’entità 𝑒𝑒𝑖𝑖,
ℎ𝑖𝑖 è colui, individuo o organizzazione, che esprime l’opinione (opinion holder),
𝑡𝑡𝑖𝑖 rappresenta la data in cui è stata espressa l’opinione.
L’orientamento dell’opinione, detto anche polarità, può essere positivo, negativo o
neutrale, oppure espresso con differenti livelli di intensità (ad esempio da 1 a 5 stelline).
Sostanzialmente, definire l’opinione in questo modo fornisce le basi per la
trasformazione di testo non strutturato in dati strutturati. La quintupla ci dà le
informazioni essenziali per effettuare, qualitativamente e quantitativamente, analisi di
opinioni.
3.4 Classificazione di un documento La classificazione a livello di documento ha il compito di determinare se l’opinione
dell’intero documento esprime un sentimento positivo o negativo.
Formalmente, il problema è quello di determinare in relazione ad un intero documento
d, che valuta un entità e, la relativa polarità oo dell’opinione. In tal caso, ovviamente,
si assume che le opinioni si riferiscano ad una singola entità e siano espresse da un
singolo opinion holder.
Le tecniche più rilevanti per questo tipo di classificazione sono basate su tecniche di
machine learning – apprendimento automatizzato – che rappresenta un ramo
dell’intelligenza artificiale che si occupa di sistemi ed algoritmi in grado di imparare
dai dati, in modo tale che possano lavorare in modo accurato su situazione nuove,
dopo essere stati opportunamente “addestrati” su un primo insieme di dati.
Sostanzialmente vi sono due gruppi di tecniche e algoritmi di machine learning, ossia:
Supervised Learning. L’algoritmo di apprendimento utilizza dati già categorizzati,
al fine di predire il corretto valore di output per ogni input valido. Il dataset di
49
Capitolo 3 Sentiment Analysis
training (training set), ossia l’insieme dei dati su cui l’algoritmo è calibrato,
contiene sia i dati di input sia il risultato e, sulla base di esso, avviene il processo
di addestramento. Algoritmi di questo tipo sono utilizzati, ad esempio, per
l’identificazione automatica di spam nelle e-mail.
Unsupervised Learning. Il processo di apprendimento avviene senza la
conoscenza di ciò che è corretto o non corretto. Il training set non contiene
dunque alcuna categorizzazione dei dati. Si fornisce un insieme di input al
sistema, che riclassificherà ed organizzerà sulla base di caratteristiche comuni per
cercare di effettuare ragionamenti e previsioni sugli input successivi. Un esempio
tipico di questi algoritmi lo si ha nei motori di ricerca. Questi programmi, data
una o più parole chiave, sono in grado di creare una lista di link rimandanti alle
pagine che l’algoritmo di ricerca ritiene attinenti alla ricerca effettuata.
Il processo di machine learning prevede la suddivisione dei dati disponibili in due
insiemi: il training set che contiene un’ampia percentuale dei dati su cui l’algoritmo
scelto è calibrato, e il test set che costituisce l’insieme dei dati su cui si eseguirà il test
del modello per verificarne la bontà.
3.4.1 Supervised Learning La classificazione del sentiment può essere ovviamente formulata come un problema
di supervised learning basato su tre classi: positiva, negativa e neutrale.
È importante notare che la classe neutra non esprime lo stesso concetto dell’assenza di
soggettività. Per chiarire questa osservazione, si consideri la recensione “Ho visto
questo film: mi ha emozionato, ma non mi ha lasciato nulla. Non lo definirei né bello
né brutto”. Il testo contiene indubbiamente contenuti soggettivi, ma il sentimento
generale sul film è neutro.
Qualsiasi tecnica di supervised learning può essere applicata alla classificazione del
sentiment, come il classificatore Naïve Bayes, Support Vector Machines o Maximum
Entropy. Il task principale della classificazione del sentiment è quello di progettare un
insieme efficace di caratteristiche, in modo tale da poter estrarre delle informazioni
significative dal testo che si analizzerà. Alcuni esempi di caratteristiche sono:
I termini e la relativa frequenza. Si tratta di parole singole o n-grammi di parole, ossia
sottosequenze di n parole, e le relative frequenze di apparizione. In alcuni casi,
potrebbe essere considerata anche la posizione delle parole. È stato dimostrato che
tali particolarità sono abbastanza efficaci nella Sentiment Analysis.
50
Capitolo 3 Sentiment Analysis
Part of speech. Alcune parti del discorso – ossia classi grammaticali come sostantivi,
verbi, ecc. – possono rivelarsi ottimi indicatori del sentiment. Ad esempio gli
aggettivi rappresentano un buon strumento per determinare quali frasi siano
soggettive; tuttavia, questo non significa che solo gli aggettivi abbiano rilevanza per
sentimento e opinioni: è evidente come anche sostantivi (“orrore”) o verbi (“amo”)
siano da considerare.
Sentiment word. Le sentiment word indicano parole singole (“ottimo”), sintagmi (“con
cura”, “mancanza di rispetto”), espressioni multiparola (“fare acqua”, “dalla
padella alla brace”) e modi di dire (“toccare il cielo con un dito”) che sono
comunemente usati per esprimere sentimenti positivi o negativi.
Negazioni. Le negazioni sono chiaramente elementi da analizzare, dato che spesso
cambiano la polarità del sentimento, come spiegato nel Paragrafo 3.2.2.
È bene tenere in considerazione come la classificazione del sentiment sia molto
sensibile rispetto al dominio da cui i dati sono estratti. Un classificatore addestrato su
documenti di un particolare dominio generalmente non sarà altrettanto efficace su un
altro dominio, in quanto le parole e i costrutti del linguaggio usati in diversi domini
possono essere leggermente differenti. Inoltre, una stessa parola potrebbe avere
un’accezione positiva in un dominio e negativa in un altro. “Leggetevi il libro” indica
un’opinione positiva se riferita ad un libro, ma negativa se relativa ad un film.
3.4.2 Unsupervised Learning Non è difficile immaginare che le sentiment word – anche dette opinion word – siano
gli indicatori dominanti per la classificazione del sentiment. Perciò, l’utilizzo di una
tecnica di classificazione basata su Unsupervised Learning che usi queste parole o
sintagmi predefiniti risulta abbastanza efficace. L’algoritmo, detto part-of-speech
(POS) tagging, opera in tal modo e fa uso di tecniche di NLP. Le part-of-speech,
letteralmente parti del discorso, assegnano ad una parola la categoria linguistica
definita dal suo comportamento sintattico e morfologico. Ogni caratteristica, quindi,
è connotata tramite un tag specifico che ne indica la relativa part-of-speech, ovvero la
classe grammaticale (come sostantivo, verbo, aggettivo, ecc.).
L’algoritmo sostanzialmente si compone di tre passi:
1. Estrazione di coppie di parole contenenti aggettivi e avverbi, essendo ottimi
indicatori di sentiment. Tuttavia, anche se un aggettivo isolato potrebbe indicare
sentiment, non è possibile determinare con certezza la sua polarità, perché dipende
51
Capitolo 3 Sentiment Analysis
dal contesto. L’aggettivo “imprevedibile” potrebbe avere una polarità positiva se
riferito ad un film d’azione, ma negativa se associato allo sterzo di un’automobile.
Pertanto, l’algoritmo estrae due parole consecutive, una delle quali è un aggettivo
o un avverbio e l’altra è una parola indicante il contesto.
2. Valutazione dell’orientamento semantico SO della coppia di parole estratta. Può
essere calcolato sottoponendo delle query ad un motore di ricerca nelle quali si
associa una volta la coppia di parole ad un termine chiaramente positivo, come per
esempio “eccellente”, e una seconda volta ad un termine palesemente negativo,
come “pessimo”. Il motore di ricerca per ogni query restituisce il numero di risultati
trovati, e in base a questi è possibile successivamente calcolare la polarità, tramite
un’opportuna equazione.
3. Dato un testo da esaminare, l’algoritmo calcola la media dei vari SO calcolati e
conseguentemente è in grado di classificare il testo come positivo o negativo.
3.4.3 Limiti della classificazione per documento Il vantaggio maggiore della classificazione per documento è dato dal fatto che essa
fornisce una panoramica del sentimento dominante su un’entità, tuttavia non fornisce
informazioni precise riguardo gli aspetti dell’entità preferiti o meno dalle persone. In
una recensione un utente valuta generalmente varie caratteristiche. Inoltre, non è
possibile applicarla a testi che non siano delle recensioni o particolari post, poiché in
essi si valutano multiple entità e, in molti casi, si comparano tra loro.
3.5 Classificazione a livello di frase Le stesse tecniche analizzate per la classificazione a livello di documento, possono
essere applicate a livello di singole frasi. Come descritto nel Paragrafo 3.3.1, una volta
identificata la soggettività di una frase è possibile classificarne la polarità del sentiment.
Entrambi i task sono problemi di classificazione. Anche la soggettività, infatti, è
possibile classificarla attraverso tecniche di machine learning.
Uno dei colli di bottiglia nell’applicazione di una tecnica Supervised Learning è quello
di dover categorizzare un gran numero di dati, costituenti il training set. Questo
processo può essere automatizzato. Dapprima si classificano frasi soggettive o
oggettive sulla base di una lista di termini (singole parole o n-grammi) che indicano
52
Capitolo 3 Sentiment Analysis
chiaramente soggettività o oggettività. Si aggiungono tali frasi al training set e si itera
il procedimento in questo modo, utilizzando il nuovo training set.
Successivamente è possibile classificare la polarità delle frasi soggettive filtrate,
attraverso tecniche simili alla POS tagging vista nel Paragrafo 3.4.2.
La classificazione a livello di frase non è adatta all’analisi di frasi complesse e/o
composte. In esse è possibile trovare anche multiple opinioni e/o clausole sia soggettive
che oggettive, e quindi diventa essenziale distinguere tali clausole, che generalmente
sono separate da congiunzioni (come ma, tuttavia, ecc.). Inoltre, ci sono dei casi più
complessi, anche se più rari, in cui le congiunzioni non sono presenti esplicitamente,
ad esempio nella frase “Il portiere è l’unico fuoriclasse in quella squadra mediocre!”.
3.6 Espansione del vocabolario Come già affermato precedentemente, le sentiment word costituiscono gli elementi
chiave per la classificazione del sentiment, per cui diventa importante creare un
vocabolario del sentiment. Questo processo può essere realizzato manualmente, ma
richiederebbe molto tempo, oppure combinando l’approccio manuale con uno
automatizzato. Il solo approccio automatizzato produrrebbe probabili errori.
Gli approcci automatizzati sono sostanzialmente due.
Approccio Dictionary-based. Una delle tecniche più semplici di questo approccio è
quello di utilizzare un insieme di sentiment word e un dizionario online. La
strategia consiste innanzitutto nel costruire manualmente un piccolo vocabolario
di parole con polarità nota e successivamente ampliarlo attraverso la ricerca
automatica di sinonimi e contrari sul dizionario online. Il processo può essere
iterato più volte, fin quando verranno aggiunti nuovi termini. Infine, sarebbe
auspicabile un’ispezione manuale per rimuovere e/o correggere eventuali errori.
Questa tecnica, tuttavia, è strettamente legata al dominio e alle polarità specifiche
del contesto. Come descritto nel Paragrafo 3.3.2, un aggettivo “silenzioso”
potrebbe avere un’accezione sia positiva che negativa.
Approccio Corpus-based. Sostanzialmente integra l’approccio Dictionary-based con
una serie di vincoli linguistici e sintattici. Una tecnica relativamente semplice
consiste nella creazione automatica di un vocabolario, partendo da un piccolo
insieme di termini e utilizzando un approccio simile al Dictionary-based per
ampliarlo, ma considerano anche le congiunzioni presenti nelle frasi da analizzare.
53
Capitolo 3 Sentiment Analysis
Congiunzioni copulative positive come “e” generalmente collegano aggettivi con
stessa polarità (“La macchina è bella e spaziosa”), mentre congiunzioni avversative
collegano aggettivi con polarità opposta (“La macchina è bella ma piccola”). In
questo modo le sentiment word sono classificate anche in relazione al dominio.
Tecniche più complesse, inoltre, permettono anche di classificare la polarità in
modo ancor più specifico, in riferimento al contesto, dato che anche in uno stesso
dominio la stessa parola potrebbe assumere polarità opposte. Un esempio è
rappresentato dall’aggettivo “considerevole” in relazione ad una fotocamera. In
relazione alla durata della batteria avrà un’accezione positiva, ma negativa se
riferito al tempo necessario per la messa a fuoco della fotocamera.
3.7 Classificazione dei singoli aspetti A questo livello si classificano i singoli aspetti, in questo modo è realmente possibile
osservare in modo specifico ciò che all’opinion holder piace o meno. In tal caso diventa
fondamentale estrarre da un documento le quintuple (𝑒𝑒𝑖𝑖 ,𝑎𝑎𝑖𝑖𝑖𝑖 , 𝑜𝑜𝑜𝑜𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖,ℎ𝑖𝑖, 𝑡𝑡𝑖𝑖) viste nel
Paragrafo 3.3.2. Per raggiungere tale obiettivo sono necessari vari task, ma
essenzialmente due sono quelli fondamentali, vale a dire l’estrazione degli aspetti (con
le relative entità) e la successiva classificazione della polarità.
3.7.1 Estrazione degli aspetti Con una tecnica unsupervised è possibile individuare nomi o sintagmi che
rappresentano espliciti aspetti. Una tale tecnica consiste di due step, quali:
1. Individuazione di nomi o sintagmi frequenti. Nomi o sintagmi possono essere
identificati utilizzando una tecnica di POS tagging. Si conteggia poi la loro
frequenza di occorrenza. Dato che in un particolare dominio o contesto, il
vocabolario di termini utilizzati solitamente converge, sostantivi particolarmente
utilizzati diventano più rilevanti dal punto di vista dell’analisi, a differenza di altri
che generalmente indicano aspetti di secondo piano. Di conseguenza, solo nel caso
in cui la frequenza di occorrenza raggiunga una determinata soglia scelta
preventivamente, i termini sono considerati utili per successive analisi.
2. Individuazione di aspetti meno frequenti per mezzo di sentiment word. L’idea è
che la stessa sentiment word possa essere utilizzata per descrivere differenti aspetti
dello stesso oggetto. Sentiment word che valutano aspetti frequenti possono anche
54
Capitolo 3 Sentiment Analysis
valutare aspetti meno frequenti, e quindi possono essere utilizzate proprio per
estrarre tali aspetti. Per esempio, si suppone che “libro” sia un aspetto molto
frequente e che lo si possa trovare in una frase come “il libro è avvincente”. Se
“avvincente” si suppone essere una sentiment word positiva, da una frase come “il
film è avvincente” è possibile estrarre l’aspetto “film”, dato che entrambe le frasi
hanno lo stesso schema.
La precisione dell’algoritmo può essere migliorata scartando nel primo step tutte le
parole o sintagmi che sicuramente non possono essere degli aspetti. Si può realizzare
sottoponendo query ad un motore di ricerca, costituite da un oggetto e il probabile
aspetto e in base ai risultati ottenuti, opportunamente elaborati, è possibile capire se
tali aspetti siano effettivamente da considerare o meno nell’analisi.
Ad ogni modo, dopo l’estrazione degli aspetti, c’è un altro problema da considerare,
oltre al fatto che potrebbero esserci aspetti impliciti non considerati, come nella frase
“Questo telefono è troppo grande” dove implicitamente si sottintende l’aspetto
dimensione. L’altro problema è costituito dai possibili sinonimi utilizzati per indicare
uno stesso aspetto. È frequente, infatti, che uno stesso aspetto sia denotato con termini
differenti. Per esempio, “foto” e “immagini” potrebbero riferirsi allo stesso aspetto in
una recensione riguardante una fotocamera. Identificare e raggruppare i sinonimi è
essenziale per una corretta analisi. In tal senso potrebbero essere utili i dizionari online,
ma non sono sufficienti dato che molti sinonimi sono dipendenti dal dominio.
3.7.2 Classificazione della polarità Come accennato precedentemente, ogni frase può essere formata da diverse clausole,
ognuna delle quali può avere diversa polarità. Per cui diventa essenziale classificare
queste specifiche polarità. Questo può essere realizzato attraverso un approccio detto
lexicon-based, basato essenzialmente sul vocabolario, ma anche su invertitori di
sentiment – quali congiunzioni avversative, o parole e sintagmi che convertono la
polarità della clausola. L’approccio lexicon-based lavora seguendo vari passi:
1. Rilevazione delle sentiment word. Data una frase che contiene uno o più aspetti, in
questo step si rilevano tutte le sentiment word. Ad ognuna di esse, se positiva gli si
assegna un punteggio di +1 e se negativa -1. Si consideri, per esempio, la frase “la
qualità dell’immagine di questa fotocamera non è buona, ma la durata della
batteria è considerevole”. Dopo questo step, essa è modificata in “la qualità
dell’immagine di questa fotocamera non è buona[+1], ma la durata della batteria
è considerevole”, perché “buona” è una sentiment word positiva, mentre
55
Capitolo 3 Sentiment Analysis
“considerevole” è molto dipendente dal contesto, come già affermato nel
Paragrafo 3.6. Inoltre, in corsivo sono stati evidenziati gli aspetti.
2. Identificazione delle negazioni. Il termine negazione si riferisce a parole e/o
sintagmi che possono modificare la polarità della clausola, come non, mai,
nessuno, nemmeno, ecc. Considerando l’esempio precedente, la frase diventa “la
qualità dell’immagine di questa fotocamera non è buona[-1], ma la durata della
batteria è considerevole”, a causa dell’avverbio di negazione “non”. Anche alcuni
verbi al condizionale (come sarebbe, dovrebbe, potrebbe, ecc.) potrebbero essere
considerati come negazioni in molti casi (“il cambio dovrebbe essere migliorato”).
3. Identificazione delle congiunzioni avversative. Una congiunzione avversativa
(come ma, però, tuttavia, invece, ecc.) ha lo scopo di contrapporre due clausole, di
modo che l’orientamento dell’una risulti opposto rispetto all’altra. Dopo questo
step, la frase di esempio diventa “la qualità dell’immagine di questa fotocamera non
è buona[-1], ma la durata della batteria è considerevole[+1]”. Separatamente poi
si potrebbero trattare casi particolari, dato che non sempre una congiunzione
avversativa indica un’inversione di polarità (“La moto è bella, ma l’altra è meglio”).
4. Aggregazione dei punteggi del sentiment. In questo step si applica una funzione di
aggregazione ai punteggi relativi al sentiment ricavati negli step precedenti per
determinare la polarità finale dell’opinione riguardo ogni aspetto della frase. Si
consideri una frase 𝑓𝑓, contenente un insieme di aspetti {𝑎𝑎1, … ,𝑎𝑎𝑚𝑚} e un insieme di
sentiment word {𝑠𝑠𝑠𝑠1, … , 𝑠𝑠𝑠𝑠𝑛𝑛} con i relativi punteggi calcolati negli step precedenti.
La polarità dell’opinione per ogni aspetto 𝑎𝑎𝑖𝑖 in 𝑓𝑓 è determinata dalla seguente
funzione di aggregazione:
𝑝𝑝𝑝𝑝𝑝𝑝𝑡𝑡𝑒𝑒𝑝𝑝𝑝𝑝𝑝𝑝𝑜𝑜(𝑎𝑎𝑖𝑖 ,𝑓𝑓) = �𝑝𝑝(𝑠𝑠𝑠𝑠𝑖𝑖)
𝑑𝑑(𝑠𝑠𝑠𝑠𝑖𝑖 ,𝑎𝑎𝑖𝑖)𝑠𝑠𝑠𝑠𝑗𝑗 ∈ 𝑓𝑓
dove 𝑠𝑠𝑠𝑠𝑖𝑖 è una sentiment word in 𝑓𝑓, 𝑑𝑑(𝑠𝑠𝑠𝑠𝑖𝑖 , 𝑎𝑎𝑖𝑖) è la distanza tra l’aspetto 𝑎𝑎𝑖𝑖 e la
sentiment word 𝑠𝑠𝑠𝑠𝑖𝑖 in 𝑓𝑓 e 𝑝𝑝(𝑠𝑠𝑠𝑠𝑖𝑖) è la polarità (o punteggio) di 𝑠𝑠𝑠𝑠𝑖𝑖 . Grazie al
denominatore si associa un peso minore a sentiment word più distanti dall’aspetto
𝑎𝑎𝑖𝑖. Se il punteggio finale è positivo, il sentiment sull’aspetto 𝑎𝑎𝑖𝑖 in 𝑓𝑓 sarà positivo,
altrimenti sarà negativo. Potrebbe anche essere neutrale.
Questo semplice algoritmo lavora bene in molti casi, ma non è sufficiente in altri più
complessi, dato che le sentiment word non coprono tutti i tipi di espressioni che
trasmettono o implicano sentiment. È possibile aumentare l’accuratezza del punteggio
finale attraverso un ulteriore insieme di regole da tenere in considerazione.
56
Capitolo 4 Sistema per la Sentiment Analysis
Sistema per la Sentiment Analysis
“La società può essere compresa solo attraverso lo studio dei messaggi e dei mezzi di
comunicazione relativi ad essi. […] Nello sviluppo futuro di questi messaggi e strumenti di
comunicazione, i messaggi fra l’uomo e le macchine, fra le macchine e l’uomo, e fra le
macchine e le macchine sono destinati ad avere un ruolo sempre più importante.”
– Norbert Wiener, 1948
a tempo ormai viviamo immersi in un ambiente mediale che ci offre stimoli in
ogni istante. Questa sensazione di essere parte di un flusso informativo è
amplificata da dispositivi mobili che accompagnano la nostra giornata con notifiche
pressanti provenienti dai social media. Questo ci porta a reagire immediatamente,
interagendo costantemente con la nostra cerchia sociale, che ormai comprende anche
aziende e organizzazioni.
Attraverso la Sentiment Analysis è possibile identificare, estrarre, etichettare e
rielaborare questo flusso informativo, per determinare l’attitudine di chi ha pubblicato
un certo contenuto, così come la polarità contestuale del contenuto stesso.
4.1 Panoramica del sistema sviluppato Il progetto di Big Data processing: un sistema scalabile per la Sentiment Analysis ha
come obiettivo la costruzione di un sistema automatico e scalabile per la rilevazione e
valutazione delle opinioni espresse sul social network Twitter, in riferimento alla
Nazionale Italiana di calcio in occasione dei Mondiali del 2014 in Brasile.
Formalmente il sistema dovrà essere in grado di:
Acquisire (per mezzo di Flume) informazioni dalla rete (tweet);
Memorizzare le informazioni acquisite su un file system distribuito (HDFS);
CAPITOLO 4
D
57
Capitolo 4 Sistema per la Sentiment Analysis
Classificare tali informazioni attraverso l’estrazione e la valutazione del sentiment
espresso (tramite Hive);
Permettere l’analisi dei risultati, in tempo reale, tramite una piattaforma di
Business Analytics (Pentaho);
Automatizzare il processo di acquisizione, memorizzazione e classificazione
tramite un sistema di workflow (Oozie).
La Figura 4.1 mostra l’architettura del sistema sviluppato.
Figura 4.1 – Architettura del sistema per la Sentiment Analysis
4.2 Twitter Twitter1 è la piattaforma di Microblogging2 più utilizzata. Secondo i dati pubblicati da
Twitter3, ogni giorno vengono inviati 500 milioni di Tweet, per una media di quasi
6000 tweet al secondo, e gli utenti attivi ogni mese sono circa 255 milioni.
Il servizio è caratterizzato dalla semplice idea di consentire agli utenti la pubblicazione
di brevi messaggi, i tweet, la cui lunghezza massima è di 140 caratteri, che oltre al testo
possono includere link a video, foto o altre risorse sul Web.
1 Sito web: https://twitter.com/. 2 Le piattaforme di microblogging consentono agli utenti di pubblicare brevi messaggi di testo (ed
eventualmente contenuti multimediali). Queste applicazioni generalmente includono funzionalità “social” poiché permettono la costruzione di una rete di contatti, ovvero persone collegate a un microblogger, che rimangono quindi costantemente aggiornate su ciascun post.
3 Alla pagina: https://about.twitter.com/it/company.
58
Capitolo 4 Sistema per la Sentiment Analysis
La piattaforma può essere utilizzata attraverso PC o dispositivi mobili, quali tablet o
smartphone. Alcuni utenti la usano per comunicare con gli amici, altri per far
conoscere informazioni circa il proprio lavoro, hobby o stato d’animo; altri ancora la
utilizzano per recuperare informazioni relative a determinati argomenti. Per chi non
avesse familiarità con la piattaforma, la tabella 4.1 mostra alcune parole chiave del
mondo Twitter.
Tabella 4.1 – Parole chiave del mondo Twitter
Parola chiave Descrizione
Tweet Messaggio, espressione di un momento o di un’idea, di massimo 140 caratteri.
Follower Colui che segue un utente, ricevendone i suoi tweet.
Following Colui che viene seguito da un utente.
@nome_utente Risposta a un tweet diretta a un utente identificato da “nome_utente”.
Messaggio diretto Messaggio privato inviato ad un utente.
Retweet Tweet con cui un utente diffonde, o condivide, un tweet di qualcun altro.
Hashtag È costituito da un termine preceduto da un cancelletto (#). Assegna un argomento al tweet.
4.2.1 Twitter API Twitter può essere utilizzato direttamente dal sito o tramite applicazioni per dispositivi
mobili. Inoltre ogni sviluppatore può utilizzarne le funzionalità attraverso le API4.
Le API (acronimo di Application Programming Interface) sono protocolli utilizzati
come interfaccia di comunicazione tra componenti software. Esse consistono in
insiemi di procedure, strutture dati o variabili che permettono al programmatore di
richiamare le funzionalità di un’applicazione di terze parti. Nel caso di Twitter, le API
consentono di interagire con l’intera piattaforma, permettendo di creare nuovi tweet,
rispondere, effettuare il retweet, eseguire ricerche o mettersi in ascolto per intercettare
i nuovi tweet che hanno a che fare con gli argomenti che interessano. Quest’ultima
funzionalità, chiamata streaming, è quella più interessante ai fini della sentiment
analysis, per questo è stata utilizzata nel sistema sviluppato.
La Twitter Streaming API5 somiglia alla normale API di ricerca, con una importante
differenza: normalmente le ricerche sono basate su una connessione REST
(acronimo di Representational State Trasfer), che fondamentalmente è una
4 Per la documentazione ufficiale si veda: https://dev.twitter.com/docs. 5 Per ulteriori informazioni, si veda la documentazione: https://dev.twitter.com/docs/api/streaming.
59
Capitolo 4 Sistema per la Sentiment Analysis
connessione HTTP6 attraverso la quale si eseguono richieste e si ottengono risposte;
nello streaming, invece, si apre una connessione a Twitter e attraverso di essa fluiscono
i dati richiesti man mano che si rendono disponibili, poiché la connessione rimane
sempre aperta finché non è esplicitamente chiusa dal richiedente.
Gli stream che Twitter mette a disposizione sono tre: User Stream, che consente di
recuperare i tweet pubblici di un determinato utente; Site Tweet, che altro non è che
una versione multiutente dello User Stream; Public Stream, che consente di recuperare
tutti i tweet pubblici di qualsiasi utente. Public Stream è la tipologia più interessante,
poiché ai fini analitici è più utile per acquisire i tweet sia per argomento che per utente.
Essa funziona secondo tre modalità: senza filtri (firehose), a campione (sample) oppure
con la possibilità di specificare filtri (modalità filter). La modalità firehose raccoglie
tutti i tweet generati sulla piattaforma e li trasmette sullo stream. Si possono impostare
alcuni parametri per l’utilizzo, ma non vi è alcuna flessibilità. Più interessante è lo
stream di tipo filter, che consente di parametrizzare la raccolta dei tweet. Infatti, tale
modalità accetta come parametri una o più parole chiave e fornisce come risultato tutti
i tweet, in tempo reale, che corrispondono a tali parole chiave.
Tale modalità di accesso richiede autenticazione tramite il protocollo OAuth7, che è
pensato per offrire un modo semplice per ottenere un accesso limitato a un servizio.
Sostanzialmente, per ottenere l’accesso alle streaming API di Twitter è necessario avere
un account Twitter e creare un’applicazione (nell’area del sito dedicata alle
applicazioni8). Una volta creata l’applicazione si possono ottenere le chiavi di accesso
(Access Token) con le quali è possibile usufruire delle Streaming API.
4.2.2 Formato dei dati I dati recuperati utilizzando le Streaming API di Twitter comprendono, oltre al campo
testuale (text) del tweet, molte altre informazioni aggiuntive9, come ad esempio: lang,
che indica la lingua del testo del messaggio; coordinates, che specifica le coordinate
geografiche, se abilitate nelle impostazioni dell’utente che ha realizzato il post;
location, che è una stringa opzionalmente definita dall’utente, generalmente indicante
6 L'HTTP (acronimo di HyperText Transfer Protocol) è il principale sistema per la trasmissione d'informazioni sul web ovvero in un'architettura tipica client-server. Funziona su un meccanismo richiesta/risposta (client/server): il cliente esegue una richiesta e il server restituisce la risposta. Nell’uso comune il client corrisponde al browser e il server al sito web.
7 Per approfondimenti si veda: https://dev.twitter.com/docs/auth/obtaining-access-tokens. 8 Al link https://apps.twitter.com/. 9 Si veda https://dev.twitter.com/docs/platform-objects.
60
Capitolo 4 Sistema per la Sentiment Analysis
la città di residenza dell’utente stesso; created_at, che indica la data e l’ora di
pubblicazione del tweet.
L’ultima considerazione riguarda il formato con cui i tweet sono inviati
all’applicazione che utilizza le API. Si tratta di oggetti JSON10.
JSON (JavaScript Object Notation) è un formato adatto per lo scambio di dati in
applicazioni client-server. È semplice da leggere e da generare sia per i computer sia
per le persone. Esso è basato essenzialmente su due strutture:
Una collezione di coppie chiave/valore, come per esempio "text":"Ciao!", dove
la chiave descrive ciò che il valore contiene.
Un elenco ordinato di valori. Nella maggior parte dei linguaggi questo si realizza
come un array, un vettore, un elenco o una sequenza.
Queste sono strutture di dati universali. Virtualmente tutti i linguaggi di
programmazione moderni li supportano in entrambe le forme.
4.2.3 Perché Twitter? Si è scelto di utilizzare Twitter sostanzialmente perché è il social network che consente
di esprimere e diffondere nel modo più rapido e conciso tutto ciò che passa per la testa
del “twittatore”, sentiment incluso. Essendo un tweet composto da un massimo di 140
caratteri, e quindi costituito da una o al massimo due frasi, consente di fondere in
un’unica tipologia di analisi, sia la classificazione a livello di documento che a livello
di frase. In tal modo, diventa poco rilevante ai fini dell’accuratezza finale, dividere il
testo del tweet nelle frasi di cui è composto.
Per di più, come detto nei paragrafi precedente, nella “twittosfera” ormai circolano
quasi 6000 nuovi tweet ogni secondo, che rendono Twitter una fonte di dati
dall’enorme potenziale informativo. Twitter è condivisione tematica: l’utente
interagisce con amici e colleghi, oppure segue l’uscita di un nuovo prodotto, o legge le
notizie o i pensieri espressi da altri utenti. A sua volta riporta le proprie opinioni. Altri
lo seguono e sullo stesso argomento dicono la loro. Così da questa modalità di libera
conversazione possono uscire punti di vista ed esperienze personali utili, ad esempio,
per determinare il grado di soddisfazione degli utenti riguardo un determinato soggetto
di discussione. Per cui, pur senza poter vantare alcuna rappresentatività del campione,
in sostanza è possibile prendere come ipotesi plausibile che un sentimento diffuso nella
società si ripercuota in una certa misura su Twitter.
10 Per approfondimenti, si veda http://json.org/.
61
Capitolo 4 Sistema per la Sentiment Analysis
4.3 Acquisizione e memorizzazione dei tweet Il primo step del sistema sviluppato, come illustrato nella relativa architettura in
Figura 4.1, consiste nell’acquisizione dei tweet dalle Twitter Streaming API, attraverso
Flume, e nella conseguente memorizzazione nel file system distribuito HDFS.
La Figura 4.2 mostra l’architettura relativa a questo primo step del sistema.
Figura 4.2 – Architettura del sistema di acquisizione dei tweet
Tale sistema consiste nell’acquisizione di tweet attraverso la libreria wrapper 11
Twitter4J12 e il salvataggio sul sink per HDFS. Ciò richiede lo sviluppo, in Java, di un
Source personalizzato che utilizzi le librerie Flume, estendendone le funzionalità.
Il primo passo consiste nell’implementazione di un Agent di Flume, e quindi delle
relative tre componenti: Source, Channel e Sink. Si ricorda che un Agent è il processo
che gestisce il flusso di dati, mentre gli elementi di tale flusso sono detti eventi.
4.3.1 Source Il Source è la componente di Flume che si connette a una fonte di dati, e avvia i dati
lungo il percorso predefinito, attraverso un flusso di dati in Flume. Un Source processa
gli eventi e li trasferisce nel Channel. Il Source opera acquisendo pezzi discreti di dati,
11 Nei linguaggi di programmazione ad oggetti, un wrapper è "un oggetto che contiene altri oggetti": si istanzia, cioè, un oggetto che renda disponibili all'applicazione che si sta scrivendo le funzioni contenute in una libreria esterna.
12 Si veda http://twitter4j.org/en/index.html.
62
Capitolo 4 Sistema per la Sentiment Analysis
li traduce in singoli eventi, e successivamente utilizza il canale per elaborare gli eventi
uno per volta o in blocco.
I Source seguono sostanzialmente due metodologie: event-driven13 o polling14. La
differenza tra le due metodologie riguarda il modo in cui gli eventi vengono generati
ed elaborati. I Source event-driven in genere ricevono gli eventi tramite meccanismi
come Callback 15 o chiamate RPC 16 . I Source che utilizzano il polling, al
contrario, effettuano interrogazioni periodiche. Quindi, semplicisticamente, è come
se gli eventi fossero spinti verso i Source event-driven, mentre i Source che utilizzano
il polling è come se estraessero tali eventi da un generatore. L’approccio utilizzato nel
sistema sviluppato è di tipo event-driven, in modo tale che ogni volta che è stato
generato un particolare tweet di interesse, sarà prodotto un evento, che verrà
processato dal Source (che creerà un apposito thread allo scopo) e trasmesso
successivamente lungo il canale, per poi essere salvato, ad opera del Sink, in una
particolare directory in HDFS.
Allo scopo è necessario sviluppare un Source personalizzato17, in Java, che, come
accennato precedentemente, faccia uso delle librerie di Flume e della libreria Twitter4J.
La libreria Twitter4J è utilizzata per ottenere l’accesso alle Twitter Streaming API. È
possibile implementare un listener che può essere aggiunto allo stream di Twitter, e
che eseguirà dei metodi callback ogni volta che un nuovo tweet, rappresentato
dall’oggetto Status18, fluirà attraverso tale stream. Affinché sia possibile connettersi
alle Twitter API, è necessario disporre delle chiavi di accesso.
4.3.2 Configurazione dell’Agent Una volta sviluppato il Source personalizzato, è necessario configurare un Agent19 di
Flume, in cui sarà indicato il nome della classe del Source appena creata e altre
informazioni di configurazione riguardanti il Source, il Channel e il Sink.
13 Un approccio event-driven indica la capacità di rilevare, consumare e reagire a determinati eventi in ingresso. Per cui, quando si verifica un determinato evento, esso sarà prontamente gestito da un gestore opportuno.
14 Il meccanismo del polling permette di rilevare, e quindi in seguito gestire, gli eventi esterni interrogando periodicamente la fonte degli eventi. Sostanzialmente, questo meccanismo attua una verifica ciclica in relazione alla presenza di nuovi eventi.
15 In programmazione, una callback è, in genere, una funzione che viene passata come parametro ad un’altra funzione (chiamante) che necessita di realizzare un compito specifico, implementato dalla callback.
16 Si veda la nota 30 del Capitolo 2. 17 Si veda: http://flume.apache.org/FlumeUserGuide.html#custom-source. 18 Si veda: http://twitter4j.org/javadoc/twitter4j/Status.html. 19 Si veda: https://flume.apache.org/FlumeUserGuide.html#a-simple-example per un esempio.
63
Capitolo 4 Sistema per la Sentiment Analysis
Per quanto riguarda il Source si specifica, oltre il nome della classe personalizzata,
anche i parametri che verranno passati ad essa. Tali parametri sono le chiavi ottenute
dall’applicazione creata su Twitter, e le parole chiave su cui incentrare la ricerca per la
conseguente acquisizione dei relativi tweet. Alcune delle parole chiave utilizzate per il
sistema sviluppato sono: nazionale italiana, nazionaleitaliana, prandelli,
formazioneazzurri, vivoazzurro, ciroimmobile, balotelli, forzazzurri, insigne, chiellini,
cassano, pirlo, derossi, cerci, ecc.
Le configurazioni relative alle restanti due componenti, quali Channel e Sink, saranno
esaminate nei prossimi due Paragrafi.
4.3.3 Channel Il Channel agisce come un percorso tra il Source e il Sink. Gli eventi vengono aggiunti
al Channel dal Source, e successivamente prelevati dal Sink.
Nel sistema sviluppato è stato definito un Memory Channel20. Un Memory Channel
utilizza una coda per salvare in memoria gli eventi fin quando non sono pronti per
essere scritti sul Sink. Tali tipi di Channel sono utili per flussi di dati che presentano
un throughput elevato; tuttavia, dato che gli eventi sono memorizzati nella memoria
del canale, nel caso si verifichi un errore c’è il rischio di perdita di dati. Se tale rischio
non è tollerabile, è possibile utilizzare un diverso tipo di canale come FileChannel, che
offre maggiori garanzie in termini di durabilità dei dati.
Ad ogni modo, attraverso la proprietà capacity del Memory Channel è possibile
settare il numero massimo di eventi memorizzati nel canale.
4.3.4 Sink Il Sink costituisce la componente finale nel flusso di dati di Flume. Il Sink ha il compito
di prelevare gli eventi dal Channel e di inviarli ad un supporto di memorizzazione
oppure di inoltrarli ad un altro Agent. Nel sistema sviluppato si utilizza un HDFS
Sink21, e quindi il Sink è stato configurato in modo tale da scrivere gli eventi in una
posizione predefinita in HDFS.
La configurazione del HDFS Sink riguarda diversi parametri. Primo, si definisce la
grandezza dei file attraverso il parametro rollCount, che rappresenta il numero di
eventi, e quindi dei tweet, contenuti in un file.
20 Per approfondimenti, si veda: http://flume.apache.org/FlumeUserGuide.html#memory-channel. 21 Si veda: http://flume.apache.org/FlumeUserGuide.html#hdfs-sink.
64
Capitolo 4 Sistema per la Sentiment Analysis
Inoltre, è stato mantenuto il formato originale dei dati, settando writeFormat = Text
e fileType = DataStream. In tal modo, il tipo di file non sarà compresso e il suo
formato sarà di tipo testuale.
La parte più interessante della configurazione riguarda il path del file:
hdfs.path = hdfs://[namenode_address]:8020/user/flume/tweets/%Y/%m/%d/%H/
Il percorso del file, come definito, utilizza una serie di wildcards22 per specificare che i
file saranno organizzati in una successione di directory per anno, mese, giorno e ora in
base a quando si verificano gli eventi. Per esempio, un tweet pubblicato il
14/20/2014 3:30PM, sarà memorizzato nella directory il cui path è:
hdfs://[namenode_address]:8020/user/flume/tweets/2014/20/14/15/
Questo è possibile aggiungendo, tramite la classe Java relativa al Source, un timestamp,
associato alla data di creazione del tweet, nell’header di ogni event. Tale header sarà
poi opportunamente trattato da HDFS Sink.
4.4 Analisi dei dati Una volta impostato opportunamente Flume, e avviato l’Agent, vengono generati in
successione diversi file su HDFS, in directory differenti, a seconda dell’orario di
pubblicazione del tweet. Il passo successivo è quello di interpretare opportunamente
questi dati grezzi, che sono in formato JSON23, per poter poi eseguire lo script Hive
necessario per effettuare la sentiment analysis.
4.4.1 Interpretazione dei dati Il formato JSON dei dati presenta una struttura arbitrariamente complessa, definita
semistrutturata, in quanto presenta delle strutture dati nidificate24, come nel caso della
struct entities. Essa contiene tre array, uno dei quali rappresentato da hashtags che
a sua volta è una struttura dati nidificata, che potrebbe contenere zero o più campi, in
relazione al numero di hashtag utilizzati nel campo text. Inoltre, alcuni campi
potrebbero esistere o meno. Il campo retweeted_status, per esempio, sarà presente
solo nel caso il tweet sia un retweet.
22 Un wildcard (o carattere jolly) è un carattere che, all’interno di una stringa, non rappresenta sé stesso bensì un insieme di altri caratteri o sequenze di caratteri.
23 Al link https://gist.github.com/3725161 è mostrata la tipica struttura di un tweet in formato JSON. 24 La struttura nidificata è quella struttura che al suo interno contiene un'altra struttura.
65
Capitolo 4 Sistema per la Sentiment Analysis
Hive ha già il supporto nativo per strutture dati complesse, come map, array e struct.
Per default, però, Hive si aspetta che le righe del file in ingresso siano delimitate da
‘TAB’, o da un qualsiasi altro carattere facilmente ridefinibile25, e quindi il formato
JSON dei dati Twitter non potrebbe essere interpretato in tal modo. Come spiegato
nel Paragrafo 2.8.3, Hive permette di definire e ridefinire in modo flessibile come i dati
sono rappresentati su disco, creando delle interfacce Serializer/Deserializer
personalizzate, utili per specificare come interpretare tali dati. Per cui è possibile
implementare una SerDe personalizzata che legga i dati JSON e li traduca in oggetti
che Hive sia in grado di elaborare.
Sono disponibili diverse interfacce SerDe utili allo scopo e già implementate. Nel
sistema sviluppato si è adottata l’interfaccia SerDe pubblicata da Cloudera 26 su
GitHub 27 e sviluppata da Joey Echeverria e Jarek Jarcec Cecho. In tal modo si è
proceduto alla creazione della input_table, con le seguenti caratteristiche:
CREATE EXTERNAL TABLE input_table ( `id` BIGINT, `created_at` STRING, `text` STRING, `lang` STRING, `user`.`location` STRING ) PARTITIONED BY (datehour INT) ROW FORMAT SERDE 'hive.serde.JSONSerDe' LOCATION '/user/flume/tweets';
Come si può vedere, la maggior parte dei campi non sono stati considerati, in quanto
non utili allo scopo. I campi del tweet in JSON ritenuti utili sono:
id: la rappresentazione intera dell’identificatore univoco per il tweet.
created_at: la data e l’ora di creazione del tweet in UTC.
text: il testo di 140 caratteri del tweet.
lang: la lingua utilizzata nel testo del tweet. Campo necessario per estrarre i tweet
in lingua italiana.
user.location: la locazione definita dall’utente nel proprio profilo Twitter. È
necessaria per effettuare un’analisi geolocalizzata. Si sarebbe potuto utilizzare il
campo coordinates, rappresentante le coordinate geografiche (latitudine e
longitudine) del tweet, riportate dall’applicazione utilizzata dall’utente Twitter.
25 Si veda: https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL. 26 Per informazioni si veda l’Appendice A. 27 Disponibile al link: http://git.io/G0Ix1Q.
66
Capitolo 4 Sistema per la Sentiment Analysis
Sfortunatamente, dopo un’attenta analisi, si è visto che solo una percentuale
molto bassa (circa il 2%) dei dati provenienti da Twitter contenessero
informazioni geografiche, molto probabilmente dovuto al fatto che gli utenti non
hanno espressamente attivato tale funzionalità nelle impostazioni
dell’applicazione. Il campo location28 invece è presente nella maggior parte dei
tweet, ma necessita di essere opportunamente interpretato, trattandosi appunto
di una stringa definita dall’utente in modo arbitrario.
Inoltre, in riferimento alla tabella creata, essa è di tipo EXTERNAL. In tal modo è possibile
specificare, tramite la clausola LOCATION, una locazione alternativa dove risiedono i dati
della tabella, in accordo con il percorso di salvataggio impostato attraverso Flume, di
modo che non sia necessario un inutile e pesante spostamento dei dati.
La clausola PARTITIONED BY permette di definire le colonne che sono chiavi di
partizionamento, permettendo alla tabella di essere splittata in directory differenti. Nel
sistema sviluppato l’organizzazione delle directory è basata sulla data o l’ora. In tal
modo, quando si eseguono delle query dipendenti da un intervallo temporale, le
directory non comprese in tale intervallo non saranno considerate da Hive, con
conseguente notevole aumento delle performance.
Infine, attraverso la clausola ROW FORMAT si è dichiarato il formato personalizzato dei
dati, specificando l’interfaccia SerDe utilizzata.
4.4.2 Determinazione del Sentiment A questo punto è possibile eseguire lo script per la determinazione del sentiment, sulla
input_table creata. Lo script esegue essenzialmente una serie di step, alcuni dei quali:
1. Filtraggio dei tweet. I tweet sono estratti sulla base del campo lang, estrapolando
solo quelli in lingua italiana.
2. Pulizia del testo. Viene effettuata la pulizia del testo per ogni tweet, mediante una
funzione UDF personalizzata.
3. Conversione del fuso orario. Ogni tweet presenta un orario in UTC29, che sarà
convertito in CEST30, per poter ottenere un’accurata analisi temporale.
28 Si è presentato un problema nello specificare il campo location, dato che location è una parola chiave di Hive, utilizzata come clausola nella definizione di una tabella esterna. Il problema è stato risolto inserendo i campi tra apice inverso (o backtick).
29 Si veda: http://it.wikipedia.org/wiki/Tempo_coordinato_universale. 30 Si veda: http://it.wikipedia.org/wiki/Central_European_Summer_Time.
67
Capitolo 4 Sistema per la Sentiment Analysis
4. Classificazione lexicon-based. Si assegna un punteggio di sentiment secondo la
metodologia lexicon-based.
5. Classificazione con tecnica supervised learning. Si assegna un punteggio di
sentiment mediante un algoritmo di supervised learning. Nello specifico si è
utilizzato l’algoritmo Multinomial Naïve Bayes.
6. Estrazione delle coordinate geografiche. Mediante la decodifica del campo
location, si ottengono le coordinate geografiche riferite all’utente che ha postato
il tweet, in modo da ottenere un’analisi geolocalizzata.
7. Calcolo della polarità finale. Si calcola la polarità finale, sulla base dei due punteggi
di sentiment ottenuti nelle precedenti classificazioni.
8. Caricamento dei dati nella output_table. I risultati ottenuti saranno caricati in una
tabella finale, su cui si possono condurre le analisi finali.
Alcuni dei passi esposti richiedono maggiori approfondimenti che saranno effettuati
nei prossimi sottoparagrafi.
4.4.2.1 Pulizia del Testo Per ottenere una classificazione più efficace dal punto di vista dell’accuratezza, e più
efficiente dal punto di vista delle prestazioni, è fondamentale effettuare una pulizia del
testo del tweet. Allo scopo è stata creata una specifica funzione UDF in Java,
successivamente importata in Hive, che svolge una serie di operazioni, quali:
Rimozione carattere ‘a capo’, link URL, hashtag (parole che iniziano con il
carattere ‘#’), riferimenti ad utenti (parole che iniziano con il carattere ‘@’);
Rilevazione e sostituzione delle emoticon. Molte volte un emoticon può
comunicare sentiment più di mille parole, per cui si è scelto di sostituire le
emoticon positive con il termine “emopos” (emoticon positiva), e quelle negative
con il termine “emoneg” (emoticon negativa). In questo modo, aggiungendo i
due termini nel dizionario, è possibile ottenere una migliore accuratezza con
l’approccio lexicon-based.
Conversione del testo in minuscolo.
Rimozione di tutti i caratteri che non siano lettere. In questa fase saranno
eliminati tutti i caratteri non utili ai fini della classificazione.
Rimozione di tutte le parole costituite da meno di tre lettere. In questo modo si
eliminano parole non utili ai fini della classificazione.
68
Capitolo 4 Sistema per la Sentiment Analysis
Rimozione delle stopword 31 . Le stopword rappresentano le parole che non
influiscono nella determinazione del sentiment, come articoli, preposizioni,
congiunzioni. Tali parole appesantirebbero inutilmente il lavoro svolto dal
classificatore.
Rimozione di tutti gli spazi ripetuti più volte.
Rimozione di tutte le lettere ripetute più di due volte. Alcuni utenti sono inclini
all’estensione delle parole attraverso la ripetizione dei caratteri, ad esempio
scrivendo “bellooooo” invece di “bello”. Questo fenomeno è molto diffuso su
Twitter 32 , e molto probabilmente è utilizzato per intensificare il sentimento
espresso, per cui si rende necessario correggere tali parole. Questo è stato
realizzato mediante un’apposita regex 33 , in combinazione con il metodo
replaceAll() di Java, che sostanzialmente sostituisce una sequenza di tre o più
caratteri uguali e consecutivi con una sola occorrenza dello stesso carattere.
Effettuata la pulizia del testo, si può procedere alla fase di classificazione del sentiment.
4.4.2.2 Classificazione lexicon-based Il primo approccio utilizzato per la determinazione del sentiment è il cosiddetto
lexicon-based. Tale metodo è piuttosto semplicistico e si basa sostanzialmente su un
vocabolario dei termini positivi e negativi, costituito da singole parole manualmente
catalogate e classificate. Il metodo, in combinazione con il classificatore automatico,
permette di aumentare l’accuratezza finale.
Allo scopo è stato creato un vocabolario con circa 2300 termini più comuni, dividendoli
semplicemente tra positivi e negativi. In seguito, si è deciso di classificare i termini in
un intervallo più ampio, compreso tra -2 e +2, dove il limite inferiore corrisponde al
termine più negativo e il limite superiore al termine più positivo. Si è presa questa
decisione essenzialmente perché così si è potuto assegnare:
Un punteggio maggiore agli aggettivi di grado superlativo assoluto
(es. “bellissimo”), a cui si è assegnato un punteggio di +2 o -2, rispetto allo stesso
31 In generale, le stopword sono quelle parole che, per la loro alta frequenza in una lingua, sono di solito ritenute poco significative dai motori di ricerca, che le ignorano. Un esempio di stopword italiane è possibile trovarlo al link: http://www.ranks.nl/stopwords/italian.
32 Come riportato da Brody e Diakopoulos nel documento citato nella sezione Bibliografia & Sitografia. 33 Una regex (regular expression) è una sequenza di simboli (quindi una stringa) che identifica un
insieme di stringhe. Permette di definire una funzione che prende in ingresso una stringa, e restituisce in uscita un valore booleano, a seconda che la stringa segua o meno un certo pattern.
69
Capitolo 4 Sistema per la Sentiment Analysis
aggettivo di grado positivo (es. “bello”), a cui invece è stato assegnato un
punteggio di +1 o -1 a seconda della polarità.
Un punteggio superiore, in valore assoluto, a parole che esprimono un sentimento
più accentuato, in relazione al dominio di riferimento. Per esempio, ad una parola
come “monumentale” si è assegnato un punteggio di +2, in quanto è molto
utilizzata nel gergo calcistico per indicare una prestazione molto positiva di un
calciatore. Inoltre, lo stesso discorso vale anche per altre parole non strettamente
legate al dominio, ma che esprimono comunque un sentimento più marcato
rispetto ad altre, come per esempio “perfetto”.
Un punteggio superiore, in valore assoluto, alle parole “emopos” e “emoneg”,
data la notevole rilevanza delle emoticon in relazione al sentiment.
In tal modo si è registrato un aumento del 2% sull’accuratezza complessiva34, rispetto
all’utilizzo dello stesso vocabolario suddiviso in soli termini positivi e negativi.
Il vocabolario, una volta creato in formato TSV 35 , è stato importato in HDFS e
successivamente è stata creata una tabella Hive EXTERNAL, in modo tale da mappare i
dati del file, nella sua locazione predefinita, senza richiederne lo spostamento.
Successivamente, tramite delle funzioni predefinite di Hive si è assegnato un punteggio
ad ogni parola del testo presente nel vocabolario. In questo caso si è attuato una sorta
di stemming36 semplificato: si sono confrontate le parole, del testo del tweet e del
vocabolario, senza considerare l’ultimo carattere, in modo tale da evitare di inserire nel
vocabolario la stessa parola nei diversi generi (maschile e femminile) e nelle diverse
declinazioni (singolare e plurale). Per esempio, nel vocabolario è stato inserito “bello”,
evitando di inserire anche “bella”, “belli”, “belle”. Infine, si è calcolato un punteggio
totale sommando i punteggi delle singole parole del testo.
4.4.2.3 Classificazione con tecnica supervised learning Per aumentare l’accuratezza complessiva del sistema si rende necessario lo sviluppo di
un algoritmo di classificazione basato sulla tecnica supervised learning. Per cui, si
addestra un classificatore del sentiment per determinare sentimenti positivi, negativi e
34 Tale dato è emerso considerando un campione di 1000 tweet casuali. Per maggiori informazioni sull’accuratezza complessiva si veda il Paragrafo 4.6.
35 In un file in formato TSV (Tab Separated Values File Type) ogni campo di una riga è delimitato dal carattere TAB (detto di tabulazione). Esso rappresenta il formato di default di Hive.
36 Lo stemming è il processo di riduzione della forma flessa di una parola alla sua forma radice, detta tema. Il tema non corrisponde necessariamente alla radice morfologica della parola: normalmente è sufficiente che le parole correlate siano mappate allo stesso tema (ad esempio, che andare, andai, andò mappino al tema and), anche se quest'ultimo non è una valida radice per la parola.
70
Capitolo 4 Sistema per la Sentiment Analysis
neutrali. Il metodo in questione è molto utilizzato per la classificazione del sentiment
a livello di documenti o frasi. Esso richiede una classificazione manuale preliminare
nella realizzazione del training set, per cui è molto dipendente dal dominio ma assicura
un notevole grado di accuratezza.
L’approccio basato su machine learning tipicamente addestra il classificatore
utilizzando unigrammi, bigrammi o trigrammi 37 di parole. La maggior parte delle
tecniche di classificazione sviluppate utilizza algoritmi di machine learning, quali il
Naïve Bayes38, Maximum Entropy39 e Support Vector Machines40. È stato dimostrato
(Obstat 2013) che, su unigrammi di parole, gli algoritmi Naïve Bayes e Support Vector
Machine presentano un’accuratezza simile e sono più accurati rispetto agli altri.
Nel sistema sviluppato si è scelto di utilizzare l’algoritmo Naïve Bayes su unigrammi
di parole, utilizzando la libreria weka41. Questa scelta è anche dovuta al fatto che il
training del modello è molto più semplice rispetto ad altri algoritmi, richiedendo una
più piccola quantità di dati per la classificazione, data l’assunzione di indipendenza
degli attributi. Per cui, risulta anche più efficiente.
È stata creata una funzione UDF Hive che implementa una versione dell’algoritmo
Naïve Bayes più adatta allo scopo, ossia il Multinomial Updateable Naïve Bayes (del
package weka.classifiers.bayes.NaiveBayesMultinomialUpdateable). Questo
algoritmo tiene in conto la frequenza di apparizione del termine all’interno dei
documenti (detta term frequency), a differenza del classico Naïve Bayes. È stato
dimostrato (Go, Bhayani e Huang 2009) che il Multinomial Naïve Bayes presenta una
maggiore accuratezza nella classificazione dei tweet su unigrammi di parole, rispetto
ad altri algoritmi quali Support Vector Machine e Maximun Entropy. Inoltre,
l’algoritmo utilizzato implementa l’interfaccia UpdateableClassifier, il che implica
un training incrementale, ossia il classificatore può essere riaddestrato usando nuovi
dati, invece di riutilizzare anche i dati già utilizzati precedentemente; questo è una
funzionalità utile, in quanto, in presenza di un training set molto vasto, il processo di
addestramento potrebbe risultare molto oneroso.
37 Un n-gramma è una sottosequenza di n elementi di una data sequenza. Un n-gramma di lunghezza 1 è detto “unigramma”, di lunghezza 2 “bigramma”, di lunghezza 3 “trigramma” e, da lunghezza 4 in poi, “n-gramma”. Per approfondimenti si veda: http://en.wikipedia.org/wiki/N-gram.
38 Si veda l’Appendice B per approfondimenti. 39 Per approfondimenti si veda: http://en.wikipedia.org/wiki/Maximum_entropy_classifier. 40 Per approfondimenti si veda: http://en.wikipedia.org/wiki/Support_vector_machine. 41 Weka offre un raccolta di algoritmi di machine learning per il data mining, scritti in Java. Gli algoritmi
possono sia essere applicati direttamente ad un dataset sia essere richiamati in un proprio codice Java. Il sito ufficiale è disponibile al link: http://www.cs.waikato.ac.nz/ml/weka/.
71
Capitolo 4 Sistema per la Sentiment Analysis
Il Naïve Bayes inoltre permette di definire un valore di soglia, compreso tra 0 e 1, che
definisce la probabilità che un certo tweet appartenga ad una determinata classe. Dopo
alcune verifiche sperimentali si è deciso di impostare un valore di soglia pari a 0,70.
Ciò significa che il tweet potrà essere classificato come appartenente ad una certa
classe, solo nel caso in cui la probabilità calcolata dal classificatore in relazione a tale
classe sia maggiore del 70%. Questo implica che se la percentuale sarà più bassa per
ognuna delle tre classi, il tweet sarà definito come “non classificabile”. La
combinazione dell’approccio lexicon-based permetterà in seguito di correggere tale
classificazione, nel caso sia sbagliata.
Per questi motivi si è deciso che in questa fase di classificazione, le classi siano tre:
+1: Rappresenta la classe dei tweet con sentiment positivo.
-1. Rappresenta la classe dei tweet con sentiment negativo.
0. Rappresenta la classe dei tweet con sentiment neutrale oppure non
classificabile.
Per quanto riguarda il training set, si è creato un file costituito da circa 480 tweet
manualmente classificati e ugualmente distribuiti nelle tre classi suddette (in tal caso,
ovviamente, la classe 0 rappresenta solo i tweet con sentiment neutrale), che poi è stato
importato in HDFS per addestrare il classificatore. Quest’ultimo, una volta definito in
Hive, determina per ogni tweet il relativo punteggio di sentiment, sulla base delle
considerazioni precedenti.
4.4.2.4 Estrazione delle coordinate geografiche Per poter effettuare una Sentiment Analysis geolocalizzata è necessario estrarre delle
informazioni geografiche da ogni tweet. Il campo coordinates del tweet in tal caso non
può essere d’aiuto, data la bassissima percentuale di un valore diverso da null. Per
questo motivo si è deciso di utilizzare il campo location.
Il campo location, però, è una stringa definita dall’utente. Questo significa che
l’utente potrebbe inserirvi qualsiasi cosa e in qualsiasi modo. È stato visto, infatti, che
il campo risulta essere compilato circa nel 64% dei tweet analizzati, ma si è potuta
estrarre un’informazione valida solo dal 32% circa di tali campi. Ciò è dovuto al fatto
che molte volte l’utente preferisce inserire una città straniera, oppure scrive
semplicemente “Italia” o magari delle parole o brevi frasi che c’entrano ben poco con
la funzione del campo. Negli altri casi, invece, la città è presente in vari modi, e deve
72
Capitolo 4 Sistema per la Sentiment Analysis
essere opportunamente interpretata; ad esempio “bologna bo”, “B A R I”, “#roma”,
“Torino - TO”, “Genova (Italia)”, “Trani (BA) - Puglia”, ecc.
Per decodificare questo campo sono state create delle apposite regex che in
combinazione con le UDF predefinite di Hive, quali regexp_extract() e
regexp_replace(), permettono di estrapolarne la città.
È stato creato, inoltre, un file TSV contenente le informazioni su tutti i comuni italiani,
e anche i nomi delle città più importanti in lingua inglese, perché è risultato che alcuni
utenti usassero tale notazione. I campi di questo file sono: città, latitudine, longitudine,
provincia, regione. Successivamente il file è stato importato in HDFS per creare una
tabella Hive EXTERNAL. Con la combinazione della tabella creata e delle funzioni UDF
è stato possibile ricavare le informazioni geografiche relative ad ogni tweet nel cui
campo location fosse presente un riferimento ad una città italiana.
4.4.2.5 Calcolo della polarità finale L’ultima fase della classificazione prevede la combinazione dei risultati ottenuti dalle
due precedenti classificazioni, lexicon-based e supervised learning, secondo il seguente
algoritmo presentato in pseudocodice:
// dsent: valore prodotto dalla classificazione lexicon-based // csent: valore prodotto dalla classificazione supervised learning // polarity: polarità finale
IF |dsent| <= 1 THEN polarity = csent ELSE IF dsent = -2 AND csent >= 0 THEN polarity = csent – 1 ELSE IF dsent = 2 AND csent <= 0 THEN polarity = csent + 1 ELSE IF |dsent| >= 3 THEN polarity = dsent / |dsent| ELSE polarity = csent
In questo modo si calcola un valore finale (polarity), compreso tra -1 e +1, a
rappresentare le tre classi negativa, neutrale e positiva.
In sostanza, si attribuisce maggiore rilevanza al risultato prodotto dall’approccio
supervised learning nel caso in cui il risultato prodotto dall’approccio lexicon-based
sia molto basso (minore o uguale a 1). Invece, man mano che il risultato prodotto
dall’approccio lexicon-based assume un valore più alto in valore assoluto, gli si
attribuisce un peso maggiore rispetto al risultato prodotto dal classificatore
Multinomial Naïve Bayes.
73
Capitolo 4 Sistema per la Sentiment Analysis
4.4.3 Tabella di output In seguito all’esecuzione dello script Hive che esegue i compiti esposti nei precedenti
paragrafi, i risultati ottenuti saranno caricati nella tabella finale (output_table), sulla
quale poter effettuare le successive analisi.
Per l’esposizione grafica dei risultati finali si è scelto di utilizzare Pentaho42. Pentaho
offre un’integrazione completa con Hadoop e le relative componenti, tra cui Hive,
permettendo di effettuare delle query su una particolare tabella di Hive, attraverso una
connessione JDBC, per poi creare i relativi report. Tutto ciò permette di conservare la
scalabilità del sistema, eliminando la necessità di uno spostamento dei dati.
4.5 Automatizzazione del Sistema I tweet sono scaricati in HDFS e successivamente importati in una tabella EXTERNAL
Hive, che permette di interrogare i dati senza la necessità di spostarli dalla loro
locazione su HDFS. Per assicurare scalabilità, e aggiungere sempre nuovi dati, diventa
necessario partizionare la tabella. Una tabella partizionata, infatti, permette di ridurre
il numero dei file letti in seguito ad una query, il che si traduce in prestazioni migliori
quando si tratta di operare su grandi quantità di dati. Tuttavia, i tweet arrivano in
streaming dalle Twitter API passando per Flume, che crea regolarmente nuovi file.
Tramite Oozie è stato possibile automatizzare il processo di aggiunta di nuove
partizioni alla input_table man mano che arrivano i dati. Si è configurato il workflow
per eseguire, ad intervalli orari, uno script che sostanzialmente esegue un comando
ALTER TABLE che permette di aggiungere nella input_table una partizione che
contiene i dati dell’ultima ora, in modo tale da avere a disposizione i dati sempre
aggiornati. Nella definizione del comando ALTER TABLE sono state incluse alcune
variabili, quali $(DATEHOUR) e $(PARTITION_PATH) che saranno sostituite da Oozie con
i valori effettivi a tempo di esecuzione.
Per eseguire un job in modo ricorrente, è necessario implementare un workflow Oozie
da eseguire. Si realizza a tale scopo un XML rappresentante un grafo aciclico diretto,
definendo nodi di controllo e nodi di azione. In esso, inoltre, si specifica la locazione
in HDFS dello script Hive che definisce il comando ALTER TABLE, e la dichiarazione
delle variabili che poi saranno passate a tale script.
42 Per informazioni su Pentaho si veda l’Appendice C.
74
Capitolo 4 Sistema per la Sentiment Analysis
Per permettere l’esecuzione periodica del workflow è necessario implementare il
Coordinator. Esso è stato configurato in modo tale da eseguire il workflow ogni ora.
Inoltre, si è specificata la locazione dell’insieme di dati di input, ossia il path su HDFS
dove risiedono i tweet. Questo path sarà aggiornato ogni ora, ogni volta che Flume
crea una nuova directory, e ciò è regolato da un’apposita funzione predefinita di Oozie
(${coord:hours(1)}) che definisce un intervallo temporale. L’evento che genera
l’esecuzione del workflow è rappresentato dal fatto che Flume abbia creato una nuova
directory, per cui quella precedente può essere importata in Hive. Questo è realizzato
tramite delle apposite funzioni predefinite di Oozie che sostanzialmente fanno in modo
che l’azione del Coordinator non sarà effettuata sulla directory attuale, fin quando non
sarà presente una nuova directory (successiva a quella corrente).
L’ulteriore processo di automatizzazione implementato coinvolge l’esecuzione dello
script Hive che implementa tutte le operazioni viste nei precedenti paragrafi. Anche in
questo caso si è creato un script con la variabile rappresentata da $(DATEHOUR), in
modo tale che il workflow sia eseguito da una certa partizione di dati in poi. Il
Coordinator, in questo caso, è stato creato in modo da eseguire lo script una volta al
giorno, dato che non vi è nel caso in esame la necessità di analizzare i dati in real-time.
Tale intervallo può essere facilmente riconfigurato nel caso in cui si presenti tale
necessità. In definitiva, lo script che effettua la Sentiment Analysis è eseguito ogni 24
ore, sull’intervallo di dati rappresentato dalle ultime 24 partizioni.
4.6 Accuratezza del Sistema Le performance di un modello sono determinate dal numero di predizioni
(classificazioni automatiche) corrette o, per contro, dal numero di errori di predizione.
Una delle modalità per la valutazione è rappresentata dalla cosiddetta matrice di
confusione, anche detta matrice di classificazione, il cui generico valore Eij rappresenta
il numero di elementi della classe i-esima che il modello assegna alla classe j-esima.
Per la valutazione del sistema si è considerato un test set, costituito da un campione di
1000 tweet casuali, diversi dal training set. L’output del modello è stato poi
confrontato con i dati reali, ricavati da un’ispezione manuale. In tal modo si è costruita
la matrice di confusione, riportata nella Tabella 4.2.
La diagonale principale indica il numero di istanze delle varie classi correttamente
classificate. Al di fuori della diagonale, in ogni riga della matrice corrispondente ad una
75
Capitolo 4 Sistema per la Sentiment Analysis
determinata classe, viene riportata la “confusione” del classificatore, ovvero il numero
dei tweet della classe assegnati erroneamente alle altre classi.
Tabella 4.2 – Matrice di Confusione del sistema
Classificazione predetta
Classi -1 0 +1 Totale
Classificazione reale
-1 89 64 10 163
0 10 665 17 692
+1 4 54 87 145
Totale 103 783 114 1000
Dalla matrice si può procedere al calcolo degli indici di performance:
L’accuratezza è la proporzione del numero totale dei tweet classificati
correttamente, rispetto al numero totale dei tweet considerati.
𝐴𝐴𝐴𝐴𝐴𝐴𝑝𝑝𝐴𝐴𝑎𝑎𝑡𝑡𝑒𝑒𝐴𝐴𝐴𝐴𝑎𝑎𝑔𝑔𝑖𝑖𝑔𝑔𝑔𝑔𝑔𝑔𝑖𝑖𝑔𝑔 % =89 + 665 + 87
1000∗ 100 = 84,10%
La precisione è la proporzione dei tweet classificati correttamente, rispetto al
totale delle predizioni, in relazione ad ogni classe.
𝑃𝑃𝐴𝐴𝑒𝑒𝐴𝐴𝑝𝑝𝑠𝑠𝑝𝑝𝑜𝑜𝑝𝑝𝑒𝑒−1 % =89
103∗ 100 = 86,41%
𝑃𝑃𝐴𝐴𝑒𝑒𝐴𝐴𝑝𝑝𝑠𝑠𝑝𝑝𝑜𝑜𝑝𝑝𝑒𝑒 0 % =665783
∗ 100 = 84,93%
𝑃𝑃𝐴𝐴𝑒𝑒𝐴𝐴𝑝𝑝𝑠𝑠𝑝𝑝𝑜𝑜𝑝𝑝𝑒𝑒+1 % =87
114∗ 100 = 76,32%
Il recall è la proporzione dei tweet correttamente classificati rispetto al numero
totale dei dati reali, in relazione ad ogni classe.
𝑅𝑅𝑒𝑒𝐴𝐴𝑎𝑎𝑅𝑅𝑅𝑅−1 % =89
163∗ 100 = 54,60%
𝑅𝑅𝑒𝑒𝐴𝐴𝑎𝑎𝑅𝑅𝑅𝑅 0 % =665692
∗ 100 = 96,10%
𝑅𝑅𝑒𝑒𝐴𝐴𝑎𝑎𝑅𝑅𝑅𝑅+1 % =87
145∗ 100 = 60,00%
In sostanza, il sistema presenta un buon valore di accuratezza globale, in linea con la
media attuale dei sistemi di sentiment analysis, considerando il fatto che non sono state
utilizzate tutte le tecniche relative all’approccio lexicon-based.
76
Capitolo 4 Sistema per la Sentiment Analysis
Per quanto riguarda la precisione, è possibile vedere che per quanto riguarda le classi -1
e 0 i valori sono abbastanza accettabili. In questi casi, infatti, abbiamo che il sistema
prevede correttamente i tweet negativi nel 86,41% dei casi, e quelli neutri nel 84,93%
dei casi. Tuttavia, una precisione più bassa si denota nella previsione dei tweet positivi,
in quanto nel 23,68% dei casi si ha un errore.
Per quanto riguarda il recall, si notano chiaramente dei valori piuttosto bassi, riferiti
alle classi -1 e +1. Questo è strettamente legato alle difficoltà intrinseche della
sentiment analysis, dovute principalmente all’utilizzo di metafore, ironia, sarcasmo e
paragoni, come si può evincere da alcune frasi estratte dal dataset analizzato, quali:
Prandelli, tesoro bello, illuminami. Cosa ci fa Chiellini in campo come terzino,
me lo spieghi?
Cerci ai Mondiali e Totti a Roma… Normale che perdiamo.
Ottimo Balotelli come punto di riferimento per l'attacco. Tipo cipresso in un
camposanto.
Cassano utile come un chiosco di porchetta davanti alla Mecca.
Ispezionando una porzione del dataset si è visto come frasi del genere, che rendono la
classificazione decisamente complessa, siano molto frequenti in Twitter. In ogni caso,
è possibile migliorare i valori relativi al recall aumentando la grandezza del training set
e ampliando il dizionario dei termini, includendo tra le sentiment word anche modi di
dire, sintagmi ed espressioni ricorrenti (ciò richiederebbe una revisione dello script,
che attualmente esegue la classificazione lexicon-based considerando singoli termini).
4.7 Analisi dei risultati Molto importante per la Sentiment Analysis è la fase di rappresentazione dei risultati.
In tal modo, infatti, è possibile sintetizzare e ottenere una visione del pensiero degli
utenti in riferimento al soggetto su cui è stata effettuata l’analisi.
Il sistema sviluppato è stato utilizzato per analizzare il pensiero espresso dagli utenti di
Twitter in riferimento alla Nazionale di Calcio Italiana impegnata nei Mondiali in
Brasile del 2014, considerando un intervallo temporale che va dal 11 Giugno 2014 al
26 Giugno 2014. Sono stati acquisiti 5.911.525 tweet per un totale di 21,73 GB di
spazio occupato su HDFS. In seguito alla fase di filtraggio, che ha coinvolto
l’eliminazione di repliche e la selezione dei tweet in italiano, i dati utili all’analisi erano
costituiti da un totale di 1.203.091 tweet. Infine, nella output_table si è deciso di non
77
Capitolo 4 Sistema per la Sentiment Analysis
riportare i tweet neutri, poiché considerati non utili per la generazione dei report, oltre
al fatto che costituiscono la maggioranza dei dati e che quindi creano un ingombro
evitabile sul file system. Questo è possibile vederlo chiaramente dalla Figura 4.3 che
mostra la distribuzione della polarità dei tweet classificati.
Figura 4.3 – Distribuzione percentuale delle polarità
Come è possibile vedere dalla Figura 4.3, una percentuale molto alta dei tweet è stata
classificata come appartenente alla classe neutra. Questo è dovuto al fatto che su
Twitter sono presenti sostanzialmente tutti i siti di news che aggiornano
frequentemente gli utenti, che a loro volta retwittano i messaggi, riguardanti tutte le
ultime notizie sulle formazioni, strategie, conferenze stampa, ecc. Per di più, il campo
lang di twitter identifica il linguaggio del testo attraverso una procedura automatica,
che ha un accuratezza pari al 82% circa 43, per cui una percentuale relativamente
alta (18%) dei tweet sarà in lingua diversa dall’italiano, risultando non classificabile
per il sistema sviluppato.
4.7.1 Intervalli temporali Affinché si possa avere una visione dell’oscillazione del sentiment è fondamentale
realizzare dei grafici che mostrino la relativa evoluzione su sequenze temporali. Si è
scelto di rappresentare tali grafici al netto dei tweet neutri, su una scala percentuale,
secondo la seguente formula:
�#𝑡𝑡𝑠𝑠𝑒𝑒𝑒𝑒𝑡𝑡 𝑝𝑝𝑜𝑜𝑠𝑠𝑝𝑝𝑡𝑡𝑝𝑝𝑝𝑝𝑝𝑝
#𝑡𝑡𝑠𝑠𝑒𝑒𝑒𝑒𝑡𝑡 𝑝𝑝𝑜𝑜𝑠𝑠𝑝𝑝𝑡𝑡𝑝𝑝𝑝𝑝𝑝𝑝 + #𝑡𝑡𝑠𝑠𝑒𝑒𝑒𝑒𝑡𝑡 𝑝𝑝𝑒𝑒𝑝𝑝𝑎𝑎𝑡𝑡𝑝𝑝𝑝𝑝𝑝𝑝�𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺 𝐵𝐵𝐵𝐵 (𝐼𝐼𝑛𝑛𝐼𝐼𝑔𝑔𝐼𝐼𝐼𝐼𝑔𝑔𝑖𝑖𝑖𝑖𝑔𝑔 𝑇𝑇𝑔𝑔𝑚𝑚𝑇𝑇𝑔𝑔𝐼𝐼𝑔𝑔𝑖𝑖𝑔𝑔)
43 Il dato, presentato da http://matpalm.com/blog/2011/10/03/mislabelled-training-data/, è riferito alla lingua inglese.
11,25%9,66%
79,08%
Tweet Positivi
Tweet Negativi
Tweet Neutri
78
Capitolo 4 Sistema per la Sentiment Analysis
4.7.1.1 Andamento giornaliero Il primo grafico, riportato in Figura 4.4, riporta l’andamento del sentiment sulla base
di intervalli temporali di 24 ore, per un periodo complessivo di 16 giorni. Sono state
aggiunte le icone relative alle tre partite disputate dall’Italia, in modo da avere una
visione più chiara e immediata del cambiamento del sentiment.
Figura 4.4 – Trend del sentiment su intervallo temporale di 24 ore
Nella tabella 4.3 si riportano le date e gli orari di inizio delle tre partite, e anche i minuti
in cui sono stati segnati i goal.
Tabella 4.3 – Dati relativi alle tre partite dell'Italia nel Mondiale 2014
Partita Data & Orario di inizio Risultato Reti segnate
Inghilterra – Italia 15 Giugno 2014 – 00:00 1 – 2 Marchisio 35’, Sturridge 37’, Balotelli 50’
Italia – Costa Rica 20 Giugno 2014 – 18:00 0 – 1 Ruiz 44’
Italia – Uruguay 24 Giugno 2014 – 18:00 0 – 1 Godin 81’
Come si può vedere dalla Figura 4.4, il sentiment è generalmente positivo nel periodo
antecedente la seconda partita. Si riscontrano un po’ di critiche dal 11 al 13 Giugno,
soprattutto riguardanti le scelte di Prandelli in relazione ai convocati, per esempio per
non aver portato Giuseppe Rossi, e anche riguardanti la scelta di far giocare Balotelli
solo in attacco, piuttosto che in tandem con Immobile. Nonostante tutto ciò, il giorno
0
10
20
30
40
50
60
70
80
90
100
79
Capitolo 4 Sistema per la Sentiment Analysis
della prima partita (il 14 Giugno, dato che la partita è stata giocata il 15 Giugno alle
00:00) si registra il picco massimo di sentiment positivo durante l’intero periodo
analizzato. Nei giorni seguenti il sentiment rimane sostanzialmente positivo, in virtù
del risultato raggiunto, ma si registra ancora dello scetticismo soprattutto in relazione
alle prestazioni di alcuni giocatori (ad esempio Chiellini o Paletta), ad alcune scelte di
Prandelli non condivise (ad esempio, posizionare Chiellini sulla fascia) oppure ad un
secondo tempo dell’Italia non troppo esaltante, nonostante la vittoria.
Per quanto riguarda la seconda partita, è evidente come la sconfitta determini un picco
negativo della curva fino al 21 Giugno. Successivamente si hanno due giorni (22 e 23
Giugno) in cui il sentiment ritorna essenzialmente positivo, perché si pensa che l’Italia
possa ancora superare il turno battendo l’Uruguay o comunque pareggiando. Però il
24 Giugno l’Italia gioca la sua terza partita, la perde e viene eliminata dai Mondiali e
di conseguenza il sentiment registrato è molto negativo e le pesanti critiche (e anche
gli insulti) riguardano sia i giocatori che l’allenatore.
4.7.1.2 Andamento orario Ulteriori report sono stati creati in relazione alle singole partite, con unità di tempo
rappresentate dalla singola ora. In questo modo si analizza l’evoluzione del sentiment
nelle ore adiacenti la singola partita, in un periodo complessivo di 16 ore.
La Figura 4.5 mostra l’andamento del sentiment in relazione alla prima partita.
Figura 4.5 – Trend del sentiment su scala oraria in relazione alla prima partita.
0
10
20
30
40
50
60
70
80
90
100
80
Capitolo 4 Sistema per la Sentiment Analysis
Come si può vedere dalla Figura 4.5, il sentiment è molto positivo nelle ore antecedenti
la prima partita, con picchi molto alti. Il picco più basso si ha nel primo tempo della
partita ed è dovuto essenzialmente alle scelte dell’allenatore riguardanti la formazione
titolare. Al termine del primo tempo, si registra un aumento di positività, ma c’è ancora
scetticismo, dovuto essenzialmente al fatto che, subito dopo il goal dell’Italia,
l’Inghilterra abbia subito pareggiato, stroncando l’entusiasmo italiano solo dopo 2
minuti. Successivamente però l’Italia vince, e nelle ore successive alla partita si registra
un sentiment molto positivo, con un picco massimo registrato dalle ore 5:00 alle 6:00.
La Figura 4.6 mostra l’andamento del sentiment in relazione alla seconda partita.
Figura 4.6 – Trend del sentiment su scala oraria in relazione alla seconda partita.
Come si evince dalla Figura 4.6, c’è molto ottimismo prima della partita, che si traduce
in sentiment molto positivo. Tale positività viene stroncata già nel primo tempo, in
quanto l’Italia non gioca bene e subisce il goal. Nel secondo tempo il risultato non
cambia, per cui il sentiment positivo continua a diminuire, per poi raggiungere il picco
minimo subito dopo la partita e successivamente continuare su questa striscia
fortemente negativa.
La Figura 4.7 mostra l’andamento del sentiment in relazione alla terza partita. Anche
in questo caso si nota positività prima della partita, dovuta al fatto che la formazione
in campo coincide con quello che la maggior parte degli utenti avrebbe voluto già in
precedenza, e oltre a ciò, all’Italia basterebbe un pareggio per passare il turno. Anche
in questo caso, però, l’Italia non gioca bene e, nel secondo tempo, trova la sconfitta e
0
10
20
30
40
50
60
70
80
90
100
81
Capitolo 4 Sistema per la Sentiment Analysis
l’eliminazione dal Mondiale. Subito dopo la partita si registra il picco minimo di
positività, e nelle ore successive il trend continua su questa striscia decisamente
negativa. I tweet positivi successivi alla partita (seppure in percentuale molto minima)
riguardano soprattutto il fatto che l’allenatore Prandelli si sia dimesso.
Figura 4.7 – Trend del sentiment su scala oraria in relazione alla terza partita.
4.7.2 Geolocalizzazione del sentiment Estrapolando la città da ogni tweet, attraverso la quale si ricavano le relative coordinate
geografiche e altre informazioni, quali provincia e regione, è possibile realizzare dei
report che rappresentino il sentiment in riferimento ad una qualsiasi area geografica,
come comune, provincia o regione. La Figura 4.8 riporta la percentuale di tweet
positivi, rispetto ai tweet totali, al netto dei tweet neutri, in relazione ad ogni regione,
secondo la seguente formula:
�#𝑡𝑡𝑠𝑠𝑒𝑒𝑒𝑒𝑡𝑡 𝑝𝑝𝑜𝑜𝑠𝑠𝑝𝑝𝑡𝑡𝑝𝑝𝑝𝑝𝑝𝑝
#𝑡𝑡𝑠𝑠𝑒𝑒𝑒𝑒𝑡𝑡 𝑝𝑝𝑜𝑜𝑠𝑠𝑝𝑝𝑡𝑡𝑝𝑝𝑝𝑝𝑝𝑝 + #𝑡𝑡𝑠𝑠𝑒𝑒𝑒𝑒𝑡𝑡 𝑝𝑝𝑒𝑒𝑝𝑝𝑎𝑎𝑡𝑡𝑝𝑝𝑝𝑝𝑝𝑝�𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺 𝐵𝐵𝐵𝐵 (𝐺𝐺𝑔𝑔𝑔𝑔𝑖𝑖𝑔𝑔𝑛𝑛𝑔𝑔)
La regione più positiva è la Puglia, che durante tutto l’arco temporale considerato
risulta essere quindi la più ottimista e fiduciosa. A seguire, la Calabria e la Campania.
La regione meno positiva (o più negativa), invece, risulta essere il Friuli-Venezia Giulia,
le cui critiche riguardano soprattutto le prestazioni di Chiellini, Insigne e Cassano.
Seguono il Lazio e la Liguria.
0
10
20
30
40
50
60
70
80
90
100
82
Capitolo 4 Sistema per la Sentiment Analysis
Figura 4.8 – Distribuzione dei tweet positivi per ogni regione.
83
Capitolo 5 Conclusioni e sviluppi futuri
Conclusioni e sviluppi futuri
“Il futuro appartiene a coloro che credono nella bellezza dei propri sogni.”
– Eleanor Roosevelt
’obiettivo prefissato in questo lavoro di tesi riguardava la creazione di un sistema
efficiente, affidabile e scalabile per la Sentiment Analysis, tramite l’utilizzo delle
funzionalità offerte da Hadoop e dalle relative componenti.
Per raggiungere tale obiettivo si è innanzitutto proceduto all’estrazione dei tweet dal
Social Network Twitter, in relazione alla Nazionale Italia di Calcio nel periodo in cui
è stata impegnata nei Mondiali brasiliani del 2014. Sulla base di specifiche parole
chiave sono stati acquisiti tali tweet, in tempo reale (sfruttando le Twitter Streaming
API), attraverso la componente Flume di Hadoop, e sono stati memorizzati su HDFS.
Successivamente, si è proceduto alla fase di classificazione del sentiment, che ha
coinvolto l’implementazione sia di un classificatore automatico – allo scopo è stato
utilizzato l’algoritmo Multinomial Naïve Bayes – sia di un dizionario dei termini, dove
a ciascun termine è stato associato un valore numerico ad indicare la polarità positiva
o negativa del termine. Successivamente si è implementato un script Hive che
permette, per ogni tweet, sia di determinarne la polarità finale (negativa, neutrale o
positiva) combinando i due approcci supervised learning e lexicon-based, sia di
estrapolarne le informazioni geografiche relative all’utente che ha postato il tweet. I
dati prodotti sono stati elaborati e presentati secondo diverse dimensioni, mediante il
tool Pentaho, per ottenere grafici e report relativi al sentiment, sia in riferimento ad un
determinato intervallo temporale, che ad una particolare area geografica.
La fase finale ha coinvolto l’automatizzazione di tutte le operazioni, sfruttando la
componente Oozie di Hadoop.
Per quanto riguarda gli sviluppi futuri, il sistema sviluppato, seppur presentando
un’accuratezza globale degna di nota, presenta dei valori di recall, in riferimento alle
classi negative e positive, che possono essere sicuramente migliorati.
CAPITOLO 5
L
84
Capitolo 5 Conclusioni e sviluppi futuri
Il miglioramento di tali valori si ottiene ottimizzando l’approccio lexicon-based, con:
La creazione di un vocabolario di espressioni, in cui siano presenti sentiment
word multiparola. In tal caso, si dovrebbe aggiungere una nuova fase in cui si
estraggono n-grammi di parole da ogni frase, con n variabile da 2 al numero di
parole costituenti l’espressione con il maggior numero di parole nel vocabolario,
e si verifica per ogni n-gramma se questo sia presente nel vocabolario di
espressioni. Per l’estrazione degli n-grammi si potrebbe utilizzare l’apposita
funzione UDAF predefinita di Hive ngrams(array<array<string>>,N, K,pf)
con qualche accorgimento, dato che essa estrae gli n-grammi più frequenti,
oppure si potrebbe optare per l’implementazione di una nuova UDAF che
estragga solo gli n-grammi, senza un successivo ordinamento.
Il trattamento delle negazioni e congiunzioni avversative, secondo l’approccio
analizzato nel Paragrafo 3.7.2.
È anche possibile migliorare l’approccio supervised learning, mediante:
L’ampliamento del training set. In tal caso si tratta di trovare il giusto equilibrio
che fornisca maggiore accuratezza, poiché un training set costituito da pochi
attributi potrebbe generare underfitting, al contrario invece, con troppi attributi,
potrebbe causare overfitting. L’underfitting è la situazione in cui il classificatore
non dispone di informazioni sufficienti per classificare nuove istanze.
L’overfitting, invece, è la situazione in cui il classificatore dispone di così tante
informazioni da non riuscire a predire con successo le nuove istanze.
La modifica del classificatore in modo da considerare combinazioni di
unigrammi, bigrammi e trigrammi di parole. È stato dimostrato (Gebremeskel
2011) che, sulla lingua inglese, utilizzando il Multinomial Naïve Bayes si ottiene
un’accuratezza superiore del 2% circa, lavorando sulla combinazione di
unigrammi/bigrammi piuttosto che sui singoli unigrammi di parole.
Inoltre, il sistema sviluppato non permette una classificazione in base ai singoli aspetti,
per cui si potrebbe realizzare. In tal caso il sistema dovrebbe essere modificato per
analizzare le singole frasi, da cui estrarre gli aspetti e per ognuno di questi determinare
un punteggio di sentiment. In più, l’intero post avrà un punteggio complessivo
determinato dalla somma delle polarità di ogni frase.
Infine, per quanto riguarda le performance del sistema, per ottenere migliori risultati
si potrebbe utilizzare Impala1, piuttosto che Hive.
1 Si veda Appendice A.
85
Appendice A Cloudera
Cloudera
Cloudera1 è stata la prima azienda a proporre una distribuzione Hadoop (la CDH2),
acquisendo clienti del calibro di Ebay, Nokia, Samsung, tanto per citare i più noti. La
distribuzione CDH 5 è presente sia in versione gratuita, sia in versione enterprise (in
abbonamento). Entrambe le versioni contengono i pacchetti open source: Hadoop,
Flume, Hive, Mahout, Oozie, Pig, Sqoop, Zookeeper, Hue (interfaccia grafica per
Hadoop), HBase, Impala, Search, Spark.
Le distribuzioni CDH contengono connettori per database di terze parti (Oracle,
Teradata, Netezza e così via) e un tool di gestione del sistema (Cloudera Manager), che
nella versione gratuita non include alcune funzionalità, quali backup, disaster
recovery3 e integrazioni con LDAP4. La versione enterprise, oltre al Cloudera Manager
completo, offre una funzionalità di audit5 e di gestione degli accessi e anche il supporto
tecnico su tutta la piattaforma.
Cloudera ha introdotto nella sua distribuzione il motore di esecuzione di query
distribuite chiamato Impala. Esso consente di eseguire query su dati che risiedono su
HDFS o su HBase tramite lo stesso linguaggio di Hive (HiveQL) e la stessa interfaccia
grafica (Hue Beeswax6). Impala, oltre a essere adatto a lavorare in modalità batch, può
essere impiegato per eseguire query real time, poiché i tempi di risposta sono
1 Home page: http://www.cloudera.com/content/cloudera/en/home.html 2 CDH è l’acronimo di Cloudera’s Distribution Including Apache Hadoop. 3 Il disaster recovery (in italiano Recupero dal Disastro), in informatica ed in particolare nell'ambito della
sicurezza informatica, indica l'insieme delle misure tecnologiche e logistico/organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi di business per imprese, associazioni o enti, a fronte di gravi emergenze che ne intacchino la regolare attività.
4 LDAP (Lightweight Directory Access Protocol) è un protocollo standard per l'interrogazione e la modifica dei servizi di directory (un programma o un insieme di programmi che provvedono ad organizzare e memorizzare informazioni e gestire risorse condivise all'interno di reti di computer, rese disponibili agli utenti tramite la rete stessa) come un elenco aziendale di email o una rubrica telefonica o più in generale qualsiasi raggruppamento di informazioni che può essere espresso come record di dati ed organizzato in modo gerarchico.
5 Le funzionalità di audit permettono la verifica sia delle funzionalità del sistema, sia della conformità o regolarità dei suoi comportamenti.
6 Beeswax è la parte dell’interfaccia grafica Hue che riguarda Hive.
APPENDICE A
86
Appendice A Cloudera
nettamente migliori rispetto ad Hive. Ciò è dovuto all’architettura di Impala, che non
utilizza MapReduce, ma accede ai dati tramite un motore di query parallelo le cui
soluzioni sono specifiche e ottimizzate per tipologia di query. Le performance di
Impala, infatti, dipendono sia dall’hardware sia dalla complessità delle query. Per
esempio, in presenza di molta RAM disponibile per il caching dei dati, l’incremento di
performance è notevole (dalle 10 alle 100 volte più veloce).
87
Appendice B Classificazione bayesiana
Classificazione bayesiana
La classificazione bayesiana è una tecnica statistica con la quale si determina la
probabilità di un elemento di appartenere a una certa classe. Per esempio, può essere
impiegata per stimare la probabilità di un cliente di appartenere alla classe dei
compratori di un prodotto specifico, dati alcuni attributi del cliente quali il tipo di
lavoro svolto, l’età, il reddito, lo stato civile e così via.
La tecnica si basa sul teorema di Bayes, che definisce la probabilità condizionata, o a
posteriori, di un evento rispetto a un altro. La probabilità condizionata di un evento A
rispetto a un evento B è la probabilità che si verifichi A, sapendo che B è verificato.
B.1 Classificatore Naïve Bayes
Il classificatore Naïve Bayes è basato sull’assunzione semplificativa che tutti gli
attributi (feature) che descrivono un certo dato sono tra loro condizionalmente
indipendenti data la classe a cui appartiene il dato. Tale assunzione, chiamata
indipendenza condizionale delle classi, ha lo scopo di semplificare i calcoli, e proprio
per questo l’algoritmo prende il nome di naïve. Avvalendosi di un insieme di dati
etichettati per l’addestramento, classifica i nuovi dati utilizzando il teorema di Bayes e
selezionando la classe che presenta la probabilità più alta di essere la classe a cui il dato
appartiene.
L’algoritmo possiede i seguenti punti di forza:
Lavora bene in caso di “rumore”1 in una porzione di dati.
Tende a non considerare gli attributi irrilevanti.
Il training del modello è molto più semplice rispetto ad altri algoritmi.
Quando l’ipotesi di indipendenza condizionale è verificata, il Naïve Bayes esegue una
classificazione di tipo MAP (massimo a posteriori) e il numero dei termini da stimare
1 Per rumore si intende la presenza di errori nelle misurazioni o nei dati.
APPENDICE B
88
Appendice B Classificazione bayesiana
diventa lineare nel numero di attributi. Nonostante questa assunzione sia violata nella
maggior parte dei problemi reali come, ad esempio, la categorizzazione del testo, il
Naïve Bayes si comporta molto bene e risulta essere molto efficace ed accurato.
B.2 Classificatori Naïve Bayes in Weka
Weka (acronimo di Waikato Environment for Knowledge Analysis) offre una
collezione di algoritmi di machine learning. Di seguito saranno brevemente analizzati
due versioni dell’algoritmo Naïve Bayes disponibili in weka, in relazione alla
classificazione dei tweet.
B.2.1 Multinomial Naïve Bayes Il Multinomial Naïve Bayes definisce che la probabilità che un tweet appartenga ad
una certa classe sia:
𝑃𝑃 = 𝑝𝑝!�𝑃𝑃𝑖𝑖𝑛𝑛𝑖𝑖
𝑝𝑝𝑖𝑖!
𝑖𝑖
𝑖𝑖=1
Dove 𝑝𝑝 è il numero totale di attributi costituenti il training set, 𝑘𝑘 è il numero degli
attributi contenuti nel singolo tweet da classificare, 𝑃𝑃𝑖𝑖 è la probabilità che un attributo
sia presente nel tweet e 𝑝𝑝𝑖𝑖 è il numero di volte che l’attributo è presente nel tweet. Dato
che un attributo potrebbe presentarsi diverse volte nello stesso tweet, e quindi avere
una frequenza di occorrenza maggiore di 1, l’algoritmo è multinomiale. Questa
formula è utilizzata per calcolare la probabilità relativa ad ogni classe. Durante il
calcolo, per determinare se un certo tweet appartenga ad una classe positiva, negativa
o neutrale, solo il valore di 𝑃𝑃𝑖𝑖 varia, tutti gli altri sono fissi. 𝑃𝑃𝑖𝑖 cambia perché la
probabilità che un attributo appartenga ad una classe neutrale, positiva o negativa è
differente. I termini 𝑝𝑝! e 𝑝𝑝𝑖𝑖! sono utilizzati per tenere in conto il fatto che l’ordine delle
occorrenze degli attributi in un tweet non è rilevante. Ma poiché questi valori sono gli
stessi per ogni classe, risultano non essere utili nel calcolo della probabilità relativa ad
ogni classe, per cui possono essere eliminati semplificando la formula:
𝑃𝑃 = �𝑃𝑃𝑖𝑖𝑛𝑛𝑖𝑖
𝑖𝑖
𝑖𝑖=1
Tale formula definisce semplicemente una produttoria delle probabilità di ogni
attributo elevate al numero di volte che tale attributo si presenta. La formula
89
Appendice B Classificazione bayesiana
rappresenta una modifica della formula standard di Bayes, in modo tale da considerare
anche la frequenza di occorrenza di un attributo in un certo tweet. In sostanza, se un
attributo si presenta due volte nello stesso tweet, la sua probabilità sarà moltiplicata
per due.
La probabilità che ogni attributo appartenga ad una certa classe è ottenuta durante la
fase di training. Per esempio, un attributo come “grande” in un certo tweet avrà tre
probabilità, in relazione ad ognuna delle tre classi (neutrale, positivo, negativo).
Calcolate le tre probabilità finali in riferimento all’intero tweet, quella con il valore più
alto determinerà la classe di appartenenza del tweet stesso. In tal modo si assume che
tutte le classi abbiano la stessa probabilità di esistenza. Se così non fosse basterebbe
moltiplicare il risultato per la probabilità della classe.
B.2.2 Naïve Bayes Il Naïve Bayes è sostanzialmente simile al Multinomial Naïve Bayes. La sola differenza
sta nel fatto che esso non prende in considerazione la frequenza di un attributo.
Il Naïve Bayes, infatti, considera nel calcolo solo la presenza o l’assenza di un
attributo, piuttosto che la sua frequenza.
90
Appendice C Pentaho
Pentaho
Pentaho1 è la più diffusa suite di prodotti Open Source per la Business Intelligence. È
composto da diversi pacchetti tra loro integrati che consentono la gestione completa
di tutte le problematiche della Business Intelligence e dei Data Warehouse.
Tra le caratteristiche predominanti della piattaforma spiccano i moduli:
Data Integration. Accesso e gestione dei dati eterogenei da fonti diverse (DB,
Excel, CSV, Web service, ecc.), anche di grandi dimensioni.
Analisi e controllo. Audit e monitoraggio dei dati importati, analisi di tipo Point
and Click, creazione di analisi multidimensionali OLAP.
Reporting. Gestione, produzione e pianificazione dei report tabellari o grafici in
formato HTML, Excel, PDF, Testo.
Dashboard. Visualizzazione globale di tutti i dati, creazione di cruscotti dal lato
utente, organizzazione di tutte le operazioni della piattaforma.
Data Mining: Analisi dei dati attraverso sofisticati algoritmi per scoprire regole e
correlazioni significative e nascoste.
Pentaho quindi consente di accedere, interagire, integrare, modificare, visualizzare ed
analizzare i dati, sia che questi siano memorizzati in un flat file, su un database
relazione, su Hadoop o su un database NoSQL, all’interno di un ambiente data
warehouse, sia che provengano da flussi dei social media, siano salvati su archivi
operativi locali, piuttosto che in cloud. Pentaho agevola a scoprire, capire e analizzare
i dati, visualizzandoli in diverse forme e tipologie.
La caratteristica più interessante, per quanto riguarda il sistema sviluppato, è
sicuramente l’integrazione con l’ecosistema Hadoop, ed i particolare Hive2. In tal
modo è stato possibile creare report in Pentaho, la cui sorgente di dati è rappresentata
da una tabella Hive, effettuando le query sui dati senza richiederne lo spostamento.
1 Sito web: http://www.pentaho.com/. 2 Per approfondimenti: http://wiki.pentaho.com/display/BAD/Reporting+on+Hive+Data.
APPENDICE C
91
Bibliografia e Sitografia
Bibliografia e Sitografia
Abhishek. Hadoop, HDFS, MapReduce and Hive - Some salient understandings. 5
Novembre 2012. http://hadoop-gyan.blogspot.it/2012/11/map-reduce.html
(consultato il giorno Aprile 7, 2014).
Bing, Liu. «Opinion Mining and Sentiment Analysis.» In Web Data Mining: Exploring
Hyperlinks, Contents, and Usage Data. Springer, 2011.
Bing, Liu. «Sentiment Analysis and Subjectivity.» In Handbook of Natural Language
Processing. Damerau, Fred J.; Indurkhya, Nitin, 2010.
Brody, Samuel, e Nicholas Diakopoulos. «Cooooooooooooooollllllllllllll!!!!!!!!!!!!!!
Using Word Lengthening to Detect Sentiment in Microblogs.» Luglio 2011.
http://www.nickdiakopoulos.com/wp-
content/uploads/2007/05/BrodyDiakopoulosEMNLP11pp.pdf (consultato il
giorno Maggio 15, 2014).
Capriolo, Edward, Dean Wampler, and Jason Rutherglen. Programming Hive.
O'Reilly Media, 2012.
Collaborative Consulting. «The Fast-Track to Hands-On Understanding of Big Data
Technology.» Maggio 2014. http://www.collaborative.com/wp-
content/uploads/2014/05/the-fast-track-to-hands-on-understanding-of-big-
data-technology-part-2-WP.IM_.111.pdf (consultato il giorno Maggio 30,
2014).
Congiu, Roberto. A JSON read/write SerDe for Hive. 11 Luglio 2011.
http://www.congiu.com/a-json-readwrite-serde-for-hive/ (consultato il giorno
Maggio 8, 2014).
Gebremeskel, Gebrekirstos. «A Sentiment Analysis of Twitter Posts about news.»
Masters Thesis, 2011.
Ghemawat, Sanjay, e Jeffrey Dean. «MapReduce: Simplied Data Processing on Large
Clusters.» Google Research Publications. Dicembre 2004.
http://static.googleusercontent.com/media/research.google.com/it//archive/
mapreduce-osdi04.pdf (consultato il giorno Aprile 21, 2014).
92
Bibliografia e Sitografia
Go, Alec, Richa Bhayani, e Lei Huang. «Twitter Sentiment Classification using Distant
Supervision.» CS224N Project Report, Stanford, 2009.
Holmes, Alex. How partitioning, collecting and spilling work in MapReduce.
Settembre 2012. http://grepalex.com/2012/09/24/map-partition-sort-spill/
(consultato il giorno Aprile 12, 2014).
Holmes, Alex. «Streamlining HDFS for big data.» In Hadoop in Practice, di Alex
Holmes, 169-193. Manning Publications Co., 2012.
Hue Team. «Execute Hive queries and schedule them with Oozie.» Settembre 2013.
http://gethue.com/hadoop-tutorials-ii-2-execute-hive-queries-and/
(consultato il giorno Giugno 20, 2014).
Khuc, Vinh Ngoc, Chaitanya Shivade, Rajiv Ramnath, e Jay Ramanathan. «Towards
Building Large-Scale Distributed Systems for Twitter Sentiment Analysis.»
2012.
Lin, Jimmy, e Alek Kolcz. «Large-Scale Machine Learning at Twitter.» s.d.
http://www.dcs.bbk.ac.uk/~DELL/teaching/cc/paper/sigmod12/p793-lin.pdf
(consultato il giorno Giugno 19, 2014).
Lin, Jimmy, e Chris Dyer. Data-Intensive Text Processing with MapReduce (Synthesis
Lectures on Human Language Technologies). Morgan & Claypool Publishers,
2010.
Lublinsky, Boris, Kevin T. Smith, e Alexey Yakubovich. Professional Hadoop
Solutions. John Wiley & Sons, Inc., 2013.
McCallum, Andrew, e Kamal Nigam. «A Comparison of Event Models for Naive Bayes
Text Classification.» 1998.
McClary, Dan. Acquiring Big Data Using Apache Flume. 10 Giugno 2013.
http://www.drdobbs.com/database/acquiring-big-data-using-apache-
flume/240155029 (consultato il giorno Maggio 6, 2014).
Melloncelli, Damiano. «Sentiment Analysis in Twitter.» Tesi di Laurea Magistrale in
Informatica, Scuola di Scienze, Università di Bologna, 2014.
Monti, Corrado. «Sentiment Analysis applicata a microblogging in lingua italiana:
sviluppo e valutazione di un sistema automatico.» Tesi di Laurea Magistrale in
Informatica, Facoltà di Scienze Matematiche, Fisiche e Naturali, Università
degli studi di Milano, A.A. 2011-2012.
93
Bibliografia e Sitografia
Narayanan, Vivek, Ishan Arora, e Arjun Bhatia. «Fast and accurate sentiment
classification using an enhanced Naive Bayes model.» 2013.
Obstat, Nihil. Baseline Sentiment Analysis with WEKA. 11 Giugno 2013.
http://jmgomezhidalgo.blogspot.it/2013/06/baseline-sentiment-analysis-with-
weka.html (consultato il giorno Maggio 2014, 29).
Pang, Bo, e Lillian Lee. «Opinion mining and sentiment analysis.» 2008.
Rezzani, Alessandro. Big data. Architettura, tecnologie e metodi per l'utilizzo di grandi
basi di dati. Maggioli Editore, 2013.
Rodeghiero, Paolo. Verifica sperimentale di un modello per MapReduce. Padova,
2012.
Russell, Matthew A. Mining the Social Web: Data Mining Facebook, Twitter,
Linkedin, Google+, Github, and More. O'Reilly Media, 2013.
Scherer, Michael. «Inside the Secret World of the Data Crunchers Who Helped Obama
Win.» 7 Novembre 2012. http://swampland.time.com/2012/11/07/inside-the-
secret-world-of-quants-and-data-crunchers-who-helped-obama-win/
(consultato il giorno Maggio 4, 2014).
weka, alanf, dpdonohue, e fracpete. Use WEKA in your Java code. 14 Gennaio 2013.
http://weka.wikispaces.com/Use+WEKA+in+your+Java+code (consultato il
giorno Maggio 29, 2014).
White, Tom. Hadoop: The Definitive Guide, 3rd Edition. O'Reilly Media / Yahoo
Press, 2012.
Wikipedia, l'enciclopedia libera. MapReduce. 18 Aprile 2014.
http://en.wikipedia.org/wiki/MapReduce (consultato il giorno Aprile 24,
2014).
Witten, Ian, Eibe Frank, e Mark Hall. Data Mining: Practical Machine Learning Tools
and Techniques. Morgan Kaufmann Publishers, 2011.
Zhang, Lei, Riddhiman Ghosh, Mohamed Dekhil, Meichun Hsu, e Bing Liu.
Combining Lexicon-based and Learning-based Methods for Twitter Sentiment
Analysis. 2011.
94