Havenask介绍

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

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

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

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

Havenask在线检索服务简介

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

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

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

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等）、自由定制和更新业务逻辑、机房内/机房间大规模部署。大大减轻了引擎的运维压力
  

Suez Admin

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

Carbon二层调度

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

1. 服务的启停、扩缩容

1. rolling 升级

1. 资源、进程、业务等描述都可以在保证服务能力的情况下自动升级
2. 可以灵活控制升级比例，从而实现灰度升级
3. 多种拓扑结构下的升级（QRS的按行切换、Searcher的按列切换）

2. 异常节点自动恢复
   
3. 服务状态监管，对外披露服务状态
   

Suez Admin集群管理

• 老版本Suez Admin直接基于Carbon接口的集群管理使用起来较为不便，用户需要自己处理复杂的目标。但是对于一个日常运维人员而言，他大部分情况下是围绕表进行集群管理的，更关心如何方便地添加和变更一张表，以及调整表所在物理集群的一些参数。因此从Havenask 1.0.0开始，Havenask支持默认基于最新的Suez Admin Catalog和Cluster接口管理集群
  
• Catalog接口包含表相关的所有信息，Cluster接口包含集群的在线进程信息。当用户启动一个集群的时候会默认调用Cluster接口启动一个最小的集群，然后用户就可以调用Catalog接口建表改表。Suez Admin会根据表的分片数以及配置信息分配节点、下发目标给Carbon，从而实现表部署到集群上并对外提供服务的目的。用户也可以更新配置模板来调整表和进程。Catalog接口还包括对于全量表的索引构建的管理能力，能够自动下发批次增量索引到集群上。总体来说简化了集群管理的工作，降低了运维的负担
  

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以后，会存在如下几个阶段：
  

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

欢迎钉钉扫码加入 Havenask 开源官方技术交流群：