<返回更多

10年+,阿里沉淀出怎样的搜索引擎?

2020-09-10    
加入收藏
10年+,阿里沉淀出怎样的搜索引擎?

 


阿里妹导读:搜索引擎是阿里的10年+沉淀,具有很高的技术/业务/商业价值。1688很多场景都借助了搜索中台的能力,基于此,以1688主搜为例介绍搜索全链路知识点,希望对你有所借鉴,有所启发。

一、整体架构

搜索引擎分为数据源聚合(俗称dump)、全量/增量/实时索引构建及在线服务等部分,以Tisplus为入口经由Bahamut(Maat进行工作流调度)->Blink->Hdfs/Swift->BuildService->Ha3->SP->SW等阶段对客户提供高可用/高性能的搜索服务。其中数据源聚合在tisplus平台和Blink平台完成,Build service和Ha3在suez平台完成,SP和SW通过drogo进行部署。具体架构图如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

二、Tisplus

1688目前有spu、cspu,company,buyoffer和feed等引擎及offer离线在tisplus运维,该平台主要ha3和sp的搭建和维护,大体架构如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

在日常维护中偶尔会遇到数据源产出失败的问题,主要是由于数据源表权限过期及zk抖动等原因。性能方面,在集团内搜索中台团队的引入Blink Batch模型后,dump执行时间被缩短,具体指标如下(以buyoffer引擎为例):

10年+,阿里沉淀出怎样的搜索引擎?

 

在tisplus平台,离线dump的入口如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

DAG数据源图示例:

10年+,阿里沉淀出怎样的搜索引擎?

 

下面主要说下离线dump数据源处理流程,包括Bahamut、Maat和数据输出。

2.1 Bahamut——数据源图处理

Bahamut是离线数据源处理的组件平台,将web端拼接的数据图通过jobManager翻译成可执行的sql语句。目前Bahamut包含的组件有四类,分别是:

  1. 数据输入:datasource(支持tddl和odps)
  2. KV输入:HbaseKV(Hbase数据表)
  3. 数据处理:Rename(数据字段重命名),DimTrans(使用1对多的数据聚合),Functions(简单字段处理),Selector(字段选择),UDTF(数据逻辑处理),Merge(数据源聚合),Join(left join)
  4. 数据输出:Ha3(Hdfs/swift)

对数据源的处理过程,描述如下:

10年+,阿里沉淀出怎样的搜索引擎?

 


by 敬明

而对于Bahamut->blink过程可以陈述如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

其中,Bahamut将任务拆解后扔给JobManager进行逻辑节点到物理节点的转换,形成若干节点后再归并组合成一个完整的SQL语句,例如上图Kratos_SQL就是一个增量Join的完整SQL,配合资源文件一起通过BayesSDK提交任务。此外,平台增加了一个弱个性化配置的功能,可以通过个性化配置来实现控制某个具体任务的并发度、节点内存、cpu等等参数。

2.2 Maat——分布式流程调度系统

Maat是基于开源项目Airflow再次开发的分布式流程调度系统,具有可视化编辑及通用的节点类型,Drogo化部署,分集群管理及完善的监控&报警机制等优点。

关于Airflow及其他工作流系统,对比陈列如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

eed引擎为例,maat调度页面如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

当任务错误时,可以通过该页面进行“将指定步骤置fail”然后重跑全量任务,也可以通过查看某个步骤的log获悉任务失败原因。

2.3 Ha3 doc——数据输出

经过上述步骤后,最后将数据以xml的形式(isearch format)输出到HDFS/Pangu路径(全量)和Swift Topic(增量),引擎全量时通过HDFS路径获取全量doc文件进行build,增量时直接从swift topic中获取增量更新消息更新到引擎中。离线平台通过一个服务为Tisplus引擎模块提供表信息的查询等功能,以下是一个HA3表包含的信息:

{
 "1649992010": [
   {     "data": "hdfs://xxx/search4test_st3_7u/full", // hdfs路径
     "swift_start_timestamp": "1531271322", //描述了今天增量的时间起点
     "swift_topic": "bahamut_ha3_topic_search4test_st3_7u_1",
     "swift_zk": "zfs://xxx/swift/swift_hippo_et2",
     "table_name": "search4test_st3_7u", // HA3 table name,目前与应用名称一样
     "version": "20190920090800” // 数据产出的时间
   }
 ]
}

三、Suez

经过上述步骤后,数据以xml(isearchformat)的格式产出到Hdfs和swift,然后通过在suez_ops平台的离线表中选择数据类型为zk并配置相应的zk_server和zk_path即可。

然后由Build service完成全量/增量/实时索引的构建,然后分发到Ha3在线集群提供服务。

suez的离线表构建逻辑如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

suez在线服务逻辑如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

下面针对离线(buildservice)和在线(ha3)进行简述:

**3.1 Build Service——索引构建
**

Build Service(简称BS)是一套提供全量、增量、实时索引的构建系统
build_service总共有五类角色:

其中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框架的全文检索引擎,提供丰富的在线查询子句,过滤子句,排序子句,聚合子句且支持用户自定义开发排序插件。服务架构如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

1688主搜引擎由一组Qrs、searcher和summary组成:

qrs/searcher/summary等机器通过挂载到cm2提供服务,比如qrs有对外cm2,可以对SP等调用方提供服务,searcher和summary有对内cm2,可以接收从qrs来的请求并完成召回排序取详情等服务。

一次调用方的query服务,要经由qrs->query解析->seek->filter->rank(粗排)->agg(聚合)->rerank(精排)->extraRank(最终排)->merger->summary(取详情)的过程,具体描述如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

其中,ReRank和ExtraRank由Hobbit插件及基于Hobbit的战马插件完成,业务方可以根据自身需求开发战马特征并指定各特征权重得到商品的最终分。

四、Drogo

drogo是基于二层调度服务Carbon的无数据服务的管控平台,1688的SP服务及QP代理服务均部署在该平台。

1688搜索链路主要服务平台部署情况简述如下:

10年+,阿里沉淀出怎样的搜索引擎?

 

参考文档:
《搜索中台开发运维一体化实践-Sophon》、《基于DAG的分布式任务调度平台-Maat》、《tisplus用户操作手册》、《Build Service用户手册》、《Build Service源码》、《Ha3 用户手册》、《Ha3搜索引擎简介》、《drogo平台介绍》、《搜索离线平台系统架构及实现介绍》、《基于Blink Batch模式的搜索离线任务开发实践》、《搜索离线平台计算引擎简介——基于Blink2.2和Bayes的演进之路》、《解密双11实时计算每秒4.72亿背后的核心技术——Blink》、《SARO用户手册》、《工作流引擎比较》、《Airflow简介》、《Airflow github》

原文发布时间为:2019-09-24
作者:清刚
本文来自云栖社区合作伙伴“阿里技术”,了解相关信息可以关注“阿里技术”。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>