深刻淺出搜索架構引擎、方案與細節（上）

深刻淺出搜索架構引擎、方案與細節（上）

原創： 58沈劍 架構師之路 2017-02-14

1、緣起

《100億數據1萬屬性數據架構設計》文章發佈後，很多朋友對58同城自研搜索引擎E-search比較感興趣，故專門撰文體系化的聊聊搜索引擎，從宏觀到細節，但願把邏輯關係講清楚，內容比較多，分上下兩期。

 

主要內容以下，本篇（上）會重點介紹前三章：

（1）全網搜索引擎架構與流程

（2）站內搜索引擎架構與流程

（3）搜索原理、流程與核心數據結構

（4）流量數據量由小到大，搜索方案與架構變遷

（5）數據量、併發量、策略擴展性及架構方案

（6）實時搜索引擎核心技術

 

可能99%的同窗不實施搜索引擎，但本文必定對你有幫助。

 

2、全網搜索引擎架構與流程

全網搜索的宏觀架構長啥樣？

全網搜索的宏觀流程是怎麼樣的？

全網搜索引擎的宏觀架構如上圖，核心子系統主要分爲三部分（粉色部分）：

（1）spider爬蟲系統

（2）search&index創建索引與查詢索引系統，這個系統又主要分爲兩部分：

一部分用於生成索引數據build_index

一部分用於查詢索引數據search_index

（3）rank打分排序系統

 

核心數據主要分爲兩部分（紫色部分）：

（1）web網頁庫

（2）index索引數據

 

全網搜索引擎的業務特色決定了，這是一個「寫入」和「檢索」徹底分離的系統：

【寫入】

系統組成：由spider與search&index兩個系統完成

輸入：站長們生成的互聯網網頁

輸出：正排倒排索引數據

流程：如架構圖中的1，2，3，4

（1）spider把互聯網網頁抓過來

（2）spider把互聯網網頁存儲到網頁庫中（這個對存儲的要求很高，要存儲幾乎整個「萬維網」的鏡像）

（3）build_index從網頁庫中讀取數據，完成分詞

（4）build_index生成倒排索引

 

【檢索】

系統組成：由search&index與rank兩個系統完成

輸入：用戶的搜索詞

輸出：排好序的第一頁檢索結果

流程：如架構圖中的a，b，c，d

（a）search_index得到用戶的搜索詞，完成分詞

（b）search_index查詢倒排索引，得到「字符匹配」網頁，這是初篩的結果

（c）rank對初篩的結果進行打分排序

（d）rank對排序後的第一頁結果返回

 

3、站內搜索引擎架構與流程

作全網搜索的公司畢竟是少數，絕大部分公司要實現的其實只是一個站內搜索，站內搜索引擎的宏觀架構和全網搜索引擎的宏觀架構有什麼異同？

以58同城100億帖子的搜索爲例，站內搜索系統架構長啥樣？站內搜索流程是怎麼樣的？

站內搜索引擎的宏觀架構如上圖，與全網搜索引擎的宏觀架構相比，差別只有寫入的地方：

（1）全網搜索須要spider要被動去抓取數據

（2）站內搜索是內部系統生成的數據，例如「發佈系統」會將生成的帖子主動推給build_data系統

 

看似「很小」的差別，架構實現上難度卻差不少：全網搜索如何「實時」發現「全量」的網頁是很是困難的，而站內搜索容易實時獲得所有數據。

 

對於spider、search&index、rank三個系統：

（1）spider和search&index是相對工程的系統

（2）rank是和業務、策略緊密、算法相關的系統，搜索體驗的差別主要在此，而業務、策略的優化是須要時間積累的，這裏的啓示是：

a）Google的體驗比Baidu好，根本在於前者rank牛逼

b）國內互聯網公司（例如360）短期要搞一個體驗超越Baidu的搜索引擎，是很難的，真心須要時間的積累

 

4、搜索原理與核心數據結構

什麼是正排索引？

什麼是倒排索引？

搜索的過程是什麼樣的？

會用到哪些算法與數據結構？

 

前面的內容太宏觀，爲了照顧大部分沒有作過搜索引擎的同窗，數據結構與算法部分從正排索引、倒排索引一點點開始。

 

提問：什麼是正排索引（forward index）？

回答：由key查詢實體的過程，是正排索引。

用戶表：t_user(uid, name, passwd, age, sex)，由uid查詢整行的過程，就是正排索引查詢。

網頁庫：t_web_page(url, page_content)，由url查詢整個網頁的過程，也是正排索引查詢。

 

網頁內容分詞後，page_content會對應一個分詞後的集合list<item>。

簡易的，正排索引能夠理解爲Map<url, list<item>>，可以由網頁快速（時間複雜度O(1)）找到內容的一個數據結構。

 

提問：什麼是倒排索引（inverted index）？

回答：由item查詢key的過程，是倒排索引。

對於網頁搜索，倒排索引能夠理解爲Map<item, list<url>>，可以由查詢詞快速（時間複雜度O(1)）找到包含這個查詢詞的網頁的數據結構。

 

舉個例子，假設有3個網頁：

url1 -> 「我愛北京」

url2 -> 「我愛到家」

url3 -> 「到家美好」

這是一個正排索引Map<url, page_content>。

 

分詞以後：

url1 -> {我，愛，北京}

url2 -> {我，愛，到家}

url3 -> {到家，美好}

這是一個分詞後的正排索引Map<url, list<item>>。

 

分詞後倒排索引：

我 -> {url1, url2}

愛 -> {url1, url2}

北京 -> {url1}

到家 -> {url2, url3}

美好 -> {url3}

由檢索詞item快速找到包含這個查詢詞的網頁Map<item, list<url>>就是倒排索引。

 

正排索引和倒排索引是spider和build_index系統提早創建好的數據結構，爲何要使用這兩種數據結構，是由於它可以快速的實現「用戶網頁檢索」需求（業務需求決定架構實現）。

 

提問：搜索的過程是什麼樣的？

假設搜索詞是「我愛」，用戶會獲得什麼網頁呢？

（1）分詞，「我愛」會分詞爲{我，愛}，時間複雜度爲O(1)

（2）每一個分詞後的item，從倒排索引查詢包含這個item的網頁list<url>，時間複雜度也是O(1)：

我 -> {url1, url2}

愛 -> {url1, url2}

（3）求list<url>的交集，就是符合全部查詢詞的結果網頁，對於這個例子，{url1, url2}就是最終的查詢結果

 

看似到這裏就結束了，其實否則，分詞和倒排查詢時間複雜度都是O(1)，整個搜索的時間複雜度取決於「求list<url>的交集」，問題轉化爲了求兩個集合交集。

 

字符型的url不利於存儲與計算，通常來講每一個url會有一個數值型的url_id來標識，後文爲了方便描述，list<url>統一用list<url_id>替代。

 

list1和list2，求交集怎麼求？

方案一：for * for，土辦法，時間複雜度O(n*n)

每一個搜索詞命中的網頁是不少的，O(n*n)的複雜度是明顯不能接受的。倒排索引是在建立之初能夠進行排序預處理，問題轉化成兩個有序的list求交集，就方便多了。

 

方案二：有序list求交集，拉鍊法

有序集合1{1,3,5,7,8,9}

有序集合2{2,3,4,5,6,7}

兩個指針指向首元素，比較元素的大小：

（1）若是相同，放入結果集，隨意移動一個指針

（2）不然，移動值較小的一個指針，直到隊尾

 

這種方法的好處是：

（1）集合中的元素最多被比較一次，時間複雜度爲O(n)

（2）多個有序集合能夠同時進行，這適用於多個分詞的item求url_id交集

這個方法就像一條拉鍊的兩邊齒輪，一一比對就像拉鍊，故稱爲拉鍊法

 

方案三：分桶並行優化

數據量大時，url_id分桶水平切分+並行運算是一種常見的優化方法，若是能將list1<url_id>和list2<url_id>分紅若干個桶區間，每一個區間利用多線程並行求交集，各個線程結果集的並集，做爲最終的結果集，可以大大的減小執行時間。

 

舉例：

有序集合1{1,3,5,7,8,9, 10,30,50,70,80,90}

有序集合2{2,3,4,5,6,7, 20,30,40,50,60,70}

 

求交集，先進行分桶拆分：

桶1的範圍爲[1, 9]

桶2的範圍爲[10, 100]

桶3的範圍爲[101, max_int]

 

因而：

集合1就拆分紅

集合a{1,3,5,7,8,9}

集合b{10,30,50,70,80,90}

集合c{}

 

集合2就拆分紅

集合d{2,3,4,5,6,7}

集合e{20,30,40,50,60,70}

集合e{}

 

每一個桶內的數據量大大下降了，而且每一個桶內沒有重複元素，能夠利用多線程並行計算：

桶1內的集合a和集合d的交集是x{3,5,7}

桶2內的集合b和集合e的交集是y{30, 50, 70}

桶3內的集合c和集合d的交集是z{}

 

最終，集合1和集合2的交集，是x與y與z的並集，即集合{3,5,7,30,50,70}

 

方案四：bitmap再次優化

數據進行了水平分桶拆分以後，每一個桶內的數據必定處於一個範圍以內，若是集合符合這個特色，就可使用bitmap來表示集合：

如上圖，假設set1{1,3,5,7,8,9}和set2{2,3,4,5,6,7}的全部元素都在桶值[1, 16]的範圍以內，能夠用16個bit來描述這兩個集合，原集合中的元素x，在這個16bitmap中的第x個bit爲1，此時兩個bitmap求交集，只須要將兩個bitmap進行「與」操做，結果集bitmap的3，5，7位是1，代表原集合的交集爲{3,5,7}

 

水平分桶，bitmap優化以後，能極大提升求交集的效率，但時間複雜度仍舊是O(n)

bitmap須要大量連續空間，佔用內存較大

 

方案五：跳錶skiplist

有序鏈表集合求交集，跳錶是最經常使用的數據結構，它能夠將有序集合求交集的複雜度由O(n)降至O(log(n))

集合1{1,2,3,4,20,21,22,23,50,60,70}

集合2{50,70}

要求交集，若是用拉鍊法，會發現1,2,3,4,20,21,22,23都要被無效遍歷一次，每一個元素都要被比對，時間複雜度爲O(n)，能不能每次比對「跳過一些元素」呢？

 

跳錶就出現了：

集合1{1,2,3,4,20,21,22,23,50,60,70}創建跳錶時，一級只有{1,20,50}三個元素，二級與普通鏈表相同

集合2{50,70}因爲元素較少，只創建了一級普通鏈表

 

如此這般，在實施「拉鍊」求交集的過程當中，set1的指針可以由1跳到20再跳到50，中間可以跳過不少元素，無需進行一一比對，跳錶求交集的時間複雜度近似O(log(n))，這是搜索引擎中常見的算法。

 

5、總結

文字不少，有宏觀，有細節，對於大部分不是專門研究搜索引擎的同窗，記住如下幾點便可：

（1）全網搜索引擎系統由spider， search&index， rank三個子系統構成

（2）站內搜索引擎與全網搜索引擎的差別在於，少了一個spider子系統

（3）spider和search&index系統是兩個工程系統，rank系統的優化卻須要長時間的調優和積累

（4）正排索引（forward index）是由網頁url_id快速找到分詞後網頁內容list<item>的過程

（5）倒排索引（inverted index）是由分詞item快速尋找包含這個分詞的網頁list<url_id>的過程

（6）用戶檢索的過程，是先分詞，再找到每一個item對應的list<url_id>，最後進行集合求交集的過程

（7）有序集合求交集的方法有

         a）二重for循環法，時間複雜度O(n*n)

         b）拉鍊法，時間複雜度O(n)

         c）水平分桶，多線程並行

         d）bitmap，大大提升運算並行度，時間複雜度O(n)

         e）跳錶，時間複雜度爲O(log(n))

 

6、下章預告

a）流量數據量由小到大，搜索方案與架構變遷-> 這個應該頗有用，不少處於不一樣發展階段的互聯網公司都在作搜索系統，58同城經歷過流量從0到10億，數據量從0到100億，搜索架構也不斷演化着

b）數據量、併發量、策略擴展性及架構方案

c）實時搜索引擎核心技術 -> 站長髮布1個新網頁，Google如何作到15分鐘後檢索出來