您的位置:首页 > 财经 > 能源 > Ha3搜索引擎简介

Ha3搜索引擎简介

2018-10-06 来源:云栖社区  浏览:    关键词:索引,增量模型,hdfs

Ha3是阿里巴巴搜索团队开发的搜索引擎平台,它为阿里集团包括淘宝、天猫在内的核心业务提供搜索服务支持。

Qrs用于接收用户查询,将用户查询分发给Searcher,收集Searcher返回的结果作整合,最终返回给用户,这里的用户既指直接通过http请求查询引擎的自然人,也指Ha3的上游服务,如sp(搜索链路的Ha3上游服务)和tpp(推荐链路的Ha3上游服务)。

Searcher是搜索查询的执行者,倒排索引召回、统计、条件过滤、文档打分及排序及摘要生成的过程都是在Searcher上完成的。

根据业务的需要,有时也会把摘要(Summary)单独分出来,搭建一套独立的摘要集群。

在实际的部署中,Qrs和Searcher都是采用多行部署的方式,可以根据业务的流量变化作调整。

Searcher还可以根据业务的数据量调整列数,解决单机内存或磁盘放不下所有数据的问题。

Qrs和Searcher都可以通过运维系统挂载到发现服务上,这里提到的发现服务通常是cm2和vipserver。

结合gig 这个搜索团队开发的RPC lib,对Qrs和Searcher的访问均可以做到自动的流量均衡及坏节点检测降级,达到业务上的平稳运行。

我们把索引数据的生成过程称作离线过程。

Ha3的索引是通过搜索团队开发的Build Service系统生成的。

Build Service首先是一个独立的服务,通过运维系统对数据源产出的信号监控,这个独立服务产出全量和增量索引到hdfs上,通过dp分发给Ha3的Searcher。

全量索引的产出周期通常是一天或数天,增量索引的周期通常是几十分钟。

Build Service也以lib的方式存在于Ha3当中,用于实时处理增量消息,直接将索引生成到Ha3 Searcher的内存当中,这样,Ha3的查询结果对数据时效性的保证能做到秒级。

但这种方式也比较耗内存,随着实时消息的到来作线性增长,因此每次加载增量索引时,Ha3都会清理实时索引的内存。

table是数据表,Ha3中一个zone必须包括一张主表(item_table),有时也会包括辅表,辅表在数量上没有限制。

辅表数据是对主表的补充,在线查询时Searcher通过配置中指定的字段,将主表和辅表的结果连接(join)到一起返回给用户。

在某些业务场景下,对主表中的文档,又会有进一步划分的需要,于是这里面还存在一个子文档(subdoc)的概念,供一些特殊业务使用,子文档在本文先不展开说明业务配置(biz)描述了前文提到的Qrs及Searcher上的统计、算分、排序、摘要等多个环节。

单集群多biz,可以满足例如ABTest的需要zone是用于将多个biz与多个table作业务上的划分而存在的概念,它和biz、table的关系均是一对多。

查询时,用户需要填入zone的名称和zone下的biz名称,来指定执行对应zone下的业务逻辑,zone是必须要指定的,而biz在用户没指定的情况下,使用默认(default)的业务配置在线流程中,用户访问Ha3的方式是向多行部署的其中一个Qrs发送请求,而Qrs的选择是通过发现服务配合流量均衡策略实现的。

一个完整的请求会包含查询关键词,并且会包含描述了统计、过滤、排序的行为参数。

Qrs会再次通过发现服务结合流量均衡策略,选择具体的一列或多列Searcher机器,将用户查询分发下去。

Searcher上执行索引查找、过滤、统计,这些流程的具体行为与相关参数在查询和配置中均会有涉及。

Qrs上的查询逻辑相对于Searcher来说比较简单。

一次完整的查询分为两个阶段:一阶段与二阶段。

一阶段Qrs会向一个完整行的多列Searcher发送请求,从多列Searcher中拿到结果后作合并与排序,而二阶段则是将排序后,前N个文档(这里的N由用户指定)的docid或者primary_key拼到查询串中,送回给Searcher作摘要(Summary)查询,拿到多列摘要(Summary)结果后再做一次结果合并,返回给用户Searcher的在线查询流程步骤较多,主要是以下几个部分:Seek: 倒排索引的召回、合并与求交等操作Filter: 对用户指定的条件将倒排召回的结果集再过滤一遍,剔除不满足条件的文档Rank: 粗排算分,这里的算分过程耗时通常较少,但参与计算的文档量巨大,经过这一步后,得分靠前的文档会被保留,其余都会被删除,具体保留多少文档由用户的配置或查询条件决定,通常与参与Rank的文档有数量级上的差距Agg: 对结果集的统计,统计的内容依据用户的查询条件决定Rerank: 精排算分,到这一步,参与算分的文档与Rank过程有数量级上的差距,而计算逻辑较为复杂ExtraRank: 返回给Qrs前的最终排序一个典型的业务查询流程我将用下图说明我们的一个实际业务在查询中与Ha3的交互过程:搜索入口访问图中的Ha3上游,Ha3上游在请求Ha3前,会根据需要(如用户个性化信息、查询词扩展、类目预测等等)生成Ha3查询串,请求Ha3Ha3的Searcher部分按文档质量,依次切分成zone1、zone2、zone3,Ha3上游会设定一个预期返回的文档个数阈值,先请求zone1,当zone1召回的文档数不满足阈值时,会继续查询zone2,仍不够时,则会再次查询zone3第3步完成后,上游会将Ha3召回的文档送到算分集群中用更为复杂的算法模型进行算分,从算分集群拿到结果后,上游会取排名前列的文档,向Ha3的Summary获取这些文档的摘要信息,返回给搜索前端离线流程的执行者Build Service,负责将纯文本的商品数据构建成Ha3格式的索引文件。

原始的商品数据有两类,一类是存放在hdfs上的全量商品数据,这个定期(一般以天为周期)由业务方产出,另一类为实时增量数据,在商品信息变更后,由业务方即时同步给消息系统swift。

为了高效稳定地将全量和增量数据产出给Ha3,Build Service被设计成了由3个角色组成。

Processor: 对原始文档的文本处理,包括业务逻辑对字段内容的改写与分词Builder: 将原始文档转化,产出索引格式的数据Merger: 将Builder产出的索引数据作合并,产出为最终被Searcher加载的索引文件全量流程的输入数据是存放在hdfs上的原始文档。

全量索引的build流程包括手动触发与自动触发。

手动触发就是由集群的管理者通过运维系统管控页面触发。

自动触发则是由运维系统定期扫描zk server上的路径监听新数据产出的信号触发。

Merge从hdfs上拿到生成好的索引数据,Merge成各列Searcher上能够加载的索引文件Merge过程完成后,运维系统调用dp将其分发到Searcher所在的本地磁盘上增量与全量流程的不同之处在于数据源。

与全量数据源为hdfs不同,增量的数据源是由数据产出方每时每刻都在发送的增量消息,这类消息经过swift的原始topic后,再经由Processor处理,之后的流程就和全量索引产出的流程相同了。

增量索引会定期地分发到Searcher的磁盘上实时索引的数据源和增量索引一样,是数据产出方发送的swift消息。

与增量不同的是,增量是产出数据到hdfs上,通过定期分发供Searcher加载,而实时索引,是通过中转Topic,经由以lib形式存在的Realtime Builder处理后,直接放到Ha3内存中。

增量索引的时效性跟配置的生成周期有关,通常是几十分钟,而实时索引的时效性是秒级的。

在新的增量索引加载后,Ha3会对实时索引作清理为了实现业务的可定制化,Ha3提供了插件机制。

在前文介绍的离线和在线流程的各个环节中,Ha3用户可以通过开发自己的插件,对原始文档、查询Query、召回、算分、排序、摘要做业务上所期望的修改。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:service@qeerd.com,投稿邮箱:tougao@qeerd.com