京东亿级商品搜索核心技术解密

《京东亿级商品搜索核心技术解密》要点：
本文介绍了京东亿级商品搜索核心技术解密，希望对您有用。如果有疑问，可以联系我们。

作者：王春明,现任京东搜索平台部负责人,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列就可以了.检索服务分片化机制的建立也标志着京东搜索基础服务系统已经趋于完备.

完整的搜索索引服务架构,如下图所示：

（编辑：ASP站长网）