sistemi bigdata e strumenti di analisi · fonda l’ architettura, ovvero un file system...

43
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati Sistemi BigData e strumenti di Analisi Anno Accademico 2015/2016 Candidato: Paolo Valletta matr. N46002073

Upload: dinhmien

Post on 12-Sep-2018

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati

Sistemi BigData e strumenti di Analisi

Anno Accademico 2015/2016 Candidato: Paolo Valletta matr. N46002073

Page 2: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

[Dedica]

Page 3: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

Indice

Indice .................................................................................................................................................. III Introduzione ......................................................................................................................................... 4

I grandi magazzini di informazioni: Big Data ................................................................................. 5 Cenni storici ..................................................................................................................................... 8

Capitolo 1: Il mondo dei Big Data System ........................................................................................ 11

1.1 Le caratteristiche di un buon Big Data System ........................................................................ 11 1.2 Immutabilità vs. Paradigma Incrementale ............................................................................... 12 1.3 I limiti dello scaling ................................................................................................................. 13 1.4 Data Extraction: ETL o ELT? .................................................................................................. 14

1.4.1 Un approccio alternativo: ELT ........................................................................................ 15

Capitolo 2: Apache Hadoop ............................................................................................................... 17 2.1 Una soluzione: Apache Hadoop ............................................................................................... 17

2.3 Storage in un sistema Big Data ................................................................................................ 19 2.3.1 Filesystem distribuiti ......................................................................................................... 20 2.3.2 Problemi comuni ............................................................................................................... 21 2.3.3 Hadoop Distributed FileSystem ........................................................................................ 23

2.4 Data Computation .................................................................................................................... 24 2.5 MapReduce .............................................................................................................................. 24

Capitolo 3: Apache Pig ...................................................................................................................... 27 3.1 Apache Pig ............................................................................................................................... 27 3.2 Pig Latin ................................................................................................................................... 28

3.3 Perché usare PigLatin............................................................................................................... 28

3.4 Features del linguaggio ............................................................................................................ 29 3.5 Pig vs. SQL .............................................................................................................................. 29

Capitolo 4: Analisi di un caso pratico ................................................................................................ 33

4.1 Caso di studio ........................................................................................................................... 33 4.2 Setup dell’ architettura ............................................................................................................. 34

4.2.1 Apache Hadoop ................................................................................................................. 34

4.2.2 Apache Pig Latin ............................................................................................................... 35 4.3 Dati di input ............................................................................................................................. 36

4.4 Lo Script ................................................................................................................................... 38 Conclusioni ........................................................................................................................................ 42 Bibliografia ........................................................................................................................................ 43

Page 4: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

4

Introduzione

Lo scopo di questo elaborato è trattare il mondo dei Big Data System, senza tralasciare gli

strumenti di analisi (analytics tools) ad esso collegati. In questa tesi si affronta tale tema

sviluppandolo in 4 capitoli, così da applicare un approccio sia teorico che pratico. Il titolo

adoperato, “Big Data System e strumenti di analisi”, vuole mostrare, difatti, la scelta di tali

approcci. Nei vari capitoli, il tema dei Big Data sarà sviscerato il più possibile, partendo

da una semplice presentazione del dominio trattato, passando poi ad una elencazione delle

problematiche e delle nuove sfide che nascono in tale ambiente, e arrivando infine a

provare e valutare un prodotto reale, utilizzato oggi da svariate aziende del settore.

Inizialmente, vi saranno dei paragrafi che introdurranno ai Big Data System, ovvero questi

grandi magazzini di dati (noti anche come data warehouse) sviluppatisi soprattutto nella

storia recente, le cui sfide ruotano intorno a come gestire questa grossa e vasta mole di

informazioni.

Il primo capitolo, che fa da contorno all’ introduzione stessa, effettua una disamina sulle

caratteristiche e le principali features che un sistema Big Data (correttamente strutturato)

debba possedere e manifestare. Si andrà, infatti, ad analizzare le proprietà e le features

richieste ad un buon sistema, che è possibile ottenere applicando determinate tecniche

durante la progettazione e lo sviluppo dell’ intera architettura. Da qui nascerà un discorso

riguardo il contrapporsi di due approcci differenti riguardo la gestione del data model,

quali immutabilità e paradigma incrementale. Verrà mostrato come quest’ ultimo risulterà

in affanno con i data warehouse e cederà quindi il passo all’ altro approccio, che meglio

calzerà le richieste dei developer e dei clienti finali. Successivamente, verrà accennato il

processo di data mining e saranno descritti due modalità di ottenimento, processazione e

memorizzazione dei dati: ETL (Extraction, Transform, Load) ed ELT (Extraction, Load,

Transform). Infine si parlerà di come il problema della scalabilità sia centrale nello

sviluppo dei Big Data System e di come questo influenzi le scelte di progettazione e

realizzazione dei sistemi finali.

Il capitolo due, invece, abbandonerà la linea di presentazione e descrizione che ha

Page 5: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

5

contraddistinto il capitolo primo. Si parlerà qui di Apache Hadoop, introducendo questioni

ed analisi di problemi più tecnici riguardo tale piattaforma. Ovviamente, non mancherà

una disamina teorica della stessa, a partire dalla sua storia ed evoluzione per arrivare a

come oggi venga ampiamente adoperata, dato che realizza e soddisfa i principi cardini di

un sistema BigData corretto. In particolare, saranno presentati i due componenti su cui si

fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e

un sistema di computazione distribuita (MapReduce). Il problema dell’ archiviazione e

della gestione dei dati sarà sviscerato e trattato a fondo, presentando non solo le difficoltà

che si incontrano, ma anche dei confronti tra diversi approcci possibili, definendo infine le

soluzioni proposte ed offerte da Apache Hadoop.

I primi due capitoli serviranno, così, a gettare le basi per fondare ed entrare nel terzo

capitolo: qui sarà presentato un componente di Apache Hadoop chiamato Pig. Mantenuto e

sviluppato anch’ esso da Apache, si tratta di una piattaforma che offre allo sviluppatore

degli strumenti per realizzare task distribuiti in MapReduce. Il grande vantaggio che lo

caratterizza riguarda la forte libertà che offre al developer: oltre a consentire di scrivere

degli script adoperando un linguaggio più espressivo di un classico SQL, esso permette di

integrare tale codice con altro scritto in linguaggi differenti o addirittura legacy. Qui verrà

analizzato l’ intero strumento, presentando pro e contro che comporta la sua scelta. Il

linguaggio di Apache Pig che si andrà a discutere è Pig Latin, che vedremo presenta

caratteristiche versatili e agevoli im merito a Big Data System e di programmazione

distribuita su MapReduce Jobs.

Infine, con l’ ultimo capitolo si proverà sul campo l’ efficacia e le potenzialità di Pig

Latin, tramite un caso di studio creato ad hoc. I risultati ottenuti potranno così confermare

quanto descritto e dicusso a riguardo, validando così quanto scritto su di esso.

I grandi magazzini di informazioni: Big Data

Oggi giorno, grazie alla diffusione di internet e dispositivi mobili, viene prodotta una

quantità di dati poderosa. Dai social network, ai siti di video-content fino ai “semplici”

blog, il web 2.0 ha permesso a chiunque di diventare un creatore di contenuti. Questi

Page 6: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

6

contenuti, che tutti noi magari ci limitiamo a pensare siano posts, video, gifs di gattini e

mp3 del nostro cantante preferito, si tramutano in bit, tanti bit, tutti da memorizzare,

gestire, e organizzare.

Il termine utilizzato per indicare questa mole di dati vasta e eterogenea è Big Data. Come

stesso la parola ci suggerisce, stiamo parlando di qualcosa di sproporzionato rispetto alla

solita concezione comune di database o di quantità di informazioni gestite digitalmente.

Questo è sostanzialmente un

mondo da poco, e soprattutto

negli ultimi anni ha visto una

forte crescita. Questa è dovuta

molto agli interessi economici

di aziende in vari settori, che

hanno visto un’ opportunità di

crescita considerevole per i loro

business. Tali interessi ruotano

soprattutto intorno a ciò che viene chiamato “analitycs” dei dati, che consiste di un

insieme di operazioni e processi su queste informazioni al fine di trarne risposte utili per

diversi fini. Sicuramente, l’ aspetto più tangibile e vicino a noi, che ci può permettere di

capire perché è interessante e utile tener memoria di così tante informazioni, sono le

pubblicità mirate. Immaginiamo di visitare un sito di e-commerce, cerchiamo una camicia

o una maglia, e subito quel prodotto sembra iniziare a perseguitarci ovunque andiamo: la

nostra banale ricerca di un indumento è già finita in un grande magazzino di dati, è stata

elaborata e ora è usata a nostro vantaggio (o forse svantaggio?) per adattare i pop-up

pubblicitari ai nostri interessi. Sicuramente da alcuni sarà poco apprezzata tale pratica, ma

per l’ azienda è una miniera d’ oro, perché grazie alle analisi sui dati che ha raccolto

quando effettuiamo una ricerca, ora sa come prenderci “per la gola”, consigliando prodotti

a cui siamo più probabilmente interessati. Ovviamente, più dati una azienda raccoglie e

maggiori saranno le previsioni e le stime fatte, per questo si parla di quantità veramente

grandi. Altri esempi sono forse a noi meno evidenti, ma comunque di forte impatto:

Page 7: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

7

Twitter e Facebook (per citarne due) fanno uso di strumenti di analytics per analizzare i

milioni di tweets e posts scritti dagli utenti ogni giorno, così da capire i loro interessi e le

loro abitudini. L’ analisi, poi, potrà essere utilizzata per diversi fini, che spaziano dalla

pubblicità, ancora una volta, alla rilevazione degli influencer del web, per arrivare fino alla

lotta e al contrasto del terrorismo. Dei “semplici” post possono rilevare tanto su di noi, e

con gli strumenti giusti che lavorano ed incrociano tanti dati (eterogenei od omogenei)

queste aziende possono ottenere tante informazioni sulla nostra persona. Difatti, queste

tecnologie, grazie alla mole di dati in gioco, riescono a dare risposte anche molto accurate

a domande a cui sono interessate sia aziende private, mosse da interessi economici, che gli

stati nazionali di mezzo mondo, mossi da interessi di sicurezza (quasi sempre).

Data la maturazione dei concetti legati ai Big Data System, bisogna sottolineare come oggi

venga fatta una differenziazione basata sull’ utilizzo finale dei dati. Parliamo, infatti, di

business intelligence e big data come concetti differenti, pur avendo origini e concezioni

comuni:

• business intelligence utilizza la statistica descrittiva con dati ad alta densità di

informazione per misurare cose, rilevare tendenze, ecc., cioè utilizza dataset limitati, dati

puliti e modelli semplici;

• big data utilizza la statistica inferenziale e concetti di identificazione di sistemi non

lineari, per dedurre leggi (regressioni, relazioni non lineari, ed effetti causali) da grandi

insiemi di dati e per rivelare i rapporti, le dipendenze, e effettuare previsioni di risultati e

comportamenti, cioè utilizza dataset eterogenei (non correlati tra loro), dati raw e modelli

predittivi complessi.

(FONTE: https://it.wikipedia.org/wiki/Big_data#Differenze_con_business_intelligence)

Dunque, volendo tirare le somme, possiamo affermare che oggi è chiaro e comprovato che

la gestione e lo sfruttamento di dati digitali è passato dall’ essere una “competenza

importante” ad una differenziazione fondamentale e cruciale per le aziende di tutte le

dimensioni. Qualunque sia il settore aziendale di riferimento, i dati possono essere la

chiave per il successo e la crescita. Questi possono influenzare in positivo le strategie

adottate, migliorandole totalmente. Di fatti, lo sviluppo di tecnologie all’ avanguardia per i

Page 8: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

8

Big Data System non hanno visto il solo interesse di parte di aziende dell’ IT, interessate a

creare i prodotti giusti, ma anche di quelle di molti altri settori ingolosite dalle opportunità

offerte. I Big Data hanno dato un impulso innovativo sia allo sviluppo di nuovi mercati

che nel rivalutare e modificare totalmente vecchie strategie di marketing, rendendo

obsolete le società che non hanno saputo stare al passo con l’ innovazione. I Big Data

System non sono una semplice tecnologia nata nell’ IT, bensì un connubio di interessi

sviluppatasi anche grazie all’ inflenza di altri individui ed entità dei settori dell’ economia

di mezzo mondo.

Cenni storici

Essendo i Big Data System un recente campo dell’ informatica, nato con l’avvento di un

“web per tutti”, ci si è trovati con nuove sfide da fronteggiare. Dato che si è venuto a

creare in pratica un nuovo mercato, si è assistito ad una corsa di molte aziende ad

accaparrarsene quante più quote possibili. I primi sforzi per padroneggiare tutti questi dati

furono fatti senza produrre dei veri e propri nuove soluzioni software, bensì adattando ciò

che già esisteva. Dato che, negli ultimi 30 anni, nel campo dei database erano stati i

Relational Database

Management System

(RDBMS) a farla da

padrone, i primi approcci

alla gestione di così tanti

dati fu mediante tale

tecnologia. Dopo un po’,

però, il paradigma

relazionale ha mostrato i suoi limiti, che non permettevano un efficace controllo, utilizzo e

memorizzazione di questa grande mole di dati. Il grande problema con il quale ci si è

presto scontrati è stata la poca scalabilità che i sistemi RDBMS hanno dimostrato: i dati

sono cresciuti troppo, i database (o almeno, quelle tecnologie) non sono riusciti a stargli

dietro. Il classico modo di pensare (radicato nella maggior parte dei developer) della

Page 9: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

9

“tupla che raccoglie tutti i dati di un’ entità” si è rivelato poco efficace in questa

situazione, dove la grande mole di informazioni necessitava di altri tipi di trattamenti.

Inoltre, dover effettuare query era sempre più complicato, dato che i sistemi non

riuscivano a maneggiare l’ intero dataset e restituire risposte in tempi accettabili. Scalare il

sistema aggiungendo HDD e processori in più non ha dato i frutti sperati, in quanto la

potenza di calcolo arrancava ugualmente. C’era bisogno, insomma, di un nuovo approccio,

di un nuovo paradigma.

Partendo dal problema della memorizzazione, si è aperta una nuova era che ha visto la

produzione dei primi programmi software che cambiavano radicalmente approccio verso

questo aspetto. Il core e il focus di questi sistemi era proprio sullo storage, ottimizzato per

i tanti dati in gioco: nascono i sistemi database denominati NoSQL. Comunemente

chiamati anche “Not Only SQL”, queste tecnologie rappresentano dei potenti framework

applicati ai database, con approcci totalmente rivisitati rispetto a prima. Tali software

risultano delle architetture ben disposte e organizzate, specializzate proprio nella gestione

di vaste moli di dati. Questo processo è reso efficiente da una particolare differenza

rispetto ai database relazionali: la natura intrinsecamente unstructured dei dati. Questo

permette di applicare tecniche e strategie che assicurano maggior velocità di gestione e

scalabilità del sistema stesso. In tali database il crescente aumento continuo dei dati viene

dominato grazie ad una scalabilità ad approccio orizzontale, ovvero mediante l’ aggiunta

di nuove macchine al sistema. Gli strumenti software NoSQL sono stati prodotti in larga

quantità dalle più disparate aziende, tra cui le stesse che avevano particolarmente bisogno

di tali soluzioni. Ci hanno provato, tra gli altri, i grossi colossi come Amazon e Google,

che hanno presentato così i loro nuovi prodotti database. Ovviamente, la risposta del

mondo open source non ha tardato ad arrivare, così che oggi abbiamo a disposizione anche

soluzioni a codice libero. Difatto, esistono tanti software NoSQL utilizzati in vari ambiti

dei Big Data, tra i quali possiamo sicuramente citare MapReduce (by Google), Dynamo

(by Amazon), Hadoop (Apache, open source), HBase, MongoDB e Cassandra.

In questo modo, gli strumenti NoSQL sono riusciti a dare alle aziende ciò di cui avevano

bisogno per affrontare con successo le sfide dei BigData. Tuttavia, nonostante

Page 10: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

10

teoricamente tutto sembra funzionare ed andare per il verso giusto, la pratica si è rivelata

poi molto più ostica e articolata di come ce la si aspettava. Come esposto da una fine

analisi presenta da Nathan Marz nel libro “Big Data PRINCIPLES AND BEST

PRACTICES OF SCALABLE REAL-TIME DATA SYSTEMS”, notiamo che non è oro

tutto quel che luccica. Nonostante per molte situazioni queste soluzioni siano efficaci,

bisogna comunque tener conto che i database NoSQL in generale non sono la soluzione ad

ogni problema. Il mondo dei Big Data è molto complesso e sofisticato, generalizzare per

tutti i domini un determinato prodotto software database comporta grossi limiti e freni al

progetto complessivo. Questo nuovo mondo che è nato merita e necessita di qualcosa di

più di un semplice nuovo paradigma. Una delle soluzioni ideate, tra le altre, che merita di

essere citata è sicuramente la Lampda Architecture. Esso non è un semplice database

NoSQL creato ad-hoc per gestire una grossa mole di dati, bensì è un intero approccio

nuovo al problema, che trae fondamenta sia dall’ analisi e lo studio dei limiti nati dall’

adattamento dei database relazionali alle nuove esigenze, sia da quali specifici benefici

hanno dato i database NoSQL ai Big Data System. Esso prevede un’ intera architettura ben

definita e specializzata, fondata su tre layer. Ogni layer utilizza uno specifico tipo di

database (solitamente NoSQL , in base allo scopo che deve raggiungere), ha un proprio

compito e un proprio obiettivo: questa divisione permette una separazione del dominio di

interesse (dei singoli livelli) e un maggior controllo sulla complessità totale. Infine questa

strutturazione permette un ottimo compromesso tra storage, compression, retrieval e

analisi/consumo dei dati. Il pensiero alla base è tanto semplice quanto efficace e diretto:

utilizzare solo ciò che serve dove serve, facendo il giusto uso delle tecnologie adoperate ed

eliminando ogni superficialità.

Page 11: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

11

Capitolo 1: Il mondo dei Big Data System

Dopo la presentazione dei problemi, delle analisi, delle nuove soluzioni e degli approcci

più recenti al mondo dei Big Data, si passa in questo capitolo a descrivere e mostrare più

nel dettaglio cosa ci si aspetta da un sistema valido e correttamente progettato.

Ovviamente si partirà dalle caratteristiche necessarie a tener su l’ intera architettura, per

poi passare a due approcci riguardanti l’ organizzazione dell’ informazione: immutabilità o

incrementale? Verrà inoltre toccata il tema del data mining, discutendo principalmente di

due approcci al “popolamento del database”: ETL o ELT? Entrambi saranno descritti e

proposti, e sarà fatto notare come entrambi siano validi, purchè applicati nella giusta

situazione. Infine sarà discussa la scalabilità che permette un sistema BigData, proprietà

concessa solo previa una buona progettazione, fatta seguendo pratiche e tecniche oggi

ampiamente diffuse, apprezzate e validate.

1.1 Le caratteristiche di un buon Big Data System

I nuovi software NoSQL prodotti appositamente per i sistemi Big Data sono nati da studi e

analisi effettuate sul problema e i limiti riscontrati precedentemente. Queste analisi hanno

permesso di individuare della caratteristiche o proprietà che un Big Data System deve

possedere, affinché porti a buon fine il proprio compito. Queste caratteristiche sono

ovviamente differenti rispetto alle necessità dei sistemi relazionali. Oltre alla scalabilità e

alla complessità (da tenere sotto controllo) che ho già accennato precedentemente,

necessitiamo di:

• Robustezza e fault tolerance: è fondamentale che il sistema sia capace di “resistere”

ad errori umani, ad errori dovuti a problemi HW delle macchine, e ad errori che possono

compromettere la consistenza dell’ intero dataset;

• bassa latenza per consumare e aggiornare i dati: nei Big Data si ha a che fare con

una spaventosa mole di dati, che arriva di continuo e fa crescere sempre più il dataset. Il

nostro sistema deve essere in grado di darci risposte esaustive in tempo ragionevole,

Page 12: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

12

interrogando l’ intera base di dati;

• scalabilità e estendibilità: il continuo aumento del dataset richiederà che di volta in

volta il nostro sistema andrà scalato, aumentando il numero di macchine nel cluster che lo

tiene in attività; è quindi importante che il sistema abbia una certa elasticità per queste

operazioni. Inoltre, l’aggiunta di feature al sistema sarà continua data l’ eterogeneità dei

dati, sui quali potrebbero variare di continuo le richieste di chi ne usufruisce;

• manutenzione e debuggability: infine, un sistema così grande e articolato necessiterà

di essere incline ad una facile manutenzione, facilitando la fase di debug che molto spesso

è complicata da fare in un dataset anche relazionale.

Tutto ciò concorre alla produzione di un sistema strutturato, ben definito e valido nella

maggior parte delle situazioni. Se queste proprietà sono rispettate e seguite con successo, il

dataset sarà realizzato correttamente, la sua memorizzazione avverrà con successo e

potremo aggiungere di continuo features alla architettura che stiamo adoperando.

1.2 Immutabilità vs. Paradigma Incrementale

Nei sistemi Big Data troviamo enormi quantità di bit che vengono prodotti continuamente

e che necessitano di essere memorizzati adeguatamente. Nasce quindi spontanea una

domanda: come evolve il dataset in funzione di ciò? Andando a sviscerare l’ argomento e

tentando quindi di trovare una risposta, si scopre che u ruolo importante lo gioca il Data

Model. Per Data Model si intende la rappresentazione logica di come le informazioni sono

organizzate e rappresentate, ma ciò influisce anche su come avverrà il processo fisico di

memorizzazione dei dati. La scuola di pensiero legata al mondo relazionale adopera il

cosiddetto paradigma incrementale. Con tale termine si intende la pratica (molto diffusa

tra i developer di lungo corso) di utilizzare una tupla con le informazioni legate ad una

entità; quando un’ informazione viene aggiornata vi sarà un’ operazione di update su tale

tupla, che comporterà una sostituzione del vecchio dato con il nuovo. Da qui il nome, che

mostra per l’ appunto questa evoluzione incrementale che avviene. Tale sviluppo delle

informazioni fa si che queste rappresentino un vero e proprio stato in cui il sistema si trova

di volta in volta. Questo approccio è risultato obsoleto, invece, con i sistemi Big Data. Le

Page 13: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

13

nuove necessità si scontravano ampiamente con questo punto di vista. In questi sistemi

infatti si utilizza un paradigma che rispetta una proprietà cruciale: l’ immutabilità dei dati.

Questo vuol dire che al centro del dataset non troviamo più una differenziazione e

rappresentazione per “entità” del dominio di interesse, bensì l’ informazione stessa. La

classica tabella, che prima conteneva le informazioni di tutte le entità dello stesso tipo

(insieme), viene ora vista spezzata in più tabelle, addirittura una per ogni colonna prima

memorizzata. Il dato viene visto nella sua versione più atomica possibile. Ad ogni

aggiornamento o modifica di un’ informazione già memorizzata, non si andranno più ad

eseguire degli update, ma dei nuovi inserimenti di records. Questi saranno corredati di un

timestamp, che permetterà di organizzare l’ informazione e tener traccia di come essa è

cambiata di volta in volta. Questo nuovo approccio permette di rispettare l’ immutabilità

dei dati e di poter beneficiare di varie “features”. Ad esempio, se in produzione viene fatto

il deploy di un bug che “sporca” la base di dati, sarà possibile tornare in modo naturale ad

una vecchia informazione nel dataset, eliminando quella sporcata. Altro aspetto cruciale è

il notevole aumento della resistenza ad errori umani, che possono essere eliminati

rimuovendo semplicemente i records incriminati. In entrambi i casi, si continuerà ad avere

un’ informazione valida; sicuramente si è persa l’ informazione più aggiornata, ma ciò che

resta è comunque vero: il timestamp stesso permetterà di dire che in quel determinato

istante quella tupla rappresentava una verità.

1.3 I limiti dello scaling

Quando ci si trova difronte ad un sistema che inizia ad arrancare nel proprio compito, si è

subito portati ad aumentarne le qualità tecniche, quali potenza di calcolo e storage.

Applicare questa tecnica ai RDBMS, per aumentarne l’ efficienza con i Big Data, si è

rivelato inutile: sia uno scaling verticale (aumentare CPU e HDD nelle macchine) che uno

orizzontale (più macchine unite a cluster) non hanno dato le risposte che ci si aspettava.

Questo è dovuto alla natura stessa dei Big Data: questi sistemi, oltre a memorizzare tanta

informazione, ne ricevono anche di continuo, portando ad una serie di difficoltà da

affrontare. Aumentare il numero di macchine disponibili nel cluster (il cosiddetto

Page 14: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

14

sharding) ha solo aumentato la complessità dell’ intero sistema, comportando cosi il

sopraggiungere di nuovi problemi. Più macchine, ad esempio, vuol dire più hardware, e

quindi più probabilità di una rottura di questi: diminuisce il fault-tolerance generale.

Inoltre, tutti i dati che “arrivano, restano e vengono consumati” nella base di dati sono

soggetti a una facile corruzione se per sbaglio viene fatto il deploy in produzione di un bug

software che ne compromette la consistenza. Infine, l’ ennesimo grande problema che si

manifesta è la poca tolleranza agli errori umani. Questi sono molto frequenti e comuni, e

sono dovuti sia ad errori in scrittura nel database sia ai programmi software che

dovrebbero validare i dati prima della memorizzazione.

Tutto ciò ha reso l’ uso dei vecchi RDBMS impossibile nei Big Data System, e ha

spronato gli sviluppatori a cercare e realizzare le nuove soluzioni che oggi permettono di

assolvere a tutti i compiti necessari in questo nuovo mondo.

1.4 Data Extraction: ETL o ELT?

Come abbiamo visto, una delle implementazioni pratiche di un sistema BigData riguarda

le gestione di dati (personali e non) a fini statistici o analisi. Il primo passo nel

popolamento del database comporta il retrieval o la produzione dei dati. Una tecnica

utilizzata è la cosiddetta Web Scraping, che comporta la creazione di software (ad es.

parser) che girano per le pagine web dove carpire e raccogliere dei dati di interesse.

Ovviamente, prima di essere immessi nel dataset, questi andranno controllati e

eventualmente riformattati secondo una certa direttiva. Questa serie di operazioni, che

parte dal reperire i dati e finisce con l’ inserimento nel nuovo database, è detta ETL:

Extraction, Trasformation e Load.

Nello specifico, queste fasi operano sui dati nel seguente modo:

• estrazione dei dati: solitamente le sorgenti più usate sono pagine web, pdf,

Page 15: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

15

documenti di word oppure database pre-esistenti. I dati vengono raccolti e convertiti

affinché possano entrare a far parte tutti dello stessa data warehouse;

• trasformazione dei dati: una volta estratti, solitamente ci si trova davanti dei dati

grezzi, quasi sempre senza una struttura. Oltre a fornire una struttura comune e dei

metadati correlati, in questa fase si applicano azioni di derivazione, sorting, filtraggio, join

e disjoin in più o meno colonne. Questo, ovviamente, dipenderà dalle direttive con il quale

è stato formulato il nuovo dataset;

• caricamento dei dati: solo a questo punto i dati possono essere caricati, passando per

repository temporanee oppure direttamente nel dataset finale.

1.4.1 Un approccio alternativo: ELT

ETL è di uso comune e quindi abbastanza diffuso. Nel mondo dei Big Data System, però,

in contrapposizione a questo ciclo vi è un approccio simile, ma per nulla uguale : ELT.

L’approccio ELT prevede una fase di LOAD prima della TRASFORMATION, che

risultano quindi scambiate in ordine. La fase di load, in questo caso, prevede il trasporto di

dati in

tabelle di supporto. I dati grezzi, senza alcuna modifica, vengono prima trasferiti in una

locazione temporanea. Successivamente, da questa locazione saranno prelevati, trasformati

e inseriti nel dataset definitivo. Questo approccio risulta particolarmente positivo quando

si ha a che fare con grossi moli di dati: non viene “infastidita” di continuo la sorgente con

retrieval e trasformation, ma solo con un processo di copia. Questo può essere molto

vantaggioso quando la sorgente è su un server di produzione, in quanto si evita un calo

delle performace agli utenti utilizzatori del servizio. In questo modo, inoltre, oltre il mero

processo di copia dei raw data, è possiile utilizzare diversi linguaggi ottimizzati, come T-

SQL, per una trasformazione efficiente e vantaggiosa dei dati, con conseguente load nel

Page 16: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

16

database finale. È possibile affermare che un approccio ELT risulta vantaggioso su uno

ETL nei seguenti casi:

• vi sono in gioco grosse moli di dati;

• il database sorgente e il database destinatario risultano gli stessi o sono sulla stessa

macchina (magari anche di produzione);

• il database engine è specializzato nel trasporto di dati di dimensioni massicce in

tempi rapidi.

In breve, le tecniche ETL prevedono l’ aggravo delle operazioni sulla macchina sorgente,

mentre i processi ELT spostano il carico sul target. Di contro, ELT necessiterà di più

memoria per essere portato a termine. Questo è dovuto alle tabelle di supporto utilizzate

temporaneamente. In base alle situazioni e valutando i vari casi, può essere utile scegliere

ELT al posto di ETL.

Page 17: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

17

Capitolo 2: Apache Hadoop

Il primo capitolo ha fatto da introduzione al mondo dei Big Data System. Dopo averne

visto storia, problemi e potenzialità, si andrà in questo capitolo a trattare un prodotto reale.

Come abbiamo visto, molte sono le sfide nate dallo storage di così tanti dati, mai visti

prima. Come si sono mossi gli sviluppatori? Quali aziende sono entrate in questo nuovo

mercato e con quali prodotti? Nello specifico, lo strumento in questione si chiama Apache

Hadoop. Si tratta di un software molto potente e versatile, mantenuto e sviluppato oggi da

Apache, una garanzia in merito a codice open source. Esso prevede un’ intera architettura

composta da più moduli, che insieme garantiscono ottime performance e rendimenti. Due

di questi moduli, quali un file system e un meccanismo di computazione distribuiti,

saranno discussi e approfonditi maggiormente nei prossimi paragrafi e in quelli del

capitolo seguente. La sfida principale che è stata affrontata, come vedremo, riguarda lo

storage: con che tecnologia e in che modo tengo memoria di questa vasta mole di dati?

Come posso rendere il tutto il più trasparente possibile ai developer? Queste sono due

delle domande a cui sarà trovata risposta. Ovviamente, date le dimensioni dei dataset e

quindi delle potente richieste per i calcoli, si vedrà che si sfruttano molteplici macchine

collegate come un unico cluster in rete. Una architettura così fatta si rende necessaria per

dominare la complessità e fornire la potenza necessaria a supportare un sistema BigData.

Inoltre, verrà mostrato ciò che comporta questo approccio e come sono stati risolti sia i

problemi di comunicazione che quelli di gestione e storage dei dati tra le varie macchine.

Infine, una volta “sistemato” il problema dello storage, sarà affrontata la questione della

parallel computation, resa necessaria in una architettura che si basa su più macchine poste

in cluster di rete per distribuire efficacemente il carico di lavoro.

Il tutto sarà affrontato riferendosi in particolare a due componenti della soluzione software

chiamata Apache Hadoop: il file system HDFS (Hadoop Distributed File System), per la

memorizzazione dei dati, e MapReduce, per la parallelizzazione delle operazioni.

2.1 Una soluzione: Apache Hadoop

Page 18: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

18

Apache Hadoop è un

framework open source

mantenuto oggi da Apache.

Esso venne realizzato da

Doug Cutting e Mike

Cafarella nel lontano 2002,

all’ Università di Washington. Inizialmente, gli fu dato il nome di Nutch. A quei tempi, il

mondo di internet era alla ricerca di un nuovo motore di ricerca. Hadoop, infatti, nacque

con questo scopo, assolutamente opposto a ciò per cui è usato oggi.

Nel 2006 Cutting fu assunto da Yahoo! che, partendo da papers di ricerca rilasciati da

Google sui BigData System, volle smantellare Nutch e prenderne parte dei componenti.

Dalle ceneri di questi nacque Hadoop.

Oggi, nel mondo dell’ IT, molte grandi aziende adoperano Hadoop. Le recenti statistiche

parlano, in particolare, di Facebook, Ebay, Yahoo, Yelp e Twitter. Tutte sfruttano le sue

caratteristiche di analisi ed elaborazione dei BigData per le proprie necessità.

Il progetto Hadoop fa parte del mondo dello sviluppo di codice libero, e le principali

features offerte si focalizzano su una elaborazione distribuita affidabile e scalabile. Esso

prevede la possibilità di realizzare cluster di macchine senza preoccuparsi del numero

effettivo, che può essere di una come di migliaia di server tutti connessi. Il framework si

preoccuperà di collegare il tutto e smistare il lavoro, così da ottenere un sistema di

parallelizzazione e distribuzione delle operazioni da effettuare. Il progetto è formato da

diversi moduli e plugin, quali Hadoop Common, Hadoop Distributed File System, Hadoop

Yarn e Hadoop MapReduce. Il framework mette a disposizione una piattaforma per lo

sviluppo e il deploy di applicazioni che possono lavorare in parallelo su dataset molto

vasti, esonerando il developer dal compito di occuparsi di come avviene la

parallelizzazione stessa e la comunicazione tre le macchine. Infine, particolare attenzione è

data alla tolleranza ad errori hardware di una macchina del cluster, tramite tecniche di

isolamento del nodo incriminato e metodi di ridondanza che permettono di tenere più

copie dei dati, in previsione di perdite di questo tipo.

Page 19: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

19

2.3 Storage in un sistema Big Data

Nel primo capitolo è stato affrontato il tema dell’ immutabilità dei dati, particolarmente

rilevante quando si parla di Big Data System. Ciò porta ad analizzare un altro aspetto

cruciale nello sviluppo di queste architetture: la tecnologia di storage adoperata. Come

visto precedentemente, le soluzioni offerte dai sistemi Relation Database Management

(RDBMS) risultano inefficaci, dato che l’ enorme mole di dati non può essere gestita come

da essi fatto. Per affrontare il discorso, bisogna condurre uno studio sia sul dataset che sul

Data Model della base di dati, i quali influenza fortemente la decisione finale. L’ aspetto

da valutare si basa sul tipo di operazioni che è necessario fare sul disco: si parla

ovviamente di lettura e scrittura dei dati. Sia per quanto riguarda una write che per quanto

riguarda una read, sostanzialmente due sono gli approcci che vanno analizzati:

accesso/scrittura casuale oppure accesso/scrittura sequenziale. La prima opzione

garantisce che, ovunque siano posizionati i dati all’ interno del disco, essi siano

raggiungibili con egual costo. Un po’ come avviene in una struttura array. Ma questa

efficacia si traduce realmente in benefici per i sistemi in studio che ospiteranno una grossa

quantità di dati? In un grande data warehouse (magazzino di dati), di cosa si necessita? La

situazione è la seguente: di continuo arrivano nuovi dati (e ne arrivano tanti in poco

tempo) che necessitano di essere “appesi”, aggiunti alla grande massa di informazioni già

presente. Di fatti, come visto prima si segue il principio dell’ immutabilità: non si andrà

(quasi) mai ad eliminare dell’ informazione, piuttosto se ne aggiunge. Quando si vuole

effettuare un’ interrogazione, inoltre, l’ interesse volge all’ intera base di dati, e non a

parte di essa. Difatti, va interrogata e sfruttata da inizio a fine, tutto il dataset. Quando si

tratta di analisi statistiche per conto di aziende pubblicitarie, oppure seguire se un trend

viene apprezzato o meno, non avrebbe senso dare risposta su una parte dei dati, bensì si

vuole ridurre al minimo l’ incertezza e l’ errore. Di conseguenza, non si cerca

assolutamente uno storage ad accesso casuale, che non porterebbe beneficio alcuno.

Ricapitolando, si necessita di:

• un rapido append in fase di write;

• una certa dimistichezza alla scalabilità, sempre più dati entreranno, bisogna poter

Page 20: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

20

facilmente aggiungere nuovo spazio;

• operazioni di read per lo più sequenziali, che interessano l’ intero dataset;

• sistemi di tuning dello spazio stesso, con possibilità di effettuare compressioni e

decompressioni utili con le dimensioni dei dati in ballo.

Tutto ciò porta all’ individuazione della soluzione più naturale di tutte: i filesystem,

ovviamente distribuiti.

2.3.1 Filesystem distribuiti

Una gestione a file calza totalmente con i bisogni di un sistema che gestisce grandi

dimensioni di dati. Difatti, una scrittura con append è impiegata naturalmente nei

filesystem. D’ altro canto, anche la lettura, che è fatta sequenzialmente su dati scritti in

append, rispecchia positivamente quanto richiesto. Inoltre, i file system prevedono tante

funzionalità che trovano impiego nei Big Data System, quali permessi sui dati, cifratura e

compressione (con relativa decompressione). Quest’ ultima si rivela particolarmente di

valore, in quanti in un sistema con tanti dati disparati, che aumentano di continuo e che

effettua molte append a file già esistenti, poter anche effettuare manutenzione con

compressione e decompressione diventa un vero e proprio must-have per lo sviluppatore.

Tutto ciò concorre a realizzare un vero insieme di strumenti di tuning e manutenzione, che

facilitano il compito dell’ uomo e permette di mantenere il sistema in uno stato di salute

continuo. Ovviamente, in questi casi non si parla di file system locali su macchine locali,

bensì di file system distribuiti che gestisono i dati e lo storage tramite più macchine che

fanno da nodi in un cluster di rete. Molti sono gli aspetti a cui un file system distribuito

deve badare a differenza del suo fratello minore. In particolare, è possibile citare

trasparenza e concorrenza. L’ utente, o un qualsiasi processo, che chiede di accedere ai

dati deve poterlo fare senza preoccuparsi degli aspetti tecnici che comporta la

memorizzazione sul cluster. Su quale nodo è memorizzato il dato o se intanto vi ci sta

accedendo qualcun altro non deve essere un pensiero dell’ utilizzatore finale, bensì del file

system stesso. Infatti, oltre le normali primitive e funzioni che ha qualsiasi filesystem, uno

distribuito deve anche occuparsi di scegliere la macchina dove memorizzare un nuovo

Page 21: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

21

dato, in quante e quali copie memorizzarlo, ricomporre l’ informazione se una macchina

ha un errore HW che ne compromette l’ integrità, e deve, inoltre, preoccuparsi di creare

una infrastruttura di livello superiore che permette di vedere tutto lo spazio del cluster

come tutt’ uno. Essendo poi queste macchine in rete, altre problematiche comuni si

aggiungono: occuparsi di un nodo che non risponde o di un nodo cade ricade sempre sul

file system.

2.3.2 Problemi comuni

Ovviamente, come tutte le tecnologie, anche i file system distribuiti non sono esenti da

problemi e disagi. I filesystem distribuiti solitamente dividono i file in chunks, ovvero

blocchi di dimensione fissa memorizzati sulle macchine del cluster. Per quanto efficiente

sia questa procedura, è stato anche detto che, seguendo il principio di immutabilità dei

dati, si ha sempre nuova informazione da appendere a quella già esistente. Di

conseguenza, il BigData System non chiederà quasi mai al proprio file system di operare

una delete o update sui dati (e chunks) già memorizzati. Altro punto su cui riflettere:

quando arriva nuova informazione e viene appesa, molto spesso questa è di dimensione

inferiore ai chunks regolari. Si viene così a creare col tempo un problema di

frammentazione dei dati, che regolarmente va risolto con delle operazioni di tuning che

effettuano una compattazione e ricostruzione dei chunks memorizzati. I file system, in

particolare quelli ideati per le piattaforme di BigData, prevedono delle operazioni di

deframmentazione dei dati, volte a ripristinare quanto possibile delle performance nel

retrival dei dati dal disco. Ovviamente, questa operazione porta via tempo e risorse della

macchina, che potrebbe risultare anche offline per l’ intera operazione. Se, infatti, si pensa

a tutti i dati e chunks da muovere, si può subito intuire quanto sia esosa una operazione di

tale portata. Inoltre, bisogna tener sempre a mente che queste macchine sono in rete, per

cui probabilmente la deframmentazione non dovrà solo spostare i dati nell’ HDD di una

macchina, ma anche tra i nodi stessi. La rete, di fatti, può costituire un altro deterrente all’

intera operazione. I problemi, purtroppo, non finiscono qua: si pensi alla situazione in cui

si esegue sull’ intero dataset una query in cui è presente una clausola restrittiva (ad

Page 22: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

22

esempio un where). In un DBMS relazionale, la struttura tabellare dell’ informazione

permette velocemente di “tagliare” i dati restituendo quanto richiesto. Qui, invece, si ha un

enorme dataset fatto di moltissimi bit, sparsi in rete. Una soluzione è, ovviamente, scorrere

tutti i bit del file system, reperire i dati e poi tagliare quelli che non interessano. Questo è

molto esoso, sia per quanto riguarda il tempo necessario che per quanto riguarda la

memoria utilizzata. Un possibile approccio risolutivo del problema è il cosiddetto vertical

partitioning. Nei Big Data System si ha un dataset in cui, come detto prima, al centro vi è

l’ informazione stessa, e non la tupla che rappresenta un’ entità. Di conseguenza, è

possibile pensare di organizzare il file system in cartelle che, a partire dalla root, divide l’

informazione in base al contenuto, oppure la raggruppa tenendo conto delle query più

frequenti che vengono eseguite sul dataset. Questa soluzione è implementata da molti file

system distribuiti specializzati in BigData, ed è una operazione ad alto livello che prevede

la conoscenza del data model del sistema. La struttura delle cartelle permette di navigare

più velocemente tra i dati, e di conseguenza l’ esecuzione delle query dette prima ne trae

enormi benefici.

Infine, è possibile analizzare e riflettere sull’ approccio di basso livello offerto dai

filesystem distribuiti. Come visto prima, questa tecnologia era preesistente ai Big Data

System. Ad esempio, vi erano prodotti come NFS ( di Sun Microsystem), AFS (sviluppato

dalla dalla Carnegie Mellon University) e CIFS. Quando essi sono stati impiegati per le

basi di dati si è notato come le loro API rappresentavano un accesso troppo grezzo al

sistema di archiviazione. Questo portava a molte problematiche a cui badare nella scrittura

del software di sistema. Difatti, questo rappresentava una vera complicazione per i

developer nello sviluppo dei loro applicativi software.

Tutto ciò ha portato alla scrittura di nuovi prodotti, basati su filesystem distribuiti e

specializzati nella gestione di grandi moli di dati. Quello di cui i developer chiedevano era

sicuramente delle interfacce di utilizzo ed accesso complete ai dati mediante API di alto

livello, meccanismi di tuning del sistema in modo tale da tenerlo sempre efficiente e

strumenti di manutenzione in modo da mantenere costantemente valido il rapporto

performance/spazio occupato.

Page 23: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

23

2.3.3 Hadoop Distributed FileSystem

Una soluzione molto valida, realizzata da Apache ed open source, è Hadoop Distributed

File System. Esso fa parte dell’ architettura Hadoop, software realizzato in Java

specializzato nella gestione di BigData. Hadoop, in particolare, implementa l’ HDFS su

tutte le macchine del cluster, il quale si occuperà di offrire un servizio di storage

trasparente ed efficace

per memorizzare tutti i

bit del dataset.

HDFS gestisce il cluster

dividendo le macchine in

due nodi, denominati

namenode e datanode. Il

primo è una sorta di

database, che tiene

traccia delle posizioni dei

vari pezzi di ogni file, mentre il secondo tipo di nodo memorizza i dati veri e propri.

Questi pezzi di file sono detti chunk, hanno una dimensione fissa configurabile e sono

solitamente replicati su più macchine. Quando un nuovo file deve essere memorizzato,

Hadoop segna nel Namenode su quali Datanode memorizzerà i chunks, ed eventualmente

quante ridondanze genera. Quando viene richiesto l’accesso ad un file, Hadoop dovrà

semplicemente contattare il namenode per ottenere la lista dei chunk con relative

macchine che li ospitano. Vari sono i benefici che porta con sé questa tecnica: se una

macchina è offline (per manutenzione o problemi) si hanno copie dei chunk su altri nodi,

una distribuzione su più macchine dei file facilità una computazione parallela (molto

importante sui grandi dataset), infine si ha una facile scalabilità aggiungendo nuove

macchine e notificando ad Hadoop la disponibilità di nuove.

Page 24: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

24

2.4 Data Computation

Come visto fin’ ora, qualsiasi sistema Big Data, per la sua natura intrinseca, si appoggia su

cluster di macchine in rete. Tra i principali vantaggi che questo porta bisogna menzionare

sicuramente la possibilità di ampliare il parco nodi (e di conseguenza lo spazio e la

potenza di calcolo disponibili) e la naturale parallelizzazione dei calcoli effettuati. Infatti,

essendo i dati sparsi per la rete, si necessita di una piattaforma di elaborazione centrale che

organizza le varie macchine e le coordina per le operazioni di computazione necessarie.

Quindi, come ottenere i vantaggi della parallelizzazione senza gravare troppo sui compiti

del developer? Si necessita di qualcosa che solleva lo sviluppatore da questi oneri e che si

occupi in modo automatico di tali processi. L’ infrastruttura Hadoop, di cui è stato già

descritto il file system, è corredata di uno strumento che permette quanto appena descritto.

Questo strumento si chiama MapReduce.

2.5 MapReduce

MapReduce è un

framework di Google

realizzato appositamente

per i data warehouse. La

sua peculiarità è la capacità

di parallelizzare calcoli e

lavoro sulle macchine

disponibili, nonché di

adattarsi autonomamente

all’ ampliamento del sistema e all’ aggiunta di nuovi elaboratori. Il nome rappresenta

proprio le due funzioni che esso esegue: Map e Reduce. La funzione di map prende in

input l’ intero dataset o una sua parte, in base a ciò di cui necessita l’ elaborazione. Lo

script di Map viene distribuito sulle varie macchine della rete, che la eseguiranno sulla

parte di dataset che ospitano. Questa scelta si basa su una semplice osservazione: i Big

Data system ospitano enormi quantità di dati, impossibili da muovere sulla rete ogni volta

Page 25: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

25

che si necessita di una computazione. Meglio, difatti, spostare la funzione di Map.

Solitamente, la funzione di map esegue una emit dei dati in ingresso, basata sullo scopo

dell’ elaborazione. Una volta completate tutte queste esecuzioni, la macchina centrale

delegata a dirigere le operazioni muove i risultati delle singole funzioni di Map sulle

macchine destinate alla funzione di Reduce. Questa, infatti, è eseguita solitamente su un

sottoinsieme delle macchine disponibili. La funzione di Reduce riorganizza e ordina le

chiavi, in modo tale da avere vicine quelle uguali. Successivamente, visita la struttura Map

che ha in ingresso e accorpa i valori, così da restituire in output una struttura con i risultati

finali della computazione.

Nell’ esempio più classico, il “contatore di parole”, vengono eseguiti i seguenti passaggi:

1. la funzione di map riceve in ingresso un testo;

2. per ogni riga conta il numero di parole;

3. per ogni parola effettua una emit key/value che ha per chiave la parola stessa e per

valore 1;

4. si scelgono quali macchine eseguiranno la funzione Reduce. Solitamente si utilizza

una macchina per ogni chiave;

5. le macchine scelte visitano le Map ricevute e conteranno le occorrenze per la parola

delegatagli;

6. infine, i risultati dei singoli Reduce saranno inviati al nodo centrale che presenterà

così l’ output finale che prevede una struttura map con le parole come chiavi e le loro

occorrenze totali come valori.

Un’ ottima analogia per capire come agisce il framework di MapReduce può essere ciò

che facevano i funzionari romani per contare la popolazione dell’ impero. Il censimento

era gestito da un bureau centrale che dirigeva le operazioni: venivano aperti uffici di

censimento in ogni città conquistata, delegati a contare la popolazione locale, questi poi

mandavano i risultati alla città centrale e successivamente la capitale riduceva i risultati a

un conto unico per stimale la popolazione complessiva dell’ impero. Era molto più

semplice di mandare una singola persona a contare la popolazione in giro per l’ intero

impero!

Page 26: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

26

MapReduce, in unione con HDFS, lavora sul cluster di macchine dirigendo le operazioni

da fare. In particolare, quando viene richiesta una computazione, il nodo centrale contatta i

nodename per scoprire dove risiedono i chunks necessari, successivamente avvia tanti task

Map in proporzione alla grandezza dell’ input. Anche in questo caso avere tanti file di

piccole dimensioni porta a scompensi nell’ elaborazione: saranno necessari più task map

del dovuto. Una volta che le strutture Map sono tutte complete, e solo ad allora, il nodo

centrale fa un rapido check della rete e della situazione: ora dovrà individuare le macchine

da utilizzare per la funzione Reduce. In questo caso, ci saranno dei dati da spostare in rete

(ovvero l’output delle funzioni Map), per cui ci saranno diverse valutazioni correlate da

fare. Ora, però, l’ operazione di spostamento dei dati è più fattibile in quanto gli output

prodotti dalle funzioni Map non sono estesi quanto l’ intero dataset. Una volta individuate

le macchine che eseguiranno il processo successivo, queste saranno provviste delle Map

necessarie alle loro elaborazioni, solitamente assegnando un task Reduce per ogni key

univoca presente in esse. Infine, l’ elaborazione e l’ output finale saranno restituiti al nodo

centrale che potrà così presentare il risultato della computazione. Un approccio così fatto

permette una certa efficienza su grandi dimensioni di dati, dando la possibilità di

mantenere performance elevate aumentando i nodi elaboratori all’ interno del cluster.

Page 27: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

27

Capitolo 3: Apache Pig

Il terzo capitolo entra nel merito per quanto riguarda uno strumento di analisi realmente

adoperato. Si tratta di Apache Pig, sviluppato dalla stessa azienda di Hadoop come il nome

suggerisce. Esso si appoggia sull’ infrastruttura presentata nel precedente capitolo,

sfruttandone file system e il sistema di esecuzione parallela di MapReduce tasks. Come

vedremo, esso propone al developer un sistema di compilazione di codice di alto livello,

permettendo una traduzione in codice Java per MapReduce. Questo porta enormi benefici

al developer, dovuti sia alla natura procedurale del linguaggio offerto sia alla potenza di

espressività e controllo sugli operatori e implementazioni built-in già presenti. Il

linugaggio che la piattaforma permette di utilizzare si chiama Pig Latin: saranno presentati

pro e contro, features che lo particolarizzano e sarà fatta un’ analisi di confronto con il ben

più noto SQL.

3.1 Apache Pig

Un freno all’ utilizzo di MapReduce in modo diretto (crudo, o “standalone”) è

rappresentato dalle sue API. Esse, infatti, sono realizzate in Java e possono risultare così

ostiche e scomode per alcuni sviluppatori poco familiari con l’ approccio OOP (object

oriented programming). A supporto dei programmatori però sono state realizzate varie

piattaforme e framework, come ad esempio Apache Pig.

Pig è una piattaforma nata nel 2006 in Yahoo! e successivamente nel 2007 trasferita nel

progetto di Apache Software Foundation. Essa venne realizzata per l’ analisi e la

computazione su dataset molto vasti. È parte integrante del framework Hadoop. Pig

permette l’ esecuzione delle operazioni sfruttando layer sottostanti come MapReduce,

Apache Tez o Apache Spark. La piattaforma PIG mette a disposizione un linguaggio

procedurale all’ utente. Il compilatore di cui è provvista elabora il codice suddividendolo

in tanti Hadoop Jobs, realizzati ad esempio in MapReduce. Il linguaggio procedurale

messo a disposizione si chiama Pig Latin, è procedurale ed offre sia funzioni built-in che

Page 28: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

28

un sistema estendibile, grazie al quale l’ utente può definire delle proprie funzioni. L’

input di questi programmi sono solitamente grosse moli di dati, mentre l’ output viene

raccolto dagli Hadoop Jobs e memorizzato sfruttando il file system installato (che

potrebbere essere stesso HDFS). Il compilatore precedentemente nominato produce e

organizza gli output delle funzioni di MapReduce e offre dei tools di ottimizzazione del

codice.

3.2 Pig Latin

Pig Latin è il linguaggio di programmazione offerto dalla piattaforma Apache Pig. Esso

offre sia una serie di funzioni base, sia la possibilità di estendere il sistema e definirne di

nuove. Queste sono chiamate User defined functions (UDF). Esso permette di manipolare

con facilità grandi moli di dati e ottenere in output il risultato delle elaborazioni fatte

mediante il layer sottostante. Uno di questi layer può essere MapReduce. Pig Latin

produce codice Java per conto del developer, a cui può risultare difficoltoso, permettendo

agilità nella scrittura delle applicazioni. Apache Pig è responsabile della conversione del

codice Pig in task MapReduce.

3.3 Perché usare PigLatin

Il linguaggio Java di MapReduce può essere un ostacolo per alcuni programmatori,

specialmente per chi non è familiare al mondo OOP. Inoltre, Pig Latin offre anche altri

aspetti che fanno propendere per il suo impiego:

• Pig Latin offre un approccio multi-query: questo vuol dire che mentre in Java alcune

funzioni necessitano di molte LoC (linee di codice) per essere definite, in Pig Latin si

necessita di molte meno per effettuare le stesse operazioni. Questo riduce notevolmente il

tempo di sviluppo di software;

• Pig Latin è un linguaggio SQL-like, così da risultare di facile utilizzo a chi ha già

conosciuto il mondo relazionale;

• Pig Latin offre di base molti operatori e funzioni per le query, come filtri, join, e

ordinamenti. Inoltre, esso offre strutture dati particolari come tuple, bags e mappe che

Page 29: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

29

risultano assenti in MapReduce;

3.4 Features del linguaggio

Le features che questo linguaggio offre sono numerose. Sicuramente, bisogna citare in

particolare:

• un set di operatori molto corposo, per eseguire funzioni anche complesse in poco

codice;

• facile usabilità, essendo esso molto simile al tanto noto SQL;

• forte ottimizzazione, grazie a dei tools interni che permettono di migliorare il codice

e gli Hadoop Jobs prodotti, così che il developer debba preoccuparsi solamente della

semantica del linguaggio;

• estendibilità, offerta dalla possibilità per l’utente di realizzare delle funzioni proprie

e di richiamarle nelle applicazioni che realizza;

• UDF, che permette non solo di estendere le funzionalità ma anche di importare

codice scritto con altri linguaggi come Java o Phyton;

• gestione completa dei dati, siano essi in forma sia strutturata che non strutturata.

3.5 Pig vs. SQL

Nello sviluppo di query ad un dataset si è quasi sempre portati ad utilizzare SQL,

linguaggio ampiamente conosciuto e padroneggiato dai developer di tutto il mondo.

Analizzando però affondo ciò che avviene nella stesura ed esecuzione di una data pipeline,

possiamo notare come questa scelta non è sempre conveniente. Per data pipeline, qui e

nelle righe a seguire, si intende una serie di operazioni che vanno dalla lettura dei dati alla

produzione di un output valido, passando per la loro trasformazione. I motivi per cui il

linguaggio Pig è da preferire, in particolar modo quando si parla di bigdata, possono essere

riassunti nel seguenti punti:

• Pig Latin è procedurale, mentre Sql dichiarativo;

• Pig permette ai developer di scegliere dove fissare dei checkpoint nel loro flow di

lavoro;

Page 30: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

30

• Pig permette di specificare quali operatori e implementazioni utilizzare nel load e

trasformation dei dati;

• Pig supporta lo split della pipeline;

• Pig permette di inserire codice quasi ovunque all’ interno del listato;

Di seguito verranno ora analizzati punto per punto e discussi i su detti aspetti.

Pig Latin è procedurale, mentre SQL è dichiarativo. Questo obbliga il developer a seguire

determinate strutture nella dichiarazione della query. Ad esempio, un FROM segue un

SELECT mentre un WHERE segue un FROM e così via. Questo porta alla generazione di

un set di operazioni disgiunte, in cui sarà il motore del DBMS a scegliere come

organizzare e ottenere i dati dalle varie tabelle. In Pig, invece, il developer ha il controllo

sul retrieve di ogni porzione di dati, il che gli permette di gestirlo e organizzarlo come

vuole. Ancora, la rigida struttura della query non ne permette una facile inquadratura,

rendendo difficile la lettura del data flow. Invece, la natura simile ad un linguaggio di

programmazione di Pig permette di creare un codice ben strutturato e espressivo,

concedendo coì al developer la possibilità di una pulita definizione dell’ intero listato.

Pig permette ai developer di scegliere dove fissare dei checkpoint nel loro workflow.

Immaginiamo la scrittura di una query in cui siano presenti dei JOIN da varie tabelle. Il

developer non ha il controllo sul set di dati prodotti, se non alla fine della query con il

risultato in output. Difatti, se qualcosa non va bene lo noterà soltanto nell’ output, non può

controllare prima la data pipeline poiché il controllo lo ha il motore SQL. La soluzione

sarebbe creare tante tabelle temporanee o materializzate da utilizzare, che complica sia la

vita all’ ottimizzatore SQL che all’ utente quando deve leggere la query. Tramite le

funzioni di load, invece, Pig da completo controllo al developer sui dati caricati,

permettendo di fissare dei checkpoint ovunque nel codice, molto utili soprattutto in fase di

debug. Inoltre, nel caso in cui vi sia un failure all’ interno della pipeline, questa non dovrà

essere ri-eseguita nella sua totalità, cosa molto interessante quando ci si trova a lavorare su

enormi dataset.

Pig permette di specificare quali operatori e implementazioni utilizzare nel load e

trasformation dei dati. Questa feature di SQL la si può definire come “fede nell’

Page 31: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

31

ottimizzatore di query”. Infatti, data la natura dichiarativa del linguaggio, lo sviluppatore

deve scrivere solo ciò che vuole, senza preoccuparsi di come sarà fatto. Questa

preoccupazione, però, gli sviluppatori di data pipeline per Big Data vogliono averla,

poiché su ciò si base anche l’ ottimizzazione globale e l’ efficienza del sistema. Sono

proprio questi tuning (che nei normali DBMS vengono spesso omessi) a fare poi la

differenza tra un buon sistema ed uno poco efficiente. Bisogna appuntare che SQL

permette, certamente, degli hint, ovvero dei suggerimenti che il developer dà all’

ottimizzatore sull’ usare questa o quell’ altra implementazione di un’ operazione o

processo. Tutto ciò però resta un suggerimento, che il motore SQL può anche ignorare. Pig

dal suo canto invece permette di scegliere per ogni operazione tra diverse

implementazioni, così come permette l’ uso e la scelta degli operatori appropriati da

sfruttare. Sarà il developer ad aver parola su ogni aspetto dell’ esecuzione della data

pipeline, così che possa sistemare il tutto come meglio crede.

Pig supporta lo split della pipeline. Mentre SQL importa i dati come specificati nelle

SELECT, FROM e JOIN della query, Pig dà il pieno controllo sul data import flow nella

pipeline. Questo permette, ad esempio, di caricare dati da diverse tabelle, ordinarli su

chiavi diverse e poi utilizzarli con il codice appropriato. Questo era impraticabile in SQL,

a meno che di non utilizzare tabelle temporanee. Questa differenze è permessa dall’ uso

dei DAG (grafi aciclici diretti) con cui lavora Pig, mentre SQL sfrutta gli alberi. Tutto

questo, inoltre, porta ad un altro beneficio: la gestione separata e completa dello stream di

dati permette di ottimizzare l’accesso al disco per reads e writes, aspetto importantissimo

nei BigData Systems. Lo split, infine, dà benefici anche al compilatore Pig, al quale

possiamo meglio indicare come produrre i MapReduce Jobs, permettendo una maggiore

efficienza nella loro realizzazione.

Pig permette di inserire codice quasi ovunque all’ interno del listato. Tramite UDFs e

streams, Pig permette all’ utente di importare ed utilizzare codice nativo di altri linguaggi,

come ad esempio Java. Questo può essere utile quando si deve importare dati da sorgenti

che non siano il database. Con SQL, invece, tutto deve passare per la base di dati, e spesso

per far ciò bisogna far ricorso software di terze parti costosi e ostici. Questo aspetto di

Page 32: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

32

Pig, inoltre, gli permette di accettare anche codice legacy: eseguibili esterni di software

non più supportato possono essere lanciati e sfruttati i qualunque punto del codice. Per

un’azienda tutto ciò porta vari benefici: non deve insegnare nuovi linguaggi o nuovi

pacchetti sw di terze parti ai propri developer; spesso si trova a lavorare con codice legacy

ormai obsoleto che però torna a “nuova vita” sfruttandolo nelle operazioni Pig.

Page 33: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

33

Capitolo 4: Analisi di un caso pratico

Quest’ ultimo paragrafo sarà caratterizzato da un’ impronta puramente pratica. Difatti, a

questo punto è possibile toccare con mano e sperimentare come si comportano le soluzioni

fin’ ora analizzate. In particolare, saranno adoperati i prodotti presentati nei capitoli due e

tre: Apache Hadoop e Pig Latin. Di conseguenza, in questo capitolo verrà mostrato uno

script realizzato con tale linguaggio, per mostrarne peculiarità e caratteristiche. Il tutto sarà

accompagnato sia da un’ analisi tecnica del processo di messa in funzione della macchina

utilizzata, che da una riflessione sui risultati ottenuti.

4.1 Caso di studio

Si immagini una situazione in cui vi sia una applicazione lanciata sul mercato dal 2015,

che a poco a poco è cresciuta ed è diventata sempre più popolare. Senza che ce lo si

aspettasse, il prodotto ha avuto un forte impatto sul pubblico e si è diffuso a macchina d’

olio, tanto che è stata successivamente avviata una società e costruito un business plan ad

hoc intorno all’ app. Man mano che questa si è diffusa, la società si è ingrandita ed

espansa, ed è giunto il momento di fare il salto di qualità: convincere nuovi investitori (e

quindi soci) ad entrare nel progetto, cercando di guadagnare anche degli inserzionisti di

rilievo. Si pensi, quindi, al capo della società, che deve realizzare un report da presentare

sullo “stato di salute” del suo software. Secondo lui non ci saranno problemi: l’

applicazione è apprezzatissima dal pubblico e usata da tantissimi utenti. Nel bel mezzo

della relazione, però, ci si rende conto di una cosa: c’ è bisogno di dati analitici che

confermino e supportino la tesi riguardo la diffusione e l’ utilizzo effettivo dell’ app.

Bisogna quindi utilizzare una fonte da cui attingere dei dati sui login degli utenti. Si

immagini, quindi, di avere a disposizione tali file, in cui vi è segnato per ogni utente il

numero di minuti in cui è stato connesso in ogni giorno di utilizzo dell’ app. Dato il grande

successo che ha riscosso in circa due anni di vita, salta subito fuori un problema: i file di

log contengono centinaia di migliaia di records. Non è facile gestire tutti questi dati in

modo efficace, soprattutto se vi si approccia in modo sbagliato. Utilizzando le tecnologie

per Big Data System, però, si può agilmente venire a capo del problema e risolverlo con

Page 34: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

34

forte efficacia. In particolare, per risolvere questo caso di studio tornano utili Apache

Hadoop e Pig Latin. Il primo permetterà di realizzare un’ infrastruttura di macchine in

cluster di rete, così da scalare facilmente il sistema se la potenza di calcolo risulterà

insufficiente. Il secondo, invece, metterà a disposizione un linguaggio di scripting molto

valido che permetterà in poco tempo di realizzare quanto necessario. Tutto ciò permetterà

di dimostrare che la suddetta applicazione è un prodotto solido, fortemente utilizzato e con

un bacino d’ utenti di età media molto giovane.

4.2 Setup dell’ architettura

Nei test e implementazioni

effettuate, è stata realizzata un’

architettura con una sola

macchina, data l’ impossibilità

pratica di poter creare e gestire

un cluster di più elaboratori in

rete. In particolare, è stata

adoperata una macchina virtuale

con sistema operativo Ubuntu 16.04 LTS equipaggiata con un processore quad core, 4 GB

di RAM, 128 MB di scheda video e 30GB di spazio. Il tutto, ovviamente, emulato tramite

Oracle VM VirtualBox 5.1.6. Entrambi i software di casa Apache, per poter funzionare

correttamente, necessitano di una Virtual Machine Java. Per tale motivo, è stata installata

precedentemente Java JDK nel sistema, in versione 1.8. La piattaforma Apache Hadoop

utilizzata, invece, è in versione 2.7.3 (ultima release corrente). Infine, la versione di Pig

Latin adoperata è la 0.16.0 (ultima release corrente).

4.2.1 Apache Hadoop

In fase di installazione è stato scompattato l’ archivio in una cartella dedicata, impostato

delle variabili d’ ambiente necessarie ad individuare la posizione in cui era presente Java

(JAVA_HOME e HADOOP_HOME) e configurato il tipo di utilizzo di Hadoop: nel caso

Page 35: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

35

in questione si tratta di una singola macchina nel cluster con processi che fanno da

Datanode, da Namenode e da ResourceManager. Questi, in particolare, si avviano come

deamon di sistema e restano in ascolto di richieste su tre porte specifiche, rispettivamente

50010, 50070 e 54310. Questo è possibile osservarlo in ben tre modi:

• tramite il comando jps da console (che fa parte del pacchetto Java) è possibile

vedere i tre processi contestuali avviati, quali ResourceManager (MapReduce Jobs

executer), DatanodeManager e NamenodeManager;

• tramite il comando netstat è possibile vedere i tre processi in ascolto sulle rispettive

porte;

• tramite l’ indirizzo http://localhost:50070 che riporta una UI web con varie

informazioni su Apache Hadoop riguardo i nodi in esecuzione, il suo stato attuale, quello

del filesystem e quello dei processi avviati.

Dopo aver configurato i tre processi fondamentali, è stato creato appositamente un disco

nel filesystem di Hadoop (HDFS), successivamente formattato tramite l’ apposito

comando e messo poi a disposizione del datanode manager. I vari chunk, da

configurazione di default, sono grandi 128MB. Infine, prima di poter avviare il tutto, è

stata verificata la presenza sulla macchina di un gestore di connessioni ssh (ssh e sshd),

dato che la comunicazione con i processi Apache Hadoop avviene tramite tale protocollo.

Fatto ciò, è stato possibile avviare l’ intero sistema, tramite l’ apposito script start-all.sh

(deprecato) oppure richiamando prima start-dfs.sh e po start-yarn.sh.

4.2.2 Apache Pig Latin

Le operazioni per l’ installazione di Apache Pig risultano simili a quanto fatto per Apache

Hadoop. Difatti anche in questo caso è stato scompattato l’ archivio scaricato dal sito

ufficiale in una cartella apposita, sono state sistemate delle variabili d’ ambiente

(JAVA_HOME, HADOOP_HOME e PATH) e infine è stata configurata la modalità di

esecuzione dell’ engine, ovvero Mapreduce Mode (che è anche la modalità di default). Per

testare il funzionamento del sistema e verificare che l’ operazione di setup fosse andata a

buon fine, è stato provato un semplice script di esempio suggerito nella guida ufficiale di

Page 36: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

36

Pig. Questo prevede di leggere il file passw di Ubuntu e creare un MapReduce Job

(tramite linguaggio Pig Latin) che mostri i nomi di tutti gli utenti presenti nel sistema. Per

far ciò, è stato dapprima copiato il file passwd dal file system locale ad Hadoop

Distributed File System, tramite il comando:

hdfs dfs –copyFromLocal /etc/passwd passwd

Una volta che il file è copiato nel file system, è possibile richiamarlo nello script. Il codice

di esempio adoperato è molto semplice:

A = LOAD 'passwd' USING PigStorage(':');

B = FOREACH A GENERATE $0 AS id

STORE B INTO 'id.out';

Questo codice può essere mandato in esecuzione in due modi, avviando la shell di pig ed

eseguendo istruzione per istruzione, oppure creando un file .pig da eseguire direttamente

tramite riga di comando. In particolare, il codice prende il file passwd, lo legge riga per

riga e divide l’ informazione di ogni riga tramite il separatore “:”. Successivamente, per

ogni riga, crea un nuovo relational nella variabile B: questo conterrà l’ id di ogni utente.

Infine, tramite il comando STORE, viene scritto su un file “id.out” il nome di ogni utente e

questi sarà memorizzato nel filesystem HDFS. Per salvarlo in locale nel file system di

Ubuntu, è possibile usare l’ apposito comando da terminale:

hdfs dfs –copyToLocal id.out /path/to/my/folder/id.out

oppure effettuare un download del file dall’ interfaccia grafica web apposita, all’ indirizzo

http://localhost:50070/explorer.html.

4.3 Dati di input

Come accennato precedentemente, il programma Pig Latin che realizzato effettua delle

elaborazioni sui dati di login degli utenti. Di conseguenza, l’ input riguarda proprio tali

informazioni. Due sono i file utilizzati:

• users.csv è un file che contiene le informazioni riguardanti i vari utenti. In

particolare, in esso vi si trova id, username, nome, cognome e età;

Page 37: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

37

• logs.csv invece è un file contenente i dati di login veri e proprio. Ogni riga del file

indica l’ id di un utente, il numero di minuti per cui si è utilizzato l’ app e il giorno a cui

questi fanno riferimenti.

Di seguito è possibile vedere degli esempi di come sono strutturati i due file. A sinistra è

riportato un ritaglio del file users.csv, mentre a destra vi è un ritaglio del file logs.csv.

I file .csv sono stati prodotti tramite dei programmi scritti appositamente usando un altro

linguaggio, che li ha realizzati mettendo casualmente insieme dei nomi utente e dei nomi

di persona presi da archivi liberi online. Stessa cosa è state fatta per il file di logs, prodotto

generando casualmente delle date e dei “minuti online” per ogni utente. Dato l’ utilizzo di

una semplice macchina PC (in particolare un portatile), i dati di input utilizzati sono stati

forzatamente limitati. Difatti, per i vari test sono stati utilizzati solo 34 utenti e 17000 dati

di login (ne sono stati generati 500 per utente). I due file, per essere utilizzati e richiamati

nello script, sono stati copiati nella cartella di default in Hadoop Distributed File System.

L’ operazione è stata eseguita tramite i comandi messi a disposizione da Apache Hadoop:

hdfs dfs –copyFromLocal /var/users.csv users.csv

hdfs dfs –copyFromLocal /var/logs.csv logs.csv

La presenza dei file sul file system distribuito è possibile verificarla, infine, tramite la

comoda UI web:

Page 38: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

38

4.4 Lo Script

Le domande a cui si vuole rispondere tramite gli strumenti di analytics offerti da Apache

Hadoop sono sostanzialmente due: quanto tempo passa mediamente un utente all’

applicazione e qual è l’ età media dell’ utenza. Il linguaggio utilizzato sarà, come già

preannunciato, Pig Latin. Questi permetterà di avere una certa malleabilità dello script,

consentendo di scegliere ed utilizzare determinati operatori al posto di un altro. Anche se il

caso in esempio è semplificato e lavora su relativamente pochi dat, queste accortezze

diventano sempre più fondamentali su basi di dati vaste, tanto da rendere notevolmente

cruciale l’ uso delle tecnologie proposte fino a qui. Per sommi casi, lo script dovrà

effettuare le seguenti operazioni:

1. prendere in input i due file con i dati;

2. caricare in memoria in apposite variabili (relational) queste informazioni;

3. calcolare il totale dei minuti spesi sull’ applicazione da tutti gli utenti e dividerli per

i giorni di cui tengono traccia i log;

4. dividere questo totale per il numero di utenti. La prima risposta è così ottenuta;

5. effettuare un ragionamento simile per l’ età media. La seconda risposta è così

ottenuta;

6. salvare (eventualmente) i risultati ottenuti su disco.

Le potenzialità e la semantica offerta da Pig Latin permettono di operare tutto ciò senza

particolari problemi. Il codice utilizzato è riportato di seguito:

(1) users = LOAD 'users.csv' USING PigStorage(',');

(2) raw_users = FILTER users BY $0>1;

(3) users_details = FOREACH raw_users GENERATE $0 AS

userId, $1 AS username, $2 AS name, $3

AS age;

(4) log = LOAD 'logs.csv' USING PigStorage(',');

(5) raw_log = FILTER log BY $0>1;

(6) logs_details = FOREACH raw_log GENERATE $0 AS userId,

$1 AS date, $2 AS minutes;

(7) grp_logged = GROUP logs_details BY userId;

(8) sum_logged = FOREACH grp_logged GENERATE GROUP AS

userId, SUM(logs_details.minutes) AS

online_minutes;

Page 39: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

39

(9) join_sum_logged = JOIN sum_logged BY userId,

users_details BY userId;

(10) join_data = FOREACH join_sum_logged GENERATE $0 AS

userId, $1 AS online_minutes, $3 AS

username, $5 AS age;

(11) total_group = GROUP join_data all;

(12) avg_minutes_online = FOREACH total_group GENERATE

SUM(join_data.online_minutes)/(43*609);

(13) avg_age = FOREACH total_group GENERATE

SUM(join_data.age)/34;

(14) STORE avg_minutes_online INTO 'out1.log';

(15) STORE avg_age INTO 'out2.log';

Prima di analizzare e commentare il codice, sono necessarie delle note a riguardo: il

calcolo del tempo medio di utilizzo dell’ app da parte degli utenti è stato calcolato

sommando prima tutti i minutaggi presenti e dividendo poi questi per il numero di utenti

moltiplicato per i giorni a cui i log si riferiscono (dal 1 gennaio 2015 al 31 Agosto 2016)

ovvero 609 giorni. Infine, va precisato che il numero di utenti nel file csv è di 34.

Premesso ciò, è possibile passare ad un’ analisi più precisa del codice riga per riga.

1) viene caricato il contenuto del file users.csv all’ interno della variabile users; questo

viene fatto utilizzando l’ operatore LOAD accompagnato dalla funzione da utilizzare per

effettuare il read dei dati. In questo caso è stata utilizzata una funzione built-in chiamata

PigStorage. Se i dati sono memorizzati in modo non processabile dalle funzioni messe a

disposizione dal linguaggio, è possibile definirne una ad hoc;

2) la seconda riga del codice, invece, utilizza una funzione FILTER. Questa non fa

altro che filtrare i dati, ovvero selezionare le tuple su condizioni specifiche. Nel caso

specifico, la condizione è che la prima colonna sia maggiore di 1. Questo escamotage è

fatto per eliminare la prima riga dei dati caricati da users.csv, dato che il file presentava

una intestazione. In questo modo essa viene scartata, per non farla rientrare nel processo di

elaborazione;

3) la terza riga del codice serve per trasformare i dati, tramite il costrutto

FOREACH/GENERATE. Questi infatti permette di scorrere le righe dei dati fin’ ora

caricati e specificare un identificativo per ogni colonna; si ottiene così la variabile

relational da utilizzare in seguito per le elaborazioni;

4) viene qui caricato il contenuto del file logs.csv;

Page 40: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

40

5) viene qui filtrato il contenuto, eliminando di conseguenza la prima riga dei dati;

6) viene poi creata la variabile relational associata ai logs tramite l’ operatore di

trasformazione FOREACH;

7) con il codice a tale riga si raggruppano le tuple della relazione log_details. Questo è

fatto sulla base dell’ userId;

8) a questo punto, si sfrutta la relazione creata precedentemente per crearne una nuova,

contenente per ogni id quanti minuti è rimasto online;

9) con il codice alla riga 9 si effettua un’ operazione di JOIN di due relazione. Nello

specifico vengono giunte sum_logged e users_details sulla base del contneuto della

colonna userId. Questo produrrà una relazione che mostra sia i dettagli dell’ utente (userId,

name, age, username) che quanti minuti è rimasto online nell’ applicazione negli ultimi

due anni;

10) in tale riga si crea un’ ulteriore relazione, chiamata join_data, che sarà utilizzata

successivamente per il calcolo finale della media;

11) in questa riga viene utilizzato di nuovo l’ operatore GROUP, stavolta però con la

keyword ALL. Questa permette di raggruppare tutti i dati in un solo gruppo;

12) a questo punto, è possibile sommare tutti i minuti di tutti gli utenti. L’ operatore

utilizzato è SUM, che somma i dati della colonna online_minutes della relazione

join_data. Questi sono divisi infine per il numero totale di utenti (34) e il numero di giorni

a cui si riferiscono i log. Dal 1 Gennaio 2015 al 31 Agosto 2016 sono 609 giorni. In questo

modo, si ottiene la prima risposta ai quesiti iniziali.

13) infine, il codice in questa riga utilizza ancora la relazione join_data, questa volta per

trovare la somma di tutte le età. Tale risultato sarà poi diviso per 34 (numero di utenti).

Viene così ottenuta la seconda e ultima risposta cercata.

14) Tramite il comando STORE viene salvato il risultato della prima elaborazione nel

file out1.log. Questo sarà memorizzato sul file system distribuito di Hadoop;

15) Tramite il comando STORE viene salvato il risultato della seconda elaborazione nel

file out2.log. Questo sarà memorizzato sul file system distribuito di Hadoop.

I due file di output, out1.log e out2.log, possono poi essere letti sia da riga di comando,

Page 41: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

41

utilizzando hdfs, che dalla UI web all’ indirizzo indicato precedentemente. Il loro

contenuto sarà 19.75, che rappresenta i minuti trascorsi online in media al giorno, e 25.53,

che rappresenta l’ età media degli utilizzatori dell’ applicazione.

Page 42: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

42

Conclusioni

Lo scopo di questo elaborato è stato focalizzato sul presentare una situazione reale in cui i

Big Data System potevano essere la chiave di volta per ottenere con efficacia dei risultati

interessanti. Per tale motivo, la strutturazione del testo è stata volutamente impostata in

modo da creare e definire le basi teoriche nei primi capitoli, in modo tale da affrontare e

arrivare al quarto con buona conoscenza e coscienza di quanto si stave discutendo. Come

si è visto, i Big Data System si rivelano una vera e proprio miniera di possibilità in diverse

situazioni, in particolare in quelle estreme dove i dati sono molti e tutti importanti. Le

soluzioni che oggi si sono affermate risultano essere valide e fortemente collaudate, tanto

da rappresentare una vera e proprio sicurezza in questo settore. I sistemi Big Data si sono

quinfi affermati come una parte fondamentale del business di molte aziende. Mentre prima

potevano sembra uno strumento in più, oggi la loro “validazione” (da parte dalle stesse

aziende che hanno provato i benefici) ha fatto si che questi siano arrivati sempre di più al

core del business, stravolgendolo e arricchendolo incredibilmente. Con il passare del

tempo, si andrà sempre di più verso aziende che dovranno macinare e consumare dati ogni

giorno per rimanere alte e competitive nel mercato. I dati sono sempre più la vera

ricchezza e potere: saperli usare è cruciale. La società sempre più connessa pronosticata in

molti libri e ricerche dell’ ultimo decennio sta prendendo forma, e scommettere sul ruolo

da protagonist che avranno I Big Data System è banale: la loro importanza è già oggi

scontata. Ovviamente le sfide non finiscono qui. Uno sguardo alle stime ci fa notare che

queste quantificano (almeno indicativamente) i dati prodotti ogni giorno parlando di 2.3

trilioni di gigabyte in tutto il mondo, e si arriverà nel 2020 a circa 43 trilioni. Tutto ciò

continuerà a rappresentare una sfida continua, poichè non sarà comunque facile a star

dietro a quantità che crescono così spaventosamente di giorno in giorno. Di fatto, si sta già

viaggiando verso il futuro che ha già un nome: Data Management, termine con il quale si

riuscono discipline nell’ ambito dei Big Data, nonchè le nuove figure professionali che

questi stanno generando. Il future è alle porte, le tecnologie ci sono, gli strumenti sono

pronti: le aziende sapranno partecipare alle nuova rivoluzione industriale?

Page 43: Sistemi BigData e strumenti di Analisi · fonda l’ architettura, ovvero un file system distribuito (Hadoop Distributed File System) e un sistema di computazione distribuita (MapReduce)

43

Bibliografia

[1] Nathan Marz e James_Warren, “Principles and best practices of scalable real-time

data systems”;

[2] “Comparing Pig Latin and SQL for Constructiong Data Processing Pipelines”,

https://developer.yahoo.com/blogs/hadoop/comparing-pig-latin-sql-constructing-data-

processing-pipelines-444.html;

[3] https://en.wikipedia.org/wiki/Pig_(programming_tool);

[4] https://www.quora.com/What-is-the-history-of-Hadoop;

[5] https://www-01.ibm.com/software/data/infosphere/hadoop/mapreduce/;

[6] https://gigaom.com/2013/03/04/the-history-of-hadoop-from-4-nodes-to-the-future-

of-data/;

[7] http://hadoop.apache.org/#What+Is+Apache+Hadoop%3F;

[8] https://www.tutorialspoint.com/apache_pig/;

[9] https://datajobs.com/what-is-hadoop-and-nosql;

[10] https://www.mongodb.com/big-data-explained;

[11] http://hadoop.apache.org/;

[12] https://pig.apache.org/;

[13] https://pig.apache.org/docs/r0.7.0/piglatin_ref2.html;

[14] http://hortonworks.com/hadoop-tutorial/how-to-process-data-with-apache-pig/;

[15] http://www.bogotobogo.com/Hadoop/BigData_hadoop_Install_on_ubuntu_single_node_cluster.php;

[16] http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-

node-cluster/;

[17] http://datawarehouse4u.info/ETL-process.html;

[18] http://www.jamesserra.com/archive/2012/01/difference-between-etl-and-elt/

[19] http://www.franzrusso.it/inweb-2-0/futuro-big-data-data-management-ebook/