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

背景

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

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

• 资源浪费

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

• 维护成本

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

• 开发成本

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

• 性能

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

技术选型

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

我们来看下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部署集群部署，我们可以根据集群或者个别角色的负载去动态扩缩资源。

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