作者:sauronzhang、flashlin、fengshanliu,微信后台开发工程师
在一些推荐系统、图片检索、文章去重等场景中,对基于特征数据进行 k 近邻检索有着广泛的需求:
在经过调研后,发现已有的解决方案存在以下问题:
基于上述的这些要求以及业内组件的限制,我们借助 WFS 和 Chubby 设计并实现了 SimSvr,它是一个高性能、功能丰富的特征检索组件,具有以下特点:
SimSvr 目前已广泛应用于微信视频号、看一看、搜一搜、微信安全、表情搜索等业务,接下来会阐述 SimSvr 的设计以及如何解决来自于业务的难题。
ANN 问题在学术界已被长期研究,并且已有成熟的开源 ANN 搜索库存在,如 nmslib、hnswlib、faiss 等。在 SimSvr 中,性能及集群的存储容量是最主要考量的两个指标,因此选择了以下两个检索引擎:
ANN检索引擎效果对比
在 ip2cos 距离转换的理论基础上,我们使用看一看视频实时 DSSM 模型进行了实际召回情况的效果对比(64 维、ip 距离、100 万索引数据量,进行 1 万次查询取平均耗时),并见证了 ip2cos 的神奇效果:
从结果中可以看到,在相同迭代轮次下,不使用 batch kmeans 的方法训练耗时更长,且没有很好收敛,导致召回率不高。
为了满足单模块多模型的需求,SimSvr 使用了表的概念进行多模型的管理;另外,为支持亿级以上 HNSW 索引的表,并且希望能够并发加速构建索引,我们根据单表的数据情况,将一张表分成了多个 sharding,使得每个 sharding 承担表数据的其中一部分: tablei 的索引,由 shard0、shard1、…、shardn 构成一份完整的索引数据;而 sect 的数量则决定了表的副本数(可用于伸缩读能力、提供容灾等)。 在 SimSvr 中,我们将一个 shardi_sectj 称之为一个 container,这是 SimSvr 中最小的数据调度和加载单位。
SimSvr 架构
增量持久化
增量更新
随着推荐系统的强势发展,特征检索的使用场景越来越广泛。而作为基础组件,除了要拥有支持亿级索引的基本素养外,在功能特性上也需要不断迎合业务的发展。因此我们开发了 SimSvr,搭配特征存储 FeatureKV,在视频号、看一看、搜一搜等推荐系统中发挥了重要的作用。
7月23日19:30
第二届“腾讯运维技术开放日
“运维进阶之路”
将举行线上直播!
海报底部扫码添加“他二哥”进微信群
一起做运维大牛!
想了解鹅厂程序员有多硬核?
有哪些欢乐沙雕日常?
快来视频号找我们!
扫码关注腾讯程序员