Ha3的架构在线Ha3运维系统的离线过程(图)

　　Ha3的架构在线Ha3运维系统的离线过程(图)

　　Ha3 架构

　　在线

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

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

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

　　在实际部署中，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都会清理实时索引的内存。

　　表格、区域、商务

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

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

　　业务配置（biz）描述了上述Qrs和Searcher上的统计、计算、排序、汇总等环节。例如，单个集群中的多个业务可以满足ABTest的需求。

　　zone是一个概念，用于将多个biz和多个表划分为业务，它与biz和表的关系是一对多的。

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

　　线上流程

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

　　问号

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

　　搜索者

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

　　Seek：倒排索引的召回、合并、交集操作

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

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

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

　　重新排名：准确的分数计算。这一步，score计算和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 个角色组成。

　　Build Service 的 3 个角色

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

　　Builder：将原创文档转换成索引格式的数据

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

　　全索引的输出

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

　　hdfs 上的数据经过处理器处理后发送到 swift 的传输主题

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

　　Merge 从 hdfs 中获取生成的索引数据，并将它们合并成可以在 Searcher 上加载的索引文件。

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

　　增量索引的输出

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

　　实时索引

　　实时索引的数据源与增量索引相同，都是数据生产者发送的swift消息。与增量不同的是增量是将数据输出到hdfs，由Searcher定时分发加载，而实时索引是通过传输topic，由Realtime Builder以lib的形式处理，直接放置在Ha3内存中。增量索引的时效性与配置的生成周期有关，一般为几十分钟，而实时索引的时效性为秒级。加载新的增量索引后，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）的状态，如果是dead还是alive，是否已经达到目标状态，另一方面是调度具体Worker去执行

　　让用户不知不觉的在线服务更新是通过滚动实现的。在多线部署的前提下，carbon通过用户配置的最小服务比（minHealthRatio）参数选择合适的行数进行更新。如果当前机器不够用，它会申请新机器来弥补足够的行。这些机器升级成功后，再选择下一组机器继续升级。至于升级过程中是否停止流量，可以在target中通过carbon设置是否停止流量，但是在suez中，是worker自己决定。对于ha3，除了在内存不足的情况下binary update和forceLoad，所有的流量升级都是不断升级的