异构数据半小时实现搜索功能，一个系统搞定

配景

对付闲鱼这种处于高速增恒久的部分来说，营业场景在快速膨胀，越来越多的营业数据对搜刮手段有诉求。假如凭证通例的方法为各个营业搭建独立搜刮引擎处事，那么开拓和维护的时刻本钱将长短常庞大的。可否只用一套搜刮引擎体系支撑差异营业场景产出的数据呢?差异场景的异构数据如安在一套引擎中兼容呢?闲鱼从现实的营业需求出发，搭建了一套通用搜刮体系办理这个题目。

搜刮道理简述

闲鱼行使的搜刮引擎是阿里巴巴的HA3引擎，共同其上层的管控体系Tisplus2行使。可以拆分为以下几个子体系：

1、dump：接入搜刮体系起主要做的就是把DB数据颠末一些营业逻辑转换后(后头会具体描写的merge、join流程)，凭证引擎BuildService可以或许识此外文件名目写入到文件体系可能动静行列中供BS构建索引行使，这个进程分为全量与增量两种。

2、BuildService(简称BS)：将dump产出的数据构建成索引文件。Searcher呆板加载了BS产出的索引文件后才气提供倒排、正排、summary的查询处事。

3、搜刮营业网关：营业层封装同一处事接口，对营业接入方屏障搜刮体系底层细节。

4、Search Planner(简称SP)：组合搜刮中台多种手段，挪用算法处事对网关传入的查询串举办改写、类目猜测、算分，实现多路召回、分层查询、翻页去重等成果，对QRS返回的功效举办包装返回。

5、引擎在线处事：分为QRS与Searcher两种脚色。SP的查询哀求发送给QRS，QRS将哀求转发到多台searcher呆板上然后网络searcher返回的功效举办归并、算分、排序、返回。

整个搜刮体系的简化版布局图如下：

为每个营业场景从新搭建一套搜刮体系是有必然伟大度的，并且必要耗费较多时刻。我们但愿提供一套通用搜刮体系，当新的营业数据接入搜刮手段时，不必要营业开拓同窗能干搜刮体系道理，只要在我们的体系中注册哪些数据必要被搜刮，就可以完成搜刮手段的自主接入，险些无需开拓，真正实现异常钟快速接入搜刮。多个营业的数据共存在一套搜刮引擎处事中，各营业数据彼此断绝互不影响。

这里涉及到两个题目：

①怎样把异构数据从差异的营业db写入统一个引擎构建索引，且写入进程完全自动化、透明化，无需营业接入方参加开拓;

②怎样实现差异营业场景的开拓同窗在行使搜刮召回的进程中不感知到其他营业数据的存在，就像在行使一套为他的营业单独搭建的引擎处事一样利便。

我们的解法

针对上面碰着的2个题目，我们的办理思绪是提前构建一套通用搜刮体系，把dump、bs、search、Search Planner、网关层的根基手段都提前实现，营业在挪用处事时通过设定可选的入参来选择本身必要的手段(好比要害词改写、类目猜测、pvlog打印、分层召回等)。通过一此中间层把dump流程自动化，并对dump、search进程举办字段翻译、功效包装。

搜刮引擎根基处事的搭建进程与通例方法无大的差别，这里不具体描写。接下来我具体先容一下此方案实验进程中拆分出的4个技能要点：①通用搜刮预留表;②元数据注册中心;③两层dump;④在线查询处事。

1、通用搜刮预留表

通例环境下，我们会把dump产出的大宽表字段定名为itemId、title、price、userId等具有明晰语义的字段名。可是假如要实现多场景共用一套引擎就不能这么做了，由于并不是全部场景数据都有itemId、title、price字段，也也许某个场景中必要接入color字段可是我们的引擎中没有界嗣魅这个字段，导致无法支持这个营业场景。

既然题目的要害是字段界说有语义，那么我们办理这个题目的思绪就是让已引擎中的全部字段都完全无语义，只有范例信息。我们凭证下图的方法预界说2个维度，每个维度下各2张Mysql表和2张ODPS表(这种界说已经可以包围绝大大都场景了)，称为通用搜刮预留表。

为每张预留表预留各类范例的字段，凭证所处维度、表在维度内位置、字段范例举办字段定名：

1)将第一个维度中第一张预留表表的字段定名为dima_pk、dima_a_int_r1、dima_a_text_multilevel_r1、dima_dimb_joinkey等;

2)将第一个维度中第二张预留表表定名为dima_b_inner_mergekey、dima_b_int_r1、dima_b_int_r2、dima_b_long_r1等;

3)将第二个维度中第一张预留表表字段定名为dimb_pk、dimb_a_int_r1等;

4)将第二个维度中第二张预留表表定名为dimb_b_inner_mergekey、dimb_b_int_r1、dimb_b_long_r1等;

然后将预留表凭证上图的布局，与引擎原生的dump体系举办对接，并设置索引构建信息。当这套引擎处事搭建完成后，假如直接往通用搜刮预留表中接入几条数据，就已经可以从引擎在线查询接口中查到数据了。不外这套搜刮体系对营业开拓同窗来说是不行用的，由于营业源表功效与我们的预留表布局完全差异，营业同窗很难把数据从源表凭证我们预界说的名目所有迁徙到通用搜刮预留表，且查询时用“dima_a_text_multilevel_r1='iPhone6S'”这种无语义的方法做查询也是营业同窗无法接管的。接下来我们就来办理这些题目。

2、元数据注册中心

我们计划了一个元数据注册中心，当一个新营业必要接入搜刮手段时，只必要在注册中心填写营业相存眷册信息(包罗营业场景标签，必要接入搜刮手段的数据库、表名、字段等根基信息)，体系会分派一个营业独一辨认码，这个辨认码会作为dump、bs、查询流程中实现多营业断绝的最重要标识。

元数据注册表布局：

元数据注册中心以WEB界面情势提供新营业注册的手段，用户在填写营业的库名，会通过中间件自动拉取到包括的全部表名。用户从中选择本身必要接入的表名，界面上列出此表下的所有字段，以及体系预设的所有通用搜刮预留表字段。用户在源表字段与预留表字段之间用鼠标成立连线，完成后点击提交，体系将对用户成立的映射相关举办各项正当性搜查，搜查通事后凭证上面的元数据注册表布局写入DB。这份注册数据往后将在dump、查询等多个环节用到。

3、两层dump

每一张营业源表的语义一样平常较量单一，多张表组合在一路才气够形成一个营业场景的全貌。好比：

1)商品根基信息表中会存储商品id、问题、描写、图片、卖家id等信息;

2)商品扩展信息表中会以商品id为主键，存储商品扩展信息，如sku信息、扩展标签信息等;

3)卖家根基信息表中会以用户id为主键，存储用户的昵称、头像等根基信息;

4)卖家书用信息表中会以用户id为主键，存储用户的芝麻名誉品级。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!