[[177469]]

京東商品搜索簡(jiǎn)介

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

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

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

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

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

總體架構(gòu)

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

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

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

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

爬蟲系統(tǒng)

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

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

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

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

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

索引系統(tǒng)

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

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

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

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

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

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

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

搜索請(qǐng)求流程如下：

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

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

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

圖中名詞解釋如下：

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

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

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

1. 多級(jí)緩存策略

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

雖然拉取倒排結(jié)果緩存的key很快就解決了，但是我們?cè)诮鉀QValue的存儲(chǔ)時(shí)遇到了兩個(gè)問(wèn)題：1)拉取倒排的結(jié)果非常之多，導(dǎo)致緩存過(guò)大;2)對(duì)此結(jié)果緩存，會(huì)降低實(shí)時(shí)索引的時(shí)效性。

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

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

2. 截?cái)嗖呗?/strong>