? Facebook是目前世界上最著名的社交網站，月活躍用戶已超過10億，每日登陸網站的用戶超過6億。如果從數據抽象的角度來看，Facebook的社交圖不僅包括好友之間的關系，還包括人和實體以及實體之間的關系，每個用戶，每個頁面，每張圖片，每個應用，每個地點以及每個評論都可以作為獨立實體，用戶喜歡某個頁面則建立了用戶和頁面之間的關系，用戶在某個地點簽到則建立了用戶和地點之間的關系……如果將每個實體看作圖中的節點，實體之間的關系看作是圖中的有向邊，則Facebook的所有數據會構成超過千億條邊的巨量實體圖（Entity Graph）。實體圖中的關系有些是雙向的，比如朋友關系，有些則是單向的，比如用戶在某個地點簽到。同時實體還具有自己的屬性，比如某個用戶畢業于斯坦福大學，出生于1988年等，這些都是用戶實體的屬性。圖1是Facebook實體圖的一個示意片段。

?

????????????????????????????????????????? 圖1 Facebook實體圖（Fbid是Facebook內部唯一ID編號）

對這個巨大實體圖的搜索需求可以分為兩類，一類是對于某類實體的搜索，常見的需求是根據實體名稱搜索具體實體，實體圖中的用戶，圖片，應用，地點等都可以成為被搜索的對象，比如搜索者搜索“Jordan”，搜索系統將所有名字里包含Jordan的其它用戶搜索出來；另外一類搜索需求涉及到實體之間的關系，比如“Jordan都有哪些朋友”。

GraphSearch的定位就是成為能夠讓用戶采用自然語言界面既能夠搜索實體，也能夠搜索實體關系的社交搜索引擎。這里需要強調的是：Graph Search不僅僅是傳統的關鍵詞搜索，還允許用戶用自然語言來對結果進行搜索，即用戶可以直接提問：”Facebook有哪些員工是華人”，而其可以通過自然語言處理技術理解用戶真正想搜的內容，并給出精準的搜索結果。使用Graph Search，可以在這個巨量實體圖上搜索類似以下復雜的自然語言查詢：

a.Facebook的員工喜歡的餐館有哪些;

b.畢業于斯坦福大學的人都喜歡看什么電影;

c.我的朋友喜歡去的旅游景點有哪些;

?

Facebook Graph Search是如何做到這一點的呢？為了理解其內部運行機制, 需要先了解Graph Search的倒排索引服務Unicorn系統。

?

Unicorn:Graph Search的基石

倒排索引是搜索引擎最重要的基礎構件之一。對于通用的網頁搜索引擎比如百度谷歌來說，倒排索引的功能是建立單詞到出現過這個單詞的網頁列表之間的映射關系，這樣，當用戶輸入某個查詢詞，搜索系統通過倒排索引找到出現過這個搜索詞對應的網頁列表，并按照若干排序因子對搜索結果排序，這樣就完成了一次搜索過程。

Unicorn是建立在具有接近百億節點的實體圖上的倒排索引服務架構。與一般的網頁搜索倒排索引不同，Unicorn具有幾個獨特的特性和挑戰：

1.????????不僅要對實體名稱、評論內容等傳統的文本內容進行索引，還需要對社交關系（朋友關系）用戶行為（用戶標記某個頁面為liked）等建立索引。這里面臨的技術挑戰是：如何將社交關系這種涉及多實體關系的數據存入索引結構？

2.????????為了能夠快速響應用戶查詢，Unicorn會將幾十億節點以及千億以上的邊信息對應的索引結構保存在服務器內存中。傳統的搜索引擎盡管也需要處理百億級別的網頁數據，但是索引結構往往是存儲在磁盤中，通過外存索引加內存Cache的模式來加快查找速度。對于全內存的存儲方式，如何設計整體架構來保存這種海量信息是非常有技術難度的。

3.????????為了能夠支持類似“Facebook的員工都喜歡什么餐館”這種復雜查詢，Unicorn定義了一套獨具特色的集合操作符，通過操作符的嵌套與組合，不僅可以支持類似的復雜查詢，還可以兼顧搜索的社交屬性及搜索結果的多樣性。

?

下面將從Unicorn的數據模型、整體架構及其定義的獨具特色的集合操作符來講解Facebook的技術人員是如何應對這些技術挑戰的。

?

Unicorn的數據模型

?

??????????????????????????????????????????????? 圖2. 社交關系倒排列表與內容倒排列表

?

作為實體圖的倒排索引，Unicorn與常見的倒排索引有一定差異。通常的倒排索引由所有網頁中出現的單詞項Term及其對應的倒排列表（Posting List）構成。倒排列表往往由一系列倒排列表項（Posting）構成，每個倒排列表項包含網頁ID，單詞在網頁中出現的次數以及單詞在網頁中出現的位置信息等構成。

?Unicorn的倒排索引與傳統倒排索引有三個主要不同點（參考圖2）：

首先，Unicorn的單詞項不僅僅包含了傳統的單詞，也將社交關系或者用戶行為引入。為了表達節點之間的關系，可以構造<edge-type>:<ID>作為單詞項來表達某個節點通過社交形成的邊或者用戶行為邊，這里<edge-type>代表了邊的類型，<ID>代表了節點的內部唯一編號，比如friend:5作為單詞項的含義是節點5的朋友關系，而likes:5則代表了節點5喜歡哪些頁面這種用戶行為。

其次，倒排列表中的倒排列表項（Posting）包含的內容也與傳統倒排列表有很大差異。Unicorn的倒排列表項由（DocID,HitData）構成，其中DocID又由（Sort-Key,ID）兩項元素組成。Sort-Key是整型數值，代表了這個索引項的全局重要性，倒排列表項按照Sort-Key大小降序排列，最重要的項目排在前列，這樣有利于搜索時采取截斷等操作來快速找到優質的滿足搜索條件內容。如果兩個索引項Sort-Key相同，則按照ID值由小到大升序排列。HitData保存的數據與具體應用相關，不同的應用可能會在這里存儲不同的數據。HitData常見的應用場景是對搜索結果進行進一步的過濾，比如圖2中所示的例子，單詞項“MIT”中的倒排列表中列出了畢業于麻省理工學院的圖節點ID列表，而對應的HitData中則存儲了每個畢業于麻省理工人員對應的畢業日期和專業信息，這樣可以對搜索結果進行進一步的過濾，比如可以指定畢業于計算機專業（CS）的MIT畢業生等復雜查詢。

另外，Unicorn的特點是將所有倒排索引信息都存儲在服務器內存中。這樣可以快速響應用戶查詢，但是考慮到實體圖數量以億計，非常巨大，單機的內存遠遠沒有足夠資源對其進行存儲，必然采取分布式集群的方式來對索引數據進行管理，至于如何對如此海量數據進行高效管理，本文的整體架構小節會對此有講解。

上述內容描述了Unicorn的倒排索引數據模型，除此外，Unicorn還需要維護社交圖節點的正向索引（Forward Index）。所謂正向索引，就是以（key,value）形式存在的數據，其中key是圖節點的ID，value則會存儲圖節點的一些屬性信息，這些信息可以用來對搜索結果內容展示或者進行一些條件過濾。

?

?

?Unicorn的整體架構

?

???????????????????????????????????????????????????????????????? 圖3 ?Unicorn整體架構圖

?

?

Unicorn的整體架構分為樹狀的四層結構（圖3）：頂層聚集器，垂直聚集器，RACK聚集器以及索引服務器。頂層聚集器負責接收用戶查詢并根據搜索結果類型將查詢分發到對應的垂直聚集器中（比如搜索結果是“用戶“類型，則分發給”用戶“類型垂直聚集器），同時從垂直聚集器接收返回結果做些優選返回給用戶。垂直聚集器從頂層聚集器接收用戶查詢，并將查詢分發到RACK聚集器。RACK聚集器同樣將查詢分發給RACK內所有索引服務器并合并截斷索引服務器返回的結果，RACK聚集器的優勢在于同一機柜內服務器通信效率高。索引服務器負責在內存維護社交圖部分數據（Shard）的倒排索引,同時索引服務器負責and/or等集合操作來獲得本部分數據的搜索結果，一般一個索引服務器能夠索引幾十億條倒排列表信息。

不同垂直聚集器包含的RACK數量有很大差異，這是由該種類型數據在實體圖中的數量決定的，比如“用戶”類型的圖節點以十億計數，所以必然需要較多數量的機器，而“應用”類型的數據相比之下所需資源會少很多。

考慮到數據的可用性，Unicorn以垂直聚集器為單位進行數據冗余備份。如果某個索引服務器負責的數據發生故障，RACK聚集器負責將相應的請求轉發到其它垂直聚集器里對應的備份數據中。

?

Unicorn的查詢語言

為了能夠支持復雜的應用查詢邏輯，Unicorn定義了一些集合操作符，查詢語言通過組合這些查詢操作符可以表達復雜查詢邏輯。

最常用和最簡潔的操作符是Term操作符，其含義是直接讀取某個Term的倒排列表，比如(Term friend:5)代表的語義是找出fbid為5的節點的所有朋友關系；

常見的集合操作符還包括And/Or/Difference操作，分別代表對兩個集合的交集、并集及差集運算。比如（andfriend:5 friend:6）代表找出同時是節點5和節點6朋友的人員集合；（or friend:5 friend 6）代表找出節點5的朋友或者節點6的朋友集合；（difference friend:5 friend：6）代表找出是節點5的朋友而不是節點6的朋友集合。

除了上面提及的常見集合操作符號外，Unicorn另外定義了三個獨具特色的集合操作符：Weak-And/Strong-Or/Apply。

?

Weak-And操作符

為了增加搜索結果排序的社交化效果，可以考慮將搜索結果限定在發出搜索查詢詞用戶的朋友圈內。比如用戶Jones（假設該用戶內部Fbid=3）發出查詢“Mark”，不考慮社交因素的方式可以直接將名字里包含Mark的用戶列表找出（即查詢：（Term Mark））；如果考慮社交因素,可以將搜索結果范圍限定在搜索者Jone的朋友圈內（即查詢：(And Mark friend:3)）。

但是如果所有查詢都這樣操作也會帶來相應的問題：搜索范圍限制得過于死板和嚴格。如果嚴格按照上述邏輯，可能存在質量較好的搜索結果，但其不在搜索用戶的朋友圈內，這樣就將這種高質量的搜索結果排除在外了。為了解決上述矛盾，Unicorn引入了Weak-And操作符，顧名思義，這是對And操作符的一種弱化和條件放松。Weak-And允許一定比例或者個數的搜索結果不需要滿足所有條件也可以進入最終搜索結果隊列。

?

???????????????????????????????????????????????? 圖 4. ?Weak-and操作符

假設當前用戶Jones(fbid=3)搜索“manlanie mars”，圖4是內存中對應這個搜索的索引結構。如果Graph Search在內部施加了Weak-and操作符，其對應的內部查詢語言為：（weak-and (termfriend:3 :optional-hits 2) (termmanlanie)(term mars))。對應這條查詢語言，Graph Search返回給用戶的結果是ID列表：15,20，7,57，其中，7和57屬于同時滿足三個條件的結果，而因為weak-and指出了friend:3的optional-hits條件為2，意思是結果中最多允許2個結果不在Jones的朋友圈中，Sort-Key較高的15和20不在Jones的朋友圈中，已經將這兩個指標占滿，所以75這個結果就不再展示給用戶。Weak-and除了可以采用指定個數外，還可以用optional-weight的方式按照結果比例指定結果分布。

?

Strong-Or操作符

與Weak-And操作符相對應，Unicorn提出了針對Or操作符的改進Strong-Or操作符。這個操作符強制規定：滿足某些搜索條件的搜索結果數目必須達到總體結果的指定比例。比如下面的例子：

（stong-or friend:3

?????????? (and friend:3 live-in:100 :optional-weight 0.2)

?????????? (and friend:3 live-in:101 :optional-weight 0.3) )

其語義代表了查找Jones的朋友，同時要求其中至少20%的朋友居住在北京（fbid=100），至少30%的朋友居住在洛杉磯（fbid=101）。至于其他50%的結果對其居住地不做任何限制。 通過這種方式可以采用靈活的方式強制搜索結果增加多樣性。

?

Apply操作符

因為Facebook的所有信息構成了巨大的實體圖，很多實際應用會有順著圖中節點沿著邊進行游走遍歷的操作。對于一度關系遍歷，Unicorn已經通過索引將其建立到索引信息中，可以一次讀取直接獲得，但是對于二度遍歷甚至更高度的遍歷，則無法直接從索引中一次性讀出。

假設某個用戶希望找到：Jones的朋友喜歡哪些頁面，這是一個典型的社交圖上的二度遍歷操作。一個很直接的解決方案如下：首先可以構造查詢，找出Jones的朋友，即(friend:3 ),假設結果是fbid為5和6的人，Unicorn的頂層聚集器在接收到這個搜索結果后，構造另外一個查詢就可以找出這些人喜歡的頁面，即（or likes:5 likes:6）。這樣，一個二度遍歷操作可以轉化為分別由and和or連續的兩次查詢來解決問題。

Apply就是直接使用單個表達符號來完成上述邏輯的操作符。如果一個二度遍歷可以由第一步的and操作符，以及對第一步的搜索結果采用or操作符來構造，那么就可以使用Apply操作一步到位。比如上面的例子就可以用：（Apply likes:friend:3)來完成。

?

Graph Search

??

如何建立索引

????? Graph Search具有兩種不同類型的索引建立通道，一條通道是批處理類型的，一次處理大批量待索引的數據；另外一條通道是為了保證信息更新的時效性而建立的接近實時的索引更新通道。

批處理索引通道的原始數據存儲在數據庫中，通過Hive可以對這些數據進行訪問。在建立索引的時候，只需要程序員寫少量代碼將Hive中的每行數據轉換為（term,sort-key,id,HitData）這種格式，系統提供了Hadoop例程來自動將這種格式的數據轉換為Unicorn的索引，并將其拷貝到對應的索引服務器中。

近實時索引通道通過Scribe來作為連接更新數據和索引的聯系通道。當實體圖數據發生變化時，將這種數據變化寫入Scribe系統，然后Scribe系統會以Thrift客戶端形式將變化的數據寫入索引系統。

?

?? 搜索過程

用戶利用GraphSearch完成一次完整的搜索涉及兩個連續的過程：搜索建議階段和搜索階段。當用戶輸入查詢內容時，GraphSearch會通過自然語言處理模塊試圖理解用戶的搜索意圖并給出若干搜索建議，當用戶點擊某個搜索建議后，系統進行真正的搜索并將搜索結果返回給用戶。

在搜索建議階段，自然語言處理模塊試圖將用戶當前輸入通過句法分析構建一顆句法樹，同時這個模塊將用戶輸入中的某些片段識別為可能的實體類型（地點，人名等），并將這些片段提交Unicorn系統，同時根據Unicorn的搜索結果來構建各種可能的句法分析樹，并賦予每個句法分析樹不同權重，然后選擇得分較高的句法分析結果作為提示用戶的內容。比如用戶輸入“friends at Facebook”，自然語言處理模塊會建議：Friends whowork at Facebook，以此作為猜測的用戶搜索意圖。

當用戶選擇了某個搜索建議進行搜索時，Graph Search將對應的句法樹和在上一階段搜索獲得的實體內部ID提交給Unicorn的頂層聚集器，自然語言解析的結果以用戶可讀的方式展示在對應的搜索URL中，比如用戶搜索：restaurants liked by Facebook employees，其對應的URL包含：

273819889375819/places/20531316728/employees/places-liked/intersect

這里的273819889375819是系統內部中“餐館”對應的類別ID，20531316728是“Facebook”實體對應的內部ID，這個URL已經能夠在一定程度上以內部操作符的方式代表用戶的搜索意圖：求餐館類型的地點實體和facebook員工喜歡的地點實體的交集。

當頂層聚集器收到上述URL，可以形成一個查詢規劃：首先在某個垂直聚集器進行查詢，根據查詢結果構建新的內部查詢語言，將其提交給另外一個垂直聚集器，以此類推可以序列執行一系列查詢并得到最終結果。以上面的例子來說明，首先向“用戶”這個類別的垂直聚集器提交查詢（term employee:20531316728）,即查找Facebook的員工信息列表，假設返回n個結果fbid1,fbid2…..fbidn，那么形成新的查詢：(andplace-kind:273819889375819 (or liked-by:fbid1 liked-by:fbid2 ... liked-by:fbidn))，并提交給“地點”類型的垂直聚集器，返回的結果就是用戶希望獲得的搜索結果。結合上文提到的Unicorn整體架構圖，我們可以梳理出上述查詢的整個執行流程如下：

Step 1:句法分析樹及對應實體ID提交給頂層聚集器，聚集器形成查詢規劃；

??? Step 2:為“用戶”類型的垂直聚集器準備好查詢：（term employee:20531316728）

??? Step 3:頂層聚集器有時會根據用戶個人信息改寫上述查詢，主要是加入社交因素并通過weak-and或者Strong-or來保證社交因素起作用的同時也能一定程度上保證搜索結果的多樣性；

?? Step 4:”用戶“類型垂直聚集器接收到查詢并將其通過RACK聚集器分發給所有索引服務器；

?? Step 5:每個索引服務器從自己維護的索引中檢索出部分用戶實體的結果，對結果打分排序并將得分較高的部分用戶實體返回給“用戶“類型垂直聚集器；

?? Step 6:垂直聚集器收集各個索引服務器傳回的結果并將其返回給頂層聚集器；

?? Step 7:頂層聚集器根據返回的結果fbid1,fbid2……fbidn,為“地點”類型垂直聚集器形成新的查詢：(and place-kind:273819889375819 (orliked-by:fbid1 liked-by:fbid2 ... liked- by:fbidn)),并將其發送給“地點”垂直聚集器；

?? Step 8:“地點”垂直聚集器將接受到的查詢通過RACK聚集器分發給所有索引服務器；

?? Step 9:索引服務器在自己維護的索引里搜索結果并將得分較高的地點實體返回給“地點”垂直聚集器；

? Step 10:”地點“垂直聚集器接收各個索引服務器的返回結果，合并后提交給頂層聚集器；

? Step 11:頂層聚集器對結果進行重新打分并將得分較高結果返回給用戶作為搜索結果。

?

從以上查詢的執行流程，可以看出整體架構圖中各個構件的具體功能及其流程關系。

?

搜索結果排序

對于搜索引擎來說，搜索結果排序質量好壞直接關系到用戶體驗，對于網頁搜索來說，最主要的兩個排序因素是內容相關性以及通過網頁之間的鏈接關系分析得出的網頁重要性排名，除此外還會融合查詢詞出現位置等很多其它因素來最終人工擬合抑或通過機器學習算法來自動推導出搜索結果排序公式。

GraphSearch采用了簡單的機器學習框架來對搜索結果進行排序，即采用對若干影響搜索排名的因子進行線性加權來計算獲得最終搜索結果排名，而影響排名的因子包括：搜索用戶和搜索結果地理位置的距離遠近；搜索用戶和搜索結果通過朋友關系推導出的親密程度；查詢串和搜索結果字符串的重疊程度等幾十種排序特征。Facebook工程師認為這種簡單的機器學習排序框架有利于整個系統的可理解性和可維護性。

除了上述簡單機器學習框架外，Graph Search系統非常關注搜索結果的多樣性(Diversity)。Unicorn本身提供的Wenk-And 和Srong-Or是保證搜索結果多樣性的一種措施，除此外，Unicorn提供了對于同一類查詢結果同時采納多種不同側重點的打分函數機制，這樣每個搜索結果會同時得到多個不同維度的得分，在排序的時候可以考慮采用一定策略來融合不同打分函數的結果，以此來保證搜索結果的多樣性。比如對于搜索附近地理位置的查詢（Nearby），可以提供三種不同類型的打分函數，一種考慮搜索結果的熱門程度，一種考慮搜索用戶的社交關系，還有一種考慮距離遠近。這樣每個搜索結果會附帶三個不同的得分，在排序時為了保證結果的多樣性，可以按照一定比例將三種高得分結果進行混合輸出。

?

?

結束語

????? 社交化是當前很多互聯網應用的發展趨勢，而社交化數據往往比較適合采用實體圖來建立數據模型。面對海量的實體圖數據，如何構建其上的搜索系統，使得這個搜索系統能夠回答各種涉及關系類型的復雜查詢，這都是社交化互聯網應用必須解決的技術問題。Facebook作為世界最大的社交網站，通過Graph Search為我們提供了一套行之有效的解決方案，本文對這套技術方案進行了技術講解，期望國內同仁

總結

以上是生活随笔為你收集整理的社交搜索Graph Search技术解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。