个性化搜索引擎系统架构设计 充电了么

个性化搜索目前发展阶段不是要替换掉传统搜索，而是对传统搜索的一个补充。我们先看下它的架构如图2.2所示：

图2.2 个性化搜索架构图

个性化搜索和个性化推荐是比较类似的，这个架构图包含了各个子系统或模块的协调配合、相互调用关系，从部门的组织架构上来看，目前搜索一般独立成组，有的是在搜索推荐部门里面，实际上比较合理的应该是分配在大数据部门更好一些，因为依托于大数据部门的大数据平台和人工智能优势可以使搜索效果再上一个新的台阶。下面我们从架构图从上到下的来详细的讲一下整个架构流程的细节。

1.搜索数据仓库搭建、数据抽取部分

（1）和搜索相关的Mysql业务数据库每天增量抽取到Hadoop平台，当然第一次的时候需要全量的来做初始化，数据转化工具可以用Sqoop，它可以分布式的批量导入数据到Hadoop的Hive；

（2）和搜索相关的Flume分布式日志收集可以从各个Web服务器实时收集比如搜索用户行为、埋点数据等，可以指定source和sink直接把数据传输到Hadoop平台。

2.大数据平台、搜索数据集市分层设计、处理

在大数据平台建设搜索相关的数据集市，分层设计，和推荐大致相同。

3.离线算法部分

（1）基于Spark平台分布式来创建搜索的索引数据库，后续的增量索引一般靠消息队列的方式异步准实时更新。

（2）Spark从Hadoop加载用户画像以及商品画像的特征数据训练基于分类模型的Rerank二次重排序算法模型，来预测对搜索的候选商品被点击的概率，因为特征工程里加入了和用户个性化的特征工程，所以搜索整体排序呈现个性化的特点。如果想增加个性化的程度，可以适当把搜索的候选集合适当扩大一些。

（3）离线计算的部分结果可以更新到线上Redis缓存里，在线Web服务可以实时从Redis获取推荐结果数据，进行实时推荐。

4.在线Web搜索接口服务

（1）在线Web搜索接口服务，先从Solr/ES搜索集群里面获取和关键词相关的搜索结果作为候选集合，然后从Web项目初始化加载好的Rerank二次重排序模型进行实时点击率预测，对搜索结果进行重排序，截取指定的前面的搜索结果进行展示。这个过程会读取一部分Redis缓存数据。

（2）App客户端、网站可以直接调用在线Web搜索接口服务进行实时展示搜索结果。由于个性化搜索比普通搜索处理更复杂，所以在性能上会有所下载，但整体在可接受的范围内，一般可以单独开个搜索区域进行展示，不替换之前的传统搜索。

从架构中看，一个完整的个性化搜索涉及的技术框架也是非常多，其中个性化的因素也涉及到了用户画像系统，用户画像系统不仅仅可以用在推荐、搜索中，它是一个公司级别的通用系统，运营推广决策都会用到它。和其它部门的系统如何对接，同时适应多种应用场景就需要我们架构设计一个合理的系统，下面我们看下用户画像系统架构。