在研究基於主題的Web資訊採集之前，讓我們先來看看Web資訊採集的基本情況，這包括Web資訊採集的基本原理、基本結構和主要難題。它們是從各類Web資訊採集系統中抽象出來的，因此代表了比較本質和共性的特徵，而對於每個實際的採集系統來說，又與它們有所差別。為了更好的瞭解采採集系統，我們在本章的最後列舉了兩個執行個體。
2.1 Web資訊採集系統的基本原理Web資訊採集（Web Crawling），主要是指通過Web頁面之間的連結關係，從Web上自動的擷取頁面資訊,並且隨著連結不斷向所需要的Web頁面擴充的過程。實現這一過程主要是由Web資訊採集器（Web Crawler）來完成的。根據應用習慣的不同，Web資訊採集器也常稱作Web Spider、Web Robot和Web Worm。粗略的說，它主要是指這樣一個程式，從一個初始的URL集出發，將這些URL全部放入到一個有序的待採集隊列裡。而採集器從這個隊列裡按順序取出URL,通過Web上的協議，擷取URL所指向的頁面，然後從這些已擷取的頁面中提取出新的URL,並將他們繼續放入到待採集隊列裡，然後重複上面的過程，直到採集器根據自己的策略停止採集。對於大多數採集器來說，到此就算完結，而對於有些採集器而言，它還要將採集到的頁面資料和相關處裡結果儲存、索引並在此基礎上對內容進行語義分析。
2.2 Web資訊採集系統的基本結構2.1所示，Web資訊採集系統基本上可以劃分為七個部分:URL處理器、協議處理器、重複內容檢測器、URL提取器、Meta資訊擷取器、語義資訊解析器和資料庫，它們協調起來從Web上擷取資訊。圖中的箭頭表示資料走向。
2.2.1 URL處理器這個組件主要給待採集的URL排序，並根據一定的策略向協議處理器分配URL。按照採集系統規模的不同，URL可以是多個採集隊列，也可以是一個URL Server。比如，天羅Web採集系統採用了多個採集隊列，而Google採集系統則使用了URL Server，以達到更快的處理速度。URL處理器主要有三個資料來源：1)初始的種子URL集，中的粗箭頭所示；2)從URL提取器傳輸過來的URL集,它們是從已經採集到的頁面中提取出來的；3)頁面的Meta、主題以及摘要等資訊，來自Meta資訊擷取器，它們主要用來顯示從URL提取器中傳輸過來的URL的重要性，為在這裡排序提供依據。另外，URL處理器還有一個任務就是DNS解析。
圖2.1 Web資訊採集系統基本結構
2.2.2 協議處理器
這個組件處於系統的底層，主要通過各種Web協議來完成資料的採集。一般來說協議包括HTTP、FTP、Gopher以及BBS,也有些採集系統根據應用的需要採集Web Chat、ICQ等特殊資訊。但從主流上看，仍以HTTP為主。
2.2.3 重複內容檢測器Web上存在著大量的鏡像頁面和內容，最近的研究表明，將近30%的頁面是重複的。這極大的浪費了網路的頻寬和影響了系統的效率。所以，重複內容檢測變成了採集系統，特別是大型採集系統的重要組成部分。要採用的檢測方法，根據系統的需要，從簡單的段落匹配到複雜的相似性比較中選擇。
2.2.4 URL提取器對於採集到的頁面，經過重複內容檢測後，需要分析其中的連結，並對連結進行必要的轉換，這些任務由URL提取器來完成。首先判別頁面類型，對類型為“text、html、shtml和htm”等的頁面進行分析連結。頁面的類型可由應答頭分析得出，有些WWW網站返回的應答資訊格式不完整，此時須通過分析頁面URL中的副檔名來判別頁面類型。需要分析的標記包括<a href=……>、<area href=……>、<base href=……>、<frame src=……>、<img src=……>、<body background=……>和<applet code=……>等。頁面連結中給出的URL可以是多種格式的，可能是完整的包括協議、網站和路徑的，也可能是省略了部分內容的，或者是一個相對路徑。為處理方便，一般先將其規格化成統一的格式。
2.2.5 Meta資訊擷取器這裡所要擷取的內容包括已採集頁面的Meta資訊、Anchor資訊、頁面的標題、頁面的摘要等。擷取它們的主要目的是力圖在沒有對頁面內容語義資訊進行理解的前提下，儘可能多的挖掘meta、結構等的語義資訊，來為從這些頁面中提取出來的URL的好壞，給出一個度量。度量的結果傳輸到URL處理器，用於排序。
2.2.6 語義資訊解析器根據採集策略的不同,有些採集器還有語義資訊解析器。這裡所說的語義資訊解析就是指對常值內容建立簡單的索引。因為它在一定程度上挖掘了頁面內容的語義，所以叫做語義資訊解析器。對於一些大型的資訊採集器，比如Alta Vista，由於採集的資訊量很大，對語義挖掘的深度要求較高，所以一般將頁面語義挖掘與資訊採集獨立開來，而用專門的Indexer等組件進行處理。對於一些輕量級的採集系統，比如基於使用者個人化的採集，因為採集的資訊量不大（這樣語義資訊解析就不太影響採集效率）和採集過程中更需要語義資訊制導，所以它們也常用到語義資訊解析器。
2.2.7 資料庫經過重複內容檢測後的頁面資料、提取出來的Meta資訊、主題和摘要等都要存入資料庫，以備其他應用使用。比如，對於Google這樣的搜尋引擎，這個資料庫中的內容將用於建立索引。如果系統有語義資訊解析器，則解析出來的內容也存入資料庫。由於資料較多，所以在存入資料庫之前，資料一般要進行壓縮。
2.3 Web資訊採集面臨的主要困難和相應的技術手段:粗看起來，採集的過程似乎比較簡單，但實際上，它卻存在著許多技術上和工程上的挑戰。在分析這些挑戰之前，先看一下Web的特點。
2.3.1 Web的特點Web與傳統的資訊媒介相比，主要存在以下幾個特點：1)資訊容量的巨大性，在1998年7月，Web上的靜態文本大約有3億5千萬個，並且以每月600GB的速度增長[Kahle 1997]；2)Web的動態性，每天Web中的內容和Web的結構都在變化著；3)Web的異構性，Web中包含的檔案類型各式各樣，包括映像、圖片、聲音、文本以及Script等；4)Web頁面的重複性，最近的研究表明，將近30%的頁面是重複的；5)高連結性，平均每個頁面有超過8個連結指向別的頁面；6)多語種性，現在Web上的頁面語種超過了100個。這為Web的有效採集，特別是為搜尋引擎的採集提出了巨大的難題。
2.3.2 Web採集面臨的技術困難和相應手段從技術角度看，挑戰主要有以下幾點：第一，Web資訊容量的巨大性使得採集器不可能採集到所有的Web頁面，而且很多採集系統也沒有足夠大的空間來存放採集到的所有頁面。如何提高採集的效率，即在單位時間內採集到儘可能多的高品質頁面，是採集系統面臨的一個難題。目前，有五種頁面品質高低的計算方法：1).Similarity(根據頁面和指導採集的問題之間的相似性)；2).Backlink(根據這個頁面在Web圖中的入度大小)；3).PageRank(根據指向它的所有頁的平均權值之和,一頁的平均權值定義為這頁的權值除以這頁的出度)；4).Forwardlink(根據這個頁面在Web這個圖中的出度的大小)，5).Location(根據這個頁面的位置資訊)。Cho中對比了寬度優先方法、Backlink方法和Pagerank方法[Cho, Molina & Page 1999]，並根據實驗比較得出PageRank方法最好。這是因為Pagerank方法反映的是一種全域的頁面品質分布，它能夠較快的發現全域的高品質頁面。
第二，並行性問題。頁面的採集速度一直是影響採集器效能的重要原因。一方面，Web中的頁面數量非常龐大，另一方面，網路中的連線速度又非常緩慢，這客觀上要求系統需要並行。然而，要並行又引入新的問題：1).重複性(Overlap)，多個不同的採集器或採集線程在同時採集的時候增加了重複頁面；2).品質問題(Quality)，單個系統能夠根據演算法採集到全域最優的頁面。而如果並行，每個採集線程只能看到局部頁面，它能夠採集到的頁面品質有所下降；3).通訊頻寬代價（Communication bandwidth），為了並行，各個採集線程之間不可避免的要有一些通訊。一般來說，採集系統採用兩種模式來並行：區域網路並行模式(所有的採集線程都運行在同一個區域網路內，它們之間通過高速的內串連進行通訊)和分布式並行模式(採集系統被分布在地區上較遠的Internet上，通過網路進行遠程通訊)。在並行時，採集系統也可選用以下三種方式合作：1).獨立方式，各個採集器之間獨立的採集各自的頁面，互不通訊；2).動態分配方式，有一個中央協調器，動態協調分配URL給各個採集器；3).靜態分配方式，將URL按事先劃分分配給各個採集器。對於靜態分配方式，存在一種跨區連結(Inter-link，指一個採集器在提取連結時遇到的不屬於自己採集範圍的連結)。難題在於跨區連結並不一定能被它所屬於的採集器發現，如果本採集器採集了則可能重複採集，如果不採集則可能漏采。近期的研究工作針對這種情況比較了三種模式: 1).防火牆模式,完全不採集inter-link頁面；2).交叉模式，採集遇到的inter-link頁面；3).交換模式(Exchange mode)當採集到inter-link，就將這些連結儲存起來，積累到一定數量後傳輸給相應的採集器進行採集。實驗結果和我們的直覺一樣:交換模式最好：交換模式最好[Cho 2001]。
第三,重新整理問題。為了保持採集到的頁面是最新的，採集系統不得不對已經採集過的頁面進行周期性的更新。而隨著Web的爆炸性膨脹，這個問題幾乎變成了不可逾越的鴻溝。最近的一項報告顯示，甚至流行的Web搜尋引擎，頁面重新整理一次甚至持續數月[Lawrence&Giles 1999]。同時，這份報告也顯示，14%的搜尋引擎提供頁面是無效的。Cho試圖用泊松過程(Poisson Process)來描述頁面變動率，並研究和對比了三種頁面重新整理策略：固定順序的重新整理，隨機重新整理和純隨機重新整理策略。直覺上，更多的重新整理應該分配給更那些更新快的頁面。但研究表明，用較高的頻率重新整理更新快的頁面並不一定是明智之舉，對各種頁面採用相同的重新整理周期效果更好，而效率最佳的點在這兩種重新整理策略中間。這是因為，過高頻率的重新整理更新快的頁面，使得其它頁面有較少的重新整理機會，反而造成總體重新整理品質下降[Cho 2001]。
2.3.3 Web採集面臨的工程困難和相應手段從工程角度看：第一，正如前面分析的，Web中的資訊是完全異構、混亂和無序的，檔案格式各式各樣，網路狀況也隨時間變化莫測。所有的這些不確定性因素，為系統實現帶來了極大的困難。這就要求採集系統有完善的異常處理和故障恢複機制，充分考慮到實際網路環境中可能出現的各種情況。
第二，多線程與並行機制使系統變得非常複雜。在這種複雜的環境下，系統的許多瓶頸變得異常突出，並需要採用多種設計技巧來解決。比如說，對一個網站的採集不能過分集中，以防止造成網站負擔過重，Google中的頁面採集就是同時採集多個網站。在Google中，系統為每一個採集器都配了一個DNS快取服務器，以加快DNS解析的速度。
2.4 採集系統執行個體下面就以兩個實際的採集系統為例來具體說明，它們即有一般採集器的共同特點，也有自己的特色。
2.4.1 Mercator資訊採集器的基本結構和工作過程Mercator資訊採集器是一個由康柏研究中心研製的面向整個Web的分布式多線程資訊採集系統[Heydon&Najork 1999]。它的基本結構如2.2所示，採集步驟是從1)到8)不斷迴圈。步驟1)就是從多個線程共用的URL Frontier中移出絕對路徑的URL來。絕對路徑的URL中指明了這個URL採用什麼方式下載。具體和協議相關介面的實現在Protocol Modules中。並且，使用者可以通過設定檔案來告訴系統裝載哪些協議介面。
在步驟2)中,系統選擇了相應的協議,通過了DNS解析並從Web上下載了頁面，然後將頁面放入3)RewindInputStream（RIS）中，RIS相當於一個緩衝，能夠多次快速的讀內容。一旦檔案被放進RIS,這個背景工作執行緒就啟動內容檢測模組看是否此頁面已經被採集過，這就是步驟4)。如果採集過，系統就拋棄此頁並跳至步驟1)。
如果此頁沒有採集過，就進入步驟5)Processing Modules,在這裡對頁面進行初步的分析，比如提取標題、摘要和連結。預設狀況下，頁面中的所有連結都被提取出來，並轉換成絕對URL。然後進行步驟6),也就是根據使用者要求對URL進行過濾(Filtering)。如果URL通過了過濾器，則檢查此URL是否已經在URL待採集庫中(步驟7)。如果此URL沒有，則將它加入到URL Frontier中,等著被選中進入下一輪迴圈(步驟8)。
圖2.2 Mercator資訊採集器結構 |
2.4.2 天羅資訊採集系統的基本結構和工作過程
天羅資訊採集系統是在國家“863”計划下由曙光公司開發的智能導航系統的子系統。本採集系統最初的目標是面向整個Web的資訊採集，隨著Web服務向個人化主動服務等領域的拓展，本採集系統的後續版本在中科院計算所領域前沿青年基金資助下正在向基於主題的採集方向發展。
2.3所示，天羅Web資訊採集系統從功能上看可分為兩個部分：採集器部分和控制部分，中間的豎立虛線將他們分開。採集器部分主要負責實際採集，它分為三個部分。1).網站採集。把整個Web以網站為單位劃分成若干個連通子圖是合乎人們的瀏覽習慣的，並且也是利於儲存的。天羅Web資訊採集系統的設計就是根據這一點，對Web上的頁面以網站為單位進行採集。2).頁面採集。儘管系統從粗粒度上看，採集是以網站為單位的，但是從細粒度上講，每次只採集一頁。這個部分考慮的重點就是對採集每頁相關的協議的處理和即時網上異常的處理。3).存放庫，主要儲存採集到的資料、網站結構資訊以及相關的有用資訊。
圖2.3天羅資訊採集系統結構
控制部分主要負責採集以外的協調、策略以及與應用的介面，它分為五個部分。1).採集系統設定，主要用於系統管理員對採集系統的控制，包括設定採集起點和採集策略。2).採集系統控制，這是採集系統最具有全域觀念的一個子系統，它主要負責總體控制和其他各子系統之間的協調和串連,另外它還集中式的控制多個採集器並行。3).存放庫，主要負責儲存一致化處理後的各項資料以及在此基礎上進行索引等處理的資料。4).採集策略處理，負責處理採集系統在理論上最難的一個部分——如何有效採集和動態重新整理。5).安全開關，在實際應用系統中，採集器往往直接和Web相連，而同時又與內部的應用伺服器相連，如果不加安全處理，Web對於應用伺服器是非常危險的。為此，本採集系統設計了低成本高效率的安全開關。當與應用系統交換資料時，採集系統與Web斷開；當在Web上採集資料時，採集系統與應用系統斷開。這也是本採集系統的特色之一。圖中的箭頭描述了資料流向。
為了提高採集的效率，天羅Web採集系統採用伺服器(採集系統控制)/採集器的結構使採集系統具有很好的可擴充性。管理員可根據系統採集規模的變化動態地調整採集器的數量，在保證系統效能的前提下盡量減少系統開銷，達到最佳的效能/價格比。而且在規模動態變化的過程中，系統能維持一致的管理和資料輸出介面。
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
