文章摘要
作为全球规模领先的短视频和直播平台,旗下核心应用的日活跃用户量已超过4亿,月活跃用户接近8亿;其旗下的图像与视频生成模型也获得了超1亿用户的青睐,覆盖全球224个国家。随着平台日均产生的非结构化数据持

作为全球规模领先的短视频和直播平台,旗下核心应用的日活跃用户量已超过4亿,月活跃用户接近8亿;其旗下的图像与视频生成模型也获得了超1亿用户的青睐,覆盖全球224个国家。

随着平台日均产生的非结构化数据持续爆发式增长,传统的关键词检索方式已无法满足从数十亿乃至数百亿条视频数据中快速定位所需内容的需求。为解决这一痛点,经过技术选型与大规模落地实践,该平台基于Milvus向量数据库搭建了覆盖全业务场景的向量检索平台,目前已管理数百亿条向量数据,其中部分单集群向量规模超百亿,为内容安全审核、视频去重、智能搜索及各类AI应用提供统一检索服务。

核心技术挑战

对于新上传的视频,需先完成内容安全审核,再与平台已有海量视频进行去重比对,判断内容是否为旧视频的重新发布(如更换水印、翻转画面等)。仅依赖标题、标签等关键词信息无法完成此类任务,系统需识别视频实际内容、理解语义关联,并在海量数据中快速找到相似结果。

除视频审核与去重外,多模态搜索、RAG知识库、AI Agent等技术的落地也让更多业务依赖语义检索,向量数据库成为核心底层基础设施。但早期团队基于Elasticsearch架构增加近似最近邻索引的方案,随着业务扩张逐渐暴露出三大问题:

一是读写资源争抢导致查询延迟不稳定。Elasticsearch的写入与查询共用节点,并发量增大时两类任务会争抢计算资源,写入压力升高时查询延迟易出现大幅波动,无法满足内容安全、风控等对响应稳定性要求极高的业务场景。

二是存储与计算资源绑定,扩容成本高。Elasticsearch的存储和计算资源耦合,扩容时需同时增加CPU与内存,无法根据实际瓶颈单独扩展,当数据规模达数百亿级时,不仅造成资源浪费,也让集群调度与管理复杂度急剧提升。

三是向量维度限制。随着Embedding模型演进,部分新模型可生成超4096维向量,但原有方案的向量维度上限仅为4096,导致业务团队无法使用更适配场景的高维模型。

为何选择Milvus

经过内部评估,团队最终选定Milvus作为向量检索的核心引擎,主要考量因素包括:

其一,分布式架构优势。Milvus将写入、查询、索引构建与集群协调等任务拆分至不同组件,实现存储与计算解耦,可分别为写入和查询分配独立计算资源,保证写入稳定性的同时,查询性能不受影响;扩容时也可根据需求单独调整查询、计算或存储资源,避免不必要的硬件投入。

其二,检索性能与灵活性。Milvus可在数十亿级向量规模下实现毫秒级检索,满足实时业务需求;同时提供HNSW、IVF、DiskANN等多种索引类型,以及SQ8、RaBitQ等量化压缩方案,业务团队可根据数据规模与性能要求灵活调整策略,在召回率、延迟、内存成本间做平衡。此外,Milvus支持数万维向量,让团队可自由选择适配的Embedding模型。

其三,集成能力与生态。Milvus将标量过滤、全文检索、混合检索及聚合查询等功能集成于同一引擎,业务团队可通过统一API完成检索,无需维护多套系统;同时作为Apache 2.0许可的开源项目,拥有成熟的社区基础,方便开展深度定制与优化。

落地方案与场景实践

选定Milvus后,团队逐步将各类向量检索需求迁移至统一平台,目前已部署多个基于Milvus 2.5和2.6的生产集群,最大单集群存储超100亿条向量,部署400多个查询节点,覆盖的业务场景包括内容安全、视频去重、RAG知识库、Agent记忆、推荐画像等,支持向量维度从64维到超10000维,峰值查询吞吐量超10000QPS。

风控与内容安全:读写分离保障稳定性能

针对风控与内容安全业务对实时性的高要求,团队采用读写分离架构,将数据写入与在线查询部署在不同节点,减少资源争抢;索引方案选择HNSW以加速近似最近邻搜索,同时引入SQ8量化压缩将单条向量体积压缩至原有的四分之一,降低内存开销;通过多副本部署提升吞吐量,最终实现数十亿向量规模下超10000QPS的峰值查询能力,还通过调整Segment大小、优化副本负载分配等调优措施提升资源利用率。

视频去重:适配Append-only数据的索引选择

视频去重是核心业务之一,方案为对上传视频抽帧后转换为向量,再进行相似性检索,可识别经水印替换、画面翻转等处理的重复内容。由于去重业务数据新增为主、旧数据极少修改,团队选择HNSW索引,契合数据访问模式,保证检索效率,每秒可处理5000至10000次查询,全天候稳定运行。

集群管理:自动化与AI辅助运维

随着集群数量增加,团队通过Milvus Operator实现集群创建、扩缩容、升级等操作自动化,新集群部署仅需数分钟;基于Grafana搭建监控体系,用Apache SeaTunnel实现跨集群数据迁移;还开发了基于大语言模型的容量规划Agent,可根据业务需求推荐集群规模与索引配置,结合人工审核确保方案合理性。

容灾部署:三可用区保障服务不中断

为应对单个数据中心故障的极端情况,团队采用同城三可用区部署方案,将Milvus分布在同一城市的三个数据中心;利用Milvus无状态组件特性,当一个数据中心故障时,其他节点可继续承担工作;通过Resource Group机制为每个数据中心维护完整数据副本,同时预留冗余资源承接流量,实现单数据中心故障下搜索与写入服务零中断。

成果与价值

通过Milvus平台的落地,团队解决了原有架构的诸多痛点,实现数十亿向量规模下超10000QPS的峰值查询能力,读写分离消除了写入压力带来的查询延迟波动;集群运维效率大幅提升,新集群部署仅需数分钟,告警SLA达99%;业务灵活性增强,支持从64维到超10000维的向量,不再受维度限制;资源利用效率优化,存储与计算分离可按需扩容,压缩方案降低内存成本;容灾能力保障了核心业务的高可用性,业务团队可按需申请集群,向量检索成为内部可便捷获取的基础能力。

未来规划

接下来,团队将持续优化平台稳定性、降低资源成本,拓展更多业务场景;同时关注Milvus 3.0的Lakebase能力,探索分层存储(热数据用高性能存储、冷数据用对象存储)与全生命周期数据管理;还将加强与开源社区的合作,把大规模向量数据库的实践经验转化为技术反馈,推动Milvus的演进。

以上内容不代表本平台立场,仅供读者参考