本文分享蘑菇街在搜索和推荐方面遇到的坑，以及探索路上的经验总结，从0到1再到100，希望大家能从中有所收获。

搜索架构的现状

蘑菇街搜索当前架构

蘑菇街目前的搜索架构分为在线和离线两部分，在线部分主要负责处理在线的搜索请求，离线部分主要负责处理数据流。

在线请求链接

整个线上请求链路主要分为五个环节：topn->qr->引擎->精排序->传输。

蘑菇街统一引擎系统

下图左边红色框是蘑菇街统一的引擎体系，包括用户个性化存储体系、精细化排名存储、商品引擎、广告引擎等。由于这个形态的维护成本特别高，所以就形成了右边所示的统一内核架构。

这个架构最底层是共享内存分配器，最上层是可以支持不同数据结构的各种引擎，再上一层是索引管理。基于这个架构，不同的引擎可以根据自己的需求创建自己的索引。

与这个架构相关的是蘑菇街的运维平台，它基于虚拟化技术，可以非常快速地支持索引的创建，包括创建之后对整个索引数据的管理。还有一个排序平台，用于提供算法配置变更服务。

搜索架构离线部分的数据流

下图是离线数据流，它的主要职责就是处理数据流，完整的指标数据分为算法数据和业务数据。

算法数据参与排序，整个链路从前端ACM开始，然后落入整个数据仓库，清洗之后在数据平台运行训练脚本，将得到的特征导入特征平台然后同步到线上。

业务数据主要来源是DB，主要存储商品和门店之间的数据。业务变更主要基于bin-log事件监控，变更后进行全量和增量。全量数据每天定时做索引，增量数据会流到MQ然后通过业务组装推送到线上。

搜索架构的演变

蘑菇街搜索架构经历了五个大阶段：

蘑菇街搜索架构现状简图

为了更加清晰直观的对比，下图将目前的搜索架构简化为业务、投放、排序、召回、数据流五个层级。

接下来我们来回顾一下蘑菇街从创立到现在的演变历程。

蘑菇街搜索架构-导购时代架构

下图是2013.11年刚成立时的导购架构，用PHP代码实现三层业务+投放，召回+排序，数据流转用Java搜索引擎Solr。这个时期对排序的需求还不是很迫切，更看重商品整体的丰富度和新颖度。简单来说热销排序等于喜欢乘以10+收藏乘以50，是基于Solr的改造实现的。

电商转型初期（2013.11 ~ 2014.11），流量因为卖自己的产品而变得越来越有价值，工程师会想办法提升流量的效率。同时用户行为也越来越多，产生的数据也越来越多，增量管理也越来越复杂，数据量大，风险高，还有导购、广告、匹配等多种产品类型，最明显的挑战就是排序特征的增多，数据规模的增加，以及频率的提升。

蘑菇街搜索架构-转型初期

面对这些挑战，当时的想法是将算法分离成一个单独的 Java 项目进行计算和评分。但是百万级商品有几百个排名，算法排序达到 G 级，这些排序数据需要快速应用到搜索引擎并生效。问题在于使用增量的方式会导致索引碎片化增加，从而引起线上引擎稳定性的波动。因此，另一种方式是在 Solr 进程中设置堆外内存来管理这部分排序数据。

总结一下改造初期整体的解决方案是将算法分离出来，尽快同步部分分数到引擎上生效，这个方法当时上线的时候效果比较明显，但是随着时间的推移新的问题也出现了：

规则排毒->LTR，很多算法排序要求；

排序灵活性约束：计算出的分数离线推送到Solr；

Solr 内存压力：GC/段合并；

静态点，相关性差；

促销相关性问题：搜索“雨伞”时，带有雨伞图案的连衣裙会出现在顶部。

Solr主搜索整体架构

针对这些新问题，（2015.4~2016.3）Solr主搜索进行了改造，支持Rank插件（->）、可配置+动态，整体架构如下图所示。为了应对相关性问题，增加了新的QR系统，为了应对内存压力，Solr进行了升级（），算法去掉了动态字段增量，投递方式逐渐形成了Topn体系，以对接不同的搜索场景。

Solr 架构解决了相关度、算法变化导致的在线排序等问题，但新的问题是排序方式虽然用了机器学习，但当时主要采用的是大众化的模型，个性化需求模型很多，需要针对不同的人有不同的排序结果，也有重新排序或者拆分等更复杂的需求。

由于Solr的实现机制限制，只能进行一轮排序，更改起来比较困难。另外Solr整个索引结构非常复杂，二次开发成本较高，内存、性能等诸多问题也逐渐暴露出来。同时Java的GC也是一个难以逾越的鸿沟。

当时多轮排序的需求，除了一些文本相关性之外，还需要品牌相对于商品的权重，比如支持某些品牌、拆分类目等，这些都不是一次排序就能完成的，原来的方法只能把多轮合并成一次排序，但效果会很差。

C++ 主搜索架构

下图是上线的C++主搜索架构（2015.8~2016.11），在整体性能和排序方面做了定制化，可以支持多轮排序，全程内存模式，由排序系统支撑。

总体来说，这个阶段还是比较完整的，各个层次、整个体系都比较完整。但是在数据流转环节出现了三个问题：

整个流程没有调度，一切都取决于流程约束；

算法数量的增加使得得分变得没有可比性，这会造成在线排序的一些抖动。

业务数据增加对服务接口压力过大（提升失败）。

完整链接

由于算法序列整条链条依赖时间约定，数据容灾机制薄弱，大促时前置任务延迟无法全部完成，线上内存几乎爆掉，全量延迟频繁发生，需要人工处理；另外算法对排序点有误导，导致线上混乱，增量恢复时间过长。

为了解决这个问题，蘑菇街首先引入了基于的调度系统，驱动整个数据流，并支持错误报警。容灾的思路是增加排序SOS字段，根据定时间隔生成全量快照，快速回滚，修复单一算法字段。

两种算法增量分值不具有可比性，增量分值生效需要较长时间。比如商品在时刻1算出来是90分，在时刻2算出来是60分，就会造成线上排序抖动。这主要是因为算法的两个序列导致数据分布不同。尤其大促期间，不同时段的交易数据变化很快，商品排序的波动就很明显。同一批号增量数据正常，但是两次看到就错了。当大家0点疯狂购物的时候，变化很频繁，就会造成排序乱序。算法数据出错之后，生效时间也会比较慢。

上图的方案是将算法和分数以小全量的方式分别拖到本地在线引擎，在本地引擎中逐个加载，直接进行切换，这样每个算法增量数据生效更快，灾备也加速。

如上图所示，由于所有变更都是Doc级别更新，每次字段更新都会调用所有接口组装一次完整的数据更新，这导致业务增量压力特别大，大促期间增量QPS能达到几千到几万，这给下游40多个接口带来了很大的压力。

如上图所示，解决这个问题的方案是让引擎包括数据流都支持字段更新，只组装变化的字段，不需要组装完整的数据，这需要引擎本身的支持。上线的时候收益非常明显，关键接口的QPS降低了80%以上。

平台化（2017.1~现在）是我们现在在做的事情，我们面临UPS、广告、商品等多个引擎系统合并，广告、搜索等多个交付系统来自不同团队，带来的维护成本问题，排序、计算要求也变得更复杂，尝试非线性模型等挑战，我们有现在的架构，思路就是平台化、统一化，整合重复的系统，统一数据流。

搜索架构经验总结

一路走来，整个搜索架构的探索经验是，发展初期简单快速地支持在线业务，然后逐渐演进，满足算法的需求，最后考虑用整个平台、统一的方式来提高效率、降低成本。

不同阶段需要不同的选择，蘑菇街最早是基于Solr重写的，在团队、人员、技术储备强大之后，直接重写了搜索引擎，覆盖算法的线下线上环节，进行体系化建设。

后续计划是继续深化新架构的整体平台化，加强算法方面的学习，比如深度学习框架的研究和使用、在线学习、图搜索工程体系的构建等。

推荐架构发展概述

蘑菇街的推荐架构已经覆盖了大部分用户行为路径，从进入APP到下单、完成交易。整个推荐架构的发展分为四个阶段：

在开发初期（2013年11月~2015年6月），推荐场景不多，需求比较简单搜索次数多就会生成推荐词吗，只需要离线更新数据即可。当时比较明显的问题是没有专门的推荐系统支持推荐场景，效果追踪不好，场景对接、数据导入效率低。

1.0 版推荐架构

从0到1（2015.6~2016.3）我搭建了一个推荐系统，包括层连接场景，推荐的实时预测，以及自己写的KV系统存储推荐结果。这里有一个坑，就是我是离线做的实时预测，但其实实时预测更多的是一个在线的过程。

随着时间的推移，场景类型（猜你喜欢、搜索类似、店内）和类似场景（首页、购物车、详情页...）不断增多。算法需要实时排序，应对实时点击、加入购物车等，还有一些个性化排序需求，比如门店、类目、线下偏好等。1.0阶段主要面临三大问题：

多类型、多场景：线上系统各异，缺乏统一的对接层，成本较高；

场景配置：场景算法一对一，需要代码重复，维护困难。

个性化+实时性：缺乏系统支持。

2.0时代的架构推荐

2.0时期（2016.3~2016.12）的推荐架构主要解决了1.0的三大问题，增加了投递层，统一对外对接不同的业务场景，做了动态配置和规则模板。在个性化实时方面，增加了UPS和精准分拣系统。

2.0期推荐架构交付层配置

2.0时期推荐架构的投放层配置思路是不变部分模板化，可变部分配置化，系统提供了召回形成、数据补全、格式化等模板。当时效果很明显，321大促时运营地点个性化效果提升20%以上，双11大促时场地楼层个性化效果提升100%以上。

大促带来的巨大利润对整个系统产生了非常积极的影响，但后续的推荐架构面临着更多的需求和挑战：

资源位置、直播、图片等场景和类型不断增加；

与美的的整合，跨团队、跨地域的挑战；

工程算法用了一套代码，整个策略的开发和调试非常复杂，包括工程部分职责不明确的问题；

由于原来的模板化配置，一些简单的场景变得复杂了。

针对这些问题，蘑菇街需要实现通用化、平台化，提供全系统统一的推荐方案，实现整体算法的自动化，对接核心业务流程，明确算法人员的职责分工，提高双方工作效率。

3.0时代的架构推荐

3.0时期（2016.2~现在）的推荐架构和搜索架构类似，系统间功能更加清晰，更加统一化、平台化，主要变革在投放层。

3.0时期推荐架构交付层细节

3.0时代的推荐架构交付层一个重要的概念是场景化，用场景来处理推荐服务，不同的场景对应不同的策略实现。

推荐架构总结

推荐架构在初期和搜索架构一样，需要能够快速支撑推荐业务，不需要花费很大的精力去搭建一个很复杂的系统，在满足了业务和算法的需求之后，就需要通过平台化来提升算法和工程的效率。

后续平台化会继续深化，比如针对算法策略的评估和压测工具，全场景智能监控报警&容灾，在算法支持方面是&强化学习，并根据算法效果设计新的产品。

丁晓明，绰号小宝

蘑菇街搜索技术团队负责人

他于2011年底加入蘑菇街，2013年执掌搜索团队，见证了蘑菇街的蓬勃发展，并与团队从零开始搭建了蘑菇街的搜索及推荐系统，包括自主研发的C++主搜索引擎及广告引擎、实时个性化推荐系统、基于开源Solr/ES深度定制的实时搜索平台等。