HA3搜索引擎梳理与分析

一、HA3技术体系梳理

HA3搜索引擎技术体系图

1.1 内核

网络访问存储：通过网络访问盘古系统（集中式存储）实现存储与计算分离，支持独立扩展，降低运维成本，提高稳定性
热数据cache：支持使用mmap（lock/非lock方式）、blockcache对数据进行加载，实现对热数据的memcache
自适应bitmap：支持根据检索热度自动将部分token转换为bitmap倒排
分层存储：对于超内存数据量、高性能检索、有持久化需求场景，通过将数据根据热度分层，进行不同程度的压缩并存放在不同存储介质的方式，平衡检索性能、存储成本等需求
短链优化：将链长较短的倒排链自动转换为kv存储，提高检索性能
检索性能优化：在主键检索时，用hashtable替换二分查找，以可以接受的空间成本换取时间；range索引在建库的时候，把每一个整数按位拆分成多个倒排的term然后建立倒排索引，每个range索引目录下，包括两个子目录，分别是低4位和高60位的term建立的倒排索引，查询的时候会合并二者的结果。
数据压缩：针对数据重复等场景进行优化，减少冗余存储
数据分片：通过数据分片的设计，提高离线/实时数据任务的并行度，从而提高数据实时性
持久化：优化数据从内存dump至磁盘的过程中存在的性能问题
动态索引配置：支持动态新增正排、倒排字段，降低运维成本

红色字体为业务需要但artis体系不具备的能力。

1.2 组件

检索过滤：支持交、并、过滤等检索语义
全量/增量更新：支持全量/增量数据的离线全局计算
doc截断/回收：在全量/增量任务中，可以根据一定规则，将无效的doc丢弃，也可以根据定制的排序结果，将部分doc截断
doc聚合：根据doc中包含的token将doc排序，使建立倒排时，同一个倒排链中的doc在存储上相邻，从而提升在线检索访存的局部性
实时更新：以lib形式提供实时数据更新

红色字体为业务需要但artis体系不具备的能力。

1.3 架构

1、在线

Ha3是搜索体系中的在线部分，在其系统内部，包含Qrs(Query result searcher)和Searcher两种基本的角色。
Qrs用于接收用户查询，将用户查询分发给Searcher，收集Searcher返回的结果作整合，最终返回给用户，这里的用户既指直接通过http请求查询引擎的自然人，也指Ha3的上游服务，如sp(搜索链路的Ha3上游服务)和tpp(推荐链路的Ha3上游服务)。
Searcher是搜索查询的执行者，倒排索引召回、统计、条件过滤、文档打分及排序及摘要生成的过程都是在Searcher上完成的。根据业务的需要，有时也会把摘要(Summary)单独分出来，搭建一套独立的摘要集群。
在实际的部署中，Qrs和Searcher都是采用多行部署的方式，可以根据业务的流量变化作调整。Searcher还可以根据业务的数据量调整列数，解决单机内存或磁盘放不下所有数据的问题。
Qrs和Searcher都可以通过运维系统挂载到发现服务上，这里提到的发现服务通常是cm2和vipserver。结合gig 这个搜索团队开发的RPC lib，对Qrs和Searcher的访问均可以做到自动的流量均衡及坏节点检测降级，达到业务上的平稳运行。

2、离线

我们把索引数据的生成过程称作离线过程。Ha3的索引是通过搜索团队开发的Build Service系统生成的。
Build Service首先是一个独立的服务，通过运维系统对数据源产出的信号监控，这个独立服务产出全量和增量索引到hdfs上，通过dp分发给Ha3的Searcher。全量索引的产出周期通常是一天或数天，增量索引的周期通常是几十分钟。
Build Service也以lib的方式存在于Ha3当中，用于实时处理增量消息，直接将索引生成到Ha3 Searcher的内存当中，这样，Ha3的查询结果对数据时效性的保证能做到秒级。但这种方式也比较耗内存，随着实时消息的到来作线性增长，因此每次加载增量索引时，Ha3都会清理实时索引的内存。

1.4 插件

为了实现业务的可定制化，Ha3提供了插件机制。在前文介绍的离线和在线流程的各个环节中，Ha3用户可以通过开发自己的插件，对原始文档、查询Query、召回、算分、排序、摘要做业务上所期望的修改。

二、HA3问题视角梳理

2.1 HA3在INDEXLIB检索内核上支持了哪些功能？做了哪些优化？

INDEXLIB内核直接丰富的交并、过滤的检索语义，方便业务方使用
在性能方面，针对短倒排链、主键检索等场景进行了技术细节的优化
为了进一步提升检索效率，在全量/增量组件中，支持将相同token的doc聚合在一起，提高倒排检索时的访存局部性

2.2 如何解决存储与计算耦合导致的资源浪费和运维成本高的问题？

通过网络访问集中式存储（盘古）来实现存储与计算分离。分离后，计算节点和数据节点可以独立水平扩展，且计算节点的发布、回滚的操作无需数据分发，节省了时间。
但是，网络IO相对磁盘IO而言，在传输带宽与CPU开销上仍有不足，如何平衡各方面的性能瓶颈仍需要探索。

2.3 针对超内存数据量，HA3有哪些亮点？

在内核层面：

INDEXLIB支持通过cache置换的方式加载数据，实现热数据缓存
采用分层存储，对不同热度的数据进行不同程度的压缩，并存储在不同介质上，以此来平衡检索性能和存储开销
支持自适应bitmap，自适应的动态将高频token转换为bitmap倒排检索，提高检索效率，节省存储空间
通过简化冗余数据存储节约存储开销

三、HA3引擎特点

超内存数据存储与检索
计算与存储分离
将检索流程抽象为系统架构（流程上，抽象为qrs、searcher、summary）
离线、在线、运维一体化

四、关于HA3的一些思考

4.1 计算与存储分离的本质

计算与存储分离的本质是解决硬件资源的短板效应，从而提高资源利用率及运维效率。
计算存储分离的收益主要在于：
1、计算节点和存储节点可以独立扩展
计算节点和存储节点可以独立扩展之所以能称之为“收益”，是建立在如下潜在假设下的：

工程上存在多个计算节点访问同一份数据的需要
随着数据量的增大，扩展计算节点时带来的不必要冗余存储成本提高已经不可忽视

2、计算节点扩容/发布/回滚时无须准备数据
该收益点建立在如下潜在假设下：

准备数据的时间是扩容/发布/回滚时耗时最长且不可容忍的一环

从上面的分析中可以得出结论：若计算量较小或数据量较小，计算节点于存储节点独立扩展的架构收益是有限的，因为此时无须进行扩展或扩展导致的数据冗余存储成本并不高；当数据量大且计算量大时，支持独立扩展可以节省大量存储资源。

在系统设计中，计算与存储始终是不对等的，计算与存储分离的架构节省的更多的是存储成本而非计算成本。造成这种不对等的原因是：

对于大多数业务，计算资源成本高于存储资源成本。为了提高在线服务响应速度，系统设计方案更倾向于把大量复杂计算的结果存储下来，而非每次请求时重新计算。即使这样，在线的计算资源相对于存储资源仍然是稀缺的。
随着业务发展，在线响应速度要求越来越高且计算量越来越大，逼迫大多数业务将计算结果以数据的形式存储下来，从而引发存储量的激增。
存储的性质是可以被计算节点复用，冗余存储本身就可以被复用的内容本质上是一种浪费。

假设CPU计算速度是无限的，且成本很低，存储成本却非常高，那么可能：
（1）无须进行数据存储，而是每个请求都进行独立计算（存储也是计算的结果）
（2）单机计算资源非常充足，每个流量对应到来后，先去获取一些必要数据（量可能很小），而后直接扔到计算节点里去计算，得到结果
（3）随着业务增长，流量总量越来越大，导致单机存不下所有可能会用到的数据，需要扩展，此时，若进行计算与存储分离的架构设计，节省的就是计算资源了

在未来，量子计算或许能颠覆计算与存储分离的架构。

4.2 HA3计算与存储分离方案中涉及的问题

1、读写速率
HA3采用网络访问存储的方式实现计算存储分离，本质上是将对硬盘的访问转移到对网卡的访问。为此，须调研当前硬件参数。
万兆网卡：1.1GB/s
硬盘（SSD）：写 1.2GB/s 读 2GB/s
SSD_PCIE
SAMSUNG MZQLW3T8HMLP-00003

可见，从理论速率角度来看，SSD的写速率和网口传输速率相当，但是SSD的读速率是网口传输速率的两倍。因此采用网络访问存储的方式实现计算存储分离会将读速率钳制在网口速率，可以通过双网卡解决这一问题（由于1.1GB/s的读速率在大多数场景已经可以接受，不解决这一问题也可以）。
2、CPU开销
由于网络通信不可避免地使用一些高级网络协议，相比于硬盘IO势必要占用更多的CPU；同时，由于网络传输存在时延，会导致CPU挂起或者进行频繁的线程切换，也会引入CPU开销。因此，需要结合具体场景的CPU使用情况来确定是否适合使用网络访问存储的模式。
3、数据分布特点的影响
网络访存 + 热数据cache时这一方案的核心。但是，当数据不具备明显的冷热分布特性时，访问服务的rt可能会变得难以接受。
4、瓶颈效应
计算与存储分离后，计算资源、存储资源、广义的IO资源（包含磁盘IO、网络IO、内存IO、总线IO等）之间可能存在短板效应，较容易被忽略的是广义的IO资源的短板。在集中式管理存储时，同时也应考虑到由于IO资源不足，导致不得不引入冗余存储。一个解决这个问题的思路是将数据按照访问热度打散，避免单节点IO过于密集。

4.3 小数据量的可行方案

当数据量较小时，可以使用一些低成本的方案实现计算与存储分离。

如上图所示，通过docker间数据共享以及docker实例管理实现计算与存储分离。

如果感兴趣，欢迎关注微信技术公众号