作为京东商家不需要读懂搜索规则的数据处理，2019年算法的变革将继续加大力度，毕竟搜索的流量依旧是京东商家主要的流量获取入口，今天的文章着重解密京东搜索技术，帮助商家更好理解。
助教：鹿鸣 | 作者：搜索书生
今天是搜索书生陪伴您的第1124天
目前京东整体搜索引擎是搜索部门推荐部自主研发的商品搜索检索引擎，主要功能室为了亿万级别的海量京东用户提供有效的精准，得到快速的购买体验。主要有电脑端/移动端/微信端/手Q端口的搜索页面、移动列表页、店铺搜索、店铺列表等。虽然这套系统只有短短三四年时间，系统已经能够支持很大的PV过亿的请求回执，并且经过了多次618周年庆和双十一的考验验证。
与大众在日常使用的百度、谷歌等大的搜索引擎（或称为“全文搜索引擎”）相比，京东的商品搜索库引起与前者有很多相同之处，比如“覆盖掉海量数据”、“超高的快速查询”以及“超快速的请求回执响应时间”，同时又是自身显著地业务特点。
搜索结构化的商品数据，需要从商品系统，库存系统，价格系统，促销系统，仓储系统等多个数据库进行抽取相关数据；
通过快速和极其高效的召回率要求，保证每一个状态都可以保证被搜索捡取到商品，（除去系统问题的情况）；
商品库的信息室及时更新，目的是保证京东用户提高最佳的购物体验，——比如不能给用户展示出下柜的商品，或者商品的实时价格超出了用户搜索限定的范围。这就要求我们的搜索引擎要做到和各个系统的信息时刻保持同步，目前每天更新次数过亿；
逻辑性质复杂的商品体系业务，需要存储量的商品属性信息室倒排索引的信息两倍之多；
用户购物的个性化需求，要求系统实现用户标签与商品标签的匹配。
正是由于既要兼顾大搜索引擎的通用需求，同时要契合京东的业务特点，我们将系统架构分为四个部分：1. 爬虫系统、2. 离线信息处理系统、3. 索引系统、4. 搜索服务系统。
为了使各位学者能够很深入了解京东系统商品搜索引擎的架构体系，今天本文就给大家首先介绍了商品的搜索的总体架构体系，然后依次给大家介绍京东的爬虫系统、离线信息处理系统各个系统模块，并且对京东搜索技术的最新研究方向做一些展望的工作，希望对各位学者有很多大收获和帮助。
总体架构
京东商品搜索引擎的整体架构如下图所示：
从上到下共分为3层：
1.京东搜索最上层是有搜索的前端UV层面，负责整体的京东搜索展示页面效果。
2.中间层面是有京东搜索索引服务、SUG搜索、相关搜索、分词服务和兜底部服务组成。其中SUG搜索提供搜索输入框提示功能；相关搜索提供与query相关的其他搜索词服务；划词服务提供去除query部分词的功能；兜底服务用于索引服务异常情况下提供托底，保证用户基本的搜索可用。
3.最下层是索引生产端，主要功能是对接商品、库存、价格、促销、仓储等众多外部系统，整合相关数据生产全量和增量数据的索引，为在线检索服务集群提供全量索引和实时索引数据。
爬虫系统
商品搜索引擎的最核心是建立的商品的检索页，而建立索引需要详细的商品信息数据。我们利用京东整体大数据平台的数据库进行抽取接口的中间件系统，实现了站内京东的商品爬虫系统。用来抽取数据库中间的商品信息和及时发现变化的商品体系信息。从京东搜索实践的效果上来看，爬虫系统表现是非常稳定和可靠的。
离线信息处理系统
京东搜索系统离线信息处理系统主要功能室用来建立京东商品库搜索引擎的等待索引数据，包括全量等待索引数据和增量等待索引数据。
目前京东商品库全量等待索引数据按天进行更新，一部分是商品的基础属性信息，如商品SKU、商品信息名、颜色尺码、风格、材质等，属于比较稳定，短期时间不会有变化的情况下数据。另外一部分是商品的销量信息，比如商品销售量，商品销售额，商品评价等属于很容易变得数据、这些数据散步到多个系统中进行控制，使用的储存方式也各不相同。因此需要对这些来源分散的数据在京东商品维度进行合并。生成“商品全量待索引宽表格”。目前我们系统建立的全量待索引宽表格，不仅应用于搜索引擎服务，还同时应用于京东个性化推荐还有其他产品比如活动搜索产品活动搜索推荐的服务当中。但是仅生成宽表是无法完成京东搜索产品的搜索引擎的索引需求，因此我们利用Hadoop/MapReduce计算框架对宽表京东数据进行清洗，并且依照京东离线系统业务逻辑规则对数据进行二次“加工”，最终生成一份全量待索引数据。
京东有些商品信息，“价格体系”、“库存系统”、“上下架”等，经常会产生一些数据变化，因此京东对这些数据做全量索引满足不了商品搜索引擎的需求。为了解决策数据实时性的强行需求，我们建立了京东增量系统索引，作为全量索引的一个补充。具体系统的细节上，采用和全量索引很类似的方法对京东数据进行处理加工，生成增量待索引数据。为了保证京东增量数据的及时性和准确性质的完善。离线系统信息处理的这套系统会实时调用各商品的属性信息接口获取数据。完成增量待索引的数据支持和在线组装和生产数据值。
索引系统
索引系统是商品搜索引擎的核心，主要功能系统功能是把商品体系为维度进行一次系统储存的待索引检索数据，转化成以关键词为维度进行储存的数据值，用于京东搜索引擎系统上层服务架构进行调用。这里待索引数据指前面的离线信息处理系统生成的全量待索引数据和增量待索引数据。
此系统对于全量更新和增量更新系统处理一致的，唯一的系统区别在于待处理数据量级的差异上。一般正常情况下，全量数据索引由于京东数据量庞大体系，采用Hadoop/MapReduce进行；实时数据量小，采用的单机模式进行索引生产数据。
为了满足分布式检索的需求量，京东索引系统还会对索引的京东数据进行分片进行处理，即可以按照一定的策略方法将索引数据拆分较小的索引片段数据，用于搜索服务系统调用。
搜索服务系统
京东搜索索引服务器系统主要功能室接手京东用户的请求行动并响应，返回搜索结果。搜索服务系统的发展也经历了从无到有，从简单的搜索结果算法到很丰富的算法结果。主要分为以下几个阶段；
最初京东搜服务的系统只有一列searcher组成在线检索服务，能够完成一些简单的商品搜索；
随着京东商城访问量庞大增长，搜索服务系统增加量缓存模块系统，大大加快了请求数据处理的速度响应时间；
京东接下来为了能够提高用户的搜索体验，我们增加了Query Processor服务，负责京东用户查询意图的分析功能。提升搜索的准确性。目前Query Processor已经成为了一个融合自然语言处理、提升搜索的准确性质。目前Query Processor已经成为一个融合自然语言处理系统。机器学习等先进技术的较为成熟服务，并且还在不断的搜索部门进行优化；
为了京东可以支持个性化，我们增加一个系统User Profile服务，发展查询用户标签。将商品的标签和我们的用户标签是否匹配，作为一个特征加入排序的规则因子，实现搜索千人千面的功能；
接着随之京东数据量不断得到增长，我们将结果的包装功能从检索服务中独立出去，成为detail服务（基于缓存云实现的商品信息KV查询服务）；
将检索服务进行分片化处理，即采用类似数据库分库分表的思想，对商品id，进行hash处理后进行分片，保证各个分片数据均匀。查询时，将一个搜索请求分配到多个searcher列上，并行检索，进行局部排序后返回给merger。然后merger服务，将多个分片的检索结果进行归并，然后再进行业务排序和加工，确定要返回的商品，最后调用detail服务包装，将结果返给给blender。blender将多个搜索的结果进行融合，返回给前端。需要说明的是，此时搜索服务系统已经成为了一个“多blender&多Searcher&多merger”的系统。今后无论是访问量的增长或者数据量的增长，都可以通过扩容来满足。尤其对于618店庆、11.11之类的峰值搜索量剧增的情况下，可通过增加每个searcher列服务器的数量来满足需求。随着商品数据的不断增加，只要适时对数据做更多的分片，相应增加searcher列就可以了。检索服务分片化机制的建立也标志着京东搜索基础服务系统已经趋于完备。
完整的搜索索引服务架构，如下图所示：
京东用户通过发送请求道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. 多级缓存策略
a.Blender Page cache：由于京东搜索符合互联网的二八原则，百分之二十热门查询频度非常之高，占用每天的搜索数据请求量百分之八十，针对这一点特点，京东搜索第一级缓存以查询请求为KEY，将返回给用户的页面作为value。对于完成相同的请求，直接从缓冲页面返回结果。页面的缓存策略上线意识，缓冲命中率就接近了30%，基本解决了当时的性能问题。
b.Merge Page cache：随着业务的发展，京东排序结果需要针对不同京东用户个性化订制，导致请求中会包含用户的user pin。如果将user pin放入缓存作为key，会导致blender cache的key数量暴增，不但京东服务器需要超大的缓存空间，同时服务器缓存的命中率也会极低，最终会导致线上京东个性化服务系统的体验满意度降低。为了解决这个系统问题，将user_pin加入key，但是value只保存京东排序好的商品id，这样需要的缓存空间远远小于blender cache。当命中缓存后，调用detail直接进行结果包装。为了进一步提高缓存命中率，利用用户京东搜索的翻页习惯，即离线统计出用户的翻页数TP99，然后在value中缓存这些页面涉及到所有的商品id，从实践效果来看，用户后续的翻页请求大部分会命中cache。
c.在深入分析了业务的京东排序需求之后，我们发现拉取倒排的结果只和“查询词”&筛选条件“，作为KEY的方式对其进行一次缓存。
虽然拉取京东倒排结果缓存的key很快就解决了，但是我们在解决Value的存储时遇到了两个问题：1）拉取倒排的结果非常之多，导致缓存过大；2）对此结果的缓存数据，会降低京东实时索引的时效性性质。
对于问题1），在分析了京东业务之后，对需要缓存的信息进行了大量面积的精简并采用压缩存储，最终将一个查询的缓存控制在0.5M以下，这样京东搜索缓存数据就响应时间很快。 对于问题2），我们将拉取倒排结果数据分为两部分，第一部分是从全量索引拉取倒排结果，第二部分是从实时索引拉取倒排的结果。为了和全量索引的更新频率保持同步，我们把第一部分的京东数据进行缓存的周期置一天。对于第二部分数据，由于是京东增量结果永远少于全量结果（一般增量只有全量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技术离线训练图片的特征情况，并将其做成索引。当用户使用实拍图或者网图来搜索时，采用相同的方法提取特征，然后从索引中召回最相识的商品返回给用户。