Tourstic Presence Index: un indicatore di stima di presenze turistiche in Italia basato su dati di media-sharing

(1)

Universit`

a di Pisa

Dipartimento di Informatica

Corso di Laurea Magistrale in Informatica per l’Economia e per l’Azienda (Business Informatics)

Touristic Presence Index: un Indicatore di Stima di

Presenze Turistiche in Italia basato su Dati di

Media-Sharing

Relatore: Candidato:

Dott. Salvatore Rinzivillo Laura Guidi

Controrelatore: Tutore Aziendale:

Prof. Roberto Bruni Dott. Sergio Raimondi

(2)

Sommario

La tesi descrive il processo di estrazione, trasformazione e analisi di dati estratti da siti di media-sharing e la loro integrazione con i dati ufficiali sul turismo forniti da Istat al fine di costruire un modello di stima delle presenze turistiche in Italia.

Gli indicatori estratti sono visualizzati tramite mappe tematiche per analizzare il flusso turistico in Italia.

(3)

Indice

1 Introduzione 1

1.1 Value Lab . . . 2

1.2 Contributo personale . . . 2

1.3 Fasi del progetto e organizzazione della tesi . . . 4

2 Stato dell’arte 6 2.1 Trajectory pattern mining, analisi dei flussi e raccomandazione di percorsi . . . 6

2.2 Estrazione di informazioni dai campi testuali associati alle immagini . . . 8

2.3 Analisi della precisione del posizionamento delle immagini . . . 9

2.4 I dati ufficiali sul turismo . . . 10

3 Infrastruttura di Data Management 12 3.1 Apache Hadoop . . . 12

3.2 Apache Spark . . . 15

3.3 Confronto tra Hadoop e RDBMS . . . 20

4 Raccolta dati 22 4.1 Meccanismo per la raccolta dei dati . . . 22

4.2 Flickr . . . 23

4.3 Panoramio . . . 28

5 Data pre-processing 31 5.1 Eliminazione dei duplicati . . . 31

5.2 Individuazione dei punti appartententi al territorio italiano . . . 32

5.3 Eliminazione delle fotografie multiple per utente . . . 33

5.4 Eliminazione dei record con timestamp errato . . . 34

6 Semantic enrichment e interpretazione dei dati 35 6.1 Classificazione degli utenti . . . 35

6.1.1 Il modello . . . 36

(4)

INDICE ii

6.1.2 Risultati ottenuti . . . 37

6.1.3 Validazione dei risultati . . . 39

6.2 Interpretazione dei dati . . . 40

6.2.1 Flickr . . . 40

6.2.2 Panoramio . . . 45

6.2.3 Unione dei dati Flickr e Panoramio . . . 50

6.2.4 I dati ISTAT . . . 52

6.2.5 Confronto tra dati social e dati Istat . . . 55

7 Stima delle presenze turistiche in Italia 60 7.1 Stima a livello comunale . . . 60

7.1.1 Presenze nelle strutture ricettive . . . 60

7.1.2 Il turismo negli appartamenti per vacanza . . . 63

7.1.3 Il fenomeno dell’escursionismo . . . 68

7.1.4 Risultato complessivo a livello comunale . . . 71

7.2 Stima a livello di sezioni di censimento . . . 72

8 Knowledge Consolidation 76 8.1 Mappe a livello comunale . . . 76

8.2 Mappe a livello di sezione di censimento . . . 83

Conclusioni e sviluppi futuri 87

(5)

Capitolo 1

Introduzione

Il lavoro descritto in questa tesi costituisce una componente di un progetto interno dell’azienda Value Lab, sede del tirocinio, il cui scopo `e quello di arricchire il patri-monio aziendale con un database che permetta di descrivere la Daytime Population in Italia.

Parlando di Daytime Population si fa riferimento al numero di persone che sono presenti in un’area durante l’orario diurno. Questo concetto `e in contrasto con quello di popolazione residente, dato fornito da Istat, che fa riferimento alle persone che risiedono in una determinata area e che sono solitamente presenti nelle ore notturne. Al fine di stimare la Daytime Population di una determinata area sono state individuate le componenti che incidono su questo valore: la popolazione residente diurna, i turisti, gli studenti, i lavoratori e coloro che si spostano in una certa zona per eventi, shopping o altri motivi di svago.

In questo progetto abbiamo concentrato l’attenzione sull’aspetto turistico po-nendoci come obiettivo quello di calcolare il Touristic Presence Index un indicatore che permetta di stimare le presenze turistiche in Italia. Tale scopo è stato raggiungo tramite un processo lungo e complesso composto da fasi tecniche e fasi analitiche. In prima istanza è stato necessario capire quali fonti fossero le più idonee a reperire i dati utili per raggiungere il nostro scopo. Una volta appurato che i dati ufficiali Istat non sarebbero stati sufficienti al raggiungimento dell’obiettivo stabilito abbiamo de-ciso di integrarli con dati estratti da siti di media-sharing come Flickr e Panoramio.

Nelle seguenti sezioni verranno date alcune informazioni introduttive riguardanti il progetto descritto in questa tesi. Si inizierà da una breve descrizione dell’azienda Value Lab, si metterà in evidenza il contributo personale fornito per portare a ter-mine il lavoro, verrà inoltre spiegato come il progetto stesso è stato strutturato e come è stata organizzata questa tesi.

(6)

CAPITOLO 1. INTRODUZIONE 2

1.1 Value Lab

Questo progetto `e stato realizzato durante un tirocinio della durata di 6 mesi svolto presso Value Lab, un’azienda con sedi a Milano e Roma, che da oltre 20 anni opera nel settore della consulenza di management e IT solutions specializzata in marke-ting, vendite e retail [1].

La missione di Value Lab `e quella di aiutare le aziende ad affrontare i problemi decisionali con un approccio relazionale e oggettivo che permetta di ottenere il mi-glioramento delle performance aziendali e il rafforzamento della competitivit`a.

All’interno dell’azienda, il reparto Analytics si occupa di elaborare i dati a dispo-sizione mediante le principali tecniche di data mining al fine di estrarre informazioni utili al cliente. Queste tecniche fanno emergere le tendenze, le relazioni tra i dati, le ragioni legate al manifestarsi dei fenomeni. Quindi si riesce ad evidenziare non solo cosa sta accadendo, ma anche il motivo per cui ci`o avviene. Per raggiungere questi obiettivi vengono utilizzati potenti software statistici.

Negli ultimi anni Value Lab ha mostrato un forte interesse anche nei confronti dei cosiddetti open data, ossia la grande massa di dati eterogenei che vengono prodotti e scambiati quotidianamente in rete. Per riuscire ad elaborare in modo efficiente questa tipologia di dato, ma non solo, vengono utilizzate tecnologie nuove e adatte a gestire grandi quantit`a di dati non sempre ben strutturati. I tool che compongono l’ecosistema Hadoop sono una delle soluzioni migliori per affrontare queste proble-matiche. E’ esattamente in questo contesto che `e stato inserito il progetto descritto in questa tesi.

1.2 Contributo personale

Questo progetto si pone come scopo il calcolo del Touristic Presence Index, ossia un indicatore che stimi le presenze turistiche in Italia a diversi livelli di dettaglio.

Alcuni enti del turismo hanno portato a termine ricerche finalizzate a compren-dere e quantificare il fenomeno turistico a livello locale ma finora non sono stati pubblicati studi su scala nazionale.

Per raggiungere questo obiettivo `e stato necessario integrare le statistiche ufficiali sul turismo fornite da Istat con informazioni estrapolate dai metadati delle fotografie scaricate dai siti di media-sharing Flickr e Panoramio. Le ricerche locali appena citate sono state poi utilizzate per valutare la bont`a del risultato raggiunto.

Dal lato dell’utilizzo dei dati social, in letteratura sono presenti molti lavori che sfruttano questi dati per estrarre informazioni relative al comportamento degli utenti in ambito turistico e non solo. Alcuni studi svolti in questo ambito saranno descritti

(7)

nel Capitolo 2.

Di seguito viene riassunto il contributo personale fornito per raggiungere lo scopo prefissato:

• Implementazione del meccanismo per la raccolta tramite API dei metadati delle fotografie dai siti Flickr e Panoramio e caricamento di tali dati sul file system Hadoop (HDFS);

• Pre-processing dei metadati al fine di eliminare valori errati, duplicati o non interessanti dato lo scopo prefissato;

• Sviluppo di un modello di classificazione degli utenti come turisti o residenti in un dato comune;

• Interpretazione dei dati social utilizzando le API Python fornite da Apache Spark, unione dei dati Flickr e Panoramio e confronto con le statistiche ufficiali Istat sul turismo;

• Ideazione ed implementazione del modello di stima delle presenze turistiche in Italia, il cui output `e rappresentato dal Touristic Presence Index ;

• Creazione di un geodatabase e di alcuni layer ArcGis per la visualizzazione su mappa del Touristic Presence Index.

Il progetto ha contribuito anche a migliorare la mia formazione come Data Scien-tist, infatti Value Lab mi ha dato l’opportunità di studiare in modo approfondito e di utilizzare tecnologie di nuova generazione come Apache Hadoop e Apache Spark nell’ottica di un futuro approccio ai Big Data. Nonostante la mole dei dati trattati non sia stata eccessiva, questo progetto può essere visto come punto di partenza per usare le medesime tecnologie in contesti ancora più complessi.

Ho avuto inoltre la possibilit`a di imparare il linguaggio di programmazione Py-thon, molto utilizzato nell’ambito della Social Data Analysis e pi`u in generale per l’analisi dei dati. Inoltre in molte fasi del progetto ho utilizzato il software Esri ArcGis per effettuare le analisi spaziali sui dati e visualizzarli su mappa.

(8)

1.3 Fasi del progetto e organizzazione della tesi

Il progetto `e stato sviluppato seguendo le classiche fasi del KDD process [2], logica-mente strutturato come in Figura 1.1. Per far si che anche la tesi stessa rispecchi il processo che `e stato seguito, in linea di massima ogni capitolo descrive la realizza-zione di una singola fase.

Figura 1.1: KDD process

Di seguito vengono descritte le varie fasi del progetto, facendo riferimento allo sche-ma tipico dei processi KDD, e viene spiegato come `e organizzato il contenuto della tesi:

• La fase di Raccolta dati, descritta nel Capitolo 4, ha come obiettivo la costru-zione del dataset iniziale su cui verranno poi effettuate le analisi. In par-ticolare durante questa fase sono stati raccolti tramite API i dati dai siti di media-sharing Flickr e Panoramio e memorizzati sul file system Hadoop, HDFS.

• Le fasi di Data cleaning e Data Tranformation, descritte nel Capitolo 5, per-mettono di eliminare dal dataset di input quei dati giudicati errati, duplicati o irrilevanti al fine dell’analisi che si vuole realizzare.

• La fase di Data mining è quella in cui vengono effettivamente costruiti i model-li che permettono di estrarre informazioni dai dati mentre nella fase di Pattern evaluation si valuta la bontà del risultato raggiunto. Nel nostro caso, nel Ca-pitolo 6, viene costruito un modello necessario per selezionare la porzione di dataset rappresentativa del fenomeno turistico, quindi validato il modello e in-fine analizzati ed interpretati i dati prodotti come output. A sua volta questi dati costituiscono l’input per la costruzione del modello di stima attraverso cui viene calcolato il Touristic Presence Index, descritto nel Capitolo 7. La vali-dazione di questo modello è stata effettuata confrontando i risultati raggiunti con valori pubblicati in ricerche relative al turismo effettuate a livello locale.

(9)

• Nell’ultima fase, nota come Knowledge Consolidation, tutte le informazioni raccolte ed elaborate vengono mostrate all’utente finale in un formato facil-mente comprensibile ed interpretabile. Nel nostro caso oltre alla costruzione di un geodatabase di output, ´e stato prodotto un insieme di layer GIS per-mettendo la visualizzazione su mappa del risultato raggiunto. Alcuni esempi sono riportati nel Capitolo 8.

(10)

Capitolo 2

Stato dell’arte

Negli ultimi anni, con l’evoluzione del web nel cosiddetto Web 2.0 caratterizzato da applicazioni con elevato livello di interazione tra il sito web e l’utente, si `e as-sistito alla nascita di piattaforme di condivisione di media come Flickr, Youtube, Panoramio e molte altre. Questo fenomeno ha portato alla diffusione su Internet di grandi volumi di fotografie e video che, uniti ai metadati spaziotemporali e al-le informazioni testuali associate, sono diventati fonte di studio e di ricerca al fine di estrarre informazioni aggregate e analizzare i comportamenti sociali. Gli studi portati avanti in questo ambito si sono posti svariati scopi come l’analisi dei flussi turistici, la valutazione della qualit`a dei dati, l’individuazione di regioni di interesse e l’estrazione di informazioni dai campi testuali associati alle immagini.

Dall’altro lato le statistiche ufficiali sul turismo sono elaborate a partire da rileva-zioni e elaborarileva-zioni Istat. In particolare, l’Istat conduce indagini volte a individuare l’offerta e la domanda turistica in Italia.

2.1 Trajectory pattern mining, analisi dei flussi e

raccomandazione di percorsi

Alcuni studi e ricerche effettuati a partire da dati con associate informazioni spazio-temporali riguardano l’estrazione di conoscenza riguardo le abitudini di movimento delle persone e di particolare interesse risultano gli studi mirati a individuare gli spostamenti dei turisti. Di seguito vengono presentate alcune ricerche effettuate in questo ambito.

Giannotti et al. si sono posti come obiettivo l’individuazione di pattern che descrivono in modo sintetico il comportamento di una popolazione di oggetti in mo-vimento. Ci`o pu`o essere utile in ambiti che vanno dalla gestione del traffico stradale in aree metropolitane, al problema del traffico sostenibile fino all’applicazione in am-bito turistico. Nell’articolo che descrive il loro lavoro [3] hanno introdotto il concetto

(11)

CAPITOLO 2. STATO DELL’ARTE 7

di trajectory pattern che rappresenta un insieme di traiettorie che sono caratterizzate dall’attraversare la stessa sequenza di luoghi con simili tempi di viaggio.

Figura 2.1: Esempio di T-Pattern

Hanno inoltre definito il trajectory pattern mining come il problema di indivi-duare tutti i trajectory pattern frequenti data una time tolerance, una funzione di vicinanza e una soglia che definisce il supporto minimo. E’ stato inoltre proposto un algoritmo per la risoluzione di tale problema e mostrato un esempio di applicazione.

Y.-T.Zheng et al. si sono proposti di analizzare i flussi di traffico turistico tra alcune regioni di attrazione individuate e hanno proposto un modello basato sulle catene di Markov [4]. Il lavoro pu`o essere sostanzialmente suddiviso in tre fasi:

• la costruzione di un database di percorsi a partire da un dataset di fotografie con associate informazioni spaziotemporali;

• l’individuazione di regioni di attrazione (RoA) mediante l’utilizzo dell’algorit-mo DBSCAN per l’indentificazione di aree ad alta densit`a di punti;

• la modellazione degli spostamenti dei turisti da una RoA ad un’altra mediante una catena di Markov.

Tale metodologia è stata applicata su fotografie scaricate da Flickr relative alle città di Londra, Parigi, New York e San Francisco ed è stato dimostrato che l’ap-proccio proposto ha portato buoni risultati.

Kachkaev e Wood hanno mostrato come le fotografie scaricate dai siti di media-sharing possano essere utilizzate per misurare l’attrattività delle strade [5]. Gli autori hanno osservato che non tutte le fotografie caricate su siti di media-sharing sono utili per raggiungere questo scopo. Hanno quindi individuato un sottoinsieme di immagini il cui contenuto è adatto a misurare l’attrattività delle strade, eliminando per esempio le fotografie contenenti volti o scattate in luoghi chiusi.

Per raggiungere lo scopo prefissato gli autori hanno scelto di utilizzare il grafo stradale fornito da OpenStreetMap; ad ogni arco stradale `e necessario assegnare

(12)

uno score che rappresenti la densità dei fotografi che si trovano vicino a tale arco. L’approccio più semplice è contare i fotografi localizzati entro un certo numero di metri da ogni arco e considerare questo valore come score. Questo metodo presenta però un limite evidente dovuto alle differenti lunghezze degli archi; per evitare questo problema è sufficiente normalizzare lo score precedentemente calcolato in base alla lunghezza dell’arco.

Gli autori non si sono per`o limitati ad associare ad ogni strada uno score che misuri quanto sono frequentate ma hanno suggerito un approccio che permette di calcolare i percorsi degli utenti. Questo viene fatto utilizzando un algoritmo di routing che prende in input lo score calcolato per ogni strada e per ogni utente una coppia di coordinate origine - destinazione e restituisce il percorso che `e stato compiuto dall’utente rispettando anche i vincoli temporali imposti.

2.2 Estrazione di informazioni dai campi testuali

associati alle immagini

Le immagini caricate sui siti di media-sharing contengono informazioni che vanno ben oltre il solo aspetto spazio-temporale. Il contenuto vero e proprio delle fotogra-fie che compongono un certo dataset può essere sottoposto a un processo di image mining. Questo è però un problema piuttosto complesso che richiede competenze nell’ambito dell’image retrieval, image understanding e data mining. Le tecniche di image mining estendono le tecniche tradizionali di data mining a dati non strut-turati, quali appunto le immagini. Tuttavia queste tecniche non sono ancora state perfezionate e l’image mining è un campo ancora in continua evoluzione.

Alle fotografie sono associati per`o anche alcuni campi descrittivi, tipicamente il titolo e il tag, che permettono di estrarre informazioni riguardanti l’immagine senza vederla o senza la necessit`a di analizzarne il contenuto in senso stretto. Sono stati fatti numerosi studi per capire come sfruttare queste informazioni.

Rattenbury et al. hanno descritto un approccio per estrarre conoscenza da un insieme non strutturato di tag. Il loro studio è stato effettuato a partire da un dataset di fotografie con associate informazioni spaziotemporali e un insieme di tag, con l’obiettivo di capire per ogni tag se fa riferimento a un evento o a una località. Ciò che permette di fare questa distinzione è l’idea che un tag che fa riferimento a un evento ricorra spesso in un intervallo temporale breve mentre un tag identifica una località se è associato a immagini situate in una stessa regione nello spazio.

Nell’articolo [6] `e stato presentato un nuovo metodo, chiamato Scale-structure Identification per l’identificazione di eventi e localit`a che si basa proprio sull’idea appena descritta.

(13)

Kennedy et al. si sono posti il problema di capire come sfruttare al meglio le in-formazioni contenute nei dataset ottenuti a partire da siti di media-sharing. Hanno portato avanti un caso di studio basato su immagini scaricate da Flickr utilizzando due differenti approcci: location-driven: ossia individuare i tag significativi per al-cune aree selezionate arbitrariamente; tag-driven: per individuare luoghi ed eventi a partire dal contenuto dei tag.

Il contributo apportato dalla ricerca descritta nell’articolo [7] consiste nel trovare un metodo per combinare analisi di tipo location-based, tag-based e content-based.

Kennedy et al. sono riusciti a dimostrare che è possibile estrarre informazioni utili a partire da una collezione di fotografie e che i tag possono essere di aiuto per individuare luoghi ed eventi particolarmente interessanti per gli utenti. Inoltre la conoscenza estratta dalle analisi di tipo tag-driven e location-driven può essere uti-lizzata come vincolo per rendere il problema dell’analisi delle immagini più semplice da risolvere.

2.3 Analisi della precisione del posizionamento

delle immagini

Uno degli aspetti che si `e iniziato ad affrontare in letteratura `e quello della precisione del caricamento delle immagini caricate sui siti di media-sharing presi in analisi in questo lavoro.

Zielstra et al. [8] hanno analizzato la bontà del posizionamento di 1.433 immagini sparse in quattro continenti, confrontando la posizione risultante dal geotag associato alla fotografia con la posizione esatta della camera che viene ricostruita osservan-do effettivamente l’immagine. L’accuratezza del posizionamento viene determinata misurando la distanza tra le coordinate associate all’immagine e la posizione della fotocamera che si stima osservando il contenuto della fotografia. In teoria tale di-stanza dovrebbe essere nulla ma dalle analisi effettuate è stato osservato che alcune immagini non sono correttamente posizionate in quanto ad esse vengono attribuite le coordinate della scena fotografata anziché quelle della fotocamera, si parla in questo casi di mismatch position error.

Gli studi effettuati sul campione selezionato hanno rivelato che il posizionamento delle immagini di Panoramio risulta migliore rispetto a quelle di Flickr. Si passa infatti da un errore medio compreso tra 46 metri, per il Nord America, e 1.606 metri, per il Sud America, su Flickr ad avere errori al di sotto dei 25 metri per Panoramio. Inoltre è stato osservato che c’è forte correlazione tra il tipo di scena fotografata e il livello di accuratezza del posizionamento, in particolare le immagini scattate nei pressi delle strade hanno posizionamento molto più preciso rispetto a fotografie con

(14)

altri soggetti, come ponti e paesaggi naturali.

Hauff nell’articolo [9] ha analizzato la precisione spaziale delle fotografie caricate su Flickr. La ricerca ha portato a individuare una forte correlazione tra la popolarit`a di un luogo e l’accuratezza dei geotag. Fotografie scattate in luoghi molto popolari hanno associato un geotag spaziale molto accurato mentre immagini relative a luoghi poco popolari presentano bassa precisione di localizzazione.

Nella loro ricerca [10], Hollenstein e Purves hanno verificato l’accuratezza del posizionamento geografico delle fotografie scattate a Londra ed hanno concluso che l’attributo accuracy presente nei metadati delle immagini di Flickr è utile al fine di filtrare immagini che non sono posizionate correttamente. Inoltre in questo studio sono state realizzate delle mappe di densità che mostrano la distribuzione delle immagini con tag downtown nel territorio degli Stati Uniti. Grazie ad un algoritmo che utilizza solamente le immagini a cui è associato il tag downtown oppure centre `

e stato possibile individuare in modo sufficientemente preciso i confini delle citt`a.

Figura 2.2: Individuazione delle principali zone di chicago tramite mappa di densit`a

2.4 I dati ufficiali sul turismo

L’Istat, Istituto nazionale di statistica, `e un ente di ricerca pubblico nato nel 1926 per “diffondere e comunicare in modo efficace l’informazione statistica e le analisi realizzate per favorire la conoscenza della realt`a economica, sociale ed ambientale dell’Italia e migliorare i processi decisionali dei soggetti privati e delle istituzioni pubbliche” [11].

Tra le varie ricerche Istat conduce ogni anno indagini sull’offerta e sulla domanda turistica in Italia; vengono quindi forniti i dati relativi a tre diversi aspetti connessi al turismo:

(15)

• Capacità esercizi ricettivi : per ogni comune viene rilevata la quantità di esercizi alberghieri e extralberghieri e la loro capacità ricettiva;

• Movimento esercizi ricettivi : per ogni mese e comune vengono rilevate gli arrivi e le presenze di clienti nelle strutture ricettive classificate per categoria e tipo di struttura;

• Indici del fatturato dei servizi di alloggio: ogni trimestre vengono calcolati degli indicatori che hanno l’obiettivo di misurare il valore dei servizi offerti dalle imprese operanti nel settore turistico.

I dati forniti dall’Istat permettono quindi di avere ogni anno un’immagine dei movimenti turistici in Italia che può essere ottenuta incrociando le variabili a di-sposizione. Ad esempio Istat studia la stagionalità dei flussi turistici, individua le strutture ricettive preferite, mette a confronto il comportamento di italiani e stra-nieri. Inoltre visto che questi dati sono forniti a cadenza annuale è possibile mettere a confronto la situazione in diversi anni.

Tuttavia queste informazioni non danno un quadro completo delle presenze tu-ristiche in Italia in quanto non vengono rilevati i dati relativi agli escursionisti, cioè coloro che effettuano viaggi di un giorno senza pernottare in alcuna struttura, e a coloro che pernottano in seconde case di proprietà. Un altro aspetto che non si può trascurare è il fatto che un turista spesso va a visitare luoghi che appartengono a comuni diversi da quello in cui pernotta.

(16)

Capitolo 3

Infrastruttura di Data

Management

Durante questo progetto è stato scelto di utilizzare il framework Apache Hadoop per realizzare le fasi di Data pre-processing e Data understanding. In particolare è stato utilizzato Apache Spark poiché è uno strumento in grado di effettuare rapidamente analisi interattive su grandi quantità di dati.

Come ambiente di sviluppo `e stato utilizzato Jupyter, un ambiente di computa-zione interattiva che consente di creare documenti che contengono codice, visualiz-zazione dei dati e testo descrittivo.

Per effettuare invece le analisi che coinvolgono l’aspetto geografico dei dati `e stato utilizzato il software Esri ArcGis, un sistema informativo geografico adatto alla creazione e l’uso di mappe, alla gestione delle informazioni geografiche e ad eseguire analisi spaziali.

In questo capitolo vengono descritti pi`u in dettaglio Apache Hadoop e Apa-che Spark, in quanto sono tecnologie innovative e di cui `e interessante capire il funzionamento.

3.1 Apache Hadoop

Apache Hadoop è un framework per la memorizzazione e l’elaborazione di dati in cluster di computer. Un cluster è un gruppo di computer interconnessi su cui è possibile effettuare elaborazioni distribuite.

I cluster Hadoop sono di solito formati da un numero basso di master nodes, che controllano la memorizzazione e l’elaborazione, e da un numero elevato di slave nodes, sui quali vengono effettivamente memorizzati e processati i dati.

In origine Hadoop era costituito da due componenti principali:

• MapReduce: un framework software il cui scopo `e supportare l’elaborazione distribuita di grandi quantit`a di dati;

(17)

CAPITOLO 3. INFRASTRUTTURA DI DATA MANAGEMENT 13

• HDFS : file system distribuito su cui vengono memorizzati i dati.

Hadoop 1.0 era concepito in modo da riuscire ad elaborare unicamente job Ma-pReduce in modalit`a batch ma non era in grado di supportare l’analisi interattiva di dati ed era molto limitato per quanto riguarda l’esecuzione di applicazioni di ma-chine learning, graph mining e l’elaborazione di algoritmi che richiedono elevato uso della memoria. Per questi motivi gli sviluppatori di Hadoop hanno riscritto le sue principali componenti e si `e passati ad Hadoop 2.0.

Figura 3.1: Confronto tra Hadoop 1.0 e 2.0

La principale novit`a in Hadoop 2.0 `e l’introduzione di YARN (o MapReduce 2.0) che si occupa di gestire le risorse e schedulare i job in esecuzione in modo da utilizzare in modo efficiente la potenza di calcolo a disposizione. In particolare YARN presenta alcune differenze fondamentali rispetto a MapReduce:

• consente l’accesso simultaneo al cluster Hadoop, quindi anche ad uno stesso dataset, a tipologie di applicazioni differenti;

• l’allocazione dinamica delle risorse del cluster permette di ottenere prestazioni migliori rispetto all’approccio statico utilizzato da MapReduce 1.0;

• il ResourceManager di YARN, che si focalizza sullo scheduling dei job, risulta scalabile al crescere del numero dei nodi del cluster;

• le applicazioni MapReduce sviluppate per Hadoop 1.0 sono compatibili con YARN.

L’architettura di YARN, mostrata in Figura 3.2 `e composta essenzialmente da quattro componenti: il ResourceManager, il NodeManager, l’ApplicationMaster e il Job History Server.

Il ResourceManager viene eseguito sul master node e si occupa di gestire le risorse del cluster in base alle richieste provenienti dalle varie applicazioni in esecuzione.

(18)

Su ogni slave node viene eseguito un NodeManager che ha il compito di control-lare lo stato delle risorse del nodo e comunicare periodicamente tali informazioni al ResourceManager.

Ogni applicazione in esecuzione sul cluster `e controllata da un ApplicationMaster che si occupa di gestire ogni job e comunicare al ResourceManager lo stato dell’ap-plicazione, le risorse in uso ed eventualmente richiedere ulteriori risorse necessarie per la computazione.

Infine il Job History Server mantiene la cronologia dei job eseguiti e in esecuzio-ne.

Figura 3.2: Architettura YARN

Nel passaggio da Hadoop 1.0 alla versione successiva anche HDFS ha subito delle modifiche che permettono al sistema di essere altamente scalabile.

In origine ogni cluster HDFS era composto da un NameNode che gestisce i me-tadati del cluster e da un insieme di DataNodes in cui vengono memorizzati i dati. Hadoop 2.0 ha introdotto HDFS Federation che prevede una netta separazione tra namespace e memorizzazione fisica e supporta l’utilizzo di NameNodes multipli.

Quindi HDFS Federation utilizza NameNodes tra loro indipendenti che non han-no bisoghan-no di alcun tipo di coordinazione. I DataNodes sohan-no usati come spazio di memorizzazione comune a tutti i NameNodes del cluster. Ogni NameNode ha a di-sposizione un insieme di blocchi fisici, chiamato Block Pool, che gestisce in maniera autonoma.

(19)

Figura 3.3: Architettura HDFS Federation

3.2 Apache Spark

In origine Apache Hadoop è stato sviluppato con l’idea di elaborare grandi quantità di dati ed effettuare operazioni ETL in modalità batch. Per far ciò il paradigma MapReduce era la soluzione ottimale. Un job MapReduce suddivide un dataset in parti indipendenti e li organizza in coppie chiave, valore che possono essere elaborate in parallelo.

La funzione Map divide i record in gruppi e crea un task map per ognuno. Tali task vengono distribuiti sui nodi e la loro esecuzione produce come output un gruppo di coppie chiave, valore.

La funzione Reduce raccoglie i risultati della fase precedente e li combina in modo da risolvere il problema originale. Al termine della fase di Reduce i dati vengono salvati su HDFS

Figura 3.4: Pipeline MapReduce

L’architettura di Hadoop 2.0, basata su YARN, permette a molte tipologie di applicazione di condividere i cluster Hadoop. Il termine Hadoop non si riferisce pi`u

(20)

solamente ai moduli descritti in precedenza ma a un “ecosistema”, cio`e un insieme di applicazioni in grado di essere installate sopra lo stack di Hadoop 2.0. Ogni progetto

Figura 3.5: Ecosistema Hadoop

entrato a far parte di questo “ecosistema” `e stato sviluppato in modo da realizzare una specifica funzione, tra tutti quello che risulta interessante al fine di effettuare in modo veloce analisi interattive di dati `e Apache Spark.

Apache Spark `e un motore che effettua elaborazioni in memoria che offre un’am-pia gamma di API in Python, Java, Scala, SQL e R per la manipolazione ed analisi dei dati. Spark presenta alcune caratteristiche che ne rappresentano i punti di forza:

• Workflow generalizzati: map/reduce `e solo una parte dei costrutti utiliz-zabili in Spark. Inoltre, mentre in MapReduce i job dovevano seguire rigida-mente il paradigma, in Spark i job possono descrivere workflow con un numero arbitrario di fasi;

• Performance elevate: Spark permette l’elaborazione dei dati in memoria, questa caratteristica migliora le performance soprattutto nel caso in cui i dati siano soggetti a numerosi fasi di elaborazione. MapReduce, infatti, prevedeva la scrittura su HDFS di ogni risultato intermedio. Inoltre il fatto di poter creare workflow generalizzati migliora le performance per quei job che non si adattano perfettamente al paradigma MapReduce;

• Facilit`a di programmazione: Apache Spark `e sviluppato in modo da essere accessibile ad alto livello, infatti offre API in Python, Java e Scala;

• Multifunzionalità: Spark accentra in un unico strumento ciò che fino ad ora doveva essere affrontato con una pluralità di tool e linguaggi poco integrati fra loro. Permette infatti all’interno di una singola applicazione l’elaborazione dei

(21)

dati sia in modalit`a batch che in real-time (Lambda architecture) e l’utilizzo di SQL, librerie di Machine Learning e Graph Analysis

Tutti i job Spark prevedono una serie di operazioni che vengono eseguite su un da-taset. Spark organizza tutte le operazioni in un grafo diretto aciclico (DAG) che viene ottimizzato riordinando e combinando le operazioni quando possibile.

Figura 3.6: Esempio di DAG Spark

Il DAG Scheduler suddivide gli operatori del grafo in stage map/reduce. Ogni stage `

e composto da task che operano sulla stessa partizione di dati. Gli stage vengono passati al Task Scheduler che li manda in esecuzione attraverso il ResourceMana-ger YARN, se stiamo lavorando su un cluster Hadoop. In realtà Hadoop non è un pre-requisito necessario per il funzionamento di Spark che è in grado di funzionare anche con altri sistemi di memorizzazione, come Cassandra oAmazon S3 per citarne alcuni, e altri resource manager come Apache Mesos o in modalità standalone.

Per essere eseguita su un cluster Hadoop un’applicazione Spark ha quindi bisogno di connettersi al ResourceManager del cluster che si occupa di allocare le risorse a disposizione tra le applicazioni che ne richiedono.

All’interno di ogni applicazione Spark deve essere definito lo SparkContext che ge-stisce la connessione con il ResourceManager. Una volta connesso, Spark acquisisce esecutori sui nodi del cluster ossia processi che effettivamente eseguono l’elabora-zione in modo distribuito. A questo punto, attraverso lo SparkContext, il codice dell’applicazione viene inviato agli esecutori e infine ad ogni esecutore vengono in-viati i task da elaborare.

Come detto in precedenza, Apache Spark è nato con lo scopo di effettuare in modo efficiente analisi di dati. Per raggiungere questo obiettivo è stato suddiviso in componenti specializzate che risultano però ben integrate tra loro:

(22)

Figura 3.7: Architettura di un cluster Spark

• Spark Streaming `e utile per l’elaborazione real-time dei dati;

• GraphX consente la manipolazione parallela di grafi;

• MLLib `e una libreria che offre la versione parallela dei principali algoritmi di machine learning.

Come visibile dall’architettura di Spark, mostrata in Figura 3.8, alla base di questi moduli troviamo lo Spark Core che si occupa di fornire funzionalit`a di base, neces-sarie a tutti le componenti specializzate, come l’interazione con il file system o con il gestore delle risorse.

(23)

Consideriamo in modo pi`u dettagliato i due moduli che pi`u sono stati utilizzati durante questo progetto: lo Spark core e Spark SQL.

Il primo mette a disposizione un’astrazione per manipolare i dati: il resilient distributed dataset (RDD). Un RDD `e una collezione distribuita di elementi su cui possono essere effettuate le seguenti operazioni: creazione, trasformazione e azione.

• La creazione di un RDD pu`o essere effettuata caricando un dataset esterno oppure parallelizzando una collezione di dati prodotti dal programma. Nel momento in cui un RDD viene creato, Spark automaticamente distribuisce tra i nodi del cluster i dati contenuti al suo interno;

• Le trasformazioni sono quelle operazioni con cui si costruisce un nuovo RDD attraverso la manipolazione di un RDD di partenza;

• Le azioni effettuano un elaborazione su un RDD e restituiscono il risultato al programma chiamante.

Sebbene un RDD possa essere definito in ogni momento, Spark effettua una valuta-zione lazy. Ci`o significa che quando viene chiamata una trasformazione su un RDD l’operazione non viene eseguita immediatamente. Spark memorizza i metadati che indicano che una determinata operazione `e stata richiesta. Solamente quando su questo RDD viene richiesto di eseguire un azione allora la richiesta viene elaborata. Questo approccio permette di elaborare solamente la porzione di dati necessaria per eseguire una determinata azione risparmiando sia in termini di tempo che di spazio.

Spark SQL `e l’interfaccia offerta da Spark per lavorare con dati strutturati o semi-strutturati. Spark SQL permette di caricare e interrogare queste tipologie di dato in modo semplice ed efficiente. In particolare vengono offerte tre importanti funzionalit`a:

• Caricamento dati da sorgenti strutturate, come file JSON, Hive, Parquet;

• Interrogazione dei dati mediante query SQL all’interno di programmi Spark oppure mediante tool esterni che si connettono a Spark SQL;

• Elevata integrazione tra l’SQL e codice Python/Java/Scala/R.

Per implementare queste funzionalit`a SparkSQL fa uso di un particolare astrazione, il DataFrame. Esso non `e altro che una collezione distribuita di dati organizzata in colonne e su cui possono essere eseguite normali query SQL, ma che presenta delle ottimizzazioni rispetto ai DataFrame R o Python grazie all’intervento di un ottimizzatore di query che viene eseguito automaticamente ogni volta che viene invocata un azione su un DataFrame.

Prima che ogni operazione su un DataFrame venga eseguita, il Catalyst optimizer trasforma l’albero associato alla query seguendo le quattro fasi visibili in Figura 3.9:

(24)

analizza l’albero logico per capire le dipendenze tra le operazioni, ottimizza l’albero logico, crea l’albero fisico e infine trasforma le parti delle query in JVM bytecode. Nella fase di generazione del piano di accesso fisico, Catalyst può generare più piani, confrontare i costi e scegliere infine quello più conveniente.

Figura 3.9: Processo di ottimizzazione delle query

Un DataFrame può essere costruito a partire da varie sorgenti dati come file strutturati, tabelle Hive, database esterni o RDD già esistenti. L’accesso alle fun-zionalità di SparkSQL avvengono attraverso la classe SQLContext. Come avviene per gli RDD, anche i DataFrame vengono valutati in modo lazy, quindi le trasfor-mazioni definite su di essi vengono eseguite solo quando viene richiesta un azione. Inoltre tutte le operazioni su DataFrame vengono automaticamente parallelizzate e distribuite sul cluster.

3.3 Confronto tra Hadoop e RDBMS

Hadoop presenta alcune caratteristiche che lo rendono particolarmente adatto per effettuare analisi in larga scala.

(25)

Prima di tutto Hadoop è adatto per applicazioni che richiedono di effettuare analisi sull’intero dataset, al contrario di un RDBMS che permette di indicizzare i dati in modo da rendere veloci query e update che fanno riferimento a piccole quantità di dati. Quindi Hadoop è adatto a applicazioni in cui i dati vengono scritti una volta e letti spesso mentre un database relazionale è utile nel caso in cui il dataset venga continuamente aggiornato

Una seconda differenza che si incontra confrontando Hadoop con un RDBMS riguarda quanto sono strutturati i dati con cui si deve lavorare. I dati strutturati, organizzati in entità con un formato ben definito, sono adatti ad essere gestiti tra-mite un RDBMS ma anche Hadoop fornisce gli strumenti per poter gestire questa tipologia di dato. I dati semi-strutturati, in cui lo schema può non essere definito, e i dati non strutturati che non presentano quindi alcuna struttura interna sono diffi-cilmente gestibili tramite RDBMS mentre Hadoop lavora bene su questa tipologia di dato. Più in generale, i sistemi tradizionali richiedono agli utenti di creare uno sche-ma prische-ma di caricare dati all’interno del sistesche-ma stesso, si parla di Schesche-ma-on-Write. Questo consente ai sistemi di controllare attentamente l’organizzazione fisica dei dati nella fase di caricamento in modo da velocizzare i tempi di risposta alle interroga-zioni. Hadoop utilizza invece un approccio meno rigido: i dati vengono caricati nel sistema nella loro forma originale e il loro schema viene definito al momento della lettura, si parla in questo caso di Schema-on-Read. Ciò rende questo sistema adatto a gestire dati la cui struttura è in continua evoluzione. Da questa differenza di fondo derivano le differenze anche dal punto di vista pratico: mentre negli RDBMS i dati devono essere trasformati in base alla struttura interna del database prima di essere caricati, in Hadoop è in fase di lettura dei dati che ne viene inferita la struttura; per aggiungere nuove colonne a un database è necessario modificarne la struttura prima di poter caricare i dati mentre su Hadoop i dati possono essere aggiunti e estratti in ogni momento.

Hadoop scala linearmente con la dimensione dei dati. I dati vengono partizionati e le funzioni primitive possono lavorare in parallelo su partizioni separate. Questo significa che se viene raddoppiata la quantità dell’input raddoppia anche il tempo di elaborazione. Tuttavia se viene raddoppiata la dimensione del cluster il job verrà eseguito più velocemente rispetto a quello originale. Questo in generale non è vero per le query SQL eseguite con un RDBMS.

Vista la necessità di effettuare analisi ad hoc su un dataset che è composto da una collezione di file in formato JSON, e in cui la struttura non sempre è corretta, `

e sembrato più appropriato utilizzare Hadoop anziché un RDBMS classico. Inoltre, come spiegato nel Capitolo 1, in questo progetto è stato scelto di adottare queste tecnologie anche per acquisire conoscenze e competenze che verranno sfruttate in progetti futuri dove la mole di dati e la complessità dei problemi da affrontare renderà assolutamente necessario1`ı l’utilizzo degli strumenti descritti.

(26)

Capitolo 4

Raccolta dati

Prima di entrare nel dettaglio riguardo la metodologia utilizzata per raccogliere e analizzare i dati `e necessario descrivere le principali caratteristiche delle applicazioni Web di media-sharing.

Come detto in precedenza, i dati sono raccolti da due applicazioni Web: Flickr e Panoramio. La scelta di utilizzare queste applicazioni come sorgente di dati sono principalmente due:

• il largo utilizzo di queste due piattaforme da parte degli utenti. Flickr infatti conta oltre 112 milioni di utenti iscritti appartenenti a 63 diverse nazioni. In media ogni giorno viene pubblicato 1 milione di immagini per un totale di oltre 10 miliardi di fotografie condivise. Panoramio `e una comunit`a mondiale con oltre 120 milioni di immagini condivise e caricate su Google Maps;

• entrambi forniscono delle API per accedere ai dati.

La differenza sostanziale tra le due applicazioni considerate è dovuta al fatto che la natura di Panoramio porta l’utente a caricare immagini che hanno come soggetto luoghi visitati mentre Flickr è maggiormente orientato all’aspetto social, spingendo l’utente a condividere immagini che non sempre hanno un riferimento spaziale pre-ciso. In entrambi i casi alle immagini sono associate informazioni come titolo, tag, descrizione e commenti. Inoltre alle immagini può essere aggiunta l’informazione geografica mediante un processo noto come geotagging.

4.1 Meccanismo per la raccolta dei dati

In questa sezione viene descritto brevemente il meccanismo su cui ci si `e basati per la raccolta dei dati a partire dai siti di media-sharing.

Per portare a termine questo processo `e necessario eseguire un altissimo numero di richieste via API e di processare i file che si ottengono come risposta. Per far ci`o `

e necessario automatizzare il processo e sviluppare una semplice applicazione Web.

(27)

CAPITOLO 4. RACCOLTA DATI 23

Il primo passo è quello di creare un file contenente una lista di bounding box, ossia quadruple che rappresentano le aree da cui si vogliono estrarre le immagini. Questo file viene letto come input dallo script Python che costruisce la richiesta HTTP utilizzando i parametri necessari. La richiesta viene poi inoltrata tramite servizi web al database da cui vengono estratti i dati. Il passo successivo è quello di ricevere le risposte, sotto forma di file JSON, elaborarle e memorizzare i file sul cluster che utilizza HDFS. Lo schema dell’architettura dell’applicazione Web è mostrata nella Figura 4.1.

Figura 4.1: Meccanismo raccolta dati

4.2 Flickr

Flickr `e un sito web nato nel 2002 ed utilizzato dagli utenti per memorizzare, or-ganizzare e condividere fotografie. Abbiamo utilizzato i metadati delle immagini Flickr come sorgente di dati per individuare il comportamento dei turisti in Italia. Un insieme di immagini con associate informazioni spazio temporali `e in grado di fornire informazioni interessanti sulla presenza di persone in un luogo ed in un esatto

(28)

momento.

Nel database Flickr sono memorizzate sia le fotografie che i relativi metadati, in-clusi la data e ora di scatto. Una parte delle fotografie contiene anche un attributo di localizzazione. Friedland e Sommer in [12] sostengono che solamente al 4,3% delle fotografie caricate nei primi quattro mesi del 2010 siano associate le coordinate. La localizzazione della foto può essere associata automaticamente dalla macchina oppu-re può essere indicata manualmente posizionando l’immagine su una mappa. Flickr automaticamente associa un valore di accuratezza a tutte le foto con associate le coordinate geografiche. L’applicazione basa questo valore sul livello di zoom della mappa nel momento in cui l’immagine viene geo-taggata. I valori di accuratezza che vengono associati variano tra mondo (1), nazione(3), regione(6), città (11) e strada(16).

Nella sezione precedente abbiamo spiegato teoricamente come si realizza il mec-canismo della raccolta dei dati, vediamo adesso in pratica come `e stata realizzata questa fase.

Un client può richiedere metadati al server Flickr mediante una richiesta HTTP-GET che deve contenere l’URL del server e alcuni parametri correttamente impo-stati. In particolare è fondamentale specificare la API-key e il tipo di formato in cui i dati verranno restituiti. Il server risponde con un file, in formato XML o JSON a seconda di come è stato specificato, che contiene tutti i metadati richiesti.

Il metodo flickr.photos.search `e stato utilizzato per ottenere i metadati relativi alle immagini con geotag in territorio italiano.

Le API Flickr pongono alcuni limiti per il download di metadati: vengono re-stituite un massimo di 16 pagine con al più 250 foto per pagina. Per cercare di rispettare questo limite è stata costruita una griglia sopra il territorio italiano, sud-dividendolo in aree di 0,1 x 0,1 gradi decimali. Tuttavia non è possibile sapere a prescindere quante foto siano presenti in ogni zona individuata, quindi nel caso in cui il limite di 4.000 foto venga superato, il metodo GET flickr.photos.search vie-ne richiamato ricorsivamente su aree sempre più piccole finché il limite non viene rispettato.

Per effettuare correttamente la ricerca `e stato necessario impostare alcuni para-metri:

• bbox: lista contenente quattro valori che rappresentano la bounding box del-l’area in cui effettuare la ricerca. I quattro valori rappresentano il vertice in basso a sinistra e quello in alto a destra dell’area e corrispondono quin-di a longituquin-dine minima, latituquin-dine minima, longituquin-dine massima e latituquin-dine massima;

(29)

• accuracy: di default assume valore 16 in modo che la query restituisca solamente le fotografie con accuratezza di posizionamento massima;

• has geo: settato a 1 in modo che la query restituisca solamente le immagini con associato un geotag;

• extras: lista contenente informazioni che la query deve restituire per ogni foto. Tra i campi possibili `e stato scelto di inserire solamente il valore geo in modo che vengano restituite le coordinate associate alla fotografia;

• per page: settato a 250, rappresenta il numero di fotografie che vengono restituite per ogni pagina;

• page: indica il numero della pagina restituita dalla query, viene utilizzato per scorrere tutte le pagine restituite dalla query.

E’ stato sviluppato uno script Python che fa uso della libreria python-flickr-api per effettuare richieste e salvare i file JSON restituiti. Nella Figura 4.2 `e riportato un frammento dello script Python realizzato.

Figura 4.2: Frammento di codice - Funzione get photos

Ad ognuna di queste richieste il server risponde con un file JSON. Con SparkSQL `e possibile inferire lo schema di un file JSON e caricarlo in un RDD che poi pu`o essere manipolato mediante le API Python fornite da Spark. La Tabella 4.1 descrive gli

(30)

attributi dei metadati che vengono restituiti dall’interrogazione.

Attributo Descrizione

accuracy Accuratezza della localizzazione della fotografia

context Valore numerico che indica se la fotografia `e stata scattata all’interno o all’esterno

datetaken Timestamp associato alla fotografia

datetakengranularity Granularit`a del timestamp

farm Numero del server farm su cui `e memorizzata la

fotografia

id Identificativo univoco della fotografia

isfamily Indica se la fotografia `e visibile solamente agli utenti classificati come famiglia

isfriend Indica se la fotografia `e visibile solamente agli utenti classificati come amici

ispublic Indica se la fotografia `e pubblica

latitude Latitudine associata alla fotografia

longitude Longitudine associata alla fotografia

owner Identificativo del fotografo

place id Identificativo del luogo in cui `e posizionata la fotografia, attribuito automaticamente da Flickr

secret Numero esadecimale generato quando la fotografia

viene caricata su Flickr

server Numero del server su cui `e memorizzata la fotografia

tags Insieme di parole che descrivono il contenuto della

fotografia

title Titolo della fotografia

woeid Identificativo univoco di un’entit`a geografica

Tabella 4.1: Flickr: attributi per fotografia

Utilizzando questo metodo sono stati raccolti i metadati di 7.512.960 foto.

Flickr offre la possibilità di recuperare anche alcune informazioni riguardanti gli utenti. Per far ciò è stato sviluppato uno script Python che fa uso della libreria python-flickr-api in cui viene invocato il metodo GET flickr.people.getInfo che,

(31)

rice-CAPITOLO 4. RACCOLTA DATI 27

vuto in input il codice che identifica un utente, restituisce un file JSON che descrive ogni utente attraverso gli attributi descritti nella Tabella 4.2.

can buy pro Indica se l’utente pu`o acquistare l’account PRO

description Campo descrittivo dell’utente

has stats Indica se sono disponibili le statistiche per l’utente

iconfarm Identificativo del server farm su cui `e memorizzata la buddy icon dell’utente

iconserver Identificativo del server su cui `e memorizzata la buddy icon dell’utente

id Identificativo univoco dell’utente

ispro Indica se l’utente possiede un account PRO

location Informazione sulla localit`a di residenza dell’utente

mobileurl URL che fa riferimento alla versione mobile del profilo dell’utente

nsid Numero identificativo dell’utente

path alias Path alias che fa riferimento al percorso in cui `e memorizzato il file

profileurl URL che fa riferimento alla pagina del profilo dell’utente

realname Nome dell’utente

timezone Fascia oraria a cui appartiene la citt`a di residenza dell’utente

username Username con cui l’utente `e iscritto a Flickr

Tabella 4.2: Flickr: attributi per utente

In questo modo sono state recuperate le informazioni relative agli utenti che hanno caricato foto su Flickr nel periodo analizzato.

Uno degli attributi più interessanti è sicuramente il campo location in cui ogni utente, al momento dell’iscrizione al sito, specifica la sua origine. La problematica che risulta evidente guardando il contenuto del campo è il fatto che Flickr lascia piena libertà di inserimento di tale dato. Wood, Guerry et al. in [16] hanno verificato che la località inserita dall’utente nel proprio profilo è generalmente corretta. Nella loro ricerca hanno confrontato i valori dell’attributo location con la nazionalità dei visitatori registrati presso i centri per l’immigrazione e hanno individuato una forte correlazione tra le due variabili.

(32)

basandosi sulla località di origine che hanno indicato nel proprio profilo. Per ottenere tale risultato è stato utilizzato il database GeoNames, un database open source che contiene più di 10 milioni di nomi geografici che fanno riferimento a oltre 9 milioni di luoghi di interesse univoci. Oltre al nome del luogo, disponibile in varie lingue, GeoNames fornisce informazioni geografiche aggiuntive come latitudine, longitudine, altitudine, popolazione, classificazione amministrativa e codice postale.

Sul contenuto dell’attributo location `e stato effettuato un semplice processo di pulizia del dato: mediante apposite librerie Python sono state effettuate operazioni come l’eliminazione di caratteri speciali, simboli di punteggiatura e lettere maiuscole in modo da facilitare la ricerca dei nomi all’interno del database GeoNames. Tuttavia non `e stato possibile individuare automaticamente il nome delle nazioni di origine di tutti gli utenti, in quanto sono presenti errori di scrittura o abbreviazioni che non sono presenti nel database GeoNames, ad esempio Sydney viene spesso abbreviata con Sid o Syd.

4.3 Panoramio

Panoramio è un sito web di condivisione di fotografie con un sistema di geolocalizza-zione nato nel 2005 e acquistato da Google nel luglio 2007 . Le foto caricate sul sito dagli utenti risultano infatti visibili direttamente sulla mappa di Google Maps. Nel tempo si è formata una numerosa comunità di appassionati che utilizza regolarmente questa piattaforma.

Panoramio mette a disposizione alcune API che permettono di scaricare i meta-dati delle fotografie sia per scopo commerciale che non commerciale.

Un client pu`o effettuare una semplice richiesta GET mediante un API REST. In questa richiesta devono essere specificati alcuni parametri:

• bounding box: definita come una quadrupla che delimita l’area di ricerca del-le foto. I quattro valori quindi corrispondono a longitudine minima, latitudine minima, longitudine massima e latitudine massima;

• from e to: valori che rappresentano gli estremi dell’intervallo di foto che viene restituito dalla query.

I dati sono infatti liberamente scaricabili da Panoramio ma devono essere rispettati due limiti di download: al massimo possono essere scaricate 100 fotografie per query e non possono essere effettuate pi`u di 100.000 query al giorno.

Per cercare di rispettare tale limite è stato usato un criterio simile a quello adottato con Flickr: prima di tutto il territorio italiano è stato suddiviso in bounding box di dimensione 0,1 x 0,1 gradi decimali; considerando il valore della variabile count restituita dalla query, che indica il numero totale di foto presenti all’interno dell’area selezionata, è stato realizzato uno script Python che per ogni bounding box esegue

(33)

un ciclo che permette di scaricare tutte le foto rispettando i limiti di download in quanto la differenza tra i parametri from e to viene sempre tenuta inferiore a 100. Il seguente frammento di codice mostra questo procedimento.

Figura 4.3: Frammento di codice - Utilizzo API Panoramio

Ogni query effettuata restituisce un file JSON. L’intero dataset `e stato caricato su un nodo HDFS e manipolato mediante le API Python offerte da Spark. La Tabella 4.3 riporta gli attributi dei metadati delle immagini di Panoramio.

height Altezza dell’immagine

latitude Latitudine associata alla fotografia longitude Longitudine associata alla fotografia owner id Identificativo univoco dell’utente

owner url URL che fa riferimento al profilo dell’utente

(34)

Tabella4.3: continua dalla pagina precedente

photo file url URL che indirizza all’immagine photo id Identificativo univoco della fotografia photo title Titolo della fotografia

place id Identificativo del luogo in cui `e posizionata la fotografia, assegnato automaticamente da Panoramio

upload date Timestamp associato alla fotografia

width Larghezza dell’immagine

Tabella4.3: si conclude dalla pagina precedente

Tabella 4.3: Panoramio: attributi per fotografia

(35)

Capitolo 5

Data pre-processing

Il pre-processing è quell’attività che mira a migliorare la qualità dei dati prima di sottoporli ad analisi. La presenza di informazioni ridondanti, irrilevanti o errate può rendere difficile l’interpretazione dei dati e per questo motivo questa fase è fondamentale per il buon esito dell’intero processo.

Questo capitolo ha lo scopo di illustrare tutte le fasi che sono state affrontate al fine di eliminare dal dataset quei record che non sono utili a fini analitici. Tra tutti gli attributi che caratterizzano ogni fotografia, descritti nel capitolo precedente, quelli a cui principalmente siamo interessati sono le coordinate geografiche e il timestamp.

5.1 Eliminazione dei duplicati

La prima operazione di pulizia dei dati ha lo scopo di eliminare i duplicati. Al fine dell’analisi che si vuole effettuare si ritiene interessante mantenere nel dataset sola-mente record univoci sui campi latitudine, longitudine, id utente. Ogni punto nel dataset cos`ı ottenuto testimonia la presenza di una persona in un preciso punto nello spazio. Per far ci`o `e sufficiente eseguire una query in cui si individuano le triple < latitudine, longitudine, id utente> univoche nei due dataset. Il frammento di codice seguente riguarda l’eliminazione dei duplicati dai dati scaricati da Flickr.

Figura 5.1: Frammento di codice - Eliminazione duplicati Flickr

In particolare viene definito un RDD, chiamato data flickr, in cui vengono selezio-nati solamente alcuni attributi del dataset di partenza. E’ stato poi costruito il DataFrame TableSchema a partire dall’RDD data flickr. Il DataFrame cos`ı definito viene poi registrato come tabella temporanea su cui viene effettuata la query per l’eliminazione dei duplicati. Conservando una sola occorrenza dei record duplicati

(36)

CAPITOLO 5. DATA PRE-PROCESSING 32

restano significativi solamente gli attributi latitudine, longitudine e id utente men-tre a tutti gli altri attributi viene assegnato il valore NULL.

5.2 Individuazione dei punti appartententi al territorio

italiano

Vista la metodologia utilizzata per la raccolta dei dati, ossia la definizione di un insieme di bounding box su cui effettuare le interrogazioni, `e inevitabile che non tutti i punti cadano all’interno del territorio italiano. Per poter eliminare i punti non interessanti `e necessario utilizzare alcuni dataset di supporto:

• dati geografici in formato shapefile forniti da Istat relativi alle seguenti zoniz-zazioni del territorio italiano: sezioni di censimento, aree di censimento, aree subcomunali, localit`a, comuni;

• mappa cartografica europea.

Il tool Intersect messo a disposizione dal software ArcGis calcola l’intersezione geometrica tra gli elementi appartenenti a due feature class. L’utilizzo di tale tool ha permesso di individuare 4 categorie di punti:

• punti che intersecano le sezioni di censimento italiane;

• punti che non intersecano le sezioni di censimento italiane ma che intersecano il territorio di uno stato europeo;

• punti che non intersecano con nessuna delle due cartografie. Tali punti sono in realtà situati lungo la costa italiana; i punti che distano più di 200 metri dal litorale sono stati considerati non interessanti mentre a quelli con distanza inferiore a 200 metri dalla costa è stato associato il codice della sezione di censimento più vicina.

Nella Figura 5.2 i punti colorati in verde sono quelli che intersecano le sezioni di censimento italiane mentre quelli in rosso sono quelli classificati come esteri. I punti colorati in blu nella prima immagine sono quelli le cui coordinate ricadono in mare, di questi sono stati mantenuti solamente quelli vicini alla costa, visibili in giallo nella seconda immagine.

(37)

(a) Dataset iniziale (b) Dataset dopo l’eliminazione dei punti all’estero e in mare

Figura 5.2: Mappa delle immagini prima e dopo il processo di pulizia

5.3 Eliminazione delle fotografie multiple per utente

Dopo aver selezionato solamente i punti relativi al territorio italiano sono state fat-te alcune analisi preliminari per capire come questi sono distribuiti nello spazio ed `

e emerso che accade spesso che un utente scatti molte fotografie in un’area molto limitata. Tale comportamento è stato considerato come una distorsione dell’infor-mazione in quanto ciò che è interessante ai fini delle analisi turistiche è il fatto che molte persone abbiano visitato un determinato luogo e non che vi abbiano scattato molte foto. Per questo motivo si è ritenuto opportuno considerare solamente una volta le fotografie scattate da uno stesso utente a distanza molto ravvicinata. Quin-di data una sezione Quin-di censimento s ed un utente u è stato deciso di mantenere nel dataset un solo record per ogni coppia <s, u>.

Nella Figura 5.3 viene mostrata la mappa di Milano con suddivisione per sezione di censimento e si mettono a confronto i dati originali con quelli ottenuti dopo l’eliminazione delle fotografie multiple. Le sezioni sono colorate in base al numero di punti per sezione di censimento, con una scala in cui il verde rappresenta i valori più bassi fino ad arrivare al rosso che si riferisce a quelli più alti. Nella prima immagine la quantità di punti per sezione di censimento è in generale più elevata, questo lo si può dedurre dalla presenza di numerose sezioni colorate in rosso, arancione e giallo. In particolare emergono le sezioni corrispondenti a Piazza Duomo e Palazzo Reale (in rosso); la stazione centrale, la Galleria Vittorio Emanuele e la zona di Porta Nuova (in arancione). Queste sono quindi le aree di Milano dove in valore assoluto sono state scattate due immagini.

(38)

Figura 5.3: Mappa di Milano prima e dopo l’eliminazione delle fotografie di un utente in una stessa sezione di censimento

Mantenendo un solo punto per ogni coppia <s, u> il significato dei colori visi-bili sulla mappa cambia leggermente: vengono contati infatti gli utenti distinti che hanno effettuato fotografie in quella sezione. Come nel caso precedente emerge il Duomo e la Galleria Vittorio Emanuele; in questo caso si nota per`o in arancione il Castello Sforzesco, che nel caso precedente non emergeva, mentre hanno minore incidenza la zona di Porta Nuova e della stazione centrale.

5.4 Eliminazione dei record con timestamp errato

Dopo aver ottenuto un dataset corretto dal punto di vista geografico `e stata consi-derata la dimensione temporale e sono stati individuati alcuni errori nei timestamp presenti tra i metadati delle fotografie. Infatti, nel dataset ottenuto da Flickr, 1.772 fotografie hanno data antecedente al 2002 mentre 89 fotografie hanno data successi-va al 2015. Tali record sono stati eliminati in quanto non si `e riuscita a giustificare la presenza di questi valori errati.

Per 556.740 foto questo attributo `e mancante ma `e stato deciso di mantenere nel dataset questi record in quanto tutti gli altri attributi sono significativi.

I metadati delle fotografie di Panoramio invece risultano corretti per quanto ri-guarda l’aspetto temporale, tutte le fotografie per cui l’attributo `e presente hanno data appartente al periodo preso in analisi; 382.351 immagini non hanno associata l’informazione temporale.

Al termine di questo procedimento sono stati ottenuti 2.315.981 punti con asso-ciato un codice di sezione di censimento per Flickr e 2.628.383 punti per Panoramio.

(39)

Capitolo 6

Semantic enrichment e

interpretazione dei dati

In questo capitolo vengono analizzati i dataset risultanti dalle fasi di raccolta dati e pre-processing.

Nella prima sezione viene descritto il processo che ha portato a capire quali utenti sono effettivamente dei turisti in modo da poter mantenere nel dataset solamente i dati che ci interessano al fine delle analisi da effettuare.

Nella seconda sezione vengono analizzati i dati a disposizione, quindi sia i dati social che i dati Istat relativi al turismo e vengono messi a confronto in modo da capire come le due sorgenti dati possano essere tra loro integrate in modo da estrarre informazioni il pi`u possibile complete.

6.1 Classificazione degli utenti

La fase di pre-processing descritta nel Capitolo 5, non considera un aspetto fonda-mentale, ossia il fatto che su Flickr e Panoramio non vengono caricate solamente foto dal chiaro aspetto turistico. L’analisi descritta in questa sezione ha lo scopo di effettuare una profilazione degli utenti presenti sul territorio italiano. In particolare si vogliono identificare le persone Residenti e Turisti in un determinato comune in base alle seguenti definizioni:

Residente Un utente u viene considerato Residente nel comune c se è il luogo in cui lavora o dimora. E’ considerato accettabile il fatto che a un utente venga associato più di un comune di residenza, si pensi ad esempio a una persona che lavora in un luogo diverso da quello in cui dimora o di cui è originario.

Turista Secondo l’Organizzazione Mondiale del Turismo (OMT) un turista `e “colui che viaggia in paesi diversi da quello in cui ha la residenza, al di fuori del proprio ambiente quotidiano (...) per almeno una notte e per un periodo non superiore a un anno” mentre gli escursionisti sono “coloro che trascorrono

(40)

CAPITOLO 6. SEMANTIC ENRICHMENT E INTERPRETAZIONE DEI DATI 36 meno di 24 ore nel Paese di destinazione e che non trascorrono la notte nelle strutture ricettive del Paese”. Al fine della nostra analisi siamo interessati a cogliere entrambi i fenomeni.

A partire da queste definizioni sono state costruite delle regole che data una coppia <utente, comune> la classifichi come Residente o Turista in base al comportamento dell’utente. Sono state calcolate una serie di variabili che prendono in considera-zione principalmente la dimensione temporale della foto per capire se un utente si comporta da turista o residente in un determinato comune nell’intervallo di tempo considerato.

6.1.1 Il modello

Al fine di classificare ogni coppia <utente, comune> come Residente o Turista `e stato costruito un sistema di regole a partire dalle variabili a disposizione.

Di seguito vengono descritte le regole che sono state definite. Per ogni coppia <u,c>, con u un utente e c un comune:

• Se u ha fatto foto solamente in un anno nel comune c:

◦ u `e residente in c se e solo se vale una delle seguenti condizioni: − u ha fatto foto in c in pi`u di 4 mesi distinti;

− u ha fatto foto in c in 3 stagioni su 4.

◦ u `e in vacanza in c se e solo se vale una delle seguenti condizioni: − u ha fatto foto in c solo nei weekend;

− u ha fatto foto in c solo in estate; − u ha fatto foto in c in una stagione su 4;

− u ha fatto foto in c in due settimane durante l’intero anno.

Queste regole vanno quindi a riconoscere come residente quell’utente che fre-quenta regolarmente un determinato comune mentre la seconda regola individua comportamenti tipici del turismo italiano.

Un simile ragionamento `e stato applicato a quegli utenti che hanno fatto foto nell’arco di pi`u anni in uno stesso comune:

• Se u ha fatto foto in pi`u anni distinti nel comune c:

◦ u è residente in c se e solo se vale una delle seguenti condizioni: − in ogni anno u ha fatto foto in c in più di 4 mesi distinti ; − u ha fatto foto in c in 3 stagioni su 4 nell’arco dei vari anni. ◦ u è in vacanza in c se e solo se vale una delle seguenti condizioni:

(41)

CAPITOLO 6. SEMANTIC ENRICHMENT E INTERPRETAZIONE DEI DATI 37 − u ha fatto foto in c solo in estate;

− u ha fatto foto in c in una stagione su 4;

− u ha fatto foto in c nella stessa stagione nell’arco dei vari anni.

Le regole appena definite sono piuttosto forti e non riescono a classificare tutte le coppie. Per riuscire ad attribuire una classificazione anche a tali coppie si `e scesi ad un livello di aggregazione pi`u basso e sono state definite due ulteriori regole per ogni tripla <u, c, a>, con u un utente, c un comune e a un anno :

• u `e residente in c se e solo se durante l’anno a vale una delle seguenti condizioni:

◦ in ogni anno u ha fatto foto in c in pi`u di 4 mesi distinti;

◦ u ha fatto foto in c in 3 stagioni su 4.

• u `e in vacanza in c se e solo se durante l’anno a vale una delle seguenti condizioni:

◦ u ha fatto foto in c solo nei weekend ; ◦ u ha fatto foto in c solo in estate;

◦ u ha fatto foto in c in una stagione su 4;

◦ u ha fatto foto in c in due settimane durante l’intero anno.

6.1.2 Risultati ottenuti

Le regole definite nella sezione precedente sono state applicate ai due dataset risul-tanti dalla fase di pre-processing.

La Tabella 6.1 mostra i risultati ottenuti applicando il modello descritto nella sezione precedente ai dati di Flickr. Poich´e siamo interessanti solamente ai turisti, il 79% delle coppie <utente,comune> rientrano in questa categoria, che corrispondono al 68% delle fotografie.

Numero coppie <utente,comune> Numero fotografie

Residenti 17.893 544.949

Turisti 337.200 1.565.067

Non classificati 72.101 200.965

427.194 2.315.981

Tabella 6.1: Flickr: Risultati della classificazione

In modo analogo la Tabella 6.2 riporta i risultati ottenuti applicando il modello ai dati di Panoramio.

(42)

CAPITOLO 6. SEMANTIC ENRICHMENT E INTERPRETAZIONE DEI DATI 38 Numero coppie <utente,comune> Numero fotografie

Residenti 27.246 600.206

Turisti 453.926 1.838.733

Non classificati 94.545 189.444

575.753 2.628.383

Tabella 6.2: Panoramio: Risultati della classificazione

In questo caso le coppie <utente,comune> che vengono classificate come turi-stiche sono il 79%, che corrispondono a circa il 70% delle fotografie raccolte.

Nella Figura 6.1 viene riportato un esempio del risultato ottenuto dopo l’esecu-zione del processo di classifical’esecu-zione sopra descritto.

Figura 6.1: Mappa delle immagini nell’area di Milano prima e dopo la classificazione

Le mappe con i punti in verde rappresentano il dataset iniziale mentre le mappe con i punti in rosso rappresentano solamente i punti classificati come turistici. Le prime due immagini si riferiscono ai dati Flickr mentre la seconda coppia riporta i dati Panoramio.

Grazie a questa analisi si `e riusciti a individuare i due dataset che verranno considerati utili al fine dell’individuazione delle zone di interesse turistico, ossia i 1.565.067 record di Flickr e i 1.838.733 record di Panoramio classificati come turistici.