基于Milvus的向量检索平台实践

背景

随着计算机技术及机器学习技术的发展,特征向量作为一种多媒体数据(文本、语音、图片、视频)的描述方式,逐渐成熟起来,而向量检索(向量相似计算)也逐渐成为一种通用的需求。

向量检索在之家拥有非常广泛的应用场景,如推荐在线业务非明文召回场景,相似视频/图片/音频去重场景等等。截止到22年初,业务方部署了9个向量检索引擎去检索向量数据。随着向量检索需求增加,与之俱来了很多问题:

  • 资源浪费

    每个业务线都会搭建自己的向量检索引擎,资源没有统一管理,会出现不必要的资源浪费。

  • 维护成本

    维护向量检索引擎会有一些技术门槛,业务方无法专心于处理业务,且Vearch社区不活跃,基本上碰到问题都需要业务方自己去解决或者想办法绕过。

  • 开发成本

    为了适配新的召回需求,每次上线新的向量接入需求都需要业务方定制化开发。无法更敏捷地支持在线业务的需求变更。

  • 性能

    Vearch的性能也越来越满足不了在线业务的需求,导致在线召回项目有较高的超时率,影响线上实验及模型效果。

技术选型

之家数据开发团队在22年初开始筹备搭建向量检索平台,经过一系列开源方案的调研选型后,我们最终选择了Milvus作为向量检索平台的底层引擎。Milvus出色的架构无论是在稳定性,高可用性,可维护性,功能性及性能都有非常不错的表现。

基于Milvus的向量检索平台实践_第1张图片

我们来看下Milvus2.x版本的架构实现特点:

  • 微服务

    Milvus将服务拆成多个角色,每个角色职责划分相对独立,这样每个角色的源码阅读起来非常容易。简单介绍下Milvus的角色职责:

    • ETCD:负责存储元数据

    • 对象存储:负责存储向量数据

    • Proxy:Milvus统一的访问层

    • DataNode/DataCoord: 负责向量的写入

    • IndexNode/IndexCoord:负责向量索引的构建

    • QueryNode/QueryCoord : 负责向量的查询

    • RootCoord: 负责处理DDL去协调其他Coord,全局时间分发,维护当前元数据快照

    其中IndexNode/QueryNode/DataNode 这些角色是实际工作的Woker节点,IndexCoord/QueryCoord/DataCoord 是负责协调Woker节点,及将任务handoff其他角色的节点。

  • 支持云原生

    Milvus 服务本身是没有状态的,数据存储在对象存储,元数据会存放在ETCD。原生支持K8s部署集群部署,我们可以根据集群或者个别角色的负载去动态扩缩资源。

  • 向量操作读/写/建索引之间进程级别隔离

如上图,向量 读/写/建索引都是通过不同的节点完成,这样操作之间都是通过进程之间隔离,不会抢占资源,相互影响。

此外,Milvus还可以在查询的时候指定不同的一致性级别。在真实的业务场景中,一致性要求越强,查询对应的响应时间也会变长。用户可以根据自己的需求选择不同的一致性级别。除了Milvus出色的架构能力之外,Milvus非常活跃的社区及其背后优秀的商业公司Zillix也是我们选择Milvus的重要原因。

向量检索平台介绍

目前向量检索平台已经日益成熟,已经支持了30多个离在线需求。在性能,稳定性,资源节约方面都非常不错的提升。

基于Milvus的向量检索平台实践_第2张图片

基础设施

部署

我们通过改造Milvus 原生的部署方式,将Milvus集群部署在之家云K8s集群中。因为Milvus服务本身是无状态的,在K8s上,我们可以根据业务的查询写入需求,灵活地扩缩Milvus的服务节点,节约服务器成本。

基于Milvus的向量检索平台实践_第3张图片

监控/日志

我们将监控/历史日志采集到Prometheus/ES ,可以非常方便的通过监控日志定位问题,配置报警。

基于Milvus的向量检索平台实践_第4张图片

索引的选择

  • IVF-FLAT 倒排索引

IVF-FLAT适合数据量较小的集合,在我们的测试场景中,十万级别的数据使用IVF-FLAT索引可以得到很好的查询性能。通过调整构建索引参数nlist和查询参数nprobe,在召回准确率和召回性能之间找到适合业务需求的平衡点。

  • HNSW 图索引

图索引在大数据量集合的情况下,相较IVF-FLAT可以提供更快的查询性能,但是也会使用更多的内存。目前之家推荐召回主要使用的是IVF-FLAT索引,而对于基础数据量比较大的搜索数据,HNSW索引可以提供更高的性能。

副本、分片的选择

不同的分片数和副本数,对于高并发下的查询性能有显著影响:

  • 对于小数据量集合(十万数量级)推荐使用一个分片即可,可以通过扩展副本数,提高集合的并发能力,从而提高查询QPS。如将副本数设置与QueryNode节点数量一致,可以充分利用每一个QueryNode。

  • 对于千万级别的大集合比较容易受到资源限制(内存占用),一般无法设置太多副本。可以先通过Milvus官方提供的计算工具(Milvus Sizing Tool · Vector Database built for scalable similarity search)评估大概会占用的内存,再根据quernNode节点的实际情况确定分片数量。

容量规划

下图是我们的压测报告,经过一系列的压测我们得出结论:

(数据量:109780;索引:lvf-flat;1分片,10副本,查询参数:nlist 1024,size200,noprob 50)

  1. 每个querynode(12核16GB)可支持500QPS

  2. 每个Proxy(4核8G)可支持1200QPS

  3. querynode与Proxy比例建议为2:1

  4. 向量平台每个实例可以支持3500QPS

  5. 小数据量(<10万) 场景下,建议1分片多副本。分片数过多会导致性能下降

  6. 以上场景下,cpu消耗均低于60%,内存占用低于10%且没有持续增长的趋势

基于Milvus的向量检索平台实践_第5张图片

平台对Milvus的一些优化

之前提到我们选择Milvus的一个重要原因就是Milvus非常活跃的社区和背后优秀的商业公司,我们反馈的问题都会有社区的运营跟进。在我们对Milvus不熟悉时,社区的同学会专门来之家为我们解惑,协助我们上线。在享受社区的开源红利的同时,我们在熟悉Milvus的过程中还会向社区贡献我们对Milvus的改进:

  • 集成kafka时候指定kafka配置

    https://github.com/milvus-io/milvus/pull/18742

  • 修复QueryNode metric相关问题

https://github.com/milvus-io/milvus/pull/18367

https://github.com/milvus-io/milvus/pull/19479

https://github.com/milvus-io/milvus/pull/20426

https://github.com/milvus-io/milvus/pull/20427

  • 修复加载配置时未正确释放锁

https://github.com/milvus-io/milvus/pull/18773

  • 优化RootCoord show collection操作延迟

    https://github.com/milvus-io/milvus/pull/20124

  • 修复小数据量的集合不能及时加载索引

    https://github.com/milvus-io/milvus-sdk-go/pull/311

  • 修复birdwatcher force-release 删除元数据失败

    https://github.com/milvus-io/birdwatcher/pull/55

此外在之家内部还有些通用性低或者抽象得不太完善的实现,后面完善后会和社区讨论是否可以贡献给社区,下面分享两处查询性能方面的优化。 在我们的测试场景下,在各组件CPU使用率正常的情况下,查询索引的性能比较稳定,但经过各组件之间的RPC通信后,TP99 就会变得比较高,基本在 100 ms 以上,在网络环境差的场景影响尤为明显。以下两处优化本质都是减少RPC请求次数,避免因网络抖动导致TP99飙高。

1.弱一致性查询不去访问RootCoord获取时间戳

背景:

  1. Milvus写入的数据和RoodCoord发送的心跳都会带有RooCoord的时间戳,会写到logbroker里面 ,QueryNode会消费数据里的时间戳更新servicetime t1。

  2. 在做强一致性查询时也会向RootCoord查询时间戳 t2。

  3. QueryNode只有在 t2>t1 之后,才能确保要查询的数据都到齐了之后将查询到的数据返回给 Proxy

基于Milvus的向量检索平台实践_第6张图片

优化:

目前在弱一致性的场景也会向RootCoord同步时间,这个时间并没有应用在QueryNode, 仅仅是用来做msgID,在日志里追踪查询行为。因此在弱一致性场景我们在Proxy本地做了时间戳分发,不会再去请求RootCoord。这样可以减少一次RPC请求,避免网络原因导致查询tp99较高的问题。

2.QueryCoord分配Segment时优先分配给这个副本的shardleader节点

背景:

我们接着介绍下背景:如图我们看到的是一个集合某一个副本下两个分片的查询场景。

  1. 其中Proxy会分别去QueryNode请求两个分片的leader

  2. 由于分配Segment是基于QueryNode持有向量的行数做均衡分配的,每个shard的Segment可能会被分配到不同的QueryNode

  3. 所以shard leader需要去其他QueryNode Search Segment,会额外多一次RPC的开销

基于Milvus的向量检索平台实践_第7张图片

优化:

针对特别大的数据量集合的场景,SegmentQueryNode之间负载均衡是非常有必要的。我们存在一些在线业务场景数据量很小,只会占据很少的资源。但是对查询延迟有极高的要求。因此我们就在QueryCoord分配Segment时,关闭了rebalance checker,将Segment分配到ShardLeader所在的机器。这样就不会有QueryNode之间的查询了。

基于Milvus的向量检索平台实践_第8张图片

应用案例

推荐非明文召回:

非明文召回服务良好的支撑了用户长短期兴趣召回模型、双塔召回模型、冷启动召回模型等23个算法向量模型数据生产及24路非明文召回。

主要流程:

  1. 加工好的向量数据写到Hive

  2. 配置调度任务将Hive数据定期同步到Milvus的AB表中

  3. 在北斗系统定制召回及策略融合策略,就可以上线召回模型

最后说一下刚才说到的AB表功能,向量平台平台目前提供两种数据更新方式,增量更新和用过AB表的方式全量更新。增量更新方式适用于业务数据不断增长,必须以全量数据作为基础数据为业务提供向量检索。比如,图片、文本、视频、音频去重业务。全量更新适用于算法小数据实验,可以快速看到实验效果,每次实验数据数据会自动隔离,不会相互影响。全量更新可以精确到天、小时、分钟级别,可以满足算法不同需求。下图是AB表的流程,每5分钟调度任务会全量同步Hive中模型加工好的向量数据,待所有数据写完,索引构建成功,就会通知向量平台从查询旧表(图中collection12091610)切换到新表(collection12091815)。

基于Milvus的向量检索平台实践_第9张图片

收益:

  • 性能方面

    召回超时率较Vearch下降了3-7

    平响较Vearch下降了55%

  • 简化向量接入流程

    接入全面配置化,取代了Vearch产品需要代码开发的发布方式,上线效率提升至少1

后续规划

  1. Milvus的Upsert功能未Release,目前有部分数据量特别大的业务会强依赖这个功能。

  2. 部分去重场景需要强一致性查询,但是目前强一致的查询延迟较高,需要和社区一起探讨优化思路。

你可能感兴趣的:(milvus,人工智能)