[[177469]]

京東商品搜索簡介

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

與人們?nèi)粘Ｊ褂玫娜绻雀?、百度等大搜?或稱為“全文搜索”)引擎相比，京東商品搜索引擎與前者有相通之處，比如“覆蓋海量數(shù)據(jù)”、“超高并發(fā)查詢”以及“超快速的請求響應(yīng)時間”，同時又有自身顯著的業(yè)務(wù)特點：

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

正是由于既要兼顧大搜索引擎的通用需求，同時要契合京東的業(yè)務(wù)特點，我們將系統(tǒng)架構(gòu)分為四個部分：1. 爬蟲系統(tǒng)、2. 離線信息處理系統(tǒng)、3. 索引系統(tǒng)、4. 搜索服務(wù)系統(tǒng)。

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

總體架構(gòu)

京東商品搜索引擎的整體架構(gòu)如下圖所示：

從上到下共分為3層。最上層是由搜索的前端UI層，負責(zé)頁面展示。

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

最下層是索引生產(chǎn)端，主要功能是對接商品、庫存、價格、促銷、倉儲等眾多外部系統(tǒng)，整合相關(guān)數(shù)據(jù)生產(chǎn)全量和增量數(shù)據(jù)的索引，為在線檢索服務(wù)集群提供全量索引和實時索引數(shù)據(jù)。

爬蟲系統(tǒng)

商品搜索引擎的核心是建立商品索引，而建立索引需要詳細的商品信息數(shù)據(jù)。我們利用大數(shù)據(jù)平臺的數(shù)據(jù)庫抽取接口和中間件系統(tǒng)，實現(xiàn)了站內(nèi)商品爬蟲系統(tǒng)，用來抽取數(shù)據(jù)庫中的商品信息和及時發(fā)現(xiàn)變化的商品信息。從實踐的效果上來看，爬蟲系統(tǒng)表現(xiàn)是非常穩(wěn)定和可靠的。

離線信息處理系統(tǒng)

離線信息處理系統(tǒng)主要功能是用來建立商品搜索引擎的待索引數(shù)據(jù)，包括全量待索引數(shù)據(jù)和增量待索引數(shù)據(jù)。

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

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

索引系統(tǒng)

索引系統(tǒng)是商品搜索引擎的核心，主要功能是把以商品為維度進行存儲的待索引數(shù)據(jù)，轉(zhuǎn)換成以關(guān)鍵字為維度進行存儲的數(shù)據(jù)，用于搜索引擎上層服務(wù)進行調(diào)用。這里待索引數(shù)據(jù)指前面離線信息處理系統(tǒng)生成的全量待索引數(shù)據(jù)和增量待索引數(shù)據(jù)。

此系統(tǒng)對于全量和增量的處理是一致的，唯一的區(qū)別在于待處理數(shù)據(jù)量的差異。一般情況下，全量數(shù)據(jù)索引由于數(shù)據(jù)量龐大，采用Hadoop/MapReduce進行;實時數(shù)據(jù)量小，采用單機進行索引生產(chǎn)。

為了滿足分布式檢索的需求，索引系統(tǒng)還會對索引數(shù)據(jù)進行分片處理，即按照一定策略將索引數(shù)據(jù)拆分成較小索引片，用于搜索服務(wù)系統(tǒng)調(diào)用。

搜索服務(wù)系統(tǒng)

搜索索引服務(wù)系統(tǒng)主要功能是接受用戶請求并響應(yīng)，返回搜索結(jié)果。搜索服務(wù)系統(tǒng)的發(fā)展也經(jīng)歷了從無到有，從簡單到豐富到過程。主要分為如下幾個階段：

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

完整的搜索索引服務(wù)架構(gòu)，如下圖所示：

搜索請求流程如下：

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

Blender、Merger、Searcher和Detail是整個系統(tǒng)的核心組件，它們之間的調(diào)用關(guān)系由Clustermap管理。各個模塊將自己的服務(wù)注冊到ClusterMap，同時從ClusterMap訂閱其調(diào)用模塊的信息來確定實際調(diào)用關(guān)系。

簡要搜索服務(wù)流程，如下圖所示(搜索服務(wù)系統(tǒng)內(nèi)部處理流程)：

圖中名詞解釋如下：

• Page cache：頁面緩存，blender模塊直接緩存輸出的頁面，merger緩存了多頁商品id;
• Attr cache：屬性緩存，緩存的搜索屬性導(dǎo)航區(qū)的數(shù)據(jù);
• Doc cache：緩存查詢詞從全量索引召回的結(jié)果;
• OP：運營平臺服務(wù)，負責(zé)搜索運營數(shù)據(jù)的服務(wù)化;
• QP：query processor，負責(zé)query意圖識別。

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

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

1. 多級緩存策略

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

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

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

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

2. 截斷策略

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

3. 均勻分片策略

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

4. 業(yè)務(wù)優(yōu)化

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

搜索技術(shù)的新發(fā)展

我們在當前的架構(gòu)基礎(chǔ)之上，正在進行一些新的探索，比如場景搜索和圖像搜索。

場景搜索

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

圖像搜索

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

作者：王春明，現(xiàn)任京東搜索平臺部負責(zé)人，2011年加入京東搜索團隊，期間一直負責(zé)京東搜索引擎研發(fā)工作，主導(dǎo)了多次搜索架構(gòu)升級工作保障其滿足京東發(fā)展需求，擅長搜索引擎、高性能服務(wù)開發(fā)、分布式系統(tǒng)架構(gòu)。

 【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】