京东商品搜索介绍。京东商品搜索引擎是搜索推荐部门自主研发的商品搜索引擎。其主要功能是为海量京东用户提供精准、快捷的购物体验。目前主要入口包括PC/手机/微信/手Q搜索、手机列表页、店铺搜索、店铺列表等。日均PV过亿，通过了众多618店庆和双11的考验。与人们日常使用的大搜索（或“全文搜索”）引擎如谷歌、百度相比，京东.com的商品搜索引擎与前者有相似之处，如“覆盖海量数据”、“超高并发查询”、“超快的请求响应时间”，但也有其显着的业务特征：结构化的商品数据，需要从产品、库存、价格、促销、仓储等多个系统中提取；极高的召回率要求，保证每一件处于正常状态的商品都能被搜索到；商品信息的及时更新是为了保证用户良好的购物体验——例如，无法向用户展示柜内商品，或商品实时价格超出用户搜索限制范围。这就需要我们的搜索引擎时刻与各个系统的信息保持同步，目前每天的更新量已经过亿；对于逻辑复杂的商品业务，需要存储的商品属性信息是倒排索引信息的两倍；用户购物的个性化需求要求系统将用户标签与商品标签进行匹配。正是因为我们需要兼顾大型搜索引擎的普遍需求，同时又契合京东的业务特点，我们将系统架构分为四个部分：1.爬虫系统，2.离线信息处理系统，3.索引系统，4.搜索服务系统。为了让读者深入了解京东商品搜索引擎的结构，本文首先介绍商品搜索的整体结构，然后依次介绍爬虫系统、离线信息处理系统等部分，并期待搜索技术的最新研究方向。希望对所有读者有所帮助。总体架构京东商品搜索引擎的总体架构如下图所示：从上到下分为3层。最上层是搜索的前端UI层，负责页面展示。中间层由搜索索引服务、SUG搜索、相关搜索、文字标记服务和自底向上服务组成。其中，SUG搜索提供了输入框下拉提示词的功能；相关搜索提供与查询相关的其他搜索词服务；基本搜索可用。最底层是指标生产端，主要功能是对接商品、库存、价格、促销、仓储等诸多外部系统，整合相关数据，生产全量和增量数据指标，提供全量、真实-在线搜索服务集群的时间索引数据。爬虫系统商品搜索引擎的核心是建立商品索引，而建立索引需要详细的商品信息数据。我们利用大数据平台的数据库抽取接口和中间件系统实现站内商品爬虫系统，用于抽取数据库中的商品信息，及时发现变化的商品信息。从实际效果来看，爬虫系统的性能非常稳定可靠。离线信息处理系统离线信息处理系统的主要功能是为商品搜索引擎创建待索引数据，包括全量待索引数据和增量待索引数据。目前所有被索引产品的数据都是每日更新的，其中一些是产品的基本属性信息，如产品sku、产品名称、颜色、规格、款式、材质、面料等，相对稳定，短时间内不会发生变化。另一部分是产品销售信息，比如产品销量、销量、评论等，都是可变数据。这些数据分布在多个系统中，使用不同类型的存储。因此，需要在商品维度上将这些分散来源的数据进行合并，生成一个“全商品待索引宽表”。目前，全量待索引宽表不仅用于搜索引擎服务，还用于个性化推荐等其他产品和服务。然而，仅生成宽表不能满足搜索引擎的索引要求。因此，我们采用Hadoop/MapReduce计算框架对宽表数据进行清洗，根据离线业务逻辑规则对数据进行二次“加工”，最终生成一个全量的待索引数据。一些商品信息，如“价格”、“库存”、“上架/下架”等，经常发生变化，因此对这些数据进行全量索引无法满足商品搜索引擎的需求。为了解决对实时数据的强烈需求，我们建立了增量索引作为全量索引的补充。具体细节上，通过类似全量索引的方式对数据进行处理，生成增量数据进行索引。为保证增量数据的及时性和准确性，离线信息处理系统会实时调用商品信息接口获取数据，完成增量数据的在线组装和生产，以供索引。索引系统索引系统是商品搜索引擎的核心。其主要功能是将商品维度存储的待索引数据转换为关键词维度存储的数据，用于调用搜索引擎的上层服务。这里，待索引数据是指离线信息处理系统产生的全量待索引数据和增量待索引数据。本系统对全量和增量的处理是一致的，唯一的区别是处理的数据量不同。由于数据量巨大，一般使用Hadoop/MapReduce进行全量数据索引；实时数据小，单机做指标。为了满足分布式检索的需要，索引系统还对索引数据进行了分片处理，即按照一定的策略将索引数据拆分成更小的索引分片，供搜索服务系统调用使用。搜索服务系统搜索索引服务系统的主要功能是接受用户请求并作出响应，返回搜索结果。搜索服务系统的发展也经历了一个从无到有，从简单到丰富的过程。主要分为以下几个阶段：最初，搜索服务只有一个栏目搜索器，形成在线搜索服务，可以完成一些简单的产品搜索；随着访问量的增加，搜索服务系统增加了缓存模块，大大加快了请求的处理速度；接下来，为了提升用户体验，我们添加了QueryProcessor服务，负责分析用户查询意图，提高搜索准确率。目前，QueryProcessor已经成为融合了自然语言处理、机器学习等先进技术的成熟服务，并且还在不断优化中；为了支持个性化，添加了用户配置文件服务以查询用户标签。将商品标签是否与用户标签匹配作为特征添加到排名因子中，实现千人搜索；然后随着数据量（商品量）的增加，我们将结果打包功能从检索服务中分离出来，成为明细服务（基于缓存云实现的商品信息KV查询服务）；对检索服务进行分片，即采用类似数据库分库分表的思路，对商品id进行哈希处理，然后分片，保证每个分片的数据是统一的。查询时，将一个搜索请求分配给多个搜索器列，并行检索，部分排序后返回给合并器。然后合并服务合并多个分片的搜索结果，然后对业务进行排序处理，确定要返回的产品，最后调用明细服务包将结果返回给blender。Blender将多次搜索的结果进行融合，返回给前端。需要注意的是，此时的搜索服务系统已经变成了一个“multi-blender&multi-Searcher&multi-merger”的系统。未来无论是流量的增长，还是数据量的增长，都可以通过扩容来满足。特别是对于618店庆、11.11等搜索量激增的高峰期，可以通过增加每个搜索者列的服务器数量来满足需求。随着商品数据的不断增加，只要及时将数据分割成更多的碎片，就可以相应地增加searcher栏目。搜索服务碎片化机制的建立，也标志着京东的搜索服务基础体系更加完善。完整的搜索索引服务架构如下图所示：搜索请求流程如下：外部请求通过VIP到达Blender；Blender调用QP，QP调用运营平台，其中运营平台主要负责服务日常运营数据，QP负责分析查询；Blender同时请求Merger和其他垂直搜索服务；Merger调用UserProfile获取用户标签信息；合并将请求发送给每个搜索者；每个搜索者召回产品并将其返回给Merger；Merger合并多个搜索器的结果，确定需要输出的产品，请求Datail打包对应的产品信息；详细包装产品信息返回给Merger；Merger将打包后的产品返回给Blender；Blender将Merger返回的结果与其他垂直搜索结果合并，最后返回给前端。Blender、Merger、Searcher和Detail是整个系统的核心组件，它们之间的调用关系由Clustermap管理。每个模块将自己的服务注册到ClusterMap中，同时从ClusterMap中订阅自己调用模块的信息，以确定实际的调用关系。一个简单的搜索服务流程，如下图所示（搜索服务系统内部处理流程）：图中各名词解释如下：Pagecache：页面缓存，blender模块直接缓存输出页面，以及合并缓存多页产品ID；Attrcache：属性Cache，搜索属性导航区的缓存数据；文档缓存：缓存从全索引中调出的查询词；OP：运营平台服务，负责搜索运营数据的服务化；QP：查询处理器，负责查询意图识别。用户请求发送到blender，首先解析参数。如果它命中blender页面缓存，它将直接返回给用户。如果没有命中，则调用运营平台服务（OP）和QP，传递给Merger。Merge将检查它是否命中Attr缓存。如果命中只是请求属性汇总结果，会直接返回给blender。否则进一步检查合并页面cahce是否命中，如果命中则直接调用detail包返回给blender。如果没有命中，则调用UserProfile获取用户标签，传递给搜索者（限于篇幅，图中只列出了一个搜索者，实际有多个）。Searcher收到请求，判断是否命中doc缓存。如果它命中文档缓存，它会拉取增量结果；如果它没有命中文档缓存，它会提取完整的和增量的结果。然后依次进行排序和在线业务处理，将结果返回给合并。Merger合并多个searcher结果，排序，在线业务处理，最后调用detail打包，最后返回结果给blender，blender合并多个搜索结果返回给用户。作为高并发系统，为了保证高召回率和低响应延迟，我们将整个搜索服务流程的处理全部放在内存中进行计算。多个搜索器并发处理请求，单个搜索器内部使用线程池技术，即所有线程共享倒排索引和商品属性信息，提高内存使用效率；每个查询使用一个独立的线程串行执行，保证多个并发查询的查询线程互不影响。另外，通过合理设置线程池的大小，可以保证系统的CPU资源得到充分利用。经过以上两方面的系统优化，整个搜索服务系统的稳定性、召回率、内存使用率、计算速度等指标都有了很大的提升。但是我们改进系统的步伐并没有停止，因为通过实践，我们发现基于内存和线程池的搜索服务还有几个瓶颈亟待解决，主要包括：拉取、排序、在线业务处理。针对这些问题，我们进行了二次优化，主要有以下措施：1.多级缓存策略BlenderPagecache：由于搜索符合互联网第28条规则，20%的热门查询有很高频，占每日搜索请求的80%%。对于该特性，以查询请求为key查找一级缓存，以返回给用户的页面为value。对于完全相同的请求，结果直接从缓存中返回。页面缓存策略推出时，缓存命中率接近30%，基本解决了当时的性能问题。MergePagecache：随着业务的发展，需要针对不同的用户自定义排序结果，导致请求中包含该用户的用户pin。如果直接将用户pin作为key放入缓存，blender缓存中的key数量会急剧增加。不仅需要很大的缓存空间，而且缓存的命中率也会极低，最终导致在线个性化服务的体验满意度。减少。为了解决这个问题，在key中加入了user_pin，但是value中只保存了排序后的productid，这样需要的缓存空间比blendercache少很多。当命中缓存时，调用detail直接包装结果。为了进一步提高缓存命中率，利用用户的翻页习惯进行搜索，即离线统计用户的翻页次数TP99，然后将这些页面缓存在值中。大多数页面请求都会命中缓存。经过对业务和排序需求的深入分析，我们发现抓取和排序的结果只与“查询词&过滤条件”相关，与用户无关。因此，我们可以使用“querywords&filterconditions”作为key。它被缓存。虽然很快解决了取倒排结果缓存key的问题，但是我们在解决Value的存储时遇到了两个问题：1）拉取大量倒排结果导致缓存过大；2）对于这个Result缓存会降低实时索引的时效性。针对问题1），经过业务分析，将需要缓存的信息进行了极大简化，并采用了压缩存储，最终将一个查询的缓存控制在0.5M以下。对于问题2），我们将取到的倒排结果分成两部分。第一部分是从全量索引中拉取的倒排结果，第二部分是从实时索引中拉取的倒排结果。为了跟上全量索引的更新频率，我们将第一部分数据的缓存周期设置为1天。对于第二部分数据，由于增量结果远小于全量（一般情况下增量结果小于全量的5%），所以每次缓存时都会进行实时计算，这是图3中的doc缓存机制。在实践中，命中doc缓存的响应时间比未命中低1-2个数量级。以后随着增量结果的积累，如果实时取倒排结果成为性能瓶颈，也可以缓存增量索引段。2.截断策略对于一些热门查询，因为有很多结果，比如“男装”和“鞋子”，原来的查询结果有几千万。如果将这些结果一一处理，性能会很差。同时，从用户的角度来看，只有top的查询结果才对用户有意义。通过分析用户翻页次数，可以得到截断保留的topN结果。如何保证截断不影响用户体验？首先，我们为产品建立一个离线模型，即为每个产品计算一个质量评分数据。然后在索引阶段，将所有产品按照质量得分降序排列，保证在倒链中，排在前面的产品的质量得分总是高于排在后面的。在线从前到后的fetching和post过程中，如果结果数达到10*topN，则停止fetch和post。然后计算结果的文本相关性，然后根据文本相关性选择topN。截断算法上线前后，虽然KPI指标没有明显变化，但是对于大结果的查询性能提升了一个数量级。3.统一分片策略从整体架构图中可以看出，如果将一个term的postings链平分，那么对应term的pullpostings也会分配到各个searcher列。正是因为每个搜索器列都是并行计算的，这样的平均操作可以大大减少每个查询的平均响应时间。从理论上讲，我们采用的统一分片策略也能有效适配抓取、排序、在线业务处理等CPU密集型任务。但是，分片的增加会导致更高的硬件成本，同时集群节点之间的通信成本也会增加，这就需要进一步的权衡。4、业务优化京东的搜索业务不仅有上述的策略和工程逻辑，还需要整合很多业务逻辑。由于几乎每次搜索都会召回很多结果，如果业务逻辑处理不当，也会导致搜索体验不佳。这个问题没有通用的解决方案，但是通过实践，我们总结出一个基本原则：尽可能在离线阶段完成业务逻辑，减少在线的计算量！例如，在进行搜索排序时，我们需要根据用户搜索历史行为（浏览、点击、购买等）调整召回结果的排序。在工程实现上，我们会先对每一个展示的商品，离线统计所有用户在同一个query下的行为，然后建立一个模型来计算query。下载每个产品的重量并存储在哈希结构中；在线排序时，直接使用query+productid作为key，取出权重作为反馈特征参与综合排序。搜索技术的新进展在现有架构的基础上，我们正在进行一些新的探索，如场景搜索、图片搜索等。场景搜索随着京东集团目前业务的扩张，用户在使用搜索时，目的不仅仅是为了寻找商品，更多的是查询促销活动。为了满足这些新的需求，我们在当前的商品指数中整合了推广系统的数据。我们先在QueryProcessor中增加对应intent的识别，然后将promotions等数据转化为index数据。QueryProcessor只要识别出用户方便的查询意图，就会返回相应的结果。图片搜索传统搜索仅针对文本，但电子商务系统中的产品图片非常重要，许多购买决策都依赖于它。目前，我们利用深度学习技术，对图像特征进行离线训练，并做成索引。当用户使用实拍或在线图片进行搜索时，以同样的方式提取特征，然后从索引中调出最相似的商品返回给用户。作者：王春明，现任京东搜索平台部负责人，2011年加入京东搜索团队，期间一直负责京东搜索引擎研发工作。他领导了多次搜索架构升级，以确保其满足京东的发展需求。擅长搜索引擎和高性能服务开发，分布式系统架构。【本文来自专栏作者张凯涛微信公众号（凯涛博客），公众号id：kaitao-1234567】
