Web Spider
Antonio Gullì
[email protected]
Compito di un sistema di spidering



Raccogliere documenti dal Web a partire da un set
S0 dato in input
Gweb=(Nweb,E web) grafo orientato che descrive
l’insieme delle pagine e dei link
Tipi di visita:



DFS
BFS
Con priorità


Pre-assegnata staticamente -- PageRank (approssimato)
Assegnata dinamicamente
Architettura di un Search Engine
INTERNET
Spider
Query
Engine
Ranker
Page
Repository
Indicizzatore
Architettura Spider
INTERNET
DNS
Revolvers
LEGENDA
DNS Cache
Strutture Dati
Parallel
Downloaders
Moduli Software
Already
Seen Pages
Parsers
Parallel
Crawler Managers
…
Indexer
Priority
Que
…
Robot.txt
Cache
…
Parallel Link
Extractors
Distributed Page
Repository
SPIDERS
INDEXERS
Page
Analysis
Architettura Spider
Principali Strutture Dati






Pagine già visitate (problema: quando URL distinte
puntano in realtà alla stessa pagina o a pagine simili?)
Prossime pagine da visitare (coda di priorità o struttura
FIFO/LIFO, con update dinamico efficiente)
Robot.txt cache (I Webmaster possono raccomandare
cosa visitare e cosa non visitare)
DNS cache (risoluzione degli indirizzi IP)
Page Repository (dove memorizzare le pagine)
Architettura Spider
Principali Moduli Software






Crawler Managers (si coordinano per decidere i prossimi
task da assegnare ai Downloaders, Bilanciamento,
controllo del carico…)
DNS Resolvers (risolvono gli indirizzi IP in modo async)
Parallel Downloaders (effettuano il download vero e
proprio delle pagine Web usando HTTP)
Parsers (convertono i formati, parserizzano le
informazioni, memorizzano le pagine nel repository)
Link Extractors (estraggono i link dalle pagine presenti nel
repository e li memorizzano, senza sosta, nella struttura
dati che tiene traccia delle prossime pagine da visitare)
Note sul funzionamento spider
Se una pagina non è stata modificata ?


Supporto direttamente fornito da HTTP

http://www.w3.org/Protocols/rfc1945/rfc1945
"conditional GET" If-Modified-Since header field
Se il Webmaster non vuole far visitare una pagina?

Supporto dato, come raccomandaz., dal Robot Standard
1.

2.
http://www.robotstxt.org/wc/norobots.html
META tag all’interno di HTML
Note sul funzionamento spider
Presentarsi (HTTP Header)




“The User-Agent request-header field contains information about the user agent
originating the request. …statistical purposes, the tracing of protocol violations,
and automated recognition of user agents… Although it is not required, user
agents should include this field with requests.”
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Filtrare (Esempio di Robot.txt)
User-agent: webcrawler
Disallow:
User-agent: lycra
Disallow: /
User-agent: *
Disallow: /tmp
Disallow: /logs

Filtrare (Esempio di META TAG)
<META NAME="ROBOTS" CONTENT="NOINDEX">
<META NAME="ROBOTS" CONTENT="NOFOLLOW">
Combinazioni delle due
Algoritmi usati ad alto livello dai moduli sw
Link Extractor:
while(<ci sono pagine da cui estrarre i link>){
<prendi una pagina p dal page repository>
<estrai i link contenuti nel tag a href>
<estrai i link contenuti in javascript>
<estrai …..
<estrai i link contenuti nei frameset>
<inserisci i link estratti nella priority que, ciascuna con
una priorità dipendente dalla politica scelta e:
1) compatibilmente ai filtri applicati
2) applicando le operazioni di normalizzazione>
<marca p come pagina da cui abbiamo estratto i link>
}
Downloaders:
while(<ci sono url assegnate dai crawler manager>){
<estrai le url dalla coda di assegnamento>
<scarica le pagine pi associate alla url dalla rete>
<invia le pi al page repository>
}
Crawler Manager:
<estrai un bunch di url dalla “priority que” in ordine>
while(<ci sono url assegnate dai crawler manager>){
<estrai le URL ed assegnale ad S>
foreach u  S {
if ( (u  “Already Seen Page” ) ||
( u  “Already Seen Page” && (<sul Web server la pagina è più recente> )
&& ( <u è un url accettata dal robot.txt del sito>) ) {
<risolvi u rispetto al DNS>
<invia u ai downloaders, in coda>
}
}
Architettura Distribuita Spider

Google (www.google.com )

3,083,324,652 pagine raccolte
Centinaia di milioni di Web server distinti
Stimando 4Kb per pagina compressa → >10Tera
~1.000 server linux (10% totale) → sistema distribuito
phython e c++

http://www.google.com/bot.html





Fast ( www.alltheweb.com )
 2,112,188,990 pagine raccolte
 c++

Liste di spider noti
 http://joseluis.pellicer.org/ua/
 http://www.robotstxt.org/wc/active/html/index.html
Architettura Distribuita Spider

Stima “dall’esterno” delle performance richiesta



Supponendo che il 40% delle pagine Web si
modifichi in una settimana (~ 1.250.000.000) →
~2000 page/sec
Una singola macchina linux con “puro download”
raggiunge picchi di 80-100 page/sec usando
Posix thread
Rallentamenti dovuti a latenza di rete e gestione
locale dati e strutture distribuite
Architettura Distribuita Spider

Requisiti

Architettura altamente ottimizzata


Tolleranza ai guasti


Nuovi formati (PDF, PS, XML), Nuove politiche, Nuovi protocolli, …
Correttezza


server non HTTP complaint, HTML non complaint, HTTP/HTML trap…
Estendibilità


Il fallimento di un server non deve bloccare il sistema, punti di
recovery….
Robustezza


Elevato page download rate, ridurre i colli di bottiglia
Non essere invasivo, Presentarsi correttamente, No hammering, …
Configurabilità on the fly

Larry Page, 97: “It turns out that running a crawler which connects to
more than half a million servers, and generates tens of millions of log
entries generates a fair amount of email and phone calls”
Architettura Distribuita Spider

Sistema distribuito (100 … >1000 spider server )


Problema: partizionamento delle pagine Web da visitare
Soluzione:





Hash per sito
Hash per URL
Gerarchica (per domini), Geografica (per nazioni)
Problema: con che frequenza aggiornare le pagine Web
Soluzioni Adattative

Per esempio, settando la freq. di aggiornamento in base alle
modifiche nelle precedenti visite
Architettura Distribuita Spider

Sistema distribuito (100 … >1000 spider server )


Problema: tenere sincronizzata la struttura “Already Seen Pages”
tra i vari nodi di elaborazione
Soluzioni Euristiche:






Caching/Replicazione delle URL più frequentemente accedute
Bloom Filter, descrizione approssimata delle URL possedute localmente
Batch Update, con limitata probabilità di visite ripetute
Hash per sito o altri assegnamenti statici con zero-overlap
Problema: minimizzare l’impatto delle comunicazioni inter nodo
Soluzioni comuni:


Comunicazioni bufferizzate
Caching / Replicazione
Architettura Distribuita Spider

Sistema distribuito (100 … >1000 spider server )

Problema: come individuare se due pagine sono simili


Soluzione Euristica: Signature




Esempio pagine con counter, javascript che modifica il testo
Estrazioni di parte “significativa” del testo
MD5 (spesso usato in luogo della stessa URL), SHA, Fingerprint
Problema: come evitare di sovraccaricare i server
remoti
Soluzione:


Politiche di throttling
Intervallare il download di URL provenienti da siti Web distinti
Architettura Distribuita Spider

Sistema distribuito (100 … >1000 spider server )


Problema: aumentare l’efficienza del singolo nodo spidering
Soluzioni comuni:



Multithreading: cpu bound, i/o bound (Es, altavista)
I/O Async (Es, Google)
Pipeline software
D
P
D
R
P
D
D
P
R
Page Downloading
Parsing
Sending to Repository
R
P
R
Architettura Distribuita Spider

Sistema distribuito (100 … >1000 spider server )


Problema: bilanciare il carico e garantire fault-tollerance
Soluzione:
 Hash (soluzione comune, ma non tutte le pagine ed i siti
pesano allo stesso modo. Cosa succede in caso di
fallimento ?)
 Consistent Hashing (usato inizialmente in Web Caching e
P2P sia le URL che i server sono mappati in un unit circle.
In caso di caduta non è necessario un remapping
completo)
 Database con transizioni
Architettura Distribuita Spider

Sistema distribuito (100 … >1000 spider server )


Problema: minimizzare la distanza di rete tra le pagine Web
ed il sistema di spider
Soluzione: Tipicamente si distribuisce il lavoro tra diversi
data-center




località geografiche distinte (Google 4 distinti)
minimizzare il numero di border gateways attraversati
Problema: Individuare un dataset S0 ”buono”. La scelta della
frontiera da cui partire ha un impatto diretto sulla “rapidità”
con cui si converge verso le pagine “interessanti”
Soluzione: ODP, …
Politiche di visita delle pagine








BFS, DFS
Priorità: BackLink count, Frequenza di modifica
Priorità: PageRank, Google
R(i) = (1-d) / N + d * ∑j (R(j) / N(j)), j  B(i)
0<d<1, N numero delle pagine nella collezione
B(i) insieme delle pagine che puntano la pagina i
N(j) numero dei link uscenti dalla pagina j
Spesso si calcolano delle approssimazioni
Confronto:



Google: Junghoo Cho and Hector Garcia-Molina and Lawrence Page, "Efficient
crawling through URL ordering", "Computer Networks and ISDN Systems, vol 30
num. 1—7 pages 161--172", "1998";
Altavista: Marc Najork and Janet L. Wiener, "Breadth-First Crawling Yields HighQuality Pages Proceedings of the 10th International World Wide Web Conference
Elsevier Science Hong Kong 114—118 May 2001",
Politiche di visita delle pagine


“…breadth-first search order discovers the highest
quality pages during the early stages of the crawl BFS”
328 milioni di URL nel testbed
Politiche di visita: brevi cenni su Focused Crawling

Idea: massimizziamo il numero di pagine “rilevanti” raccolte e
minimizziamo quelle raggiunte


Analisi della struttura dei link


Pagerank
Modelli di retrieval


http://dev.funnelback.com/focused-crawler-review.html
Vector space “query driven” (agenti)
Machine Learning


Costruzione dei “grafi contestuali” (chi linka cosa ?)
Approccio Bayesano, un set di classificatori vengono trainati per
assegnare documenti a differenti categorie basandosi sulla loro
distanza attesa dalle pagine obbiettivo
Politiche di visita: brevi cenni su Focused Crawling

il teorema di Bayes stima la probabilità condizionale
che si verifichi l’evento Hi in presenza dell’evento E:
Pr( H i | E ) 
Pr( E | H i ) Pr( H i )
i  1,...., n
P( E )   Pr( E | H j ) Pr( Hj )
j

Pr[documento rilevante | che il termine t è presente]
Pr[documento irrilevante | che il termine t è presente]
Pr[termine t sia presente | il documento sia rilevante]

Pr[termine t sia presente | il documento sia irrilevante]


Indicizzare ciò che non si è raccolto
25-30% dell’indice di google è costruito in tal modo




Esempio “madonna”
This is G o o g l e's cache of http://www.madonna.com/.
These terms only appear in links pointing to this page: madonna
Desumere il “contenuto” di una pagina Web dal
“contesto” in cui la stessa è sistemata



Nessun contenuto testuale
pagina non raggiunta
Indicizzare ciò che non si è raccolto
Supponiamo di non avere raggiunto la pagina P “whitehouse.org”,
ma di avere già raggiunto ed indicizzato un insieme di pagine
{P1….Pr} che puntano P
Supponiamo di estrarre dal link che da ciascun Pi, 1<i<r, punta P
una finestra di testo.




…George Bush, President of U.S. lives at <a
href=http://www.whitehouse.org> WhiteHouse</a>
… George Washington was at <a href=http://whitehouse.org>
WhiteHouse</a>
Pagina Web e Documento
Virtuale
bush
White House
Washington
Tecniche alternative di URL Discovery

“Hidden Web”: non linkata o HTML non statico

Riferito dal browser:


Presente sul DNS



HTTP 1.0: “The Referer request-header field allows the client
to specify, for the server's benefit, the address (URI) of the
resource from which the Request-URI was obtained.”
Testata con demoni di discovery
Presente su Usenet o altre fonti
Generata “on the fly”

~ 60-80% dei contenuti Web
Un esempio concreto: high-performance
distributed Web crawler – Univ. Brooklyn 2002




5.000 linee C++, phython, STL, Red-Black tree, PCRE, BDB
Comunicazioni bufferizzate intranodo, inter-nodo
Strategia BFS (altre integrabili)
Partizionamento delle URL via hash






K-way shuffling
Coda di Priorità per gli host ready e quelli waiting (recentemente
acceduti); Inoltre una coda di priorità per ciascun host
Page Repository realizzato via NFS su 4 Sun servers
DNS Resolver asincrono
Complessive 300 pagine al secondo (limite sui router), 18
giorni in totale, checkpoint ogni 4 ore
138 milioni di pagine scaricate, 120 milioni di pagine “uniche”
Un esempio concreto: high-performance
distributed Web crawler – Univ. Brooklyn 2002
HTTP requests:
network errors:
read timeout exceeded errors:
robots.txt requests:
successful non-robots requests
average size of page
total data size
total successfull non-robot requests
200 (OK)
404 (not found)
302 (moved temporarily)
301 (moved permanently)
161,549,811
5,873,685
2,288,084
16,933,942
138,742,184
13,354 bytes
1.85 TB
138,742,184
121,292,132
7,379,633
6,065,464
2,885,665
100.00%
87.42%
5.32%
4.37%
2.08%
Alcune soluzioni descritte in letteratura

Google




Sergey Brin and Lawrence Page, "The anatomy of a large-scale
hypertextual Web search engine", "Computer Networks and ISDN
Systems vol. 30 num 1--7, pages 107--117", "1998";
Junghoo Cho and Hector Garcia-Molina and Lawrence Page,
"Efficient crawling through URL ordering", "Computer Networks and
ISDN Systems, vol 30 num. 1—7 pages 161--172", "1998";
Junghoo Cho and Hector Garcia-Molina, “Parallel crawlers. In Proc.
of the 11th International World--Wide Web Conference", "2002";
Altavista


Allan Heydon and Marc Najork, "Mercator: A Scalable, Extensible
Web Crawler journal World Wide Web vol.2 num.4 pages 219-229
1999",
M. Najork and A. Heydon, "On High-Performance Web Crawling
Research Report, Compaq Systems Research Center, 2001",
Alcune soluzioni descritte in letteratura

Arianna, Università di Pisa


Università di Pisa


D. Dato, A. Gullì, G. Attardi, Web Host Enumeration Through DNS,
Web Net '97, Toronto, 1997.
Paolo Boldi and Bruno Codenotti and Massimo Santini and
Sebastiano Vigna, “UbiCrawler: A Scalable Fully Distributed Web
Crawler",
Polytechnic University, Brooklyn

V. Shkapenyuk and T. Suel. “Design and implementation of a highperformance distributed Web crawler”, “In Proceedings of the 18th
International Conference on Data Engineering (ICDE'02), San Jose,
CA Feb. 26--March 1, pages 357—368”, “2002”
‘Coffee’ time on google
Cookie di Sessione
Spider non espande
HTML non
significativo
ODP, ODP Descr.
Ma lo spider dove
ha trovato il caffè
nella prima
risposta?
PageRank da le risposte in un ordine intuitivo
‘Coffee’ time on google
Estratto dal documento virtuale
Documento dato dal Web Server