揭秘阿里自研搜索引擎 Havenask 在线检索服务

2024-01-09
浙江
本文字数：4335 字
阅读完需：约 14 分钟

作者：谷深

Havenask 是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎，深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内几乎整个阿里的搜索业务。本文针对性介绍了 Havenask 的在线服务，它具备高可用、高时效、低成本的优势，帮助企业和开发者量身定做适合业务发展的智能搜索服务。

一、Havenask 介绍

Havenask 是阿里巴巴广泛使用的自研大规模分布式检索系统，是过去十多年阿里在电商领域积累下来的核心竞争力产品，广泛应用在搜推广和大数据检索等典型场景。在 2022 年云栖大会-云计算加速开源创新论坛上完成开源首发，同时作为阿里云开放搜索 OpenSearch 底层搜索引擎，OpenSearch 自 2014 年商业化，目前已有千余家外部客户。

下图展示了 Havenask 中一个完整的搜索服务：在线系统、索引系统、管控系统、扩展插件，且包括了查询流、数据流、控制流。其中在线检索服务，包含了 QRS 和 Searcher，Qrs 负责接收用户查询、查询分发、收集整合结果。Searcher 是搜索查询的执行者，负责倒排索引召回、统计、条件过滤、文档打分、排序、摘要生成等。

Havenask 支持千亿级别数据实时检索、百万 QPS 查询，百万 TPS 高时效性写入保障，毫秒级查询延迟和数据更新，并具有良好的分布式架构、极致的性能优化，能够实现比现有技术方案更低的成本，普惠更多的开发者和企业。

开源地址：http://github.com/alibaba/havenask

1.1 Havenask 在线检索服务简介

Havenask 是一款高效、可扩展的分布式 SQL 搜索引擎。该引擎具有以下核心特性：

支持多种不同类型的索引，能够满足不同业务场景的检索需求
稳定低延时，确保检索的速度和准确性
高度可定制，用户可以根据实际需求进行个性化配置和扩展

通过以上特性的集成和优化，Havenask 在海量数据处理方面表现出色，它为阿里集团旗下大量业务场景，如淘宝、天猫等，提供了快速准确的检索能力。

1.2 Havenask 在线检索服务架构

如下图所示，Havenask 在线检索服务主要由以下几部分构成：

Suez Admin：Suez Admin 是 Havenask 集群的管理中枢，主要负责集群资源的调度以及目标管理；
Suez Worker: Suez Worker 是由 Suez Admin 基于运维人员的集群描述分配和管理的引擎在线工作节点；
Navi ：Navi 是通用的分布式图执行框架，在 Havenask SQL 引擎运行的过程中根据用户查询对应的 SQL 计算图调度对应 SQL 算子和资源；
Havenask SQL：通过 Navi 框架上定义和注册的 Havenask SQL 算子与资源集合实现的 SQL 检索引擎。主要运行在 Suez Worker 上，Havenask 集群中的工作节点又可以进一步分为以下两类：

QRS 是一类多副本（Replica）的查询工作节点。主要负责处理用户查询请求、解析和校验 Query、生成和执行 SQL 计划；
Searcher/Database 是一类多副本（Replica）、多数据分列（Partition）的数据工作节点。主要基于 QRS 的远程调用执行 SQL 分布式计划的一部分，负责查询索引、召回文档。Searcher 还会基于 Suez Worker 的索引管理能力加载 BuildService 构建的全量索引、批次索引，订阅 Swift 消息构建实时索引。

二、搜索基础服务框架：Suez

Suez 是一个支持多表、多业务的通用搜索在线服务框架，支持快速分发和加载索引和配置数据、搜推广场景下常见类型的索引（倒排，kv 等）、自由定制和更新业务逻辑、机房内/机房间大规模部署。大大减轻了引擎的运维压力。

2.1 Suez Admin

suez admin 在整个框架中是一个中枢，它负责对于搜索集群目标进行调度。它拿到业务视角的业务描述后，对这个大的最终目标进行分解，然后根据各部分的信息去和 hippo（一层资源调度器）、suez worker 等组件进行交互，最终让整个服务达到用户的期望状态。在这个过程里和日后漫长的运行中，还要不断收集 worker 的状态，自动化应对诸如进程挂掉、机器故障、网络异常等各种各样的问题，保证稳定的对外服务能力

Carbon 二层调度

以上这些需求本质上是大型分布式服务都会需要的调度逻辑，我们把这部分逻辑单独划分出来，沉淀出了一套独立的二层调度器 Carbon。在阿里内部 Carbon 是一个基于 K8S 的 controller，在当前开源版本目前 Carbon 被封装在 Suez Admin 上基于 SSH 进行调度，未来也将支持 K8S 调度。

Carbon 主要支持以下能力：

服务的启停、扩缩容
rolling 升级
资源、进程、业务等描述都可以在保证服务能力的情况下自动升级
可以灵活控制升级比例，从而实现灰度升级
多种拓扑结构下的升级（QRS 的按行切换、Searcher 的按列切换）
异常节点自动恢复
服务状态监管，对外披露服务状态

Suez Admin 集群管理

老版本 Suez Admin 直接基于 Carbon 接口的集群管理使用起来较为不便，用户需要自己处理复杂的目标。但是对于一个日常运维人员而言，他大部分情况下是围绕表进行集群管理的，更关心如何方便地添加和变更一张表，以及调整表所在物理集群的一些参数。因此从 Havenask 1.0.0 开始，Havenask 支持默认基于最新的 Suez Admin Catalog 和 Cluster 接口管理集群。

Catalog 接口包含表相关的所有信息，Cluster 接口包含集群的在线进程信息。当用户启动一个集群的时候会默认调用 Cluster 接口启动一个最小的集群，然后用户就可以调用 Catalog 接口建表改表。Suez Admin 会根据表的分片数以及配置信息分配节点、下发目标给 Carbon，从而实现表部署到集群上并对外提供服务的目的。用户也可以更新配置模板来调整表和进程。Catalog 接口还包括对于全量表的索引构建的管理能力，能够自动下发批次增量索引到集群上。总体来说简化了集群管理的工作，降低了运维的负担。

2.2 Suez Worker

Suez Worker 提供了加载多表和业务信息的功能。进程需要加载的索引表以及需要加载的业务配置等等都统在一个 json 结构中描述，对外提供 Restful CRUD 接口。因此 Suez Worker 既可以独立存在，也可以通过 Suez Admin 调度。Suez Worker 也会接受 Catalog 上发来的 BuildService 索引构建结果与 Swift 上的实时消息，以保证自己的数据时效性不延迟。

Suez Worker 需要同时承担配置管理和索引管理的两种任务，它时刻会根据最新接受的目标来调整自己需要执行的自动化任务，可能存在的场景很多，包括但是不局限于以下：
自动内存管理，全量、增量、实时根据内存情况加载，不会超限
多种业务加载策略，既可以渐进导流，也可以激进地起新下老
自动化的磁盘管理和老版本保留，既可以做到快速回滚恢复，又不会占满磁盘

因此 Suez Worker 采用了状态机来维护一份决策表，当一个事件触发时如新批次下发、新全量下发、新配置下发等，会根据当前表的状态例如表的加载状态、是否缺磁盘内存等来决定下一步行为。

三、SQL 解析与优化：Iquan

Iquan 是基于 Calcite/Flink 开发的 SQL 解析与执行计划优化模块（基于 Java 语言编写）, 目前已经支持了大部分 SQL 标准语法及 UDF/UDAF 扩展。当 Havenask 引擎启动的时候，QRS 节点会加载 iquan 模块，并基于加载的在线配置生成一份 Catalog 清单，用于描述当前集群可用的表和 UDF 信息。你可以通过访问 QRS 的/SqlClientInfoj 接口来获取这份信息。

当用户查询的 SQL 语句进入 Iquan 以后，会存在如下几个阶段：

SQL 解析: SQL 语句解析阶段，会把用户数据的 sql 语句转化为对应的 AST 树。这个过程会校验用户调用的一些 UDF 是否已经注册，使用的字段是否符合类型限制等；
逻辑优化阶段: 将 AST 树转变为对应的 DAG 图，Iquan 将在这个阶段对 DAG 图做一些逻辑上的变换，比如：冗余节点合并（重复计算的地方只计算一次）、谓词下推（将判断条件下推到 Searcher，尽可能跳过无关数据）等等变换；
物理优化阶段: 将逻辑 DAG 图转成对应的物理 DAG 图。在这个阶段， Iquan 会根据 Havenask 的特点做一些特有的优化；
分布式执行图转换阶段：为了能让 physical DAG 可以运行在 Navi（Navi 介绍见下文）上，在这个阶段会将对应的物理 DAG 图转为对应的分布式执行图。

四、SQL 分布式执行框架：Navi

在阿里内部多年的搜推广在线引擎迭代中，抽象出了一套通用的实时满足用户查询、低延迟的分布式执行 Navi。原生支持流式计算、分布式图，还提供了一整套用户请求处理、配置管理、计算资源管理、全链路可观测、流式算子开发、与 Tensorflow 结合的能力。设计初衷是希望解决引擎开发过程中的共性问题，提供一体的解决方案，业务只需要聚焦于自身的业务逻辑，下面介绍其中的一些核心特性。

计算资源管理

在分布式图执行的过程中，可能需要准备很多计算相关的资源，例如某个能够缓存某种结果的 cache 类，能够支持某种插件的注册和创建的插件管理器，某种指标汇报器，某种配置等等，可能互相有依赖，比如 cache 类可能要汇报指标。它们有几个共同特点：语义清晰，功能独立，往往多次使用，大多需要初始化，有时会有自己的配置，互相之间可能会有依赖，另外由于是一次创建多次使用，所以创建和使用不是对应的，两者是分离的，使用的地方往往不关心创建逻辑。

基于此，navi 中引入了 Resource 这一非常重要的概念：一次创建、多次使用的数据，Resource 可以依赖其他 Resource。Resource 按需推导创建，从用户的视角看，所有 Resource 都是为跑算子服务的，因此资源依赖的推导也都是围绕着算子的。

下图给出了一个围绕 SQL 算子准备资源的流程，两个 Scan 算子依赖 UDF 和 MetricReporter 两个 Resource，Sort 则依赖 MetricReporter 和 Cache，同时 UDF 也依赖 MetricReporter。执行时，navi 会先创建 MetricReporter，再创建 UDF，最后创建 Scan，Sort 逻辑与此类似，需要强调的是，Cache 和 MetricReporter 是并发创建的。

分布式数据流图

在 Navi 诞生以前，Havenask 引擎采用基于 Tensorflow 的 Suez Turing 框架实现自定义的引擎算子。但是 Tensorflow 算子是无状态的，并不完全适合搜索场景。比如用 tensorflow 的无状态算子实现一个 SQL 查询中的 HashJoin 时必须把 HashMap 存在另一个地方，而不能记在自己的成员上。因此 Navi 选择将业务逻辑抽象为流式图，图中的节点是算子，边是数据流。不同算子通过有向的数据流边来关联，构成子图。在分布式环境下，子图的某些边可以被其他子图引用作为整体输出。例如 Searcher 的子图被 QRS 引用。由于边上是流式数据，所以 navi 支持流水线式的并发，能够极大提升计算图执行效率。

五、Havenask SQL 引擎

Navi 只定义了通用的分布式图执行框架，但是并没有具体定义 Havenask SQL 行为。因此 Havenask SQL 引擎实际上就是基于 Navi 算子接口实现了 Havenask 的 SQL 算子集合以及相关的计算资源。它向 Navi 注册一个特殊的 RPC 资源来对外提供 SQL 读写服务。通过注册的 Iquan 资源解析用户 SQL 请求，生成执行计划，最后再由 Navi 框架执行对应 SQL 算子组成的计算图。