-
Ha3是阿里巴巴搜索团队开发的搜索引擎平台,它为阿里集团包括淘宝、天猫在内的核心业务提供搜索服务支持。
Ha3的架构
![](https://i-blog.csdnimg.cn/blog_migrate/2cdd4b8ef93b70e7fe0cf1fd8a35d508.png)
在线
-
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的访问均可以做到自动的流量均衡及坏节点检测降级,达到业务上的平稳运行。
![](https://i-blog.csdnimg.cn/blog_migrate/c5612278749e1d707e38c77fa1e127de.png)
离线
-
我们把索引数据的生成过程称作离线过程。Ha3的索引是通过搜索团队开发的Build Service系统生成的。
-
Build Service首先是一个独立的服务,通过运维系统对数据源产出的信号监控,这个独立服务产出全量和增量索引到hdfs上,通过dp分发给Ha3的Searcher。全量索引的产出周期通常是一天或数天,增量索引的周期通常是几十分钟。
-
Build Service也以lib的方式存在于Ha3当中,用于实时处理增量消息,直接将索引生成到Ha3 Searcher的内存当中,这样,Ha3的查询结果对数据时效性的保证能做到秒级。但这种方式也比较耗内存,随着实时消息的到来作线性增长,因此每次加载增量索引时,Ha3都会清理实时索引的内存。
table、zone、biz
-
从业务的角度,Ha3包括zone、biz、table的概念
![](https://i-blog.csdnimg.cn/blog_migrate/75e3126c3b1ee10530874b7b1e7e14df.png)
-
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)结果后再做一次结果合并,返回给用户
![](https://i-blog.csdnimg.cn/blog_migrate/cf8c5b59d3d4fa86a5b1e90806f808df.png)
Searcher
-
Searcher的在线查询流程步骤较多,主要是以下几个部分:
-
Seek: 倒排索引的召回、合并与求交等操作
-
Filter: 对用户指定的条件将倒排召回的结果集再过滤一遍,剔除不满足条件的文档
-
Rank: 粗排算分,这里的算分过程耗时通常较少,但参与计算的文档量巨大,经过这一步后,得分靠前的文档会被保留,其余都会被删除,具体保留多少文档由用户的配置或查询条件决定,通常与参与Rank的文档有数量级上的差距
-
Agg: 对结果集的统计,统计的内容依据用户的查询条件决定
-
Rerank: 精排算分,到这一步,参与算分的文档与Rank过程有数量级上的差距,而计算逻辑较为复杂
-
ExtraRank: 返回给Qrs前的最终排序
-
一个典型的业务查询流程
我将用下图说明我们的一个实际业务在查询中与Ha3的交互过程:
![](https://i-blog.csdnimg.cn/blog_migrate/a5f4ad704f13f2fc6b61cc1279d0e4c6.png)
-
搜索入口访问图中的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个角色组成。
![](https://i-blog.csdnimg.cn/blog_migrate/fe6649f3f2dde96c8eedff7ad09316e4.png)
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、召回、算分、排序、摘要做业务上所期望的修改。
![](https://i-blog.csdnimg.cn/blog_migrate/8e621754b6d337996952658c4c38d5ce.png)
运维
Ha3的日常运维包括二进制版本更新、配置更新、全量与增量索引更新、扩行扩列、机器调度分配等。这些都是通过简易的web操作,后端子模块相互配合完成的,避免了全手工操作的琐碎而又容易出错的细节。实现运维环节的子模块包含以下几个:
![](https://i-blog.csdnimg.cn/blog_migrate/25fe967162e31f1d239b6e342cb3d88f.png)
- 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来执行
![](https://i-blog.csdnimg.cn/blog_migrate/9637e3dbe1ef12314b8c67b98a47f9a5.png)
-
- 让用户无感知的在线服务更新,是通过灰度(rolling)的方式实现的。在多行部署的前提下,通过用户配置的最小服务比例(minHealthRatio)参数,carbon选择合适的行数进行更新。如果当前机器不够,则会申请新的机器以凑够足够的行数,待这些机器上都成功升级后,再选下一组机器继续升级。至于升级过程中是否停流量,可以在目标中设置是否由carbon停流量,不过在suez中,都是worker自己决定的。对于ha3,除了binary更新、内存不够情况下的forceLoad,都是不停流量升级的