PageRank con Hadoop - Digital Forensics @ UniSa

PageRank con Hadoop
Giovanni Mastroianni
Giuseppe Valentino
Giugno 2012
2
Indice
1 Introduzione
5
2 Il PageRank
7
2.1
L’algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2
Algoritmo raffinato . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4
PageRank con Hadoop . . . . . . . . . . . . . . . . . . . . . . . .
11
3 Analisi delle prestazioni
3.1
3.2
15
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.1
Macchina fisica . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.2
Macchina virtuale . . . . . . . . . . . . . . . . . . . . . .
16
Casi di studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.1
Caso di studio 1 . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.2
Caso di studio 2 . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.3
Caso di studio 3 . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.4
Caso di studio 4 . . . . . . . . . . . . . . . . . . . . . . .
20
4 Conclusioni
23
3
4
INDICE
Capitolo 1
Introduzione
Ogni volta che si effettua un ricerca su Google ci sorprendiamo di quanto siano
attinenti i risultati organici. I sofisticati algoritmi utilizzati dai motori di ricerca
hanno il compito di restituire le pagine che più possono interessare l’utente.
Fare ciò non è semplice: ogni keyword, oltre a poter essere inespressiva presa
singolarmente, può soffrire di problemi di polisemia (un termine può avere più
significati) e sinonimia (ci sono diversi termini che indicano la stessa cosa).
Con l’avvento di Internet, dove tutti sono autori e tutti cercano contenuti, il
problema di reperire le informazioni è diventato cruciale per ogni motore di
ricerca. Questi ultimi devono non solo trovare e catalogare milioni di documenti
che sono rilevanti per una query, ma anche “raccomandare” i pochi risultati che
un utente vorrebbe consultare per soddisfare le proprie richieste. Possibilmente,
tra i primissimi risultati del motore di ricerca.
Per svolgere questo compito su una mole di dati enorme, è sicuramente
impensabile adoperare una sola macchina. Per questo motivo in questo lavoro
descriveremo le sperimentazioni e i benchmark dell’algoritmo di PageRank su
un cluster di macchine, utilizzato il framework Hadoop per il grid computing
e confronteremo le differenze nei tempi di esecuzione e i fattori di scalabilità
5
6
dell’algoritmo.
CAPITOLO 1. INTRODUZIONE
Capitolo 2
Il PageRank
PageRank è un algoritmo utilizzato da Google per valutare la reputazione di
una pagina. Partendo da una rete di pagine web, l’obiettivo dell’algoritmo è
quello di assegnare ad ogni pagina un punteggio; tanto più il punteggio sarà
alto, maggiore sarà l’importanza della pagina web nella rete.
PageRank svolge un ruolo fondamentale nel processo di indicizzazione di
pagine web da parte di Google poichè contribuisce a restituire, per una specifica
ricerca, solo i risultati che sono ad essa più attinenti. Informalmente, il calcolo
del PageRank è una sorta di votazione ricorsiva da parte delle pagine: ciascuna
pagina, tramite i link in uscita, vota per una o più altre pagine, accrescendone
il PageRank. Questo processo è pesato su due fattori: il PageRank della pagina
votante (un “voto” ricevuto da una pagina importante vale di più rispetto a
un “voto” ricevuto da una pagina con reputazione più bassa) e il numero di
link uscenti della pagina votante (ciascuna pagina distribuisce il proprio voto
suddividendolo equamente tra le pagine puntate dai link in uscita). Da ciò,
chiaramente, si deduce che tanto più una pagina è linkata tanto più accresce la
sua reputazione.
Metaforicamente, il PageRank può essere interpretato come un fluido che
7
8
CAPITOLO 2. IL PAGERANK
Figura 2.1: Esempio di pagine web collegate
circola nella rete di pagine e stagna in ciascuna di essa a seconda della sua
reputazione.
Una rappresentazione classica di una rete di pagine web è un grafo diretto
G(V, E) dove V è l’insieme delle pagine web ed E è l’insieme degli hyperlink da
una pagina a un’altra.
Da un punto di vista puramente matematico, il PageRank è una distribuzione
di probabilità che rappresenta la possibilità che un navigatore, cliccando a caso
sui link, possa raggiungere una determinata pagina. Considerando ciò, una
pagina con PageRank 0.5 ha il 50 % di possibilità di essere raggiunta da un
navigatore che percorre a caso il web.
2.1
L’algoritmo
Consideriamo un piccolo universo di pagine web, rappresentato in figura 2.1,
V = {A, B, C, D} con i seguenti link E = {(D, A), (D, B), (D, C), (B, C), (B, A)}
i.e. D ha un link in uscita verso tutte le pagine e B punta alle pagine A e C.
Sia |V | = n.
2.2. ALGORITMO RAFFINATO
9
Ragionando in termini di distribuzione di probabilità, ciascuna pagina ha
come PageRank iniziale il valore 0.25 (i.e.1/n). Consideriamo la pagina A: essa
è linkata da 2 pagine, quindi ciascuna di essa trasferirà il proprio PageRank
come di seguito
P R(A) =
P R(B) P R(D)
+
= 0.125 + 0.083 = 0.298
2
3
In generale, definendo L(v) il numero di link uscenti dalla pagina v e Hu
l’insieme delle pagine che linkano a u, la formula per il calcolo del PageRank
diventa
Definizione 1 P R(u) =
P
v∈Hu
P R(v)
L(v)
Questo calcolo viene effettuato durante più iterazioni dell’algoritmo in modo da
raffinare le valutazioni che tenderanno a convergere verso valori stabili.
2.2
Algoritmo raffinato
Utilizzando la definizione di PageRank data finora, sussiste un problema non
considerato: nella rete di pagine potrebbero esserci due nodi nei quali confluisce,
dopo un certo numero di aggiornamenti, tutto il PageRank senza mai uscirne.
Questo fenomeno si verifica in reti con cicli tra due nodi che non hanno altri archi uscenti. Fortunatamente, esiste un semplice stratagemma per evitare
queste situazioni. Ritornando alla metafora del fluido, si fa in modo che una
piccola quantità del PageRank totale “evapori” e si disperda casualmente tra
tutti i nodi ad ogni aggiornamento; in questo modo nella rete ci sarà sempre
una piccola quantità di PageRank che non può stagnare tra due pagine che si
linkano esclusivamente a vicenda. Per fare ciò, si introduce uno scaling factor s
ridefinendo l’algoritmo di aggiornamento.
Definizione 2 Regola di aggiornamento PageRank con scaling: Ogni pagina
viene aggiornata secondo la formula 1. Successivamente, si scalano tutti i valori
10
CAPITOLO 2. IL PAGERANK
di un fattore s. Questo significa che il PageRank totale nella rete passa da 1 a s.
Il restante valore 1 − s viene diviso equamente tra tutti i nodi, dando (1 − s)/n
a ciascuna pagina.
Un fattore di scaling utilizzato solitamente in pratica oscilla tra s = 0, 8 e
s = 0, 9.
2.3
Apache Hadoop
Hadoop è un framework open-source che permette di eseguire le applicazioni su
grandi cluster formati da hardware di comodità. E progettato per scalare da un
server singolo a migliaia di macchine, ognuna delle quale offre potenza di calcolo
e spazio di archiviazione locale. Prende spunto dal MapReduce di Google e dal
Google File System e permette di lavorare con migliaia di nodi e petabyte di
dati.
Ad oggi sono davvero tanti gli utilizzatori Hadoop per ricerca o per fini
commerciali, tra essi si annoverano nomi illustri quali Google, IBM, Amazon e
Yahoo!. Proprio quest’ultimo è uno dei maggiori utilizzatori di Hadoop. Vanta
più di 100,000 CPUs in 40,000 computer, il loro cluster più grande è formato
da 4500 nodi (2*4 cpu box con 4*1TB dischi e 16GB RAM). Yahoo! utilizza
Hadoop per supportare la ricerca web e una serie di servizi, come ad esempio
“Ad System”. In alcuni documenti vengono mostrate le potenzialità di Hadoop
e i guadagni in termini di tempo nell’uso di una griglia per la risoluzione di alcuni
problemi. In questo primo esempio, vengono comparati i tempi di esecuzione
per l’analisi di 100 TB di dati (cosa normalissima per Yahoo!) con diverse
configurazioni:
• Computer standard (100 MBPS): 11 giorni
• Soluzione con connessione a 10 Gbit: 1 giorni
2.4. PAGERANK CON HADOOP
11
• 1000 computer normali: 15 minuti!
Questo serve a sottolineare l’efficienza di una griglia, e quindi di Hadoop, per
l’analisi di un’ingente mole di dati. É proprio per questo motivo che abbiamo
deciso di utilizzare questo strumento in un ambito di calcolo che Google utilizza
in ogni istante per poter catalogare la vastissima mole di dati che caratterizza
le pagine web di tutto il globo.
2.4
PageRank con Hadoop
In questa sezione descriveremo come è possibile implementare l’algoritmo di
PageRank utilizzando il paradigma map/reduce.
Input
Il formato di input utilizzato prevede un file strutturato nel seguente
modo: (P1 , < O1 , O2 , . . . , On >) dove P1 è una pagina web e < O1 , O2 , . . . , On >
è la lista delle pagine puntate da P1
Map
Durante la fase di map viene calcolato, per ogni pagina P, il contributo
che verrà poi passato ad ogni pagina Oi puntata. Come descritto precedentemente, questo contributo è pari al valore di PageRank della pagina P diviso per
il numero di outlink. L’output della fase di map sarà quindi una serie di coppie
R(P)
chiave-valore del tipo: (Oi , PL(P)
).
Ragionando in termini implementativi ciò viene realizzato con la seguente
porzione di codice:
12
1
CAPITOLO 2. IL PAGERANK
S t r i n g URL = key . t o S t r i n g ( ) ;
RankRecord r e c o r d = new RankRecord ( v a l u e . t o S t r i n g ( ) ) ;
for ( String u : record . getUrlList () ) {
3
d o u b l e newRank = r e c o r d . g e t U r l L i s t ( ) . l e n g t h == 0 ? 0 : r e c o r d .
getRank ( ) / ( r e c o r d . g e t U r l L i s t ( ) . l e n g t h ) ;
5
c o n t e x t . w r i t e ( new Text ( u ) , new O b j e c t W r i t a b l e ( new D o u b l e W r i t a b l e (
newRank ) ) ) ;
}
7
c o n t e x t . w r i t e ( new Text (URL) , new O b j e c t W r i t a b l e ( r e c o r d .
getUrlList () ) ) ;
Reduce Durante la fase di reduce viene di fatto calcolato il nuovo valore di
PageRank secondo la formula 1 di ciascuna pagina sfruttando i dati calcolati
nella fase di map, pesandoli eventualmente con il fattore di scaling. L’output
della fase di reduce sarà una lista con i valori di PageRank aggiornati in modo da
poter ricominciare la fase di map. Questo procedimento iterativo viene ripetuto
per un numero fissato di volte (nel nostro algoritmo, 15).
Anche questo viene facilmente implementato tramite le API di Hadoop:
1
String [ ]
u r l L i s t = new S t r i n g [ 0 ] ;
f o r ( ObjectWritable w : val ) {
3
i f (w . g e t D e c l a r e d C l a s s ( ) . t o S t r i n g ( ) . e q u a l s ( D o u b l e W r i t a b l e .
class . toString () ) ) {
rank += d ∗ ( ( D o u b l e W r i t a b l e ) w . g e t ( ) ) . g e t ( ) ;
}
5
i f (w . g e t D e c l a r e d C l a s s ( ) . t o S t r i n g ( ) . e q u a l s ( S t r i n g [ ] . c l a s s .
toString () ) ) {
7
u r l L i s t = ( S t r i n g [ ] ) w. get ( ) ;
}
9
}
rank = ( 1 − d ) + rank ;
2.4. PAGERANK CON HADOOP
11
c o n t e x t . w r i t e ( key , new RankRecord ( rank , u r l L i s t ) ) ;
13
14
CAPITOLO 2. IL PAGERANK
Capitolo 3
Analisi delle prestazioni
3.1
Hardware
L’analisi delle prestazioni è stata effettuata su una griglia complessiva di 39
macchine, 1 master e 38 slave. Tuttavia, l’installazione del framework Hadoop è
stata effettuata su macchine virtuali. Descriveremo quindi in seguito sia la configurazione hardware di ogni macchina ospitante sia la configurazione di ciascuna
delle macchine virtuali.
Le macchine sono collegate tra loro da una rete LAN a 100 Mbit/s.
3.1.1
Macchina fisica
Ciascuna delle 39 macchine fisiche è dotata di
• 4 GB di memoria RAM
• Sistema Operativo Windows 7 a 32-bit
• Processore Intel Celeron G530, dual-core 2.4GHz
• 230 GB di hard-disk
15
16
CAPITOLO 3. ANALISI DELLE PRESTAZIONI
3.1.2
Macchina virtuale
La configurazione di ogni macchina virtuale prevede
• 2 GB di memoria RAM
• Sistema Operativo Linux Ubuntu 11.10 a 32-bit
• 1 Processore
• 50 GB di hard-disk
3.2
Casi di studio
3.2.1
Caso di studio 1
Nel primo caso di studio abbiamo voluto misurare le performance del nostro
algoritmo su un diverso numero di macchine (1, 4, 8, 16, 32, 38), per valutarne
la scalabilità a parità di input (16 GB). Il tempo di esecuzione dell’algoritmo, in
stand-alone, su una sola macchina è stato di 24 ore. Passando già a una configurazione con sole 4 macchine si può notare come la scalabilità sia quasi lineare.
Il limite teorico lineare (riportato in rosso sul grafico 3.1) è chiaramente utopico
utilizzando Hadoop, in quanto bisogna tenere in considerazione l’overhead da
inizializzazione dei map/reduce task, dallo split dell’input e dal suo successivo
riassemblamento finale.
Ciò nonostante, il grafico 3.1 mostra come passando da una configurazione
all’altra, le performance vengono incrementate in maniera notevole, confermando quanto sia importante per le performance di questo algoritmo il numero
di macchine a disposizione. Utilizzando il massimo numero di slave a nostra
disposizione i tempi crollano da 24 ore (1 nodo) a soli 49 minuti (38 nodi).
3.2. CASI DI STUDIO
17
Figura 3.1: Test di scalabilità con input 16 GB
3.2.2
Caso di studio 2
In questo secondo caso di studio abbiamo misurato le differenze, in termini di
tempi di prestazioni, nel modificare il numero di reduce impiegati da Hadoop.
Questo caso di studio ha avuto un’importanza cruciale, in quanto il nostro algoritmo concentra proprio nella fase di reduce, buona parte della sua complessità
computazionale. In generale, è possibile conoscere a priori il numero ottimale
di reduce task dalla formula
(nodes ∗ mapred.tasktracker.tasks.maximum)∗ c
dove nodes è il numero di slaves impiegati, mapred.tasktracker.tasks.maximum
indica il numero massimo di map/reduce task che possono essere eseguiti simultaneamente da ciascuna macchina (di default è pari a 2), mentre c vale 0.95 o
1.75.
É possibile effettuare lo stesso ragionamento per il numero di processi map.
Tuttavia, nel nostro caso, la fase di map è di basso carico e, quindi, non siamo
18
CAPITOLO 3. ANALISI DELLE PRESTAZIONI
Figura 3.2: Performance al variare del numero di reduce task
intervenuti nel modificare a mano il numero di map task, preferendo il comportamento classico di Hadoop. Il numero di map task, in Hadoop, dipende dalla
taglia del file di input e dal valore di block size: più blocchi ha il file di input,
maggiori saranno i map task impiegati. É possibile intervenire sul numero di
map task modificando il valore di block size di Hadoop (di default è pari a 64
MB).
L’importanza di quantificare il numero di map/reduce task è importantissimo, poichè l’inizializzazione di ciascuno di essi comporta un’aggiunta di overhead al carico totale che può non essere giustificato nel caso in cui il lavoro che
essi compiano sia di breve durata.
Nel nostro caso di studio abbiamo provato a modificare il numero di reduce task su un file di input di 16 GB. Il nostro test è stato eseguito su 38
macchine con 72 e 133 reduce task (questi numeri sono derivati dall’espressione precedente). Com’è possibile osservare in figura 3.2, con 72 e 133 task,
il miglioramento rispetto all’algoritmo stand-alone è tangibile e questo è gius-
3.2. CASI DI STUDIO
19
tificato dal fatto che il nostro algoritmo concentra buona parte del carico nella
fase di reduce. Con 72 reduce otteniamo tempi di prestazione ottimali. Anche
questo è in linea con le nostre attese, poichè non è possibile eseguire più di 2
task in parallelo su una macchina, con 133 reduce alcuni task vengono messi in
coda ed eseguiti in un secondo momento e, aggiungendo a questo l’overhead di
inizializzazione, è giustificato il peggioramento delle prestazioni.
3.2.3
Caso di studio 3
Nel nostro terzo caso di studio abbiamo voluto misurare le prestazioni del nostro
algoritmo su file di input di taglia differente. Precisamente le dimensioni dei dati
di input analizzati sono stati 5.7 MB, 509 MB, 3.7 GB e 16 GB tutti eseguiti
sul cluster completo di 38 macchine.
Figura 3.3: Confronto prestazioni dell’algoritmo tra locale e distribuito
Per il primo file, osserviamo dal grafico 3.3 che addirittura l’utilizzo di
Hadoop peggiora le prestazioni rispetto all’esecuzione dello stesso input in modalità
20
CAPITOLO 3. ANALISI DELLE PRESTAZIONI
stand-alone. Questo risultato è giustificabile poichè, come già detto, Hadoop ha
dell’overhead intrinseco dovuto all’inizializzazione dei vari task e alla lavorazione
dell’I/O. Oltre a ciò, la taglia del file in input è inferiore alla block size di default
(64 MB), per cui l’algoritmo non utilizza nient’altro che 1 solo map task.
Il discorso cambia già a partire dal secondo input, 5 volte superiore rispetto
al primo, su cui le prestazioni di Hadoop iniziano a dare i loro frutti, riducendo
a meno di 1/4 il tempo di esecuzione rispetto a un singolo pc. Questo è giustificabile perchè il carico di computazione che si concentra nella fase di map viene
scaricato in più task che, come già detto, crescono proporzionalmente con la
taglia dell’input.
Le prestazioni più incoraggianti si hanno sui due input di taglia maggiore,
dove il confronto tra cluster di Hadoop e macchina singola diventa imbarazzante:
nel caso estremo si passa da 24 ore di esecuzione a soli 49m! La spiegazione di
questo miglioramento, oltre alle potenzialità di Hadoop, è dovuta al fatto che il
nostro algoritmo concentra buona parte della computazione nella fase di reduce.
Quindi, aumentando il numero di postazioni e, di conseguenza, il numero di
reduce task, i benefici sono evidenti.
3.2.4
Caso di studio 4
In quest’ultimo caso di studio abbiamo confrontato i tempi di esecuzione variando il numero di repliche dei dati in input. Il fattore di replica, di default
pari a 2, è un indice importante che indica il numero di repliche per ogni blocco
del file sui nodi della rete. Nel caso predefinito, ad esempio, ogni blocco dei
file in input sarà presente su due macchine del cluster. Questo indice influisce
anche sul tempo di caricamento dell’input da file system classici al file system
distribuito di Hadoop.
Nel nostro caso abbiamo configurato Hadoop per effettuare 1, 2 e 3 repliche
di un file di input di 3.7GB.
3.2. CASI DI STUDIO
21
Figura 3.4: Performance al variare del fattore di replica
Come possiamo osservare dal grafico 3.4, i tempi di esecuzione non sono
fortemente influenzati dalla modifica del fattore di replica, per cui in tutti i
nostri casi di studio precedenti abbiamo utilizzato il fattore di replica di default,
pari a 2.
22
CAPITOLO 3. ANALISI DELLE PRESTAZIONI
Capitolo 4
Conclusioni
Come abbiamo potuto osservare dai risultati descritti precedentemente, PageRank è sicuramente un algoritmo che si adatta al paradigma del grid computing.
Con una griglia di modesta entità sono balzati subito all’occhio i grandi guadagni
in termini di tempi di esecuzione e scalabilità e abbiamo buone ragioni di credere
che questi risultati possano essere confermati con griglie molto più grandi e performanti. Il paradigma map/reduce di Hadoop ha inoltre facilitato enormemente
lo sviluppo dell’algoritmo e i test, gestendo in maniera totalmente trasparente
le modifiche di configurazione delle macchine e contribuendo a raggiungere in
un lasso di tempo più che ragionevole i nostri risultati.
23
24
CAPITOLO 4. CONCLUSIONI
Bibliografia
[DJ10]
Easley D. and Kleimberg J. Networks, Crowds and Markets. Cambride
University Press, New York, 2010.
[Whi09] Tom White. Hadoop: The definitive guide. O’Reilly, 2009.
25