共计 2820 个字符，预计需要花费 8 分钟才能阅读完成。
阿里巴巴搜索引擎 HA3 架构
1.HA3 架构分为在线和离线两局部
• 在线是一个传统的 2 层服务架构，别离叫做 QRS 和 search。QRS 负责承受用户申请，做一些简略解决之后把申请发给上面的 search 节点，search 节点负责加载索引并实现检索，最终由 QRS 会集各个 search 节点的后果并返回给用户。
• 离线局部分为两个环节，一个环节是数据的预处理，其外围的工作是把业务和算法维度的数据加工成对索引敌对的大宽表，另一个环节是索引的构建，它的次要挑战是既要反对大规模的索引更新，也要保障索引是实时性。
2.HA3 的特点次要有三个：
• 第一个是高性能的服务架构；
• 第二个是丰盛的索引能力；
• 第三个是金字塔形的算法工作框架
这些特点是 HA3 在阿里巴巴团体内风靡十分无利的武器，但随着这几年业务的倒退，这一架构逐步成了咱们再往前进一步的拦路虎。
搜索引擎 HA3 外围挑战
具体体现在 2 个方面，一个是深度学习的浸透，另一个是数据维度的收缩。
1. 深度学习，
它的应用范畴，从晚期的精排，逐渐扩散到了粗排、检索，比方向量索引的召回。深度学习的引入自身也会带来 2 个问题：一个是深度模型的自身的网络结构通常比较复杂，对执行流程和模型大小都有十分高的要求，传统的 pipeline 工作模式是十分难以无效反对的；另外一个问题是模型和特色数据的实时更新也对索引的能力提出了很大的挑战，在线上百亿级别的更新是一个常态。
2. 数据维度的收缩，以电商畛域为例，原来思考的维度次要是买家、卖家这两个维度，当初得思考地位、配送、门店、履约等等，同样是配送，有 3 公里 5 公里送的，有同城的，还有跨城的，像这样的例子还有很多。而搜索引擎离线的工作流程会把各个维度的数据 join 成一张大宽表，这会导致数据更新的规模成笛卡尔积的模式开展，在新场景下，无论是更新的量级还是时效性上都很难满足
搜寻传统解决方案
就是依据业务数据维度的特点，把引擎分拆成过多个不同的实例，而后在业务层通过查问不同的引擎实例来失去后果。比如说饿了么的搜索引擎就有门店、商品等维度的数据，为了解决门店状态的实时变动对索引的冲击，能够部署两个搜索引擎实例，一个用来搜寻适合的门店，另外一个用来搜寻适合的商品，由业务方先查门店引擎再查商品引擎来实现。但这个计划有一个显著的毛病，那就是合乎用户用意的门店十分多的时候，门店的数据须要从门店引擎序列化到业务方再发送给商品引擎，这里序列化的开销十分大，往往须要对返回的门店数目做肯定截断，而截断的门店中很可能有更匹配用户用意的，这样对业务成果也会有比拟大的影响。特地热门的商区，不论是对用户还是卖家，都是十分大的损失。
HA3 SQL 新的解决方案
以数据库 SQL 的执行形式来重塑搜寻，外围要点有 3 条。
**1. 将原来大宽表的模式扩大
成反对多表，每个表的索引加载、更新、切换做到互相独立，把原来须要离线 join 的操作变成在线查问时 join。**
2. 彻底摈弃原有的 pipeline 的工作模式，以 DAG 图化的形式来执行，并将搜寻的性能形象成一个个独立的算子，与深度学习的执行引擎进行对立。
3. 以 SQL 的形式来表白图化的查问流程，这样不光用户应用起来简略，也能够复用 SQL 生态的一些根底性能。举个例子，电商个性化搜寻技术外面，把商品、个性化举荐、深度模型等信息别离放到不同的表中，配合上灵便的索引格局，比方倒排索引、正排索引、KV 索引等等，加上执行引擎自身能够反对并行、异步、编译优化等技术，不论是内存还是 CPU 都能失去无效利用，很轻松地就能解决业务上的各种问题。
搜索引擎 HA3 新的架构
次要分为三层：
• 最底下一层是 searchRuntime 的 Framework，其外围职责次要有索引治理和服务调度，其中索引局部次要是加载的策略和查问接口，如计算存储拆散的反对、实时索引构建的反对等等；服务调度次要解决的是过程的 failover 和服务的更新，即通常意义的面向终态的二层调度，次要的特点是以对立的形式做过程的重启、程序的更新、灰度的公布等等。
• 两头这一层是 DAG 引擎层 ，其核心内容有两个，一个是执行引擎自身，另一个就是算子。这里的执行引擎次要有三局部的能力，包含单机内图的执行，分布式的通信和深度学习，通过算子间的互联，咱们可能很不便的把搜寻的查问流程和深度学习进行对接，实现深度学习在搜寻的各个阶段的浸透，如向量检索、粗排和精排。算子局部的形象是这轮架构形象最重要的一环，把原来面向过程式的开发变成了独立性能的开发，一方面要求算子自身的性能要尽可能内聚，另一方面算子级别的治理也更有利于性能的复用和公布。
• 最下面一层是 SQL 查问层，外围的工作有两局部，一个是 SQL 解析，另外一个是查问优化。因为 DAG 的流程能够任意定制，如何让用户更不便地构建图、更不便的进行算子间的合作会是很要害的问题，简略、通用是个必须思考的，这也是咱们首选 SQL 的起因；另外一个起因是业界 SQL 的执行器，通常蕴含逻辑优化和物理优化两个环节，这个对一个简单的 DAG 的执行提供了十分好的形象，咱们也利用了这个机制来进行了很多粗疏的优化，包含图的变换、算子合并、编译优化等等。
实际案例
1. 饿了么
外卖搜寻场景的例子，假如用户在搜寻框外面输出了一个关键词 ” 牛肉面 ”，搜索引擎后盾的流程大体如下：通过用户的地位信息找到当初还在营业的、并且能卖牛肉面的门店，每个门店给出最匹配的商品，最初返回最合乎用户需要的门店与商品。在这里，门店营业状况如何、配送能力是否足够、对应的商品有没有卖完，这些数据都须要实时更新的，而在大规模的数据外面疾速找到匹配的信息，也波及到丰盛的索引技术，比方空间索引、倒排索引、向量索引等等，最初门店和商品的排序也要依赖深度模型的参加，用户的偏好、优惠信息、间隔都是很重要的因素。原有的搜寻流程是基于 elasticsearch 通过别离查问门店和商品维度的表来实现的，但会有查问后果截断和深度学习接入艰难的问题，而在 HA3 上这些问题都非常容易解决，迁徙到新架构后，不光业务的长尾问题隐没了，而且性能还晋升 1 倍，给后续算法的迭代留下了十分大的空间，这里性能的晋升次要来自于索引构造和查问优化上的一些工作。
2. 淘宝本地生存的服务
其外围的诉求也是心愿在淘宝的搜寻外面引入本地服务的概念，如天猫超市和盒马的小时达的业务，通过将门店和商品维度的数据独自分拆，不光更新能力晋升了两个数量级，还复用了饿了么搜寻的很多性能。
3. 钉钉的钉盘搜寻
业务上须要在传统的搜寻上反对钉盘文件的权限管制，因为文件和权限这两个维度数据的规模都十分大，而且更新比拟频繁，通过 HA3SQL 在线的实时本地 join，非常低提早的解决了这个问题。
4. 外部监控零碎
原来是基于开源技术 druid 构建的，但业务规模上来逐渐不能满足需要了，常常出现异常须要手动解决的状况，咱们在 HA3 的根底上扩大了时序数据索引，借助 SQL 并行执行的能力，latency 有了显著降落，稳定性也失去了质的晋升。
