一、整体架构
搜索引擎分为数据源聚合(俗称 dump)、全量/增量/实时索引构建及在线服务等部分，以 Tisplus 为入口经由 Bahamut（Maat 进行工作流调度）->Blink->Hdfs/Swift->BuildService->Ha3->SP->SW 等阶段对客户提供高可用/高性能的搜索服务。其中数据源聚合在 tisplus 平台和 Blink 平台完成，Build service 和 Ha3 在 suez 平台完成，SP 和 SW 通过 drogo 进行部署。具体架构图如下：
二、Tisplus
1688 目前有 spu、cspu，company，buyoffer 和 feed 等引擎及 offer 离线在 tisplus 运维，该平台主要 ha3 和 sp 的搭建和维护，大体架构如下：
在日常维护中偶尔会遇到数据源产出失败的问题，主要是由于数据源表权限过期及 zk 抖动等原因。性能方面，在集团内搜索中台团队的引入 Blink Batch 模型后，dump 执行时间被缩短，具体指标如下（以 buyoffer 引擎为例）：
在 tisplus 平台，离线 dump 的入口如下：
DAG 数据源图示例：
下面主要说下离线 dump 数据源处理流程，包括 Bahamut、Maat 和数据输出。
2.1 Bahamut——数据源图处理
Bahamut 是离线数据源处理的组件平台，将 web 端拼接的数据图通过 jobManager 翻译成可执行的 sql 语句。目前 Bahamut 包含的组件有四类，分别是：
数据输入：datasource（支持 tddl 和 odps）
KV 输入：HbaseKV（Hbase 数据表）
数据处理：Rename（数据字段重命名），DimTrans（使用 1 对多的数据聚合），Functions（简单字段处理），Selector（字段选择），UDTF（数据逻辑处理），Merge（数据源聚合），Join（left join）
数据输出：Ha3（Hdfs/swift）
对数据源的处理过程，描述如下：
by 敬明
而对于 Bahamut->blink 过程可以陈述如下：
其中，Bahamut 将任务拆解后扔给 JobManager 进行逻辑节点到物理节点的转换，形成若干节点后再归并组合成一个完整的 SQL 语句，例如上图 Kratos_SQL 就是一个增量 Join 的完整 SQL，配合资源文件一起通过 BayesSDK 提交任务。此外，平台增加了一个弱个性化配置的功能，可以通过个性化配置来实现控制某个具体任务的并发度、节点内存、cpu 等等参数。
2.2 Maat——分布式流程调度系统
Maat 是基于开源项目 Airflow 再次开发的分布式流程调度系统，具有可视化编辑及通用的节点类型，Drogo 化部署，分集群管理及完善的监控 &报警机制等优点。
关于 Airflow 及其他工作流系统，对比陈列如下：
eed 引擎为例，maat 调度页面如下：
当任务错误时，可以通过该页面进行“将指定步骤置 fail”然后重跑全量任务，也可以通过查看某个步骤的 log 获悉任务失败原因。
2.3 Ha3 doc——数据输出
经过上述步骤后，最后将数据以 xml 的形式(isearch format)输出到 HDFS/Pangu 路径（全量）和 Swift Topic（增量），引擎全量时通过 HDFS 路径获取全量 doc 文件进行 build，增量时直接从 swift topic 中获取增量更新消息更新到引擎中。离线平台通过一个服务为 Tisplus 引擎模块提供表信息的查询等功能，以下是一个 HA3 表包含的信息：
三、Suez
经过上述步骤后，数据以 xml(isearchformat)的格式产出到 Hdfs 和 swift，然后通过在 suez_ops 平台的离线表中选择数据类型为 zk 并配置相应的 zk_server 和 zk_path 即可。
然后由 Build service 完成全量/增量/实时索引的构建，然后分发到 Ha3 在线集群提供服务。
suez 的离线表构建逻辑如下：
suez 在线服务逻辑如下：
下面针对离线（buildservice）和在线（ha3）进行简述：
3.1 Build Service——索引构建
Build Service(简称 BS)是一套提供全量、增量、实时索引的构建系统 build_service 总共有五类角色：
admin ：负责控制整体 build 流程，切换全量增量状态，发起定期任务，相应用户的控制请求；
processor ：负责数据处理，将用户的原始文档转化为轻量级可 build 的文档形态；
builder ：负责构建索引；
merger ：负责索引整理；
rtBuilder ：负责在线索引的实时构建。
其中 admin、processor、builder、merger 是以二进制程序的方式运行在 hippo 上，rtBuilder 是以 lib 的形式提供给在线部分使用。
一个完整的全量+增量过程会产生一个 generationid，该 generation 会经历 process full-> builder full -> merger full ->process inc -> builder inc ->merger inc 的过程，其中处于 inc 过程后，builder inc 和 merger inc 会交替出现。1688 在 ha3 升级之前经常会出现 build tooslow 问题就是因为分配到了坏节点或 builderinc/merger inc 阶段卡住。
3.2 Ha3——在线搜索服务
Ha3 是一套基于 suez 框架的全文检索引擎，提供丰富的在线查询子句，过滤子句，排序子句，聚合子句且支持用户自定义开发排序插件。服务架构如下：
1688 主搜引擎由一组 Qrs、searcher 和 summary 组成：
Qrs 的作用是：对输入的查询作解析与校验，通过后把查询转发给相应的；searcher，收集合并 searcher 返回的结果，最后对结果做一些加工并返回给用户。其中也可以通过写 meger 插件干预合并规则；
searcher：可以是文档的召回服务(searcher)，也可以是文档的打分与排序服务(ranker)或者是文档的摘要服务(summary)；
summary：1688 主搜将 searcher 和 summary 分离，summary 集群只提供取商品详情的服务。
qrs/searcher/summary 等机器通过挂载到 cm2 提供服务，比如 qrs 有对外 cm2，可以对 SP 等调用方提供服务，searcher 和 summary 有对内 cm2，可以接收从 qrs 来的请求并完成召回排序取详情等服务。
一次调用方的 query 服务，要经由 qrs->query 解析->seek->filter->rank(粗排)->agg(聚合)->rerank(精排)->extraRank(最终排)->merger->summary(取详情)的过程，具体描述如下：
其中，ReRank 和 ExtraRank 由 Hobbit 插件及基于 Hobbit 的战马插件完成，业务方可以根据自身需求开发战马特征并指定各特征权重得到商品的最终分。
四、Drogo
drogo 是基于二层调度服务 Carbon 的无数据服务的管控平台，1688 的 SP 服务及 QP 代理服务均部署在该平台。
1688 搜索链路主要服务平台部署情况简述如下：
参考文档：
《搜索中台开发运维一体化实践-Sophon》、《基于 DAG 的分布式任务调度平台-Maat》、《tisplus 用户操作手册》、《Build Service 用户手册》、《Build Service 源码》、《Ha3 用户手册》、《Ha3 搜索引擎简介》、《drogo 平台介绍》、《搜索离线平台系统架构及实现介绍》、《基于 Blink Batch 模式的搜索离线任务开发实践》、《搜索离线平台计算引擎简介——基于 Blink2.2 和 Bayes 的演进之路》、《解密双 11 实时计算每秒 4.72 亿背后的核心技术——Blink》、《SARO 用户手册》、《工作流引擎比较》、《Airflow 简介》、《Airflow github》
本文转载自公众号阿里技术（ID：ali_tech）。
原文链接：
https://mp.weixin.qq.com/s/omJQ_1OgjbYnbpHBua-lSQ
中国开源发展研究分析 2022
本次报告为开发者，技术管理者，开源社区运营、市场，开源办公室工作人员带来信息上的增量以及对开源趋势、...
评论