Google搜尋引擎技術實現探究
化柏林
(中國科學技術資訊研究所 北京 100038)
【摘要】 本文從技術的角度剖析了Google搜尋引擎的體繫結構與工作過程，詳細介紹了基於Robot的網頁搜尋、標引入庫和檢索引擎三大模組，統計了Google的技術資料，並分析了Google的技術實現特點，解釋了Google檢索的種種現象。
【關鍵詞】 Google 搜尋引擎 技術實現 【分類號】 G354Anatomy of Google Search Engine Viewed on Technical Implementation
Hua Bolin
(Institute of Scientific and Technical Information of China, Beijing 100038)
【Abstract】 This paper anatomized architecture and procedure of Google viewed on Technical Implementation. It introduced three functional modules, which is Web crawler, index and create database, search engine. Then do a statistic of technical data about Google, and analyzed technical feature, explained a variety of phenomena when using Google to retrieval.
【Keywords】 Google, Search Engines, Technical Implementation
1 Google技術總況與體繫結構
Google擁有10億個網址，30億個網頁，3.9 億張映像，Google 支援66種語言介面，16種檔案格式，面對如此海量的資料和如此異構的資訊，google是如何?半秒內搜尋的呢？ Google擁有1600台伺服器，大部分代碼用C或C++實現，有很好的執行效率，運行在Solaris 或Linux 上。Google用了64個桶(barrels)，有293M詞典（lexicon）、43G的順排檔檔案、41G的倒排檔檔案,構造了一個5.18億個超連結的網路關聯圖。
Google搜尋引擎有兩個特徵來提高查准率：利用網頁間的連結關係來計算每一個網頁的等級；利用連結關係來改善檢索結果。除此之外，Google還對所有的點擊都有定位資訊，廣泛利用搜尋的親近度。第二，Google 記錄詳細的可視化表達諸如詞的字型大小，大或粗體的詞的權重就高。第三，整個頁面的HTML源檔案在知識庫中是可用的。
Google搜尋引擎從功能上同樣分為三大部分：網頁爬行、標引入庫和使用者查詢。網頁爬行主要負責網頁的抓取，由URL伺服器、爬行器、儲存空間、分析器和URL解析器組成, 爬行器是該部分的核心；標引入庫主要負責對網頁內容進行分析，對文檔進行標引並儲存到資料庫裡，由標引器和分類器組成，該模組涉及許多檔案和資料，有關於桶的操作是該部分的核心；使用者查詢主要負責分析使用者輸入的檢索運算式，匹配相關文檔，把檢索結果返回給使用者，由查詢器和網頁層級評定器組成，其中網頁等級的計算是該部分的核心。其總體系統結構1所示。
2 基於Robot的搜尋過程
Robot使用多線程並發搜尋技術，主要完成文檔訪問代理、直接選取引擎和存取控制引擎。基於Robot的Web頁搜尋模組主要由URL伺服器、爬行器、儲存空間、URL解析器四大功能組件和資產庫、錨庫、連結庫三大資料資源構成，另外還要藉助標引器的一個協助工具功能。具體過程是,有個URL伺服器發送要去抓取的URL，爬行器根據URL抓取WEB頁並送給儲存空間，儲存空間壓縮Web頁並存入資料資產庫，然後由標引器分析每個WEB頁的所有連結並把相關的重要訊息儲存在anchors 檔案中。URL解析器讀anchors檔案並解析URL，然後依次轉成docID。再把anchor文本變成順排索引，送入索引庫。具體過程2所示。
2．1 URL伺服器(URL Server)
URL伺服器是整個Web頁搜尋模組的開始，主要用來管理和維護URL列表。首先由它發送一個新的URL給爬行器，讓爬行器去搜尋。如果爬行器遇到了不可下載的網頁，就會給URL一個返回資訊，然後取下一個URL。URL伺服器會從文檔索引庫裡不斷地取新的URL以供爬行器使用。
2．2 爬行器(crawler)
爬行器是整個搜尋模組中最關鍵的一部分，它由好幾個分布的爬行器組成，並協同工作。爬行器遇到HTML頁的頭有如下標記就不再抓取此頁，<head><meta name="robots" content="noindex, nofollow"></head>，返回一個空值，繼續向其他方向爬行，這就有效防止爬行器標引此頁及本頁的相關連結頁。如果網頁已經標引過，就從將要爬行的網頁隊列中移除。Web頁文本的繁殖思想是由3W蠕蟲來實現的，當它搜尋非文本資訊時，儘可能少的下載文檔，以擴充搜尋度，因為非文本資訊片等沒有連結會造成爬行的中斷。這樣，Google就可以通過各種策略來解決排序沉沒（rank sink）和排序漏出(rank loak)等問題。
2．3 儲存空間(store server)
儲存空間把爬行器抓來的Web頁進行壓縮並儲存到資料資產庫中。資料資產庫包含每一個Web頁的全部HTML，所有的網頁用zlib進行壓縮，Google更注重zlib的壓縮速度而不是壓縮率。bzip對資料庫的壓縮率接近4:1，而zlib為3:1。這樣，Google就能把147.8G的HTML文檔壓縮成53.5G的資料存放區在庫中。在資料資產庫中，對文檔進行歸類，加上docID首碼、文檔的長度和URL。文檔索引記錄著每一個文檔的資訊，它是一個有固定長度，經docID排序的ISAM索引（Index sequential access mode）。存在每個條目中的資訊包括當前文檔狀態，資料庫中的指標，文檔校正和以及其它統計資訊。如果文檔被爬行過，它也包含到可變長檔案的指標，這個稱為docinfo的檔案包含文檔的URL和標題。否則，指標指向僅包含URL的URL列表。
2．4 分析器(parser)
分析器可以看成是標引器的一部分，也可以說是標引器的一個協助工具功能部分。它分析每個WEB頁的所有連結並把相關的重要訊息儲存在anchors 檔案中，構成一個錨庫。每當從WEB頁分析出一個新的URL時，為每個WEB頁分配一個稱為docID的關聯ID。這個檔案包含足夠的資訊來決定每個連結的何去何從。錨經常提供比web頁本身更精確的頁描述。錨可以存在文檔，這些文檔不能被基於文本的搜尋引擎所標引，片、程式、資料庫。這就為返回那些不能精確爬行的Web頁提供了可能。
2．5 URL解析器(URL Resolver)
URL解析器讀anchors檔案並把相對URL轉成絕對URL，然後依次轉成docID。把anchor文本變成順排索引，存到文檔索引庫裡，並用anchor所指向的docID進行關聯。把URL轉換成docID的檔案,是由URL校正和及相應的docID兩列組成的一個列表，並以校正和排序。為了找到一個特定URL的docID，首先計算URL的校正和，在校正和檔案中進行二元尋找,以找到相應的docID。執行一次批處理，通過合并檔案把URL 轉成docID。使用這種批處理模式很關鍵，要不然就得為每一個連結都作一次尋找，假設一個磁碟上有322,000,000個連結記錄，那麼這樣一個過程需要2個多月的時間。它還產產生對docID的連結資料庫，以用於計算所有文檔的PageRanks。
3 標引入庫
標引入庫模組由分類器和標引器組成。標引入庫模組處理大量的檔案和資料，用來構建龐大的資料庫，主要涉及資料資產庫、詞典庫、連結庫、桶等。桶的結構與內容非常複雜，有關桶的操作是本模組的核心，
3.1 分類器(sorter)
分類器從桶中取出資料，按docID進行一級分類，然後按照wordID進行二級分類併產生倒排檔索引。分類器產生wordID的列表並把其位移量寫到倒排檔索引中。一個稱為DumpLexicon的程式把這個列表和由標引器產生的詞典揉和在一起並為檢索器產生一個新的詞典。
3．2 標引器(indexer)
標引器有許多函數，它讀資料庫，解壓縮文檔然後進行分析。每個文檔都被轉成一套單詞出現頻率，稱之為採樣數。採樣數記錄單詞及在文檔中出現的位置，字型的大小以及大寫資訊。標引器把這些採樣數分配到一套“桶”中，建立一個部分分類的順排索引。對於中文，Google主要採用了二元切分法，也就是為什麼我們輸入長於兩個漢字的中文，如果不加雙引號，Google會自動給以切分的原因。
3．3 桶(barrels)
Google共有64個桶（barrels），每個桶都存著wordID的歸類，包括順排檔與倒排檔。如果一個文檔包含落在某個桶裡的詞，docID和wordID的列表以及相應的命中列表就被記錄到桶裡。Google儲存每一個wordID時，儲存的是與所在桶的最小wordID的相對差異，而不是儲存實際的wordID。這樣，在未排序的桶中用24位儲存wordID，留下8位用來儲存命中列表的長度。
倒排檔索引就象順排檔一樣由系列的桶組成，唯一的不同是被分類器處理過。有個重要的問題是docID應當在doclist中如何排序。一個簡單的解決辦法是用docID進行分類，這允許多詞查詢而帶來的不同doclist的合并。另外一個辦法是按詞在每個文檔中出現的頻率等級進行分類儲存，儘管這使得處理單個詞的查詢變得繁瑣，但為多詞查詢提供了可能。Google在這兩個方案中選擇了折衷，使用兩套倒排的桶，一套為包括標題和anchor hits的命中列表，我們稱之為短桶，另一套為所有的命中列表，我們稱之為長桶。
在順排檔索引和倒排檔索引中，命中列表佔據了大量的空間。命中列表是指詞在一篇文檔中的出現頻率，包括位置、字型和大寫資訊。Google為編碼位置、字型和大寫考慮了多種編碼方案——簡單編碼、最佳化壓縮編碼和哈夫曼編碼。由於最佳化壓縮編碼對空間的要求比簡單編碼低，操作過程比哈夫曼編碼簡單，因此，Google最終選擇了最佳化壓縮編碼。
Google用兩個位元組的壓縮編碼來記錄每次命中，命中類型有兩種：特殊命中與普通命中。特殊命中包括URL的命中率、標題、連結文本和關鍵標記。普通命中含有所有的資訊，包括大寫位、字型大小和12位標記詞在文檔中出現的位置資訊等。字型大小用3位來表達文檔的其它內容的相對值（僅有7個值可用，因為111是特殊命中的標記）。特殊標記由大寫位，字型設成7來表明是一個特殊命中，有4位表示類型，用8位標記位置。為了節省空間的，命中列表的長度由順排檔中的wordID和倒排檔中的docID決定。分別需要8位與5位。如果長度更長的話，在相應的位裡就存著一個溢出編碼，接下來的兩個位元組儲存命中列表的實際長度。
3．4 詞典(lexicon)
詞典有幾種不同的形式。對早期系統的一個重要改變是根據合理的代價分配記憶體。該詞典包含1400萬個詞條（有些生僻詞沒加），由兩部分實現，詞表和指標的雜湊表。詞表還有一些輔助資訊用以實現其它功能。對於每個有效wordID，詞典包含指向wordID所在桶的指標。它指向docID和相應的命中列表的doclist。Doclist表明該詞在所有文檔中出現的所有情況。
4 檢索過程與網頁層級
Google使用者查詢模組主要由網頁層級評定器和查詢器組成。
4．1 查詢器(searcher)
查詢器運行在Web伺服器上，並用DumpLexicon產生的詞典、倒排檔索引和PageRanks一起來響應查詢。首先接受使用者輸入的檢索運算式，進行分析得出各項檢索要求，提取檢索詞並轉成wordID,接著到短桶文檔列表裡進行查詞，遍曆文檔列表直到匹配所有的詞條，找到一篇就計算網頁等級，短桶查完了，如果沒有足夠的匹配記錄，就去查長桶。查完了所有的文檔列表，就對檢索結果進行排序並返回前K項。
4.2 網頁層級評定器(PageRanker)
網頁層級評定器借用了圖書文獻裡的參考文獻與引用文獻的評價思想，利用連結網頁的數量及重要性進行等級評定，而連結網頁的重要性由它的連結網頁的數量及重要性決定，因此是一種迭代計算。評級函數有許多參數，如類型權重和相互關聯類型權重等。
如果有許多網頁指向網頁P，那麼P就是一個好的網頁。IR'(P)，從不同域的連結要比同一個域內的連結重要。自然連結可以表明相關重要性。當從網頁 A 連結到網頁 B 時，Google 就認為“網頁 A 投了網頁 B 一票”。Google 根據網頁的得票數評定其重要性。除了考慮網頁得票數（即連結）的純數量之外，Google 還要分析投票的網頁。“重要”的網頁所投出的票就會有更高的權重，也有助於提高其它網頁的“重要性”。 被引率高就說明該頁值得看，PageRank通過web連結架構來處理靠遞迴繁殖提高權重的情況。
假定網頁A有指向A的網頁T1...Tn（也叫引用網頁）。參數d是一個設定於0、1之間的遞減因子，通常定為0.85。C(A)為從網頁A鏈出去的連結數，因此，網頁A的PageRank就可以求出：
PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))
PageRank 或者PR(A)用迭代演算法來計算，相當於一個正常化的Web連結矩陣的特徵向量。有26,000,000個網頁在一台中型工作站上用幾個小時就能算完。PageRanks形成了web頁的機率分布，所有web頁的PageRanks和為1。
重要的、高品質的網頁會獲得較高的網頁層級。Google 在排列其搜尋結果時，總會考慮每個網頁的層級。當然，如果不能滿足使用者的查詢要求，網頁層級再高對使用者來說也毫無意義。因此，Google 將網頁層級與完善的文本匹配技術結合在一起，為使用者找到最重要、最有用的網頁。Google 所關注的遠不只是關鍵詞在網頁上出現的次數，它還對該網頁的內容以及該網頁所連結的內容進行全面檢查，從而確定該網頁是否滿足使用者的查詢要求。Google在檢索引擎裡用一個使用者反饋機，對信任使用者可有選擇地評估所有的返回結果，這種反饋被存到資料庫裡，當修改評級函數時，就能發現對以前評過級的檢索所產生的影響。
5 功能檢索的實現
對於Google的檢索實現，筆者對檢索做了大量的測試，而對技術僅作了有限的部分測試，其理解如下：
5.1 邏輯運算式
Google支援的邏輯運算有與、或、非，其形式分別為“ ”、“or”、“-”，對應Google進階檢索裡的“包含全部字詞”、“包含任何一個字詞” 、“不包含以下字詞”。Google不支援截詞檢索，因為截詞檢索會極大地降低電腦的檢索速度。當然Google對詞的切分技術也並不理想，對西文比較有效，對亞洲語言作得不好。
5．2 指定檔案類型
Google可以指定尋找的檔案格式，如pdf、doc、ppt等格式檔案。如果某個搜尋結果是 PDF 檔案而不是網頁，它的標題前面會出現以藍色字型標明的 [PDF]。使用者只想查一般網頁，而不要 PDF 檔案，只需在搜尋關鍵詞後加上 -filetype:pdf 就可以了，而如果只想查pdf檔案，則用filetype:pdf就可以指定pdf檔案了。每一個文檔在資料庫裡都有其檔案類型，因此，實現它並不困難。
5．3 指定範圍
Google可以指定網頁的範圍，如(all)intitle,(all)intext ，(all)inurl，(all)inanchor等。網頁標題只是對HTML的<title></title>裡的內容進行檢索，如果title的內容與文章真正的標題不一致，則Google沒有能力檢索出來。在http://www7.scu.edu.au/programme/fullpapers/1921/com1921.htm裡的文章真正的標題是The Anatomy of a Large-Scale Hypertextual Web Search Engine，而相關HTML檔案裡<title></title>的內容卻是The Anatomy of a Search Engine，因此在Google的輸入框裡鍵入allintitle:“The Anatomy of a Large-Scale Hypertextual Web Search Engine”，是查不到該文章的。而對文章內容的檢索識別是HTML檔案裡的<body></body>中的內容。當然還可以限定時間、指定網站等。通過site:www.xxx.xxx.xxx指定網站實現站內搜尋是很有用的。
5．4 語言問題
Google支援66種語言介面，35種語言指定檢索，Google對語種的判別不是通過URL資訊（網域名稱中的國別），主要通過HTML中的charset，和對網頁內容部分識別的統計資訊來聯合判斷。其實,好多人還把Google當詞典來用，我們輸入“"層次分析法" analysis”指定中文網頁就可以檢索出層次分析法的英文翻譯。
5．5 同義字檢索
選擇“搜尋所有網站或搜尋所有中文網頁”，輸入“電腦”，則會把含有“電腦”的網頁（不論有沒有“電腦”）搜尋出來，而在簡體中文網頁裡就不會實現這樣的功能，因為Google採用Basis Technology的中文簡繁體轉換技術。
5．6網頁目錄
Google按內容把網頁資訊分為15個大類，主要是通過詞頻分布與統計技術，對內容進行識別並用分類器（sorter）進行歸類。
5．7 Image Search
Google搜集了3.9 億張映像，對映像的描述資訊建了一個很大的資料庫。映像檢索使用的主要是檔案名稱、圖片附近的文本、圖片的標題以及從圖片中提取的部分內容。
5．8 相似結果
google 會省略相似的結果，尤其是來自不同網站頁內容相同的文章，有時我們在Google顯示的結果中不能下載相應的文章時，而省略的結果中可能允許下載，這時google的省略功能就帶來了不便。判斷內容相似主要可能是根據文章題目、文章大小和部分詞語統計資訊等。當然還有許多特點與提示,那不是本文討論的重點。
當我們瞭解了Google的技術實現，就可以理解檢索過程中出現的種種現象。針對這些特點再去調整檢索策略，這樣它返回的結果就不再成千上萬了。正常情況下，把檢索結果控制在百條左右，是一個專業檢索水平的標誌，這樣的結果對我們也才真正的有意義。
參考文獻
[1] http://www.google.com/intl/zh-CN/features.html
[2] http://www.google.com/intl/zh-CN/why_use.html
[3] Junghoo Cho, Hector Garcia-Molina and Lawrence Page. Efficient crawling through URL ordering http://www7.scu.edu.au/programme/fullpapers/1919/com1919.htm
[4] Sergey Brin and Lawrence Page. The Anatomy of a Large-Scale Hypertextual Web Search Engine. http://www-db.stanford.edu/~backrub/google.html
[5] The Google Pagerank Algorithm and How It works. http://www.iprcom.com/papers/
pagerank/
|
