作者：谷深
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 算子组成的计算图。
六、总结
Havenask 是一套包括集群调度与运维、分布式执行引擎、SQL 算子与资源集合的搜索服务，为用户提供高性能、低成本、易用的搜索服务。同时具有灵活的定制和开发能力，帮助客户和开发者量身定做适合自身业务的智能搜索服务，助力业务增长。
Havenask 开源官网：
https://havenask.net/
Havenask 开源项目地址：
https://github.com/alibaba/havenask
阿里云 OpenSearch 官网：
https://www.aliyun.com/product/opensearch文章来源：https://www.toymoban.com/news/detail-785231.html
文章来源地址https://www.toymoban.com/news/detail-785231.html
到了这里，关于揭秘阿里自研搜索引擎 Havenask 在线检索服务的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
