海量資料處理 倒排索引

2021-06-08 20:58:41 字數 2849 閱讀 2660

在資訊大**的今天,有了搜尋引擎的幫助,使得我們能夠快速,便捷的找到所求。提到搜尋引擎,就不得不說vsm模型,說到vsm,就不得不聊倒排索引。可以毫不誇張的講,倒排索引是搜尋引擎的基石。

vsm全稱是vector space model(向量空間模型),是ir(information retrieval資訊檢索)模型中的一種,由於其簡單,直觀,高效,所以被廣泛的應用到搜尋引擎的架構中。98年的google就是憑藉這樣的乙個模型,開始了它的瘋狂擴張之路。廢話不多說,讓我們來看看到底vsm是乙個什麼東東。

文件(document):乙個完整的資訊單元,對應的搜尋引擎系統裡,就是指乙個個的網頁。

標引項(term):文件的基本構成單位,例如在英文中可以看做是乙個單詞,在中文中可以看作乙個詞語。

查詢(query):乙個使用者的輸入,一般由多個term構成。

那麼用一句話概況搜尋引擎所做的事情就是:對於使用者輸入的query,找到最相似的document返回給使用者。而這正是ir模型所解決的問題:

資訊檢索模型是指如何對查詢和文件進行表示,然後對它們進行相似度計算的框架和方法。

舉個簡單的例子:

現在有兩篇文章(document)分別是 「春風來了,春天的腳步近了」 和 「春風不度玉門關」。然後輸入的query是「春風」,從直觀上感覺,前者和輸入的查詢更相關一些,因為它包含有2個春,但這只是我們的直觀感覺,如何量化呢,要知道計算機是門嚴謹的學科^_^。這個時候,我們前面講的term和vsm模型就派上用場了。

首先我們要確定向量的維數,這時候就需要乙個字典庫,字典庫的大小,即是向量的維數。在該例中,字典為 ,文件向量,查詢向量如下圖:

vsm模型示例

ps:為了簡單起見,這裡分詞的粒度很大。

將query和document都量化為向量以後,那麼就可以計算使用者的查詢和哪個文件相似性更大了。簡單的計算結果是d1和d2同query的內積都是1,囧。當然了,如果分詞粒度再細一些,查詢的結果就是另外乙個樣子了,因此分詞的粒度也是會對查詢結果(主要是召回率和準確率)造成影響的。

上述的例子是用乙個很簡單的例子來說明vsm模型的,計算文件相似度的時候也是採用最原始的內積的方法,並且只考慮了詞頻(tf)影響因子,而沒有考慮反詞頻(idf),而現在比較常用的是cos夾角法,影響因子也非常多,據傳google的影響因子有100+之多。

大名鼎鼎的lucene專案就是採用vsm模型構建的,vsm的核心公式如下(由cos夾角法演變,此處省去推導過程)

vsm模型公式

從上面的例子不難看出,如果向量的維度(對漢語來將,這個值一般在30w-45w)變大,而且文件數量(通常都是海量的)變多,那麼計算一次相關性,開銷是非常大的,如何解決這個問題呢?不要忘記了,我們這節的主題就是 倒排索引,主角終於粉墨登場了!!!

倒排索引非常類似我們前面提到的hash結構。以下內容來自維基百科:

倒排索引(英語:inverted index),也常被稱為反向索引置入檔案反向檔案,是一種索引方法,被用來儲存在全文搜尋下某個單詞在乙個文件或者一組文件中的儲存位置的對映。它是文件檢索系統中最常用的資料結構。

有兩種不同的反向索引形式:

由上面的定義可以知道,乙個倒排索引包含乙個字典的索引和所有詞的列表。其中字典索引中包含了所有的term(通俗理解為文件中的詞),索引後面跟的列表則儲存該詞的資訊(出現的文件號,甚至包含在每個文件中的位置資訊)。下面我們還採用上面的方法舉乙個簡單的例子來說明倒排索引。

例如現在我們要對三篇文件建立索引(實際應用中,文件的數量是海量的):

文件1(d1):中國移動網際網路發展迅速

文件2(d2):移動網際網路未來的潛力巨大

文件3(d3):中華民族是個勤勞的民族

那麼文件中的詞典集合為:

建好的索引如下圖:

倒排索引

在上面的索引中,儲存了兩個資訊,文件號和出現的次數。建立好索引以後,我們就可以開始查詢了。例如現在有乙個query是」中國移動」。首先分詞得到term集合,查倒排索引,分別計算query和d1,d2,d3的距離。有沒有發現,倒排表建立好以後,就不需要在檢索整個文件庫,而是直接從字典集合中找到「中國」和「移動」,然後遍歷後面的列表直接計算。

1.左側的索引表如何建立?怎麼做才能最高效?

可能有人不假思索回答:左側的索引當然要採取hash結構啊,這樣可以快速的定位到字典項。但是這樣問題又來了,hash函式如何選取呢?而且hash是有碰撞的,但是倒排表似乎又是不允許碰撞的存在的。事實上,雖然倒排表和hash異常的相思,但是兩者還是有很大區別的,其實在這裡我們可以採用前面提到的bitmap的思想,每個term(單詞)對應乙個位置(當然了,這裡不是乙個位元位),而且是一一對應的。如何能夠做到呢,一般在文書處理中,有很多的編碼,漢字中的gbk編碼基本上就可以包含所有用到的漢字,每個漢字的gbk編碼是確定的,因此乙個term的」id」也就確定了,從而可以做到快速定位。注:得到乙個漢字的gbk號是非常快的過程,可以理解為o(1)的時間複雜度。

2.如何快速的新增刪除更新索引?

有經驗的碼農都知道,一般在系統的「做加法」的代價比「做減法」的代價要低很多,在搜尋引擎中中也不例外。因此,在倒排表中,遇到要刪除乙個文件,其實不是真正的刪除,而是將其標記刪除。這樣乙個減法操作的代價就比較小了。

3.那麼多的海量文件,如果儲存呢?有麼有什麼備份策略呢?

當然了,一台機器是儲存不下的,分布式儲存是採取的。一般的備份儲存3份就足夠了。

海量資料處理

1 有一千萬條簡訊,有重複,以文字檔案的形式儲存,一行一條,有 重複。請用5分鐘時間,找出重複出現最多的前10條。方法1 可以用雜湊表的方法對1千萬條分成若干組進行邊掃瞄邊建雜湊表。第一次掃瞄,取首位元組,尾位元組,中間隨便兩位元組作為hash code,插入到hash table中。並記錄其位址和...

海量資料處理

給定a b兩個檔案,各存放50億個url,每個url各占用64位元組,記憶體限制是4g,如何找出a b檔案共同的url?答案 可以估計每個檔案的大小為5g 64 300g,遠大於4g。所以不可能將其完全載入到記憶體中處理。考慮採取分而治之的方法。遍歷檔案a,對每個url求取hash url 1000...

海量資料處理

分而治之 hash對映 hash統計 堆 快速 歸併排序 300萬個查詢字串中統計最熱門的10個查詢。針對此類典型的top k問題,採取的對策往往是 hashmap 堆。hash統計 先對這批海量資料預處理。具體方法是 維護乙個key為query字串,value為該query出現次數的hashtab...