本次主题主要介绍到家app搜索系统。在看下文之前，可以内心思考下，自己对搜索系统在技术方面的了解有哪些， 如果自己去实现一个搜索系统会如何设计。之后可以根据介绍的下文的搜索系统对比下与你心里的方案是否一致呢。

•降低用户了解成本。新用户如果到app中，如果没有搜索，那么他就需要了解app如何寻找到他想要的服务，这个是需要成本的，那么会无形中劝退不少新用户。•缩短用户下单距离。用户从主页到下单页，中间经过的页面越多，用户流失率越高，下单率越低。

做任何事情之前，需要了解要求是如何，那么搜索要求是什么，主要是以下4点：

•大量数据检索。搜索肯定是需要在能提供给用户的服务数据里进行检索，这个数据量就看服务数据的规模，一般数据量都会比较多。

•支持文本检索。这个肯定是基础，搜索都是通过文本进行搜索服务，所以文件检索的形式需要比较丰富，比如搜索加空调氟或者加氟再或者加氟空调，我们都需要给他展示空调加氟相关的服务。多字段索引，这个就是基于搜索不仅仅是单纯通过文本检索，他还包含其他方面综合检索，比如城市，经纬度，服务类型，渠道等等条件，这些字段都需要进行索引处理。

•多字段索引。这个就是基于搜索不仅仅是单纯通过文本检索，还包含其他方面综合检索，比如城市，经纬度，服务类型，渠道等等条件，这些字段都需要进行索引处理。

•快速响应。就是不能让用户输入搜索词后，迟迟展示不出结果，响应越快，用户体验肯定更好，所以需要系统响应效率要高。

常见的关系型数据库是否能实现上面的搜索的要求，以现在常见的MYSQL举例：

•大数据量检索，mysql是可以支持的，数据过大可以做分库分表，但是搜索这个大数据量还有个要求，就是搜索内容一般是非结构数据，为什么呢？因为不同服务会存在一致或者不一致的属性字段，当然mysql也允许字段为空或者有默认值，所以也可以强制改成结构化的数据。所以大数据量检索这一点是MYSQL也能算是符合要求的。

•文本检索，相信大多数人想到的是SQL like，但是这个检索第一 文件检索形式过于简单，而且还存在不能执行索引的情况。所以这个一点就不支持了。

•多字段索引，mysql是支持创建联合索引的，所以貌似是支持这点要求的，但是需要穷举各种可能联合查询条件，而且联合索引过多也会影响mysql的写入性能，所以这点就不怎么友好支持这种要求。

•快速响应，如果要让mysql支持上面三点，估计就不能快速响应了。

根据上面可以得出结论常见关系型数据就不符合搜索要求了。

那么什么数据存储模式最合适呢？目前现在最常见的java的搜索引擎是Elasticsearch、Solr、Lucene，其中Elasticsearch和solr都是基于Lucene的，lucene有什么优势呢，就是在于它完美的支持了搜索几个要求：

1.非结构化的存储。2.基于文本匹配规则丰富。3.多字段匹配性能高。

我们知道它能支持这些特性，但是为什么它如此优秀？主要在于索引方式：倒排索引

索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值，而是由属性值来确定记录的位置，因而称为倒排索引。

docid年龄性别122男222女318男

这里一行就代表一个文档。每个文档都对应一个文档Id(docid)。那么给这些文档建立的倒排索引就是

年龄

年龄docid列表221,2183

性别

性别docid列表男1,3女2

可以看到，一个字段有一个自己的倒排索引，分成了字典和索引列表。但是这样跟mysql的辅助索引是不是类似？luence是如何设计呢？

图1

lucene 增加了一个term index进行先一步检索，可理解成前缀检索，lucence目前是通过使用Finite State Transducers 简写是FST，这是一种压缩存储和查询方式，索引的整体查询逻辑就是通过匹配term index 获取前缀相同的term Dictionary在具体哪个offset位置，之后通过类似二分法去查找对应的索引列表。现在大家应该大体知道lucene的倒排索引主要的处理逻辑。

上面介绍是搜索引擎的索引流程，接下来就是考虑如何进行搜索。

举个例子，例如：搜索 “北京” 相关的数据有几十万个数据，需要都展示给用户吗？

首先考虑用户的需求，因为正常用户不会看几十万数据，其次系统性能也是一方面难点，因为搜索出数据后，肯定需要对数据进行处理，一次性处理几十万数据，性能可想而知；

其次就是搜索是否还有其他的要求，比如对特定的服务进行处理或者增加一些推荐相关的服务等等。

这些就是常见的搜索需要考虑的问题，那么搜索流程应该是怎么去做的呢？

需要了解几点：一般用户翻页最多深度大约在20页左右，所以按照这个页数，一般会将相关度最高的top 几百的服务筛选出来。这就是搜索内容最原始的数据集合。

正常搜索会有各种排序，例如 距离，好评、销量等等，这些都是用户关心的,那么对于这就需要对原始数据集合进行排序，这样的结果就是搜索大体展示结果。

但是搜索还有一个关键作用就是提高或降低对服务的曝光率，所以会有推荐服务等对搜索列表进行比较特殊化的处理。

所以总结出以下几点：

1.筛选top n 相关性高的服务列表2.对指定排序规则进行排序3.对特殊处理的服务放到列表指定位置

根据刚才总结的几点，来看下常见搜索的大体流程是怎样做？

图2

主要分为几个步骤：

•筛选：根据搜索词去匹配top n的服务列表。•粗排：对列表进行大体排序，例如好评等排序，如果只是单纯想按照相关度排序，筛选阶段一般已满足需求。•精排：在粗排的基础上进行微调或者增删等操作，主要是满足业务上特殊需求进行顺序处理，例如就是对特殊处理的服务放到列表指定位置。

这就是常见的搜索流程，可以举个例子，一个外卖的场景，搜索是按照距离进行排序，当然也有其他要求，为了满足单量平均，需要将一定时间内获取订单的商家进行降权处理。如果用户搜索水饺，按照左右常见的流程改怎么做呢？大家可以心里想下，改怎么处理呢？

还是那三个维度：

•筛选：就是根据搜索词水饺去匹配相关度高的数据列表，比如top 500等。•粗排：就是对列表进行距离排序。•精排：通过获取时间段内商家的单量进行相应的降序。

返回搜索结果。

一个比较常见的搜索场景的搜索流程就实现了。

到家搜索一期-称为列表时代，为什么呢？因为它跟其他app的搜索类似，也是通过用户搜索词展示服务列表，所以称为列表时代。

要搭建搜索肯定需要搜索的要求去搭建。要求是什么呢？搜索要求：

基本

•内容匹配。•支持多种排序（好评等）。

特殊要求

•运营指定相关服务进行置顶。•出售指定推广位置。•商家维度的惩罚奖励机制。

我们可以考虑下按照正常搜索流程考虑下怎么做呢？

1.筛选--就是常见的相关性内容匹配基本满足内容匹配的要求。2.粗排--通过对应字段进行排序例如好评等3.精排--对于商家维度的惩罚奖励机制方面可以进行精排处理。

但是对于推广位置和指定服务列表置顶这个怎么筛选展示呢？

因为肯定是需要跟推广或者指定服务相关的搜索词才能置顶或者展示，那么怎么去界定用户搜索词和这两者是否有关系呢？我们处理方案是通过词库去做中间的媒介。

词库的构成一般是：词 对应 某业务。

搜索要求：

•优先匹配自营、直约。•提供联想词策略。•搜索无结果时，推荐可能相关服务。

这个要求就有区别常见搜索要求：

1.如何才能优先匹配自营、直约？2.联想词的数据需要从哪来才能作为联想词呢？3.既然都无结果，如何推荐可能相关服务呢？

这三个疑问就是二期当时需要考虑的点，而最后我们处理方案跟一期当时启发一样，第一点和第二点通过词库进行处理的，那么具体要怎么做呢？

图3

我们通过运营人员多个词库 配置了自营/三方词库、资源位词库、直约词库、以及搜索热词配置，而就是通过众多这些词库做一个聚合形成一个联想词的词库,这样我们就实现刚才第一点 和 第二点的要求，但是还有一点要求没有实现。

那就是搜索无结果时，推荐可能相关服务怎么做呢？我们可以考虑下，为什么无结果呢？1.相关度要求太高 2.服务范围内没有与用户搜索词相关的服务。

既然知道是这2点原因，我们可以分析，能否降低相关度要求，这个一般是不会的同意的。

那就第二点，是否可以放开服务范围，查询全国匹配的服务，推荐这些服务的对应的服务项呢？这个方案是可行的。

于是第三点就有处理方案：放开服务范围检索对应服务项进行推荐。那么整体流程就是如下：

图4

可以看到用户搜索首先先匹配词库，如果符合自营、直约数据优先展示，当筛选数据无结果，通过检索全国范围维度获取对应服务项或者对应的服务列表进行推荐，其他的就是正常的搜索流程了。

搜索要求：

1.基本上词库都是运营人工配置，既有成本，也会出现人工配错的概率，所以需要降低运营配置成本和错误概率。2.用户搜索词覆盖范围广，许许多多可能跟服务相关的词都会出现，所以需要降低用户搜索无结果出现的概率。

降低人工成本和错误概率，那么就是系统化、自动化实现搜索词库扩容是最合适的，该怎么做呢？

实现系统化、自动化首先要明确运营配置的词库给谁用？当然是给用户使用，那么用户反馈是才是最有效的。可以通过收集用户搜索数据和行为流程来确定哪些词属于哪些服务项吗，是不是就解决了这个问题？接下来通过埋点数据清洗进行尝试

图5

从这个流程可以知道我们可以通过这种方式，让用户的行为作为搜索词库系统性、自动性去完善和填充词库，也是实现了第一点的要求：降低运营配置成本和错误概率。

同时这个词库也在不断降低无结果率，为什么呢？因为它将我们做无服务推荐的核心实现了，就是通过搜索词去获取服务项信息，所以整体的搜索三期流程如下

图6

那么目前到家APP搜索的大体流程就讲完了。目前我们看到的到家APP的流程大体就是这样的流程。

主要是这个三个点：

1.持续提高准确率，是因为到家覆盖的服务品类比较多，每个品类都有自己一套专属词语，而这些词语单纯靠人工补充不现实，所以需要系统持续补充词库。2.扩充商品库，目前商品库只是包含了平台的商品信息，但是前一段时间双硕阿姨的消息，发现好多通过她的数据进行搜索，但是因为搜索库里没包含阿姨信息，导致无结果。所以需要增加搜索的覆盖场景，增加阿姨等信息到商品库中。3.搜索词解析优化，由于目前搜索词解析略显简单，没有考虑词性等方面，而且会出现答非所问事件，例如搜索花，出现花圈相关的服务，所以需要引入词性相关的组件作为解析词的一部分，尽量避免这种场景。

作者:王逸

来源-微信公众号:天鹅到家技术团队

出处:https://mp.weixin.qq.com/s/rsQJKM4x3PvlNHjvWSgO4w