Ch20 Web crawling and indexes

1. Ch20 Web crawling and indexes 2010. 4. 19. 최성빈

2. Overview • Web crawling이란 인덱싱을 하고 검색엔진을 지원하기 위해서, 웹에서 페이지를 모으는 과정이다. • Crawling의 목적은, 최대한 빠르고 효율적으로, 가능한 많은 수의 유용한 웹 페이지를, (그들간의) 링크 구조와 함께 모으는 것이다. • 이번 장에서는,Web Crawler(spider)에 대해 살펴본다.

3. Overview • 이번 장의 목적은, 상업용 웹 검색 엔진을 위한 crawler를 어떻게 생성하는 가를 기술하려는 것이 아니다. • Student project나 연구 project 범위 내에서의 Crawling에 관련된 이슈를 다뤄본다. • 20.1 : web crawler의 요구사항 • 20.2 : 이들 각각이 어떻게 다루어지는지 • 20.3 : web-scale implementation을 위한, 다중의 기계에서의 distributing index에 대해 논의

4. 20.1.1 Features a crawler must provide • Robustness : 웹에는 Spider Trap을 생성하는 서버들이 있다. Spider trap : crawler를 호도(mislead)해서, 특정 도메인에서 무한한 숫자의 페이지를 전송(fetch)하도록 하는 웹페이지 crawler는 그러한 trap에서 저항성이(resilient) 있어야 한다. • Politeness : Web Server들은, crawler의 방문 율(rate)에 대해, 내재적인 혹은 명시된 정책이 있다. 이러한 정책을 존중해줘야 한다.

5. 20.1.2 Features a crawler should provide • Distributed: crawler는 다중의 기계에서 분산되어 작동할 수 있어야 한다. • Scalable: crawler는 다른 기계 및 bandwidth를 추가함으로써, crawling rate를 확장할 수 있어야 한다. • Performance and efficiency: crawl system은 processor, storage, network bandwidth등의, 다양한 시스템 자원을 효율적으로 사용해야 한다.

6. 20.1.2 Features a crawler should provide • Quality: 전체 웹 페이지의 상당 부분이, 사용자 요구사항과 관련해 유용성(utility)이 떨어지므로, Crawler는 유용한 페이지를 우선적으로 fetching해야 한다. • Freshness: 대부분의 application에서, crawler는 지속 모드로 동작해야 한다. 그래서 최신의 페이지들을 fetch해야 한다. • Extensible: crawler는 여러 방면에서 확장 가능해야 한다. 다른 data format이나, 새로운 fetch protocol등에 대응할 수 있어야 한다. 이를 위해선 crawler의 architecture가 모듈화 되어 있어야 한다.

7. 20.2 Crawling Hypertext Crawler의 기본 동작 • Crawler는 seed set을 구성하는 하나 혹은 여러 개의 URL에서 시작한다. • seed set에서 URL을 하나 선택한 뒤, 그 URL의 web page를 fetch한다. • 전송된 페이지는 파싱 되며, 텍스트와 링크가 추출된다. • 추출된 텍스트는 text indexer로 보내진다. • 추출된 링크는 URL frontier에 추가된다. URL frontier는 crawler가 미래에 fetch할 URL이다. • 이렇게 단순한, 재귀적인 동작 방식은, 실제 web crawling system이 가지는 많은 요구사항에 의해 복잡해진다.

8. 20.2 Crawling • 우리가 제시하는 crawling기법은, Mercator crawler의 design을 따른다. Mercator crawler는 많은 수의 연구용 및 상업용 crawler의 기반을 형성했다. • 참고로, 한 달에 10억 개의 페이지를 fetching하기 위해서는 1초에 수백 개 씩의 페이지를 fetch해야 한다. 이 정도 fetch rate를 달성하기 위해, 여러 병목 부위를 해결하려 multithreaded design을 어떻게 이용하는지 살펴볼 것이다.

9. 20.2 Crawling • 독자들 중 crawler를 만들고자 하는 사람을 위해, 비전문적인(nonprofessional)crawler가 만족해야 하는 기본 특성을 다시 한번 상기시켜 본다. • Only one connection should be open to any given host at a time • A waiting time of a few seconds should occur between successive requests to a host. • Politeness restrictions detailed in Section 20.2.1 should be obeyed.

10. 20.2.1 Crawler architecture • URL frontier : fetch할 URL을 보관 • DNS resolution module : URL로 지정된 페이지를 fetch할 web server를 결정한다. • Fetch module : Http protocol을 이용해 URL에서 웹 페이지를 가져온다 • Parsing module : fetch된 web page에서 텍스트와 링크를 추출한다. • Duplicate elimination module : 추출된 링크가 이미 URL frontier에 있거나, 최근에 fetch된 것인지 판별한다.

11. 20.2.1 Crawler Architecture • Crawling은 하나 혹은 수백개 이상의 thread에서 수행되며, 각각의 thread는 Figure 20.1의 논리 cycle을 순환하게 된다. • 이 thread는 단일 process로 수행될 수도 있고, 분산시스템의 서로 다른 노드 에서 다중의 process로 나뉘어 실행될 수도 있다.

12. 20.2.1 Crawler Architecture • Crawler thread는 URL을 frontier로부터 가지고 오는 것으로 시작한다. • URL에 해당하는 page를 http protocol을 이용해 fetching한다. • fetch된 page는 임시 저장소에 기록되고, 몇 가지 작업이 거기서 수행된다. • page를 parsing해 텍스트와 링크를 추출한다. • 텍스트는 indexer에 보내진다. • 링크 정보는 ranking을 위한 indexer(21장)에 보내진다. • 추출된 링크는 일련의 테스트를 거쳐, URL frontier로 보낼 지가 결정된다.

13. 20.2.1 Crawler Architecture 추출된 링크는 일련의 테스트를 거쳐, URL frontier로 보낼 지가 결정된다. 1. web page의 내용이 다른 URL에서 이미 관측된 내용인지 테스트한다.

14. 20.2.1 Crawler Architecture 2. 추출된 URL이 frontier에서 제외되어야 하는지에 대해, 몇 가지 테스트를 수행한 뒤, URL filter가 판단한다. • 예를 들어, crawl이 특정 domain을 제외하도록 할 수 있다. ex> 모든 .com URL • Web의 많은 호스트들이, 자신들의 website의 일부를 crawling에 제한을 가할 수 있다. robots exclusion protocol이라는 표준으로 알려져 있다. 이것은 robots.txt파일을 사이트 내 URL hierarchy의 root에 위치시키는 것으로 실행된다.

15. 20.2.1 Crawler Architecture 3. URL이 normalized되어야 한다. • 링크에 대한 HTML encoding은 종종 현재 페이지에 대한 상대주소를 지정하곤 한다. 예> 현재 페이지 : http://en.wikipedia.org/wiki/Main_Page http://en.wikipedia.org/wiki/Wikipedia:General_disclaimer 4. 중복 제거를 위한 체크 • URL이 이미 frontier에 있거나, (non-continuous crawl의 경우)이미 crawl된 경우, frontier에 추가하지 않는다.

16. 20.2.1 Crawler Architecture Crawler에서는, 특정 thread에 의해 housekeeping task가 수행되기도 한다. • 이런 thread는 대개 작동하지 않고 있다가, 가끔씩 몇 초간 작동한다. • crawl progress statistics의 로그 정보(crawl된 URL, frontier의 크기 등) 를 수집한다. • crawl의 작동을 중지시켜야 할지 결정한다. • checkpointing을 수행한다. • checkpointing : URL frontier등과 같은 crawler의 현재 상태를 snapshot해 디스크에 기록한다. • crawler에 치명적 오류가 발생하는 경우, crawler는 가장 최근의 checkpoint에서부터 다시 시작할 수 있다.

17. Distributing the crawler 분산된 crawler의 여러 노드가 어떻게 서로 통신하고 URL을 공유하는가? • URL filter 뒤에, host splitter를 이용해 URL을 배치(dispatch)한다.

18. Distributing the crawler • 하지만 분산 architecture의 “Content Seen?” module은 몇 가지 점에서 어려움이 있다. 1. URL frontier나 duplicate elimination module과 달리, document fingerprints/ shingles는 host name에 따라 partition될 수 없다. 따라서 fingerprints/shingles는 그들의 특성에 따라 partition되어야 한다. 대부분의 “Content Seen?” test는 remote procedure call로 이루어진다. 2. Document fingerprint/shingles의 stream에 locality가 거의 없다. 따라서, 자주 사용되는(popular)fingerprint를 caching하는 것은 도움이 되지 않는다. 3. 문서는 시간에 따라변화함으로, continuous crawling의 관점에서 볼 때, outdatedfingerprint/shingles를 content-seen set에서 삭제할 수 있어야 한다. 이를 위해, URL frontier에 URL 자체 뿐 아니라, fingerprint/shingles도 저장할 필요가 있다.

19. 20.2.2 DNS resolution • 각각의 Web Server는 고유의 IP 주소를 가지고 있다. • www.wikipedia.org와 같은 텍스트 형태의 URL을 207.142.131.248 과 같은 IP 주소로 변환하는 과정을 DNS(Domain Name Service) resolution 혹은 DNS lookup이라 한다. • DNS resolution과정에서, 변환을 수행하고자 하는 프로그램은 DNS server에 접촉하여 변환된 IP주소를 리턴받는다.

20. 20.2.2 DNS resolution • DNS resolution은 web crawling에서 잘 알려진 병목 부분이다. domain name service의 분산된 특성 상, 수초 혹은 그 이상의 시간이 소요된다. • 이런 특성은, 초 당 수백 개의 문서를 fetching해야 하는 목표에 장애물이 된다. • 표준적인 해결법은 caching이다. • 최근에 DNS lookup을 수행한 URL은, DNS cache에서 발견될 가능성이 높다.

21. 20.2.2 DNS resolution • DNS resolution의 또 하나의 어려움은, 표준 library에서 lookup의 구현은 대개 synchronous하다는 것이다. • DNS에 한 가지 request가 만들어진 경우, 그것이 완료될 때까지 그 노드의 다른 crawler thread들은 차단(block)된다. • 이것을 피하기 위해, 대부분의 web crawler는 그들만의 DNS resolver를 구현해 가지고 있다.

22. 20.2.2 DNS resolution • Thread i가 DNS server로 메시지를 보낸 뒤, timed wait를 수행 • 다른 thread로부터 신호를 받거나, 제한된 시간이 지난 경우, 다시 시작(resume)한다. • 하나의 분리된 DNS thread가, 표준 DNS port(port 53)에서, Named service로부터 들어오는 response packet을 수신한다. • response를 받으면, thread i의 시간 제한이 지나지 않은 경우, crawler thread i에 신호를 보내 response packet을 전달한다. • Thread i의 시간 제한이 지난 경우, 정해진 수 만큼 새로운 메시지를 DNS server로 보내는 것을 반복한다. Mercator의 디자이너는 5회를 권장한다. • 대기 시간의 시간 제한은 매 시도마다 지수적으로 증가한다. Mercator의 경우 1초에서 시작해 90초에서 끝난다.

23. 20.2.3 The URL frontier • 노드의URL frontier는,crawl process(혹은 다른 crawl process의 host splitter)에서 URL을 제공받는다. • URL을 frontier에 관리하고 있다가, crawler thread에서 URL을 요청할 때 다시 내주게 된다. • frontier가 리턴하는 URL의 순서에는, 두 가지 고려사항이 반영된다. 1. 자주 바뀌는 high-quality page는 자주 crawling할 필요가 있다. 페이지의 우선 순위는 quality와 change rate의 함수이다. 2. politeness. 짧은 시간 동안 반복적인 fetch request는 피해야 한다. • locality of reference : 많은 URL이 같은 host내의 다른 URL을 링크하는 경향이 있다. • 특정 시간에 한 host에 최대 한thread만 fetch할 수 있도록 제약을 두어도 이것은 마찬가지이다. • 체험적인 대안은, host에 대해 연속된 fetch request에 (host로부터 가장 최근에 fetch한 시간보다 몇 자리 수 큰) gap을 삽입하는 것이다.

24. 20.2.3 The URL frontier • URL frontier의 polite and prioritizing implementation을 보여준다.

25. 20.2.3 The URL frontier 목적 : • 1. only one connection is open at a time to any host. • 2. a waiting time of a few seconds occurs between successive requests to a host • 3. high-priority pages are crawled preferentially 두 가지 Major Submodule: F front queues, B back queues • 두 가지 모두 FIFO queues. • front queue는 Prioritization을 구현, • back queue는 politeness를 구현

26. 20.2.3 The URL frontier Front Queue : • URL이 Frontier에 추가되면, Prioritizer가 Fetch history(웹 페이지의 변화율을 고려)에기초해 URL에우선순위 i값(1에서 F사이 값)를 배정 -> URL은 이제 i번째 Front queue에 추가된다.

27. 20.2.3 The URL frontier Back Queue : • 각 B back queues는 다음을 준수한다. • it is nonempty while the crawl is in progress. • it only contains URLs from a single host • 보조 테이블 T를 이용해 host와 back queue의 mapping을 기록한다. • back queue가 비어서 front queue로부터 다시 채워질 때, 테이블 T도 같이 업데이트 되어야 한다.

28. 20.2.3 The URL frontier Heap : • 각 Back queue마다 하나의 entry를 가진다. • 가장 이른 시간에 entry가 된 queue의 host가 다시 contact할 수 있다.

29. 20.2.3 The URL frontier • Frontier로부터 URL을 요청하는 crawler thread는, heap의 root를 추출 • 추출한 heap root에 해당하는 back queue j의 head에서 URL u를 가져간다. • u를 fetching한 뒤, Calling thread는 j가 비어있는지 체크한다. • 비어있다면 front queue의 head에서 URL v를 추출한다. front queue의 선택은 랜덤 선택으로, 높은 우선순위를 가지는 queue로 biased되어 있다 (높은 우선순위를 가지는 URL이 보다 빠르게 back queue로 이동한다)

30. 20.2.3 The URL frontier • Front queue의 숫자,priority를 배정하는 방법,queue를 선택하는 정책이 시스템에 구축하고자 하는 priority 특성을 결정한다. • Back queue의 숫자가, politeness를 준수하면서 모든 crawl thread를 바쁘게 돌릴 수 있는 범위를 제어한다. • Mercator의 디자이너들은, crawler thread보다 약 3배 많은 수의 back queue를 추천했다. • web scale의 crawl에서, URLfrontier는 node에서 가용한 것보다 더 많은 양의 메모리를 요구할 수 있다. 해결책 : 대부분의 URL frontier가 디스크에 있도록 한다. queue의 일부분은 memory에 있도록 한다.

31. 20.3. Distributing indexes • 매우 많은 컴퓨터 cluster에서의 index 분산에 대해 생각해본다. • 인덱스 구현의 두 가지 대안 partitioning by terms : • index term의 dictionary가 subset으로 나뉘고, 각 subset이 node에 자리함 • 쿼리는 query term에 해당하는 node로 route된다. • 원칙적으로, 이것은 더 큰 동시성(concurrency)를 제공하는데, 서로 다른 쿼리 단어로 구성된 쿼리는 서로 다른 기계들을 작동시킬 것이기 때문 • 실제로는, multiword query는 merging을 위해 긴 postings list를 보내야 한다 -> 이 비용이 동시성의 장점을 상쇄시킨다. • partition간의 load balancing은 query term의 분포 및 co-occurrence에 따라 결정된다 -> 이것은 시간에 따라 갑자기 변하기도 한다. -> 최적화 하는 것이 쉽지 않다.

32. 20.3. Distributing indexes partitioning by documents : • 보다 자주 쓰이는 방법 • 각 노드는 문서 전체의 부분집합에 대한 인덱스를 가진다. • 쿼리는 모든 노드로 전달되고, 각 노드별 결과가 합쳐져 사용자에게 제공된다. • local disk seek이 더 많아지는 대신, internode communication을 줄인다. • 어려운 점 : idf와 같은 global statistics 의 경우 전체 collection의 문서를 대상으로 계산되어야만 한다. • 이것은 분산된 “background process”에 의해 계산된다. - 주기적으로 각 노드에global statistics를 refresh 한다.

33. 20.3. Distributing indexes • 문서를 노드에partition하는 방식을 어떻게 결정하는가? 1. 한 호스트의 모든 페이지는 한 노드로 배정한다. 2. 각 URL을 Index node공간에 hash한다. - 노드 별로 보다 균일한(uniform) 쿼리 시간을 가져온다. - 쿼리가 각 노드로 전해지고, 각 노드의 상위 k개 결과가 합쳐져, 쿼리에 대한 상위 k개 문서를 찾는다.

34. 20.4 Connectivity servers • 웹 검색 엔진은, Web Graph에 대한 Fast connectivity query를 지원하는 connectivity server를 필요로 한다. : crawl control, web graph analysis, sophisticated crawl optimization, link analysis(Ch 21) • Connectivity query : which URL link to a given URL? which URLs does a given URL link to? • Outlink및 Inlink의 URL들 간의 매핑을 메모리에 저장할 필요가 있다.

35. 20.4 Connectivity servers • Web에 40억 개의 페이지가 있고, 각각의 페이지가 다른 페이지로 10개의 링크를 가지고 있다고 가정 단순하게 계산해보면, 4 x 109 x 10 x 8 byte = 3.2 x 1011 byte 의 메모리가 필요하다. • 처음 보기에 이것은 Data compression문제로 보인다. • 하지만 우리의 목적은 단순히 Web graph를 압축해서 메모리에 맞추어 넣는 것이 아니다. => 효율적으로 connectivity query를 지원하는 것이다.

36. 20.4 Connectivity servers • 각각의 Web Page가 unique integer로 표현된다고 가정 • Inverted index와 유사한 Adjacency table을 만든다. • 특정 page p의 row는, p로 링크되는 웹 페이지들의 integer배열을 가진다. • 같은 방식으로 p에서 링크하는 페이지 또한 table로 나타낼 수 있다. • 이 방식은 앞서 방식에 비해 50%정도 공간을 절약할 수 있다. • Table의 저장 공간을 더 줄이기 위한, 몇 가지 다른 방법들이 있다.

37. 20.4 Connectivity servers 1. Similarity between lists • Table의 행 별로 많은 구성요소들이 중복되어 있다. • 여러 유사한 행끼리 prototype row를 지정한다면, 나머지는 간편하게 표현될 수 있을 것이다. 2. Locality • 많은 링크들이, 같은 host에 있는 page와 같이, “nearby” page로 링크되어 온다. • 따라서 encoding시 link의 destination을 작은 숫자를 사용해서 공간을 절약할 수 있다. 3. We use gap encodings in sorted lists • 각 link의 destination을 저장하기 보다, 직전 entry에서의 offset값을 기록한다.

38. 20.4 Connectivity servers • ㅇ • 같은 website에서 온 page들이, 근접된 정수 값을 가진다. • Table의 많은 entry들이 중복된 것이다.

39. 20.4 Connectivity servers • 4번째 줄을 다음과 같이 encode할 수 있다. “The same as the row at offset 2, with 9 replaced 8” • offset, integer dropped, integer added 의 정보가 특정되어야 함 • 7개의 이전 행 까지만 offset 적용함 => 2가지 이점 (1) offset값이 3bit만으로 표현 가능하다 (경험적으로 조절 가능). (2) maximum offset을 작은 값으로 설정함으로서, 여러 candidate prototype들을 검색하는 일을 하지 않을 수 있다.

40. 20.4 Connectivity servers • 만약 이전 7개 행에서, 현재 행을 표현하는 데 적합한 prototype이 관찰되지 않는다면? • 이런 경우 empty set에서 시작해서 각 정수를 더하는 방식으로 표현한다.

41. 20.4 Connectivity servers • 먼저, URL hash에서 index lookup을 해서,Table내의 row number를 얻는다. 그리고 다른 행의 엔트리에 관계해서 encode된 entry들을 재구성한다. -> 이과정은여러 단계의 indirection을 거치게 된다. • 하지만 실제로는 자주 일어나지는 않는다. • Table을 생성할 때, heuristic을 적용해서, 현재 행을 모델링 할 후보로, 이전 7개 행을 조사할 때 둘 간의 similarity 의 threshold를 요구한다. • Threshold값은 주의 깊게 설정되어야 한다. • 너무 높게 설정되면, prototype을 거의 사용치 않고, 대부분의 행이 새로 만들어지는 행이 된다. • 너무 낮게 설정되면, 대부분의 행이 prototype으로 표현되게 되어, row를 재구성하는데 많은 level의 indirection을 거치게 되어, 쿼리 시간이 길어진다.