搜索引擎新架构:与SQL不得不说的故事( 二 )


搜索引擎新架构:与SQL不得不说的故事文章插图
搜索引擎HA3新的架构主要分为三层:

  • 最底下一层是searchRuntime的Framework , 其核心职责主要有索引管理和服务调度 , 其中索引部分主要是加载的策略和查询接口 , 如计算存储分离的支持、实时索引构建的支持等等;服务调度主要处理的是进程的failover和服务的更新 , 即通常意义的面向终态的二层调度 , 主要的特点是以统一的方式做进程的重启、程序的更新、灰度的发布等等 。
  • 中间这一层是DAG引擎层 , 其核心内容有两个 , 一个是执行引擎本身 , 另一个就是算子 。 这里的执行引擎主要有三部分的能力 , 包括单机内图的执行 , 分布式的通信和深度学习 , 通过算子间的互联 , 我们能够很方便的把搜索的查询流程和深度学习进行对接 , 实现深度学习在搜索的各个阶段的渗透 , 如向量检索、粗排和精排 。 算子部分的抽象是这轮架构抽象最重要的一环 , 把原来面向过程式的开发变成了独立功能的开发 , 一方面要求算子本身的功能要尽可能内聚 , 另一方面算子级别的管理也更有利于功能的复用和发布 。
  • 最上面一层是SQL查询层 , 核心的工作有两部分 , 一个是SQL解析 , 另外一个是查询优化 。 由于DAG的流程可以任意定制 , 如何让用户更方便地构建图、更方便的进行算子间的协作会是很关键的问题 , 简单、通用是个必须考虑的 , 这也是我们首选SQL的原因;另外一个原因是业界SQL的执行器 , 通常包含逻辑优化和物理优化两个环节 , 这个对一个复杂的DAG的执行提供了非常好的抽象 , 我们也利用了这个机制来进行了很多细致的优化 , 包括图的变换、算子合并、编译优化等等 。

搜索引擎新架构:与SQL不得不说的故事文章插图
实践案例1. 饿了么外卖搜索场景的例子 , 假设用户在搜索框里面输入了一个关键词"牛肉面" , 搜索引擎后台的流程大体如下:通过用户的位置信息找到现在还在营业的、并且能卖牛肉面的门店 , 每个门店给出最匹配的商品 , 最后返回最符合用户需求的门店与商品 。 在这里 , 门店营业情况如何、配送能力是否足够、对应的商品有没有卖完 , 这些数据都需要实时更新的 , 而在大规模的数据里面快速找到匹配的信息 , 也涉及到丰富的索引技术 , 比如空间索引、倒排索引、向量索引等等 , 最后门店和商品的排序也要依赖深度模型的参与 , 用户的偏好、优惠信息、距离都是很重要的因素 。 原有的搜索流程是基于elasticsearch通过分别查询门店和商品维度的表来实现的 , 但会有查询结果截断和深度学习接入困难的问题 , 而在HA3上这些问题都非常容易解决 , 迁移到新架构后 , 不光业务的长尾问题消失了 , 而且性能还提升1倍 , 给后续算法的迭代留下了非常大的空间 , 这里性能的提升主要来自于索引结构和查询优化上的一些工作 。 2.淘宝本地生活的服务其核心的诉求也是希望在淘宝的搜索里面引入本地服务的概念 , 如天猫超市和盒马的小时达的业务 , 通过将门店和商品维度的数据单独分拆 , 不光更新能力提升了两个数量级 , 还复用了饿了么搜索的很多功能 。 3.钉钉的钉盘搜索业务上需要在传统的搜索上支持钉盘文件的权限控制 , 由于文件和权限这两个维度数据的规模都非常大 , 而且更新比较频繁 , 通过HA3SQL在线的实时本地join , 非常低延迟的解决了这个问题 。 4.内部监控系统原来是基于开源技术druid构建的 , 但业务规模上来逐步不能满足需求了 , 经常出现异常需要手动处理的情况 , 我们在HA3的基础上扩展了时序数据索引 , 借助SQL并行执行的能力 , latency有了明显下降 , 稳定性也得到了质的提升 。


推荐阅读