阿里开源高性能搜索引擎 Havenask - Ha3
本文会重点介绍一下阿里系的搜索引擎中间件 Havenask（内部代号Ha3），在阿里内部支持了淘宝、天猫、菜鸟、优酷、高德、饿了么等在内的阿里搜索业务。Ha3 支持千亿级别数据及时检索、百万qps查询，百万TPS高时效性写入保障，毫秒级查询耽误和数据更新。
开源地址：http://github.com/alibaba/havenask
1. 发展历程
https://i-blog.csdnimg.cn/blog_migrate/b5ad556ab05c433f5df47a9030236152.png
[*]1999年~2008年劈头于雅虎搜索技术（YST、Vespa）的单机版搜索引擎，支持淘宝、B2B等子公司搜索业务。
[*]2009年~2011年完成自研搜索引擎HA3（Havenask）研发，开启自研大规模分布式高性能搜索引擎期间。
[*]2013年Havenask支持阿里巴巴团体几乎所有搜索业务，统一代码分支，以产品化方式规模化支持团体大量搜索业务。
[*]2018年深度学习技术广泛应用，Havenask继承演进，除了提供传统的倒排索引能力外，还提供KV、KKV、向量索引，支持深度模型和在线预测，提供插件定制、自研CAVA语言支持业务扩展等能力，成为阿里搜推广场景的焦点AI智能引擎。
[*]2022年阿里将搜索引擎 Havenask 开源，为更多用户提供更高性能、更低成本、更便捷易用的搜索服务。
关键节点
[*]早期电商搜索是Apache http server module的形式实现，一个业务一个分支，与业务逻辑深度耦合
[*]2009年，支持业务的同时组建一支小队伍，从零开始重写整个搜索体系
[*]2011年，新体系完成研发，替代雅虎老的网页搜索并完成上线，开启了自研大规模分布式高性能搜索引擎期间。厥后这个组织架构的调解成了本日的UC 神马搜索，2013年UC整合了“一搜”团队以及百度的一支技术团队，同时引入360 等公司专家，进一步加快了移动搜索业务的推进，同年推出移动搜索品牌“神马搜索”
[*]2013年，问天引擎开始大规模支持几乎所有业务，统一代码分支、产品化方式支持大量搜索业务，技术团队整合到一起，以极致的性能优化、分布式、高可用、运维友好为目标不停打磨这个搜索产品。
[*]2016年，深度学习技术的广泛应用，ha3 逐步集成了各种除传统倒排索引以外的能力，称为阿里搜推广场景的焦点AI智能引擎。
2 架构
https://i-blog.csdnimg.cn/blog_migrate/3d5554f24fe5739247624f16b1998574.png
一个较为完备的搜索服务由：在线体系、索引体系、管控体系、扩展插件等部分构成，其中包括了查询流、数据流、控制流。
1）在线体系，包含了 QRS 和 Searcher。Qrs 负责接收用户查询、查询分发、收集整合结果。Searcher 是搜索查询的实行者，负责倒排索引召回、统计、条件过滤、文档打分、排序、摘要天生等。
2）索引体系，负责索引数据天生的过程，还包含有文档处理与索引构建服务 Build Service。索引构建分为三个步骤，对数据进行前置处理（比方分词、向量计算等）、产出索引、合并索引文件的处理。
3）管控体系，负责提供强盛的运维能力。
4）扩展插件，提供插件机制，索引和在线流程各环节中，均可以通过开发插件，对原始文档（UDF）、查询 Query、召回、算分（粗排）、排序、摘要进行机动修改。
2.1 ha3架构
https://i-blog.csdnimg.cn/blog_migrate/99d24d94bbea6097d5068adfeb330658.png
在线
[*]体系内部包含了QRS（query result searcher）和 Searcher 两种根本的角色。其中qrs用于接收用户查询，将用户查询分发给Searcher（也就是多个partition的场景），收集Searcher返回的结果作整合，最终返回给用户，这里用户指的是Ha3的调用方如 SP(搜索链路ha3上游服务) 和TPP（推荐链路ha3上游服务）。
[*]Searcher是搜索实行的实行者，倒排索引的召回、统计、条件过滤、文档打分以及排序及摘要天生的过程都在Searcher上完成。有时候根据业务需要也会把摘要（Summary）独立成一个单独的集群。
[*]实际的部署一样平常采用多机房灾备部署，QRS与Searcher 多行部署，多行主要应对大流量请求和上线过程中的部分行重启（两行保证50%可用）。Searcher可以根据业务需要调解列数，办理单机内存或磁盘放不下数据的问题。
[*]QRS和Searcher 通过运维体系挂在到发现服务上，内部常用的发现服务通常是cm2 和vipserver。结合gig团队开发的RPC lib, 对QRS和Searcher的访问可以做到主动的流量均衡和坏节点主动检测。
https://i-blog.csdnimg.cn/blog_migrate/496b0145aa1224b6e9bf5fea281f6c15.png
离线
[*]所谓的离线是指索引数据的天生过程，一样平常包括了离线全量数据的生产和及时消息的生产，都是通过Build Service体系天生的。
[*]Build Service是一个独立的服务，通过运维体系监控数据源是否有新的数据产出，将产出的全量和增量数据放到HDFS大概pangu上，通过DP服务，分发给Ha3的Searcher。其中全量索引的产出周期通常是一天一次，增量索引的产出周期是15分钟（可以配置）。
[*]在增量消息和全量消息之外还有及时消息，BS以lib的方式存在于Ha3中，用于处理及时消息，直接将产出及时索引放到Searcher的及时内存里（及时内存可配置）。如许Ha3的查询时效性就可以做到秒级，但是如果及时消息太多会把内存占满，办理办法就是 增量索引与全量索引合并的时候Ha3会清空及时内存与增量索引的交际，从而释放部分及时内存。
2.2 ha3业务分层
https://i-blog.csdnimg.cn/blog_migrate/b96a327a0870f86ac1602ea705dcf162.png
从业务角度出发，Ha3包括了zone、biz、table的概念
[*]table是数据表，Ha3中一个zone必须包括一个主表（item_table），有时候还会包括辅表，辅表在数量上没有限制。辅表数据是对主表的补充，在线查询的时候Searcher通过配置中指定的字段，将主表和辅表的结果join到一起返回给调用方。
[*]biz(业务配置) 描述了QRS和Searcher上的统计、算分、排序、摘要等多个环节。集群的多个biz，可以满足ABTest的需要。
[*]zone 是用于将多个biz与多个table 进行业务上划分存在的概念，与biz和table的关系是一对多。
用户构建查询串的时候，需要输入zone的名称和zone下biz的名称，来指定zone下的业务逻辑，zone是必须要指定的，biz是可以不指定的，这时候会使用默认的业务配置（default）
config=cluster:zone_name&&query=plain:你好&&attribute=id
3 ha3 运行细节
3.1 在线流程
在线流程中，用户访问Ha3的方式是向多行部署的其中一个Qrs发送请求，而Qrs的选择是通过发现服务配合流量均衡策略实现的。一个完备的请求会包含查询关键词，而且会包含描述了统计、过滤、排序的行为参数。Qrs会再次通过发现服务结合流量均衡策略，选择具体的一列或多列Searcher呆板，将用户查询分发下去。Searcher上实行索引查找、过滤、统计，这些流程的具体行为与相干参数在查询和配置中均会有涉及。
https://i-blog.csdnimg.cn/blog_migrate/f991d2484ffdfed170ee71eafa194876.png
3.1.1 QRS
qrs上的查询逻辑主要分两个阶段 ：第一个阶段向一个完备行的多列Searcher发送请求，从多列Searcher中拿到结果后合并排序。第二个阶段是将排序后前N个文档再次拼接查询串继承请求Searcher得到摘要查询结果，拿到摘要之后合并结果返回给用户。一样平常大多是时候摘要都是单独请求大概不请求。
3.1.2 Searcher
Searcher的在线查询流程较多，主要的步骤如下
[*]seek: 倒排索引的召回、合并与求交。这里默认是边打分边循环seek，默认128个doc为一组进行循环seek +filter
[*]filter: 剔除不满足条件的文档
[*]Rank：粗排算分，这里的算分过程耗时通常较少，但参与计算的文档量巨大，颠末这一步后，得分靠前的文档会被保留，其余都会被删除，具体保留多少文档由用户的配置或查询条件决定，通常与参与Rank的文档有数量级上的差距
[*]Agg: 对结果进行统计，统计内容根据用户查询条件决定
[*]Rerank: 精排算分，参与算分的文档跟粗排有数量级的差距，计算逻辑较为复杂。
[*]ExtraRank: 返回给qrs前的最终排序
3.2 离线流程
离线流程的实行者Build Service, 负责将纯文本的商品数据构建成Ha3格式的索引文件。原始的商品数据有两类，一类是存放在HDFS上的全量商品数据，这是定期（一样平常周期为天）由业务方产出，另一类为及时增量数据，商品信息变更后，业务放即时通知给消息体系Swift。
https://i-blog.csdnimg.cn/blog_migrate/829a8a355923429ccad0b865f62477f9.png
3.2.1 三个重要角色
[*]Processor: 从数据源拉取数据，支持多种数据源，比如HDFS、OSS平分布式文件体系，同时也支持对接Swift消息中间件处理及时数据。对原始数据做一些分词、数据格式转换等处理，开发者可以通过定制数据源reader插件和数据处理DocumentProcessor插件来扩展支持不同的数据源和数据处理逻辑。
[*]Builder:负责索引的构建，将颠末processor处理的数据按照Schema的配置构建成倒排、正派、摘要索引。Build与Processor的数据交互是通过Swift消息中间件来实现的，即Processor将处理之后的数据写到Swift，Build从Swift中读取这些数据进行索引构建。
[*]Merger：Merger负责索引的定期整理，定期索引整理使索引文件更加紧凑，可以降低在线集群索引加载的内存开销，提拔检索性能。索引整理时会清除已经标志删除的数据（及时这一块），小的索引文件合并成大的索引文件，也可以按照配置文件在整理时根据某个字段进行离线排序，如许可以进一步提拔检索性能。
除了以上三种角色之外还有BS Admin，负责整个集群的任务调度和资源管理。提供丰富的接口进行索引的构建和构建任务的启停，资源的调解等，一样平常Admin会配合调度体系来调度任务的实行并维护任务的状态。
在一个Build Service服务中可以有一个大概多个Admin，通过Zookeeper进行leader选举，只有leader才会管理整个Build Service服务，其他Admin作为fllower。
对于Processor、Builer和Meger节点，它们只有分片（Shard）的概念，没有备份的概念。比如对于Processor，每个分片处理不同的数据，一个分片只会启动一个节点，如果某些缘故原由启动了多个节点，多个节点之间通过ZK进行leader选举，只有leader节点才会存活并工作，非leader节点的历程会主动退出。Builder和Merger的环境与Processor雷同，唯一不同的是分片数是在创建表时就确定的，它们只能基于分片数据调节并发度，因此Builder和Meger节点真实启动的个数是分片数乘以并发度。
4 ha3 运维
Ha3的日常运维包括二进制版本更新、配置更新、全量与增量索引更新、扩行扩列、呆板调度分配等。这些都是通过浅易的web操纵(tisplus->suez ops)，后端子模块相互配合完成的，避免了全手工操纵的琐碎而又容易出错的细节。实现运维环节的子模块包含以下几个：
https://i-blog.csdnimg.cn/blog_migrate/e0454fc39c212563fde7068d000f41ac.png
[*]suez_ops: 线上运维操纵的入口，后台将build service、swift、ha3和离线产出做全流程的对接，配置的更新、回滚、扩列扩行、资源调解等均能在suez_ops的web界面上操纵，对于在交互和web上有强定制需求的用户，suez_ops也提供了API，以供进一步开发。
[*]suez admin: 这是一个承上启下的角色。用户通过suez_ops提交自己的运维需求，ha3 admin拿到更新信息之后，将更新目标分解，发送给自己管理的qrs大概searcher，具体变更行为由qrs大概searcher历程自己完成。
[*]carbon: 是一个内嵌在suez admin中，以lib存在的调度框架，一方面收集下游worker（qrs/searcher）的状态，检测状态（是否挂掉）、是否完成目标状态，令一方面调度具体的worker来实行。
[*]https://i-blog.csdnimg.cn/blog_migrate/9400cc41c28f17a61d8c8285965d2e35.png
让用户无感知的在线服务更新，是通过灰度（rolling）的方式实现的。在多行部署的前提下，通过用户配置的最小服务比例（minHealthRation）参数，carbon选择符合的行数进行更新。如果当前呆板不够，则会申请新的呆板以凑够足够的行数，待该组呆板都更新成功之后，再选择下一组进行继承升级。至于升级过程中是否停流量，可以在目标中设置是否由carbon停流量，不过在suez中，都是worker自己决定的。对于ha3,除了binary更新、内存不够环境下的forceLoad,都是不停流量升级的。
5 名词解释
[*]MLR模型 ：(mixed logistic regression, 混合逻辑斯特回归) 阿里盖坤提出
[*]CTR预估：click-through-rate 点击率预估，互联网广告结果的一项重要指标
[*]Kingso : 一套开源的搜索架构
[*]KV：输入一个K 大概多个 K 返回一个V大概多个V
[*]KKV：输入一个pkey和skey 返回单个值，只输入pkey则返回值序列。
[*]向量索引：非结构化数据检索，如图片、声音、视频等。开源框架包括Faiss 、milvus、Proxima等
[*]深度模型：
[*]卷积神经网络（Convolutional Neural Networks, CNN）：主要用于图像和视频处理任务，可以或许提取图像和视频的局部特性和空间关系。
[*]循环神经网络（Recurrent Neural Networks, RNN）：主要用于处理序列数据，如文本、语音等。它可以学习序列中的上下文信息，可以或许主动捕捉输入数据中的恒久依靠性。
[*]长短期影象网络（Long Short-Term Memory, LSTM）：是一种特别的RNN，可以或许更好地处理恒久依靠性。在自然语言处理范畴中应用广泛。
[*]天生对抗网络（Generative Adversarial Networks, GAN）：由天生器和判别器两部分组成，用于天生可以或许诱骗判别器的假样本，主要应用于图像、视频、音频等天生任务。
[*]自编码器（Autoencoder, AE）：一种无监督学习模型，用于数据压缩、去噪和特性提取等任务，可以或许学习输入数据的低维表现。
[*]残差网络（Residual Neural Networks, ResNet）：用于办理深度神经网络中的梯度消失问题，可以或许训练更深的神经网络。
[*]留意力机制（Attention Mechanism）：可以或许在输入序列中主动学习重要性权重，用于序列天生、呆板翻译、图像描述等任务。
[*]其他深度学习模型，如Transformer、BERT、GPT等，它们在自然语言处理范畴中应用广泛。
[*]在线预测：训练得到的模型根据在线输入给出输出
特点呆板学习深度学习模型复杂度较为简单，采用线性模型、决策树、支持向量机非常复杂，采用多层神经网络特性工程手工提取特性主动特性提取数据量较小数据量几百万计算资源较小较强算力GPU/TPU应用场景文天职类、推荐体系计算机视觉、自然语言处理 6. 开源搜索引擎
[*]Apache Lucene ：完全用JAVA编写的高性能、功能齐全的全文检索引擎架构，提供了完备的查询引擎和索引引擎、部分文天职析引擎。推出的目的是为软件开发人员提供一个简单易用的工具包，以方便地在目标体系中实现全文检索的功能，或是在此基础简历起完备的全文检索引擎。
[*]Apache Solr : 基于Lucence 的全文搜索服务器，流行的企业级搜索引擎，主要功能包括全文检索、命中高亮、分面检索、动态聚类、数据库集成，以及对富文本（word、pdf）的处理。高度可扩展，提供分布式搜索和索引复制，Solr 4 还增加了NoSQL支持。
[*]Elasticsearch: 基于Lucence的搜索引擎，提供了分布式、多租户的全文搜索引擎平台，支持海量数据的及时检索、聚合分析和可视化展示。
[*]Sphinx Search C++开发的全文搜索引擎：从头开始筹划时就考虑到了性能、相干性（又名搜索质量）和集成的简单性。它是用 C++ 编写的，实用于 Linux（RedHat、Ubuntu 等）、Windows、MacOS、Solaris、FreeBSD 和其他一些体系。Sphinx 让你可以快速轻松地批量索引和搜索存储在 SQL 数据库、NoSQL 存储或文件中的数据，大概即时索引和搜索数据，使用 Sphinx 就像使用数据库服务器一样。各种文本处理功能可以根据你的特定应用程序要求微调 Sphinx，而且许多相干功能确保你也可以调解搜索质量。
[*]Manticore Search：使用 C++ 开发的高性能搜索引擎，创建于 2017 年，其前身是 Sphinx Search 。Manticore Search 充分利用了 Sphinx，显着改进了它的功能，修复了数百个错误，几乎完全重写了代码并保持开源！这一切使 Manticore Search 成为一个当代，快速，轻量级和功能齐全的数据库，具有出色的全文搜索功能
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]