阿里巴巴搜索引擎平台Ha3揭秘

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

Ha3的架构

在线

Ha3是搜索体系中的在线部分，在其系统内部，包含Qrs(Query result searcher)和Searcher两种基本的角色。

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、zone、biz

从业务的角度，Ha3包括zone、biz、table的概念

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

** **

Qrs上的查询逻辑相对于Searcher来说比较简单。一次完整的查询分为两个阶段：一阶段与二阶段。一阶段Qrs会向一个完整行的多列Searcher发送请求，从多列Searcher中拿到结果后作合并与排序，而二阶段则是将排序后，前N个文档(这里的N由用户指定)的docid或者primary_key拼到查询串中，送回给Searcher作摘要(Summary)查询，拿到多列摘要(Summary)结果后再做一次结果合并，返回给用户

Searcher

** **

Searcher的在线查询流程步骤较多，主要是以下几个部分:

Seek: 倒排索引的召回、合并与求交等操作

Filter: 对用户指定的条件将倒排召回的结果集再过滤一遍，剔除不满足条件的文档

Rank: 粗排算分，这里的算分过程耗时通常较少，但参与计算的文档量巨大，经过这一步后，得分靠前的文档会被保留，其余都会被删除，具体保留多少文档由用户的配置或查询条件决定，通常与参与Rank的文档有数量级上的差距

Agg: 对结果集的统计，统计的内容依据用户的查询条件决定

Rerank: 精排算分，到这一步，参与算分的文档与Rank过程有数量级上的差距，而计算逻辑较为复杂

ExtraRank: 返回给Qrs前的最终排序

一个典型的业务查询流程

我将用下图说明我们的一个实际业务在查询中与Ha3的交互过程:

搜索入口访问图中的Ha3上游，Ha3上游在请求Ha3前，会根据需要(如用户个性化信息、查询词扩展、类目预测等等)生成Ha3查询串，请求Ha3

Ha3的Searcher部分按文档质量，依次切分成zone1、zone2、zone3，Ha3上游会设定一个预期返回的文档个数阈值，先请求zone1，当zone1召回的文档数不满足阈值时，会继续查询zone2，仍不够时，则会再次查询zone3

第3步完成后，上游会将Ha3召回的文档送到算分集群中用更为复杂的算法模型进行算分，从算分集群拿到结果后，上游会取排名前列的文档，向Ha3的Summary获取这些文档的摘要信息，返回给搜索前端

*离线流程*

离线流程的执行者Build Service，负责将纯文本的商品数据构建成Ha3格式的索引文件。原始的商品数据有两类，一类是存放在hdfs上的全量商品数据，这个定期(一般以天为周期)由业务方产出，另一类为实时增量数据，在商品信息变更后，由业务方即时同步给消息系统swift。为了高效稳定地将全量和增量数据产出给Ha3，Build Service被设计成了由3个角色组成。

Build Service的3个角色

Processor: 对原始文档的文本处理，包括业务逻辑对字段内容的改写与分词

Builder: 将原始文档转化，产出索引格式的数据

Merger: 将Builder产出的索引数据作合并，产出为最终被Searcher加载的索引文件

全量索引的产出

全量流程的输入数据是存放在hdfs上的原始文档。全量索引的build流程包括手动触发与自动触发。手动触发就是由集群的管理者通过运维系统管控页面触发。自动触发则是由运维系统定期扫描zk server上的路径监听新数据产出的信号触发。

hdfs上的数据经过Processor处理后送到swift的中转topic中

Builder从中转Topic中拿到经过Processor处理的文档，生成索引数据后放到hdfs中

Merge从hdfs上拿到生成好的索引数据，Merge成各列Searcher上能够加载的索引文件

Merge过程完成后，运维系统调用dp将其分发到Searcher所在的本地磁盘上

增量索引的产出

增量与全量流程的不同之处在于数据源。与全量数据源为hdfs不同，增量的数据源是由数据产出方每时每刻都在发送的增量消息，这类消息经过swift的原始topic后，再经由Processor处理，之后的流程就和全量索引产出的流程相同了。增量索引会定期地分发到Searcher的磁盘上

实时索引

实时索引的数据源和增量索引一样，是数据产出方发送的swift消息。与增量不同的是，增量是产出数据到hdfs上，通过定期分发供Searcher加载，而实时索引，是通过中转Topic，经由以lib形式存在的Realtime Builder处理后，直接放到Ha3内存中。增量索引的时效性跟配置的生成周期有关，通常是几十分钟，而实时索引的时效性是秒级的。在新的增量索引加载后，Ha3会对实时索引作清理

*插件机制*

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

运维

Ha3的日常运维包括二进制版本更新、配置更新、全量与增量索引更新、扩行扩列、机器调度分配等。这些都是通过简易的web操作，后端子模块相互配合完成的，避免了全手工操作的琐碎而又容易出错的细节。实现运维环节的子模块包含以下几个：

suez_ops:这是线上运维操作的入口，其后台将build service、swift、ha3和离线产出做全流程的对接，配置的更新、回滚、扩行扩列、资源调整等均能在suez_ops的web页面上操作，对于在交互和web上有强定制需求的用户，suez_ops也提供了API，以供进一步开发

suez admin:这是一个承上启下的角色。用户通过suez_ops的操作提交自己的运维需求，ha3 admin拿到更新信息后，将更新目标分解，发给自己管理的Qrs或Searcher worker，具体的变更行为由Qrs或Searcher进程自己完成

carbon: 是内嵌在suez admin中，以lib存在的调度框架，一方面收集下游worker(Qrs/Searcher)的状态，如是死是活、是否已经到达了目标状态，另一方面调度具体的worker来执行

让用户无感知的在线服务更新，是通过灰度(rolling)的方式实现的。在多行部署的前提下，通过用户配置的最小服务比例(minHealthRatio)参数，carbon选择合适的行数进行更新。如果当前机器不够，则会申请新的机器以凑够足够的行数，待这些机器上都成功升级后，再选下一组机器继续升级。至于升级过程中是否停流量，可以在目标中设置是否由carbon停流量，不过在suez中，都是worker自己决定的。对于ha3,除了binary更新、内存不够情况下的forceLoad,都是不停流量升级的