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