阿里巴巴网站的搜索引擎优化案例(Ha3架构在线Ha3的索引数据生成过程称作过程(图))

　　阿里巴巴网站的搜索引擎优化案例(Ha3架构在线Ha3的索引数据生成过程称作过程(图))

　　Ha3的架构

　　

　　在线的

　　Ha3是搜索系统的在线部分。在其系统中，它收录两个基本角色，Qrs（查询结果搜索者）和搜索者。

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

　　Searcher 是搜索查询的执行者。倒排索引召回、统计、条件过滤、文档评分排序、摘要生成等过程都在Searcher上完成。根据业务的需要，有时将汇总分离出来，构建一个独立的汇总集群。

　　在实际部署中，Qrs和Searcher都是多行部署的，可以根据业务流量的变化进行调整。Searcher还可以根据业务的数据量调整列数，解决单机内存或磁盘无法容纳所有数据的问题。

　　Qrs和Searcher都可以通过运维系统挂载到发现服务上。这里提到的发现服务通常是cm2和vipserver。结合gig搜索团队开发的RPC库，接入Qrs和Searcher可以实现流量自动平衡和不良节点检测降级，从而实现业务流畅运行。

　　

　　离线

　　我们将生成索引数据的过程称为离线过程。Ha3的索引是通过搜索团队开发的Build Service系统生成的。

　　Build Service 首先是一个独立的服务。通过运维系统输出的数据源的信号监控，这个独立的服务输出全量和增量索引到hdfs，通过dp分发到Ha3的Searcher。全索引的生产周期通常是一到几天，增量索引的周期通常是几十分钟。

　　Build Service 也以 lib 的形式存在于 Ha3 中，用于实时处理增量消息，并直接生成索引到 Ha3 Searcher 的内存中。这样，Ha3查询结果可以保证数据的秒级时效性。但是，这种方法也消耗更多的内存，并且随着实时消息的到达而线性增加。因此，每次加载增量索引时，Ha3都会清理实时索引的内存。

　　表, 区域, biz

　　从业务角度看，Ha3 收录了 zone、biz 和 table 的概念

　　

　　表是数据表。Ha3 中的区域必须包括一个主表 (item_table)，有时还包括辅助表。辅助表的数量没有限制。辅助表数据是对主表的补充。在线查询时，Searcher通过配置中指定的字段将主表和辅助表的结果连接给用户。在一些业务场景中，主表中的文档会需要进一步划分，所以对于一些特殊的业务用途，也有子文档（subdoc）的概念。本文将不解释子文档。

　　业务配置（biz）描述了上面提到的 Qrs 和 Searcher 的统计、评分、排序和汇总。单集群多业务可以满足，比如ABTest

　　Zone是为业务划分多个biz和多个table而存在的概念，它与biz和table的关系是一对多的。

　　查询时，用户需要填写专区名称和专区下的企业名称，以指定执行相应专区下的业务逻辑。必须指定zone，如果用户未指定biz，则使用default（默认）。业务配置

　　在线流程

　　在线过程中，用户通过向多线部署的其中一个 Qrs 发送请求来访问 Ha3，通过发现服务和流量均衡策略实现 Qrs 的选择。一个完整的请求将收录查询 关键词，并将收录描述统计、过滤和排序的行为参数。Qrs 将再次通过发现服务结合流量均衡策略选择特定列或多列 Searcher 机器来分发用户查询。Searcher 执行索引搜索、过滤和统计。这些进程的具体行为和相关参数将在查询和配置中涉及。

　　Qrs

　　Qrs 上的查询逻辑相对于 Searcher 来说比较简单。一个完整的查询分为两个阶段：第一阶段和第二阶段。第一阶段，Qrs 会向具有完整行的多列 Searcher 发送请求，并在从多列 Searcher 获取结果后对结果进行合并和排序。在第二阶段，将排序前 N 个文档（其中 N 由用户指定）。将docid或primary_key拼成查询字符串，返回给Searcher进行汇总查询，得到多列汇总结果后再次合并返回给用户

　　

　　搜索者

　　Searcher的在线查询过程有很多步骤，主要有以下几个部分：

　　Seek：倒排索引的recall、merge和intersect操作

　　过滤：根据用户指定的条件再次过滤反向召回的结果集，将不满足条件的文档剔除

　　Rank：粗略评分，这里的评分过程通常耗时较少，但涉及计算的文档量巨大。此步骤完成后，将保留得分最高的文档，其余的将被删除。具体保留多少个文档由用户的配置或查询条件决定，通常与参与Rank的文档有一个数量级的差距。

　　agg：对结果集的统计，统计的内容根据用户的查询条件确定

　　重排：精确计算积分。此时，积分计算所涉及的文档与Rank过程有一个数量级的差异，计算逻辑更加复杂。

　　ExtraRank：返回Qrs前的最终排名

　　一个典型的业务查询流程

　　我将使用下图来说明我们的一个实际业务与 Ha3 在查询中的交互：

　　

　　搜索条目访问图中上游的 Ha3。Ha3上游请求Ha3之前，会根据需要（如用户个性化信息、查询词扩展、类别预测等）生成一个Ha3查询字符串，并请求Ha3

　　Ha3的Searcher部分根据文档质量依次分为zone1、zone2、zone3。Ha3 的上游会为预期返回的文档数量设置一个阈值。首先请求 Zone1。当 zone1 召回的文档数不满足阈值时， zone2 会继续查询，如果还不够，则再次查询 zone3

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

　　离线进程

　　离线流程的执行者Build Service，负责将纯文本产品数据构建成Ha3格式的索引文件。原创商品数据有两种，一种是存储在hdfs上的全量商品数据，由业务方定期（通常以天为单位）产生，另一种是实时增量数据。商品信息发生变化后，由业务方实时同步到消息系统swift中。为了高效稳定地将全量和增量数据输出到 Ha3，Build Service 被设计为由三个角色组成。

　　

　　构建服务的 3 个角色

　　处理器：原创文档的文本处理，包括业务逻辑重写和字段内容的分词

　　Builder：转换原创文档以生成索引数据

　　Merger：合并Builder生成的索引数据，生成最终由Searcher加载的索引文件

　　全索引输出

　　全流程的输入数据是存储在hdfs上的原创文档。全索引的构建过程包括手动触发和自动触发。手动触发由集群管理员通过运维系统控制页面触发。自动触发是由运维系统定期扫描zk服务器上的路径来监控新数据的输出的信号触发的。

　　hdfs上的数据经过Processor处理后发送到swift的transit topic

　　Builder从传输主题中获取Processor处理的文档，生成索引数据放入hdfs

　　Merge从hdfs获取生成的索引数据，合并成一个索引文件，可以加载到Searcher的每一列

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

　　增量索引输出

　　增量流程和完整流程之间的区别在于数据源。与全量数据源hdfs不同，增量数据源是数据生产者一直发送的增量消息。这种消息经过swift的原创topic，然后由Processor处理，后续流程如下。与全索引输出的过程相同。增量索引会定期分发到 Searcher 的磁盘

　　实时指数

　　实时索引的数据源和增量索引一样，都是数据生产者发送的swift消息。与增量不同的是，增量是将数据输出到hdfs，通过正则分发分发给Searcher，实时索引通过传输主题直接放入Ha3内存，经过Realtime处理后lib 形式的构建器。. 增量索引的时效与配置生成周期有关，一般是几十分钟，而实时索引的时效是秒级。新的增量索引加载后，Ha3会清理活索引

　　插件机制

　　为了实现业务定制，Ha3提供了插件机制。在上述线下和线上流程的各个环节，Ha3用户可以通过开发自己的插件，对原创文档进行业务所需的修改、查询、召回、评分、排序、摘要。

　　

　　运维

　　Ha3的日常运维包括二进制版本更新、配置更新、全量和增量索引更新、行列扩展、机器调度和分配等，这些都是通过简单的web操作完成，后端各模块配合其他，避免完全手动操作的琐碎和容易出错的细节。实现运维环节的子模块包括：

　　

　　suez_ops：这是在线运维操作的入口。后台连接构建服务、swift、ha3、离线输出，实现全流程。配置更新、回滚、扩列扩列、资源调整等都可以在 suez_ops 中完成。对于交互和 web 有强烈定制需求的用户，suez_ops 还提供了 API 供进一步开发

　　suez admin：这是一个链接角色。用户通过suez_ops的操作提交自己的运维需求。ha3 admin 获取更新信息后，分解更新目标，发送给自己管理的 Qrs 或 Searcher worker。具体的变化行为由 Qrs 或 Searcher 进程自己完成。

　　carbon：是嵌入在 suez admin 中的调度框架，存在于 lib 中。一方面采集下游worker（Qrs/Searcher）的状态，比如存活还是死亡，是否达到目标状态，另一方面调度具体的worker去执行

　　

　　让用户察觉不到的在线服务的更新是通过滚动的方式实现的。在多线部署的前提下，carbon 通过用户配置的最小服务比率（minHealthRatio）参数选择合适的线数进行更新。如果当前机器不够用，会申请新机器补足行数。这些机器全部升级成功后，会选择下一组机器继续升级。至于升级过程中是否停流，可以在target中设置是否按碳停流，但在suez，由工人自己决定。对于ha3，除了内存不足时二进制更新和forceLoad，流量不断升级。