《京東億級商品搜索核心技術解密》要點：
本文介紹了京東億級商品搜索核心技術解密，希望對您有用。如果有疑問，可以聯系我們。

作者：王春明,現任京東搜索平臺部負責人,2011年加入京東搜索團隊,期間一直負責京東搜索引擎研發工作,主導了多次搜索架構升級工作保障其滿足京東發展需求,擅長搜索引擎、高性能服務開發、分布式系統架構.

招聘：?京東搜索平臺部木有有高級/資深搜索引擎研發工程師(C/C++)??、高級/資深算法工程師(C/C++)、高級/資深數據系統工程師(java)等職位,期待您的加入,一起打造彈性搜索平臺.簡歷投遞至：wangchunming@jd.com,工作地點：北京-北辰世紀中心A座.

京東商品搜索簡介

京東商品搜索引擎是搜索推薦部自主研發的商品搜索引擎,主要功能是為海量京東用戶提供精準、快速的購物體驗.目前入口主要有PC/移動/微信/手Q搜索、移動列表頁、店鋪搜索、店鋪列表等.雖然只有短短幾年的時間,系統已經能夠支持日均PV過億的請求,并且經過了多次618店慶和雙11的考驗.

與人們日常使用的如谷歌、百度等大搜索(或稱為“全文搜索”)引擎相比,京東商品搜索引擎與前者有相通之處,比如“覆蓋海量數據”、“超高并發查詢”以及“超快速的請求響應時間”,同時又有自身顯著的業務特點：

• 結構化的商品數據,需要從商品、庫存、價格、促銷、倉儲等多個系統進行抽取；
• 極高的召回率要求,保證每一個狀態正常的商品都能夠被搜索到；
• 商品信息的及時更新,目的是為了保證用戶極佳的購物體驗——比如不能給用戶展示出下柜的商品,或者商品的實時價格超出了用戶搜索限定的范圍.這就要求我們的搜索引擎要做到和各個系統的信息時刻保持同步,目前每天更新次數過億；
• 邏輯復雜的商品業務,需要存儲的商品屬性信息是倒排索引信息的2倍之多；
• 用戶購物的個性化需求,要求系統實現用戶標簽與商品標簽的匹配.

正是由于既要兼顧大搜索引擎的通用需求,同時要契合京東的業務特點,我們將系統架構分為四個部分：1. 爬蟲系統、2. 離線信息處理系統、3. 索引系統、4. 搜索服務系統.

為了使各位讀者能夠深入了解京東商品搜索引擎的架構,本文首先介紹了商品搜索的總體架構,然后依次介紹了爬蟲系統、離線信息處理系統等各個部分,并且對搜索技術的最新研究方向做展望,希望對各位讀者有所幫助.

總體架構

京東商品搜索引擎的整體架構如下圖所示：

從上到下共分為3層.最上層是由搜索的前端UI層,負責頁面展示.

中間層是由搜索索引服務、SUG搜索、相關搜索、劃詞服務和兜底服務組成.其中,SUG搜索提供輸入框下拉提示詞功能；相關搜索提供與query相關的其他搜索詞服務；劃詞服務提供去除query部分詞的功能；兜底服務用于索引服務異常情況下提供托底,保證用戶基本的搜索可用.

最下層是索引生產端,主要功能是對接商品、庫存、價格、促銷、倉儲等眾多外部系統,整合相關數據生產全量和增量數據的索引,為在線檢索服務集群提供全量索引和實時索引數據.

爬蟲系統

商品搜索引擎的核心是建立商品索引,而建立索引需要詳細的商品信息數據.我們利用大數據平臺的數據庫抽取接口和中間件系統,實現了站內商品爬蟲系統,用來抽取數據庫中的商品信息和及時發現變化的商品信息.從實踐的效果上來看,爬蟲系統表現是非常穩定和可靠的.

離線信息處理系統

離線信息處理系統主要功能是用來建立商品搜索引擎的待索引數據,包括全量待索引數據和增量待索引數據.

目前商品全量待索引數據按天進行更新,一部分是商品的基礎屬性信息,如商品sku、商品名稱、顏色、規格、風格、材質面料等等,屬于比較穩定、短時期內不會變化的數據.另外一部分是商品銷售信息,如商品銷量、銷售額、評論等,屬于易變數據.這些數據散布于多個系統中,使用的存儲也各不相同.因此需要對這些來源分散的數據在商品維度進行合并,生成“商品全量待索引寬表”.目前我們建立的全量待索引寬表,不僅應用于搜索引擎服務,還同時應用于個性化推薦等其他產品服務當中.但是僅生成寬表是無法完成搜索引擎的索引需求的,因此我們利用Hadoop/MapReduce計算框架對寬表數據進行清洗,并且依照離線業務邏輯規則對數據進行二次“加工”,最終生成一份全量待索引數據.

有些商品信息,比如“價格”、“庫存”、“上下架”等,經常會產生變化,因此對這些數據做全量索引滿足不了商品搜索引擎的需求.為了解決數據實時性的強需求,我們建立了增量索引作為全量索引的補充.具體細節上,采用和全量索引類似的方法對數據進行處理,生成增量待索引數據.為了保證增量數據的及時性和準確性,離線信息處理系統會實時調用各商品信息接口獲取數據,完成增量待索引數據的在線組裝和生產.

索引系統

索引系統是商品搜索引擎的核心,主要功能是把以商品為維度進行存儲的待索引數據,轉換成以關鍵字為維度進行存儲的數據,用于搜索引擎上層服務進行調用.這里待索引數據指前面離線信息處理系統生成的全量待索引數據和增量待索引數據.

此系統對于全量和增量的處理是一致的,唯一的區別在于待處理數據量的差異.一般情況下,全量數據索引由于數據量龐大,采用Hadoop/MapReduce進行；實時數據量小,采用單機進行索引生產.

為了滿足分布式檢索的需求,索引系統還會對索引數據進行分片處理,即按照一定策略將索引數據拆分成較小索引片,用于搜索服務系統調用.

搜索服務系統

搜索索引服務系統主要功能是接受用戶請求并響應,返回搜索結果.搜索服務系統的發展也經歷了從無到有,從簡單到豐富到過程.主要分為如下幾個階段：

• 最初,搜索服務只有1列searcher組成在線檢索服務,能夠完成一些簡單的商品搜索；
• 隨著訪問量的增長,搜索服務系統增加了緩存模塊,大大加快了請求處理的速度；
• 接下來為了提高用戶體驗,我們增加了Query Processor服務,負責用戶查詢意圖分析,提升搜索的準確性.目前Query Processor已經成為了一個融合自然語言處理、機器學習等先進技術的成熟服務,并且還在不斷的進行優化；
• 為了支持個性化,增加了User Profile服務,負責查詢用戶標簽.將商品的標簽與用戶標簽是否匹配,作為一個特征加入排序因子,實現搜索的千人千面；
• 接著隨著數據量(商品量)的增長,我們將結果包裝功能從檢索服務中獨立出去,成為detail服務(基于緩存云實現的商品信息KV查詢服務)；
• 將檢索服務進行分片化處理,即采用類似數據庫分庫分表的思想,對商品id,進行hash處理后進行分片,保證各個分片數據均勻.查詢時,將一個搜索請求分配到多個searcher列上,并行檢索,進行局部排序后返回給merger.然后merger服務,將多個分片的檢索結果進行歸并,然后再進行業務排序和加工,確定要返回的商品,最后調用detail服務包裝,將結果返給給blender.blender將多個搜索的結果進行融合,返回給前端.需要說明的是,此時搜索服務系統已經成為了一個“多blender&多Searcher&多merger”的系統.今后無論是訪問量的增長或者數據量的增長,都可以通過擴容來滿足.尤其對于618店慶、11.11之類的峰值搜索量劇增的情況下,可通過增加每個searcher列服務器的數量來滿足需求.隨著商品數據的不斷增加,只要適時對數據做更多的分片,相應增加searcher列就可以了.檢索服務分片化機制的建立也標志著京東搜索基礎服務系統已經趨于完備.

完整的搜索索引服務架構,如下圖所示：

搜索請求流程如下：

1. 外部請求通過vip到達blender；
2. Blender調用QP,QP調用運營平臺,其中運營平臺主要負責將日常運營數據服務化,QP負責分析query；
3. Blender同時請求Merger和其他垂直搜索服務；
4. Merger調用UserProfile獲取用戶標簽信息；
5. Merger將請求發給每列searcher；
6. 每個searcher召回商品并返給Merger；
7. Merger合并多列searcher的結果,確定需要輸出的商品,請求Datail包裝對應的商品信息；
8. Detail包裝商品信息返給Merger；
9. Merger將包裝好的商品返給blender；
10. Blender將merger返回的結果與其他垂直搜索結果進行合并,最終返回給前端.

Blender、Merger、Searcher和Detail是整個系統的核心組件,它們之間的調用關系由Clustermap管理.各個模塊將自己的服務注冊到ClusterMap,同時從ClusterMap訂閱其調用模塊的信息來確定實際調用關系.

簡要搜索服務流程,如下圖所示(搜索服務系統內部處理流程)：

圖中名詞解釋如下：

• Page cache：頁面緩存,blender模塊直接緩存輸出的頁面,merger緩存了多頁商品id；
• Attr cache：屬性緩存,緩存的搜索屬性導航區的數據；
• Doc cache：緩存查詢詞從全量索引召回的結果；
• OP：運營平臺服務,負責搜索運營數據的服務化；
• QP：query processor,負責query意圖識別.

用戶請求發送到blender,首先解析參數.如果命中blender page cache直接返回給用戶.如果沒有命中,則調用運營平臺服務(OP)和QP,并將其傳給Merger,Merge會檢查是否命中Attr cache,如果命中并且恰好僅請求屬性匯總結果,直接返回給blender.否則進一步查看是否命中merger page cahce,如果命中直接調用detail包裝,返給blender.如果沒有命中,則調用User Profile獲取用戶標簽,將其傳給searcher(篇幅所限,圖中只列了一個searcher,實際是多個).Searcher接到請求,判斷是否命中doc cache,如果命中doc cache,則拉取增量結果；如果沒有命中doc cahe,則拉取全量和增量結果.然后依次進行排序、在線業務處理,把結果返給merger.Merger合并多個searcher結果,排序、在線業務處理,最后調用detail包裝,最后將結果返給blender,blender合并多個搜索結果后返回給用戶.

作為一個高并發系統,為了保證高召回率和低響應延時,我們把整個搜索服務流程的處理全部放在內存當中進行計算.多個searcher并發處理請求,同時單個searcher內部采用線程池技術,即所有線程之間共享倒排索引和商品屬性信息,提高內存使用效率；每個查詢使用一個獨立線程串行執行,保證并發的多個查詢線程之間互不影響.此外通過合理的設置線程池的大小,我們可以保證系統的CPU資源得到充分利用.在上述兩個方面對系統進行優化之后,整個搜索服務系統的穩定性、召回率、內存使用率、計算速度等指標都有大幅度的提高.但是我們改進系統的步伐并沒有停歇,因為通過實踐發現基于內存和線程池的搜索服務仍然有幾個瓶頸點亟需解決,主要包括：拉取倒排、排序和在線業務處理.針對這些問題,我們進行了二次優化,主要包括如下措施：

1. 多級緩存策略

1. Blender Page cache：由于搜索符合互聯網的二八法則,20%熱門查詢頻度非常高,占每天搜索請求量80%.針對這一特點,搜索第一級緩存以查詢請求為key,將返回給用戶的頁面作為value.對于完全相同的請求,直接從緩存返回結果.頁面緩存策略上線伊始,緩存命中率就接近了30%,基本解決了當時的性能問題.
2. Merge Page cache：隨著業務的發展,排序結果需要針對不同用戶實現個性化訂制,這就導致請求中會包含用戶的user pin.如果直接將user pin放入緩存作為key,會導致blender cache的key數量暴增,不但需要超大的緩存空間,同時緩存的命中率也會極低,最終會導致線上個性化服務的體驗滿意度降低.為了解決這個問題,將user_pin加入key,但是value只保存排序好的商品id,這樣需要的緩存空間遠遠小于blender cache.當命中緩存后,調用detail直接進行結果包裝.為了進一步提高緩存命中率,利用用戶搜索的翻頁習慣,即離線統計出用戶的翻頁數TP99,然后在value中緩存這些頁面涉及到所有的商品id,從實踐效果來看,用戶后續的翻頁請求大部分會命中cache.
3. 在深入分析了業務和排序的需求之后,我們發現拉取倒排的結果只和“查詢詞&篩選條件”有關,而與用戶無關,因此可以按照“查詢詞&篩選條件”作為key的方式對其進行緩存.

雖然拉取倒排結果緩存的key很快就解決了,但是我們在解決Value的存儲時遇到了兩個問題：1)拉取倒排的結果非常之多,導致緩存過大；2)對此結果緩存,會降低實時索引的時效性.

對于問題1),在分析了業務之后,對需要緩存的信息進行了大量的精簡并采用壓縮存儲,最終將一個查詢的緩存控制在0.5M以下.

對于問題2),我們將拉取倒排結果分為兩部分,第一部分是從全量索引拉取倒排的結果,第二部分是從實時索引拉取倒排的結果.為了和全量索引的更新頻率保持同步,我們把第一部分數據進行緩存的周期置為1天.對于第二部分數據,由于增量結果遠遠少于全量結果(一般增量只有全量5%不到),每次緩存都進行實時計算,這就是圖3中的doc cache機制.從實踐中來看,命中doc cache的響應時間比未命中的降低了1-2個數量級.將來隨著增量結果的積累,如果實時拉取倒排結果成為性能瓶頸,可以對增量索引分段也進行緩存.

2. 截斷策略

對于有些熱門查詢,由于其結果較多,比如“男裝”、“鞋”之類的query,原始查詢結果幾千萬個,如果對這些結果挨個進行處理,性能會非常差.同時,從用戶角度分析,一個查詢只有排在最前面的結果對用戶才有意義.通過分析用戶翻頁次數,可以得到截斷保留topN結果.如何保證截斷不影響用戶體驗呢?首先我們對商品建立離線模型,即為每個商品計算出一個質量分數據.然后在索引階段,將所有商品按照質量分降序排列,保證在倒排鏈中,排在前面的商品質量分總是高于后面的.在線從前往后拉取倒排過程中,如果結果數達到10*topN時,停止拉取倒排.隨后對結果計算文本相關性,再按照文本相關性取topN個.截斷算法上線前后,雖然KPI指標無明顯變化,但是對大結果查詢性能提升了一個數量級.

3. 均勻分片策略

從總體架構圖中我們可以看到,如果我們將一個term的倒排鏈進行均分,那么相應term的拉取倒排也會被分配至各個searcher列.正是由于各個searcher列是并行計算的,這樣的均分操作就可以大大減少每個查詢的平均響應時間.從理論上來講,我們采用的均勻分片策略,也有效的契合了拉取倒排、排序、在線業務處理等CPU密集型的任務.但是分片增加,會帶來硬件成本增高的后果,同時集群節點間的通信成本也會增加,需要進一步權衡折衷.

4. 業務優化

京東的搜索業務并不只有上面所述的策略和工程邏輯,還必須融合很多業務邏輯.由于每一次搜索幾乎都會召回很多結果,如果業務邏輯處理不好,也會導致搜索體驗不好.針對這一問題并沒有通用的解決方法,但是通過實踐我們總結出一個基本原則：在離線階段完成盡可能多的業務邏輯,減少在線計算量!例如進行搜索排序時,我們需要根據用戶搜索歷史行為(瀏覽、點擊、購買等)對召回的結果進行排序上的調整,在工程實現上我們會先離線統計出同一個query下所有用戶對每個展示商品的行為,然后建立模型,計算出該query下每個商品的權重,將其以hash結構存儲；在線排序時,直接以query+商品id為key,取出權重作為反饋特征參與綜合排序.

搜索技術的新發展

我們在當前的架構基礎之上,正在進行一些新的探索,比如場景搜索和圖像搜索.

場景搜索

隨著目前京東集團的業務的擴展,用戶在使用搜索時,目的不僅僅是查找商品,還可能查詢促銷活動信息.為了滿足這些新的需求,我們在目前商品索引融合了促銷系統的數據.我們首先在Query Processor中增加對應意圖的識別,然后將促銷等數據轉換為索引數據.只要Query Processor識別出用戶提出這方便的查詢意圖,將對應的結果返回.

圖像搜索

傳統搜索僅僅針對文字,但是電商系統的商品圖片非常重要,很多購買決策依賴于它.目前我們利用deep learning技術離線訓練圖片特征,并將其做成索引.當用戶使用實拍圖或者網圖來搜索時,采用相同的方式提取特征,然后從索引中召回最相似商品返回給用戶.

文章出處：開濤的博客(訂閱號ID：kaitao-1234567)

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4381.html