Designing a web crawler

Question

I have come across an interview question "If you were designing a web crawler, how would you avoid getting into infinite loops? " and I am trying to answer it.

How does it all begin from the beginning. Say Google started with some hub pages say hundreds of them (How these hub pages were found in the first place is a different sub-question). As Google follows links from a page and so on, does it keep making a hash table to make sure that it doesn't follow the earlier visited pages.

What if the same page has 2 names (URLs) say in these days when we have URL shorteners etc..

I have taken Google as an example. Though Google doesn't leak how its web crawler algorithms and page ranking etc work, but any guesses?

Solution 1

If you want to get a detailed answer take a look at section 3.8 this paper, which describes the URL-seen test of a modern scraper:

In the course of extracting links, any Web crawler will encounter multiple links to the same document. To avoid downloading and processing a document multiple times, a URL-seen test must be performed on each extracted link before adding it to the URL frontier. (An alternative design would be to instead perform the URL-seen test when the URL is removed from the frontier, but this approach would result in a much larger frontier.)

To perform the URL-seen test, we store all of the URLs seen by Mercator in canonical form in a large table called the URL set. Again, there are too many entries for them all to fit in memory, so like the document fingerprint set, the URL set is stored mostly on disk.

To save space, we do not store the textual representation of each URL in the URL set, but rather a fixed-sized checksum. Unlike the fingerprints presented to the content-seen test’s document fingerprint set, the stream of URLs tested against the URL set has a non-trivial amount of locality. To reduce the number of operations on the backing disk file, we therefore keep an in-memory cache of popular URLs. The intuition for this cache is that links to some URLs are quite common, so caching the popular ones in memory will lead to a high in-memory hit rate.

In fact, using an in-memory cache of 2^18 entries and the LRU-like clock replacement policy, we achieve an overall hit rate on the in-memory cache of 66.2%, and a hit rate of 9.5% on the table of recently-added URLs, for a net hit rate of 75.7%. Moreover, of the 24.3% of requests that miss in both the cache of popular URLs and the table of recently-added URLs, about 1=3 produce hits on the buffer in our random access file implementation, which also resides in user-space. The net result of all this buffering is that each membership test we perform on the URL set results in an average of 0.16 seek and 0.17 read kernel calls (some fraction of which are served out of the kernel’s file system buffers). So, each URL set membership test induces one-sixth as many kernel calls as a membership test on the document fingerprint set. These savings are purely due to the amount of URL locality (i.e., repetition of popular URLs) inherent in the stream of URLs encountered during a crawl.

Basically they hash all of the URLs with a hashing function that guarantees unique hashes for each URL and due to the locality of URLs, it becomes very easy to find URLs. Google even open-sourced their hashing function: CityHash

WARNING!
They might also be talking about bot traps!!! A bot trap is a section of a page that keeps generating new links with unique URLs and you will essentially get trapped in an "infinite loop" by following the links that are being served by that page. This is not exactly a loop, because a loop would be the result of visiting the same URL, but it's an infinite chain of URLs which you should avoid crawling.

Update 12/13/2012- the day after the world was supposed to end :)

Per Fr0zenFyr's comment: if one uses the AOPIC algorithm for selecting pages, then it's fairly easy to avoid bot-traps of the infinite loop kind. Here is a summary of how AOPIC works:

1. Get a set of N seed pages.
2. Allocate X amount of credit to each page, such that each page has X/N credit (i.e. equal amount of credit) before crawling has started.
3. Select a page P, where the P has the highest amount of credit (or if all pages have the same amount of credit, then crawl a random page).
4. Crawl page P (let's say that P had 100 credits when it was crawled).
5. Extract all the links from page P (let's say there are 10 of them).
6. Set the credits of P to 0.
7. Take a 10% "tax" and allocate it to a Lambda page.
8. Allocate an equal amount of credits each link found on page P from P's original credit - the tax: so (100 (P credits) - 10 (10% tax))/10 (links) = 9 credits per each link.
9. Repeat from step 3.

Since the Lambda page continuously collects tax, eventually it will be the page with the largest amount of credit and we'll have to "crawl" it. I say "crawl" in quotes, because we don't actually make an HTTP request for the Lambda page, we just take its credits and distribute them equally to all of the pages in our database.

Since bot traps only give internal links credits and they rarely get credit from the outside, they will continually leak credits (from taxation) to the Lambda page. The Lambda page will distribute that credits out to all of the pages in the database evenly and upon each cycle the bot trap page will lose more and more credits, until it has so little credits that it almost never gets crawled again. This will not happen with good pages, because they often get credits from back-links found on other pages. This also results in a dynamic page rank and what you will notice is that any time you take a snapshot of your database, order the pages by the amount of credits they have, then they will most likely be ordered roughly according to their true page rank.

This only avoid bot traps of the infinite-loop kind, but there are many other bot traps which you should watch out for and there are ways to get around them too.

Solution 2

While everybody here already suggested how to create your web crawler, here is how how Google ranks pages.

Google gives each page a rank based on the number of callback links (how many links on other websites point to a specific website/page). This is called relevance score. This is based on the fact that if a page has many other pages link to it, it's probably an important page.

Each site/page is viewed as a node in a graph. Links to other pages are directed edges. A degree of a vertex is defined as the number of incoming edges. Nodes with a higher number of incoming edges are ranked higher.

Here's how the PageRank is determined. Suppose that page Pj has Lj links. If one of those links is to page Pi, then Pj will pass on 1/Lj of its importance to Pi. The importance ranking of Pi is then the sum of all the contributions made by pages linking to it. So if we denote the set of pages linking to Pi by Bi, then we have this formula:

Importance(Pi)= sum( Importance(Pj)/Lj ) for all links from Pi to Bi

The ranks are placed in a matrix called hyperlink matrix: H[i,j]

A row in this matrix is either 0, or 1/Lj if there is a link from Pi to Bi. Another property of this matrix is that if we sum all rows in a column we get 1.

Now we need multiply this matrix by an Eigen vector, named I (with eigen value 1) such that:

I = H*I

Now we start iterating: IH, IIH, IIIH .... I^k *H until the solution converges. ie we get pretty much the same numbers in the matrix in step k and k+1.

Now whatever is left in the I vector is the importance of each page.

For a simple class homework example see http://www.math.cornell.edu/~mec/Winter2009/RalucaRemus/Lecture3/lecture3.html

As for solving the duplicate issue in your interview question, do a checksum on the entire page and use either that or a bash of the checksum as your key in a map to keep track of visited pages.

Solution 3

Depends on how deep their question was intended to be. If they were just trying to avoid following the same links back and forth, then hashing the URL's would be sufficient.

What about content that has literally thousands of URL's that lead to the same content? Like a QueryString parameter that doesn't affect anything, but can have an infinite number of iterations. I suppose you could hash the contents of the page as well and compare URL's to see if they are similar to catch content that is identified by multiple URL's. See for example, Bot Traps mentioned in @Lirik's post.

Comments

[xyz]

But how do you construct the graph in the first place? if we don't want duplicate nodes i.e. we want only one node for a url, then again you need a way to detect and discard a duplicate while contructing the graph itself..

[Pepe]

@learnerforever hmmm yes that is true ... I have honestly only written a simple crawler that handled only about a 100 links so actually going into each page wasn't a huge issue. But yes I can see the problems arising when you apply this to the entire web. Lirik's paper seems worthwhile though...

[xyz]

This takes me to another question I have had. How do we hash whole content of a page. such pages are say at least 2 pagers. What kind of hash functions are able to hash 2 pagers to a single value? What is the size of a typically such hash output?

[Fr0zenFyr]

Excellent explanation. I had the same question in mind about loops (was answered above) and bot traps (still searching for a nice way to get around). I'd have given an additional +1 for CityHash, if SO allowed me. Cheers ;)

[Kiril]

@Fr0zenFyr You don't have to worry about bot traps of the infinite-loop kind, especially if you use the AOPIC algorithm for selecting URLs to crawl. I'll update my answer with a bit more detail.

[Kiril]

@Fr0zenFyr So the best way to avoid bot traps is to crawl politely, otherwise you'll have to take a look at all the ways you can get trapped and work around them. I.e. you basically have to implement a browser, use proxies, and imitate multiple browsers by switching user-agents (in accordance with the browser usage statistics)

[Fr0zenFyr]

My current model completely follows robots.txt, no-follow etc and doesn't do aggressive crawl. Thanks for the update on your post, I'll try your suggestion on AOPIC. By, the way, mayan calendar judgement day is 21Dec2012 [rolling eyes].. ;)

[Kiril]

@Fr0zenFyr ROFL, that's how much I follow the end of the world stuff I guess :)

[edocetirwi]

Checksum could be different if the page spits out dynamic content.

[Adrian]

@edocetirwi good point, I guess you'd have to look for sth else or combine it w the URL in some meaningful way

[Casper]

Dumb question maybe, but what is the Lambda page that tax is allocated to? It seems to be introduced without explanation.

[Filipe Gonçalves]

@Casper It's just a placeholder to accumulate tax credits. It doesn't represent a real page; think of it as a sentinel in the data structure that causes all of the tax accumulated credit to be redistributed over the other "real" pages when it is crawled.

[CpILL]

oh, so you just integrate over the hyperlink matrix which has the dimensions every-webpage-on-the-internet x every-webpage-on-the-internet. Easy?!? How does one do that exactly (given its a very sparse matrix)?

[Adrian]

@CpILL you're 7 years late, but there are smart ways to multiply large matrices without blowing up; If you want a production ready solution I am willing to accept payment

[CpILL]

@Adrian I'm sure you are... but I've noticed it is mostly developers on Stackoverflow and we like to do it ourselves, that is why we're here! :D

[Brian Tompsett - 汤莱恩]

This does not really answer the question: "If you were designing a web crawler, how would you avoid getting into infinite loops? " Please improve your answer.

[Karthikeyan Moorthy]

Hi Brain Sir, Thanks for comments, Actually we need to create an instance for this class and then we can apply to use.

[raju]

@Kiril Isn't distributing the tax place holder's credits to all the urls collected difficult to scale? Suddenly you need to make billions of updates! How would you scale it?

[Kiril]

@raju that doesn't happen on every cycle, it only happens once you "crawl" the lambda. "Crawling" the lambda shouldn't happen very often and you can do it asynchronously. It doesn't need to happen in real-time, it just needs to happen eventually.