作者：温佳豪，快手数据引擎技术中心架构师
>**导读**：大模型和 AI Agent 落地之后，多模态内容向量化与相似度检索逐渐成为大数据分析的基础能力。在快手，基于 Apache Doris 深度定制的 Bleem 分析引擎在承载标量分析的同时，将向量检索扩展到了千亿级规模。本文系统梳理 Bleem 引擎在存算分离架构下的演进过程，重点介绍在千亿规模、高维向量与成本约束下，结合 IVF-ON-DISK、RaBitQ 量化与全局两层索引的设计方案与实测收益，并总结生产环境沉淀的工程经验。

在快手内部，基于 [Apache Doris](https://doris.apache.org/) 深度定制优化的 Bleem 引擎，一直承载着商业化广告、AB 测试、风控圈定、电商数仓等核心业务，是快手大数据分析的核心底座之一。
随着 AI 业务的爆发，团队收到向量检索需求，梳理下来主要分为两类：
- **存量场景升级**：例如风控圈定场景，此前使用图片 Embedding 进行相似检索，主要通过暴力精确计算（全量比对）实现。数据量小时，还能应对，数据量爆发增长时，算力消耗和延迟越来越难接受，急需引入高效的向量索引。
- **增量需求演进**：原本只做标量分析的业务开始叠加向量能力。包括电商语义搜索/以图搜商品、广告相似素材挖掘、大模型训练语料检索、内容安全比对，以及基于 RAG 的 Agent 类应用。

从底层负载特性来看，这类需求表现出明确的分析型特征：
1. **数据体量大且结构分化**：单场景可达千亿级规模（在 2048 维下，千亿条数据接近 1 PB）。原始向量体积大，占存储成本主体；量化压缩后的索引文件相对较小，且多数查询仅返回 Top-K 结果。“原始数据大、索引小、输出更小”的特征为后续分层存储提供了依据。
2. **注重目标召回与性价比**：不同于在线搜索或推荐对毫秒级端到端延迟的追求，该类离线与交互分析任务的核心指标是在满足目标召回率（如 95%+）的前提下，实现计算资源消耗与存储成本的最优配比。
3. **多模态与标量数据同源**：业务通常需要在单条查询中同时完成标量过滤与向量近邻检索，倾向于在单一分析引擎内闭环处理，避免多系统流转的数据搬迁开销。

**Apache Doris 原生具备融合多模态检索（结构化查询 + 全文检索 + 向量索引）的演进方向。团队选择在 Doris 上扩展千亿级向量检索能力，不仅能直接覆盖复合检索，还能复用已有的调度、隔离与运维监控体系**。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/41f3903107e800402641d35b70b0aea4.png)
## 一、部署架构

为在千亿规模下平衡存储成本与查询延迟，系统采用**存算分离**架构作为主力部署形态，并配套读写分离与资源隔离机制。
### 01 端到端数据链路与前过滤语义

数据链路可概括成四个环节：数据导入 → 索引构建 → 向量检索 → 结果处理。
其中数据导入分为离线和实时两条链路。离线的走 Spark 从数据湖批量抽数，实时的走 Flink 从 Kafka 写入。数据进来后，Doris 会在存储层给向量列建好 ANN 索引，跟数据一起持久化。
在向量检索环节，系统统一采用前过滤（Pre-filtering）语义：
一条 SQL 既包含标量条件，又包含向量近邻。前过滤先通过倒排索引快速筛出满足标量条件的行号（row id 白名单），随后将白名单传给向量索引，仅在合规子集内计算距离。若谓词条件复杂无法走倒排，或过滤后候选集极小，系统会自动降级回退（Fallback）至暴力精确计算，兼顾查准率与数据完备性（该回退机制后文将详细展开）。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/416d1be8ed85eeeb13abe662699740fd.png)
检索结果的流向分为两类：
- **小 Top-K（百到千级）**：走在线接口，直接低延迟给到客户端；
- **大 Top-K（百万到千万级）**：直接刷进数据湖，拿去给下游做分析或者做大模型训练语料。

### 02 存算分离与多级缓存策略

为在千亿规模下平衡存储成本与查询延迟，系统采用**存算分离**作为主力部署形态。基于“原始向量体量大（千亿条近 1 PB）、量化索引小、查询输出更小”的数据特征，系统在存算分离架构下落地了分层存储与多级缓存：
- **内存层隔离缓存**：标量列由通用页缓存（Page Cache）服务；向量索引则占用独立的 ANN 倒排链缓存。两者在物理层面相互隔离并配置独立配额，避免资源竞争。
- **磁盘层队列管理**：本地磁盘依托 File Cache 机制，按内容类型划分为不同队列。向量索引文件独立存放于 Index 队列中，与普通数据列隔离管理并实现常驻。

在实际检索过程中，数据读取**优先命中内存 ANN 索引缓存，未命中则读取本地磁盘 Index 队列、极少数冷数据回源远程存储**。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/52c1e9d8a1a3e04b42376537995701d5.png)
### 03 读写分离与写入即预热

系统通过划分逻辑计算组（Compute Group）实现读写分离，不同计算组之间资源物理隔离，共享同一份底层远程数据：
- **负载完全隔离**：写入与后台数据合并（Compaction）的算力与 IO 限制在导入计算组内部，保障查询计算组的检索延迟平稳受控。
- **事件驱动预热**：向量索引在导入侧构建完成后，导入组主动向查询组的目标节点派发预热任务，触发其提前将远端索引文件拉取至本地磁盘。
- **一致性哈希路由**：基于一致性哈希将数据分片稳定路由至固定计算节点，确保预热目标节点与实际执行查询的节点精准对齐，提升本地磁盘缓存命中率。

![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/f87bd8a1730bcb8b35d93a325f65297c.png)
### **04 场景化资源隔离与管控**

不同向量检索场景的技术指标差异显著，单一定制的配置参数难以满足多样化的负载需求。针对交互式分析（追求低延迟、小 K 值）与离线批量任务（追求高吞吐、大 K 值）的技术指标差异，系统实现了细粒度的资源控制。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/d4f7556af678fa48a205911ca00f46aa.png)
- **物理计算组隔离**：依据业务场景划分独立的计算组，避免不同负载间互相抢占算力。
- **会话级参数控制**：探查链数（`nprobe`）等核心向量检索参数由会话变量（Session Variable）动态驱动，允许各业务按需调整检索策略。
- **差异化熔断与并发控制**：交互式场景设置较短超时并快速失败，以保护延迟；离线批量场景放宽超时时间、侧重吞吐。

## 二、索引选型

千亿规模下的向量选型，本质是在**召回率、性能与成本**的不可能三角中寻得平衡。针对场景“成本高度敏感、追求目标召回、不追求毫秒级极致延迟”的特征，选型策略确定为：**守住目标召回，优先压低内存成本**。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/63c9ab7614cb695bfc1b7da93491917c.png)
### 01 IVF-ON-DISK：千亿规模场景的必然选择

Doris 的向量索引能力基于开源向量数据库引擎 Faiss 构建，原生支持 HNSW、IVF 与 IVF-ON-DISK 三种索引结构。
HNSW 召回率高、查询延迟低，但要求**全量常驻内存**；常规 IVF 同样要求**倒排链全量常驻内存**。对于千亿条 2048 维数据（索引体积近 1 PB），全内存方案硬件成本无法接受。
系统最终选择 [**IVF-ON-DISK**](https://www.selectdb.com/blog/1698)：仅将簇中心等小体积元数据常驻内存，体量最大的倒排链沉降至磁盘，检索时按需加载并由专属 ANN 内存缓存兜底。该方案成功解耦了常驻内存开销与总数据规模，成为千亿场景下的必然选择。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/d30c78262dfa94ee6d408f79ba05570d.png)
以 2048 维单条向量（约 8 KB）计算，千亿条数据的原始体积接近 1 PB，生成的索引体积与原始数据相当。若采用 HNSW 或常规 IVF，需要部署数百 TB 级别的内存集群来维持索引常驻，硬件成本不可接受。**IVF-ON-DISK 成功打破了常驻内存开销与总数据规模的线性绑定关系**。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/762b8f008365c2407af01dd8ac34a666.png)
具体来看实现机制，IVF-ON-DISK 包含三个核心环节：
1. **元数据与数据解耦**：在 Doris 视角把索引文件看作元数据与倒排链本体两部分。元数据体积极小，加载时常驻内存；倒排链体积庞大，保留在磁盘介质。
2. **按需延迟加载（Lazy Loading）**：检索过程中根据粗聚类结果确定目标簇后，仅针对命中的倒排链执行磁盘读操作。
3. **专用缓存兜底**：读取上来的倒排链数据直接进入独立的内存 ANN 倒排链缓存。高频访问的热链稳定常驻内存，冷链数据按需从本地 File Cache 或远程存储读取，实现了存储容量与检索吞吐的解耦。


### 02 量化算法：RaBitQ

确定 IVF-ON-DISK 索引结构后，还需解决倒排链内部的存储密度问题。在 Doris 原生支持的 SQ（Scalar Quantization，标量量化）与 PQ（Product Quantization，乘积量化）基础上，系统引入了 RaBitQ 量化算法。三类算法的技术特征如下：
- **SQ（标量量化）**：实现简单且精度损失较小，但压缩比上限受限（通常为 4 倍至 8 倍）。
- **PQ（乘积量化）**：将向量切分为多个子空间分别聚类，能够提供极高压缩比，但会带来一定的精度损失，且需要消耗计算资源训练并维护额外的聚类码本。
- **RaBitQ**：无需切割子空间，亦无需训练与存储码本，通过随机投影与标量量化构建带有理论误差界的距离估算法。其核心特性在于**误差界随向量维度的升高而收紧**，即维度越高，距离估算越精准。

系统最终选定 **4-bit 密度的 RaBitQ 方案（对应 8 倍存储压缩）**。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/b3ff3b204957883d31879f597f6822c5.png)
为验证量化算法在不同维度下的表现，团队在开源标准数据集 SIFT-1M（128 维）与快手真实业务数据集 KWAI-1M（2048 维）上进行了对比评估。测试涵盖了维度差异达 16 倍的场景，实测数据如下：
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/5642a762fa070b314dfe8248de949d71.png)
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/858de49e33c0e3e45594b4e36bad5f28.png)
PQ 压缩比高、生态成熟，代价是需训练并常驻码本、且有整除与训练门槛约束；RaBitQ 量化免码本、带理论误差界，契合快手的主力高维业务场景。
### 03 基于表分区的全局两层索引

Doris 的向量索引默认构建在数据文件（Segment）粒度。千亿规模下 Segment 数量剧增，单次查询触达的 Segment 过多，会导致跨段归并与分片元信息处理开销过大。
为此，系统将 IVF 的粗聚类逻辑上移，与 Doris 的表分区（Partition）机制融合，建立了**全局两层索引架构**：利用全量向量训练全局质心，将向量按就近原则归簇，并将簇 ID 映射为表的分区键。查询分为两级执行：
1. **第一层（分区级粗筛）**：查询规划阶段（FE）首先比对全局质心，通过标准分区裁剪剔除大量无关表分区。
2. **第二层（段内精算）**：仅在选中的少数分区内部，加载 Segment 级 IVF-ON-DISK + RaBitQ 索引执行精细检索。

![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/3a5f2a747ea65087efa58417210f06bd.png)
**其次**，针对高维 Embedding 语义倾斜易产生“巨型簇加空桶”导致裁剪失效的问题，系统在质心训练阶段引入**带容量上限硬约束的均衡 K-Means 算法**。该算法将簇间变异系数从 0.53 压降至 0.15，最大与最小分区的记录数差距从 12 倍收敛至 2.3 倍，保障了第一层分区裁剪的实际剪枝效率。两层裁剪叠加后，单次查询实际参与计算的向量数据量降至全表体量的 1% 左右。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/d60a38c03d566e64afc2bdcb9c568253.png)
### 04 线上实例与真实收益

为验证上述选型与架构优化的综合效果，系统在快手线上一个 2048 维、千亿规模的真实向量表上进行了评估。
**测试配置如下**：
- 第一层全局分区划分为 1024 个聚类簇，查询时探查最近的 128 个分区；
- 第二层分区内部采用 **IVF-ON-DISK + RaBitQ（4-bit 量化）**，探查 128 条倒排链。

实测数据显示，完整全局两层索引方案相比暴搜：**查询耗时缩短 120 倍（42 分钟降至 21 秒），扫描字节数降低 4800 倍，CPU 消耗降低 57 倍，峰值内存降低 23 倍**，验证了该方案在千亿级高维向量检索场景下的可行性与性价比。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/742c1e06dd951fba67d15a30462769b7.png)

## 三、生产环境工程实践

在大架构落地之外，针对生产环境中的典型性能瓶颈，团队在工程实现上进行了端到端的深度优化：
### 01 回退暴搜加速：基于量化码估算距离

当标量谓词无法由倒排索引处理、或过滤后剩余候选集极小时，系统会自动回退为暴力精确计算（暴搜）。传统回退需要将完整的原始浮点向量从磁盘读回内存并逐行计算距离。
核心优化思路是：在 IVF-ON-DISK + RaBitQ 索引架构下，避开原始向量读取，直接利用 Segment 内现有的 RaBitQ 量化码按行号估算距离，免去原始向量读取；同时按存活行密度自适应切换“逐点读”或“批量读”。
优化后，回退耗时缩短 **6.8～14 倍**，峰值内存降低 **4～7 倍**，估算距离与精确距离的平均相对误差仅 0.1%。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/630e54817e5ee3f9d21423c6282b66fa.png)

### 02  大 K 语料检索优化：SQL 执行路径改写

在离线模型语料构建等场景中，业务常需一次性检索出数十万至百万级别的近邻，并输出对应的原始向量。直接执行极易导致内存溢出（OOM）。
为此，系统将检索逻辑进行**“排序”与“取向量”解耦**。子查询仅检索主键与距离，归并后将 Top-K 结果广播生成 Runtime Filter，各节点本地并行回表精准读取原始向量。
优化后，在百万级 K 值检索场景下，扫描字节数降低约 **15 倍**，峰值内存由 39 GB 大幅降至 821 MB（**降低约 47 倍**），彻底消除了超大 K 值查询引发的内存熔断风险。
![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/10562d98a1a4a76128737f8d011015a4.png)

### 03 大规模场景关键参数调优

针对千亿级超大向量负载，团队在导入与查询两侧沉淀了以下关键调优参数：
- **导入侧**：严格限制单节点索引构建并发；将单 Segment 行数与聚类数调整至匹配量级；启用存算分离的异步预热，且**仅预热向量索引文件**。
- **查询侧**：按需配置全局与区内的探查链数（`nprobe`）；加大 ANN 倒排链专属内存缓存，关闭超大数据集下的通用列存 Page Cache；调高回退阈值，促使标量谓词尽量被倒排索引完全消化。

![image\.png](https://developer.qcloudimg.com/http-save/yehe-10695849/43761f4f7b138f0db898f7fa784c7079.png)
## 四、 未来演进规划

在千亿级向量检索稳定运行的基础上，快手也在与 Doris 社区保持积极合作，将在实践中沉淀的优化经验与相关能力逐步回馈社区，推动向量检索能力的持续演进。团队后续的演进工作主要集中在三个维度：
1. **多模态混合检索与重排**：推进多模态向量特征（文本、图片、视频）与标量信号的联合检索，结合多路召回与融合重排（Fusion & Rerank）机制，降低单一通道的漏召率。
2. **向量存储解耦**：将定长、只读的大体积向量数据从常规列式存储中解耦，转为独立的纯二进制文件存储，主表仅保留逻辑指针，消除后台 Compaction 阶段对向量数据的重复编解码与读写开销。
3. **数据湖多模态检索集成**：强化 Doris 对 Paimon 等湖格式外表的索引下推支持，使计算引擎能直接识别并利用湖上的全文与向量索引，实现数据免搬迁的就近检索。


## 五、结束语

Bleem 引擎从实际业务需求出发，基于 Apache Doris 深度扩展向量检索能力，通过**存算分离与多级缓存**平衡了成本与性能，依托 **IVF-ON-DISK 结构、RaBitQ 量化与全局两层索引架构**，在千亿级高维向量场景下拿到了数量级的性能与资源收益，并完成了回退加速与大 K 值改写等工程实践。方案与线上实测数据可为行业内海量多模态检索任务的落地提供参考。

>如果你有同样的需求，或对 Apache Doris 向量检索、千亿级多模态数据分析的架构设计与工程落地感兴趣，欢迎进行社区交流与共建。
[SelectDB](https://www.selectdb.com/) 是基于 Apache Doris 的商业版本，为企业提供千亿级混合检索开箱即用、集群性能调优及 7×24 专家级技术保障。欢迎访问 [SelectDB 官网](https://www.selectdb.com/)申请试用或咨询企业级落地方案。

导读：大模型和 AI Agent 落地之后，多模态内容向量化与相似度检索逐渐成为大数据分析的基础能力。在快手，基于 Apache Doris 深度定制的 Bleem 分析引擎在承载标量分析的同时，将向量检索扩展到了千亿级规模。本文系统梳理 Bleem 引擎在存算分离架构下的演进过程，重点介绍在千亿规模、高维向量与成本约束下，结合 IVF-ON-DISK、RaBitQ 量化与全局两层索引的设计方案与实测收益，并总结生产环境沉淀的工程经验。

快手基于 Apache Doris 千亿多模态检索的实践

导读：大模型和 AI Agent 落地之后，多模态内容向量化与相似度检索逐渐成为大数据分析的基础能力。在快手，基于 Apache Doris 深度定制的 Bleem 分析引擎在承载标量分析的同时，将向量检索扩展到了千亿级规模。本文系统梳理 Bleem 引擎在存算分离架构下的演进过程，重点介绍在千亿规模、高维向量与成本约束下，结合 IVF-ON-DISK、RaBitQ 量化与全局两层索引的设计方案与

数据库

大数据

人工智能

快手Bleem引擎基于ApacheDoris实现千亿级向量检索，采用存算分离架构、IVF-ON-DISK与RaBitQ量化技术，结合全局两层索引，将查询耗时缩短120倍、CPU消耗降低57倍，有效平衡成本与性能，适用于多模态数据分析场景。

2026上云采购 | AI焕新·智启新局

bigdata-class

tchoused

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

快手基于 Apache Doris 千亿多模态检索的实践-腾讯云开发者社区-腾讯云

快手基于 Apache Doris 千亿多模态检索的实践

快手基于 Apache Doris 千亿多模态检索的实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐