点击链接阅读原文，获取更多技术内容：《揭秘，阿里开源自研搜索引擎Havenask的在线检索服务》-阿里云开发者社区
Havenask是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎，深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内几乎整个阿里的搜索业务。本文针对性介绍了Havenask的在线检索服务，它具备高可用、高时效、低成本的优势，帮助企业和开发者量身定做适合业务发展的智能搜索服务。
Havenask介绍
Havenask 是阿里巴巴广泛使用的自研大规模分布式检索系统，是过去十多年阿里在电商领域积累下来的核心竞争力产品，广泛应用在搜推广和大数据检索等典型场景。在2022年云栖大会-云计算加速开源创新论坛上完成开源首发，同时作为阿里云开放搜索OpenSearch底层搜索引擎，OpenSearch 自2014年商业化，目前已有千余家外部客户。下图展示了Havenask 中一个完整的搜索服务：在线系统、索引系统、管控系统、扩展插件，且包括了查询流、数据流、控制流。其中在线检索服务，包含了 QRS 和 Searcher，Qrs 负责接收用户查询、查询分发、收集整合结果。Searcher 是搜索查询的执行者，负责倒排索引召回、统计、条件过滤、文档打分、排序、摘要生成等。
Havenask 支持千亿级别数据实时检索、百万 QPS 查询，百万 TPS 高时效性写入保障，毫秒级查询延迟和数据更新，并具有良好的分布式架构、极致的性能优化，能够实现比现有技术方案更低的成本，普惠更多的开发者和企业。开源地址：http://github.com/alibaba/havenaskHavenask在线检索服务简介
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主要支持以下能力：服务的启停、扩缩容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接口还包括对于全量表的索引构建的管理能力，能够自动下发批次增量索引到集群上。总体来说简化了集群管理的工作，降低了运维的负担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是并发创建的。内容剩余60%，完整内容可点击下方链接查看：《揭秘，阿里开源自研搜索引擎Havenask的在线检索服务》-阿里云开发者社区
阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：阿里云开发者社区-云计算社区-阿里云