垂類搜索引擎的架構

極牛技術分享活動

極牛技術實踐分享系列活動是極牛聯合頂級VC、技術專家，爲企業、技術人提供的一種系統的線上技術分享活動。

每期不一樣的技術主題，和行業專家深度探討，專一解決技術實踐難點，推進技術創新。隔週三20點經過極牛線上技術分享羣準時開課。歡迎各個機構、企業的行業專家、技術人報名參加。

本期主題

垂類搜索引擎的架構

嘉賓介紹

郭濤，深圳市有信網絡技術有限公司技術總監，楓藤互動技術有限公司CEO。技術路線爲天然語言處理、搜索架構、推薦算法、機器學習。12年-14年，高德搜索引擎團隊資深工程師；14年-16年百度LBS事業部位置大數據部技術經理。目前專一於技術管理、產品研發、團隊管理。本科畢業於華中科技大學，碩士畢業於中國科學院。

你們好。我叫郭濤，目前是深圳市有信網絡技術有限公司總監，北京楓藤互動技術有限公司CEO。在高德地圖從事過地圖搜索引擎的開發，在百度從事過搜索引擎、推薦引擎的開發和技術管理。有創業經驗，並且目前也在創業中。很榮幸能和各位分享技術，但願你們多多交流，相互學習。

目前，以C++爲語言，專門從事複雜的搜索引擎的團隊確實很少了。如今後臺大多使用java、php，由於更加快捷，這也是技術的進步。C++、C更爲底層，對CPU資源的控制、內存的控制更加直接和隨意，所以用來實現高效的算法是很合適的，固然也很危險，一個core文件均可能好幾十G，core出來都須要十幾分鍾，並且你壓根不知道怎麼回事。因此對工程師而言，也確實更加受虐。可是我以爲對這類技術的瞭解仍是頗有必要的，不管你們的主流的工具是java仍是php、python，瞭解這類業務的對後續本身實現複雜的業務邏輯有幫助。

我以前完整的經歷過一套搜索引擎、一套推薦引擎的研發工做。如今就高德地圖搜索引擎的構建邏輯和業務邏輯分享給你們。固然，一套完整的搜索引擎的細節其實有不少的，但就一個分詞，就足夠說上1-2個小時。並且裏面除了架構以外，還有大量的nlp處理、排序算法、索引結構，咱們一次分享也不可能說的很細緻。可是我儘量在架構層面上把一些點說到。

當時咱們但願新的引擎，能達到如下目標：
一、相同機器的狀況下，qps由原來的200上升到1000，單個請求的平均耗時控制的50ms；
二、優化搜索效果，總體的ndcg評測能上升10%以上；

總體的架構圖以下：

Broker：
Broker 作爲引擎的惟一入口，包括以下幾個功能：
一、 檢索流程調度：
接收和解析前端下發的查詢請求，結合query processor 語義分析的結果，調度整個檢索流程，返回檢索結果給前端。
二、 對下游模塊的調度管理，作到對下游的負載均衡和服務容錯。
三、 整合排序：
根據下游searcher返回結果和離線調權模塊weight trimmer的結果、結合產品的特殊須要進行整合排序，挑出最好的結果。
四、 運營服務數據的統計上報，支持監控。

Broker 模塊存在的意義：
一、 broker 模塊作爲引擎的惟一入口，能夠給咱們提供完備的實時統計數據，這些完備的實時統計數據，能夠支持對系統的實時監控，也可讓咱們更好的瞭解系統的運營狀況。

二、 對於一次檢索來講，broker 是當次檢索的數據匯聚點(searcher 是整個系統的數據的匯聚點, broker 是當次檢索的數據的匯聚點)，咱們能夠從 broker 中落地一些中間數據，這些數據能夠提供給咱們離線作一些挖掘，甚至是一些實時的挖掘，而這些挖掘又能夠指導咱們下一次的檢索。

三、 提升系統的穩定性：用 broker 作下游模塊的調度管理以後(動態負載均衡、下游服務器的異常處理)，能夠極大的提升整個引擎的穩定性；老系統是由運維的同事在 sisserver 模塊之上作了一個容錯的功能，因爲各類緣由，其對系統異常狀態的識別和處理的靈敏性都不可能過高。

query processor：
query processor子系統，至關於語義分析系統。主要處理對查詢含義的理解，它作的工做主要包括如下方面：
一、基本的nlp處理，其中包括分詞、糾錯、近義詞；
二、GEO地理編碼分析；
三、查詢方案的理解。

GEO地理編碼是地圖類搜索引擎特有的nlp系統，主要是當用戶輸入一個地址以後，它能智能的分析出搜索詞的「地址片斷」，並將其轉化成地圖的經緯度座標表。好比當用戶輸入「我在北京，我想要去香格里拉，雲南的」，那麼GEO系統就須要抽象出目的地是「雲南省香格里拉」，起點是「北京市」。GEO系統是一套很是複雜的系統，裏面有完整的索引、語義分析，至關於一個小的搜索引擎。

「查詢方案」怎麼理解呢？
你們平時用地圖可能不會怎麼關注，認爲地圖的搜索應該不難。其實仍是挺難的。好比當你在北京輸入「香格里拉」，那麼計算機就須要分析出你真正的意圖是什麼，好比有如下幾種可能：
一、北京的香格里拉酒店、全部帶香格里拉的商鋪；
二、雲南的香格里拉；

好比用戶輸入「北京海淀醫院」，那麼也有幾種可能：
一、用戶是想去「海淀醫院」；
二、用戶是想看看在海淀區的全部醫院；
這些查詢意圖的理解，隨着用戶輸入的隨意，輸入查詢詞的量逐步擴大，系統也愈來愈複雜了。

至於分詞、糾錯、近義詞，這些偏傳統的nlp處理，這裏不作深刻分析了。由於這類研究太深了。只是這裏能夠分享的是，商業化的搜索引擎，對傳統的nlp處理，通常是數據 > 規則 > 算法。完善的豐富的數據+精細化的規則+算法輔助，才能保證95%以上的準確率。傳統的nlp算法通常是70%左右的準確率（相似命名實體識別），這樣是不能達到商業化要求的。說白了，就是會被老闆每天罵。

Searcher：
Searcher 模塊爲整個引擎提供基礎檢索，其包括的主要功能以下：
一、 提供基礎檢索
接收 broker 傳下來的語法樹，獲取對應的索引數據，進行語法運算，最後返回 n 條結果給 broker

二、 支持實時數據更新
searcher 爲了可以支持實時數據更新，同時爲了不去修改大索引，searcher 維護兩個索引表，分別是大索引和實時索引。實時數據更新的時候，searcher 只須要修改實時索引(因爲實時索引通常不會很大，因此修改實時索引的代價不是很大)，當實時索引變的很大的時候，會通知 indexer 離線合併索引，而後在分鏡像的推送給各個 searcher。

三、 基礎相關性計算
基礎相關性計算只負責在線計算當次檢索出來的 doc 的權重，不負責最終的排序。

index：
1、索引子系統主要包括三個功能：
一、 作爲實時數據更新的客戶端：
indexer 週期性的從數據庫拉取須要更新的數據，生成更新請求發送給 searcher 模塊。

二、 建增量索引：
建增量索引的目的是把目前須要上線提供服務的數據建成一套統一的索引，和目前 lse 裏面把三個索引進行合併的目的是同樣的。
建增量索引的觸發條件是：①天天凌晨週期性的觸發；②searcher中的實時索引的數據量很大的時候(searcher 只有一個大索引和一個實時索引)。③人工觸發；主要目的是提供一我的能夠控制的接口 (場景：分詞上線版本)

三、 建全量索引：
全量索引和增量索引的目的是同樣的，不一樣的地方是：全量索引須要從 DB 中獲取原始數據，增量索引能夠從本地獲取原始數據。
全量索引因爲要從 DB 中讀取大量的數據，因此建數據的過程會比較長。
全量索引只有在發現以前上線的數據有大量錯誤，或者是部署 indexer 和 searcher 服務器所有死掉的狀況下才會觸發，觸發的機率極低。

下圖，展現出一個完整請求的處理流程：

首先講一下架構。不管是broker、query processor、searcher，都是能夠橫向擴展的服務器。當哪個部分遇到了瓶頸，就往哪個部分部署機器就ok。這樣的設計保證後續擴容的方便。

各個系統之間處理請求，是「異步」的。這個異步和咱們在端口請求以前的異步不同。這個異步是從業務上理解而言的。舉個例子。假設咱們去醫院，咱們通常是先掛號、以後是問診、化驗、回診、付款、取藥。若是醫院的服務人員的處理，是來一個病人，統統走完流程以後，再服務下一個，咱們認爲這是「同步」的，這種方式很是低效，可是一個優勢是，用戶不須要記錄本身的信息，好比如今到哪一步了，由於醫院一直在爲你一我的服務，醫院會記錄你的進度信息。

而現實中不是如此。用戶每一個人都有本身的一個「病例」和醫院的流程單，用戶本身記錄着下一步應該作什麼，而醫院裏再也不記錄。這樣醫院中的資源就獨立服務全部用戶。用戶本身決定本身的流程，這就是異步。

在搜索引擎中，好比broker，在隊列中抽取出來的request就有多是不一樣的請求，好比「須要語義解析」、「須要排序」、這樣，每次抽取出來請求包以後，程序會根據請求的id從用戶信息池中抽取出相應的處理信息，並得出下一步應該作什麼，而後再轉發到相應的模塊處理。因此，同一個服務，同一個線程，在這樣的架構裏面，有多是在處理徹底不一樣的事情。

接下來咱們說一下searcher：

seacher的主要工做是基礎檢索處理。模塊的輸入是broker發送的基礎檢索請求；輸出是基礎檢索結果，結果主要包括召回的docid+weight列表。模塊主要功能包括：①解析基礎檢索請求包，構造查詢語法樹；②根據查詢語法樹讀取倒排數據，作語法運算；③根據檢索結果作重查和模糊匹配；④對語法運算的結果作基礎賦權；⑤根據基礎賦權得分選取前1000條結果返回給broker。若是結果不足1000條則所有返回。

這裏面有一些名詞，你們可能不是很明白，好比語法樹，好比模糊匹配。你們能夠不用太糾結。若是有人有興趣，我後續再答覆各位。簡而言之，searcher的主要功能是讀取倒排索引，接收查詢詞信息，而後根據查詢詞的語義分析信息，查找到對應的地址，而後對找到的各類地址排序，以後返回。

最後介紹一下weight trimmer。其實就是一個調權系統。咱們會把大量的查詢詞抽取出來，而後去輸入到咱們競爭對手的地圖搜索系統中，爬取出對方的結果，而後對結果進行干預調權。也就是，某一個結果在競爭對手那邊的排序，會做爲咱們本次請求結果排序的一個因子。若是在競爭對手那裏排名靠前，在咱們這邊排名也不會落後到那裏去，反之亦然。這樣能夠大量的解決掉一些長尾的badcase。使得搜索質量提高。

總體的架構介紹就是如此。這個架構是從google那邊繼承過來的一個變形體。不少網頁搜索系統也是一樣的架構，只是網頁的數據量更大而已。
在此，僅僅只是比較簡單的介紹了總體的架構和用途。關於裏面的細節，你們有想了解的能夠和我繼續交流。關於搜索算法、推薦引擎、nlp、數據挖掘方面均可以。關於如何去學習、進階，也能夠和我交流。謝謝！

Q&A
Q1：垂直搜索使用哪些經常使用算法
A1：搜索引擎是一整套架構，裏面任何一個模塊都設計到很多算法。好比說索引就涉及到數據結構的設計，檢索系統設計到語法書的數據結構設計、排序算法用到了機器學習訓練、分詞系統用到了HMM、CRF等算法，空間索引有四分數、GEOHash等等，算法太多了。

Q2：數據存儲，持久存儲與緩存選擇哪些？
A2：咱們存儲數據，就是內存和硬盤。至於持久存儲，我瞭解很少，對不一樣的介質彷佛不一樣，我以前瞭解有光盤矩陣涉及到持久存儲的，咱們沒有涉及到那麼多的存儲介質。並且搜索引擎，除了原始數據是存在數據庫裏面，其他全部的數據不是數據庫存的，例如100多G的索引直接就是文件存儲。對於部分高頻需求咱們須要緩存加速，緩存當時也不是用的redis，而是本身寫的一套緩存系統，由於咱們對於緩存的策略有本身的需求，並且也沒有設計到分佈式，也不但願落地存儲。只有徹底內存才能達到咱們的速度要求。

Q3：老引擎和索引技術本身實現仍是使用第三方？
A3：不管是新老引擎，索引結構設計和檢索流程都是本身實現的，沒有用到第三方庫或者服務。

Q4：創業公司技術能力有限，推薦和機器學習，如何選擇合適的第三方服務？
A4：問題中提到了推薦和機器學習。這裏分開說。推薦服務是一個強產品的技術類服務，推薦算法的結構和搜索還不一樣，搜索的架構，不一樣的產品之間類似性可能還很多，可是推薦的服務在不一樣的產品之間可能就很不一樣。推薦技術業內也都說：先有推薦產品，後有推薦架構和算法。因此，產品不一樣，哪怕是自身的架構和需求差別都很大，也就不存在統一和固定的第三方服務了。

目前我只知道百度開放了本身的推薦架構和算法，可是通常業務放都不會使用。由於自由根據自身業務定製化的推薦服務纔是最好的。至於機器學習，目前大多都是開放的算法架構。沒有統一提供第三方服務的。由於這類算法太底層，從底層到最上層的業務，這中間的業務形態變化太多，沒有很好的辦法標準化，因此也不可能像雲服務同樣提供服務。通常都是找到相應的算法架構，而後根據本身的業務設置參數，結合本身的數據訓練，結果的好壞取決於對業務的理解和對模型的熟悉程度。

報名請關注極牛公號並回復技術分享