第二篇Doris向量检索深度实战HNSW索引与ANN搜索详解关键字Apache Doris、HNSW向量索引、ANN搜索、近似最近邻、L2距离、内积相似度、向量量化、FLAT、SQ8、PQ、faiss标签向量数据库 | 向量索引 | 近似搜索 | 相似度计算 | 数据库优化 | 机器学习 | ANN算法 | 高维向量一、引言为什么向量检索是 AI 时代的基础设施在推荐系统、语义搜索、图像识别这些 AI 应用背后有一个共同的技术支撑——向量检索。当你在电商平台浏览商品时系统会根据你的历史行为实时推荐相似商品当你用百度以图搜图时后台在数亿张图片中找到与你上传图片最相似的那些当你和 ChatGPT 对话时它需要从知识库中快速检索与问题最相关的文档片段。这些场景有一个共同的技术特征海量高维向量数据的存储和检索。作为一名在数据领域深耕多年的工程师我见过太多团队在这个环节踩坑有的团队选择了专用向量数据库却发现运维复杂度陡增有的团队在 PostgreSQL 上启用 pgvector却发现性能瓶颈无法突破有的团队干脆用 Elasticsearch 的向量插件却发现内存消耗失控。Doris 4.0 的出现给这个领域带来了新的选择。它将向量检索深度集成到 MPP 分析型数据库的内核中实现了向量搜索与结构化查询的统一管理。今天我将从原理到实战系统性地解析这套能力的实现细节和使用方法。二、向量检索基础概念2.1 高维向量数据类型在 Doris 中向量以 ARRAYFLOAT 类型存储。ARRAY 是 Doris 支持的数组类型而 FLOAT 表示每个维度是 32 位浮点数。以下是一个典型的向量字段定义embedding ARRAYFLOATNOTNULLCOMMENT文本向量化结果向量的维度dim必须与实际数据一致。以主流的 Embedding 模型为例OpenAI text-embedding-3-small: 1536 维 OpenAI text-embedding-3-large: 3072 维 BGE-large-zh: 1024 维 M3E-large: 1024 维 Jina-embeddings-v2-base-en: 768 维如果维度不匹配Doris 会在建表时报错ERROR 1105 (HY000): errCode 2, detailMessage Array size mismatch: vector dimension 1024 does not match index definition 768这个约束非常重要。在实际生产中我强烈建议在 ETL 流程中对向量维度做校验提前发现数据质量问题。2.2 近似最近邻ANN与精确最近邻Exact NN暴力搜索Brute Force是最直接的向量检索方式计算待查询向量与数据库中所有向量的距离返回最近的 TopK 个。这种方法精度 100%但时间复杂度是 O(n)在亿级数据规模下完全不可行。ANNApproximate Nearest Neighbor是一类算法的统称它们通过预处理索引结构在召回率和性能之间寻求平衡┌─────────────────────────────────────────────────────────────────┐ │ ANN 算法性能曲线图 │ │ │ │ 召回率 │ │ 1.0 ┤• │ │ │ • │ │ 0.9 ┤ • │ │ │ • │ │ 0.8 ┤ • │ │ │ • │ │ 0.7 ┤ • │ │ │ • │ │ 0.5 ┤ •─────────────── │ │ │ • │ │ 0.0 ┤────────────────────────────────────────────────────── │ │ 低 性能 高 │ │ (延迟/QPS) │ │ │ │ • HNSW • IVF-PQ • LSH • 暴力搜索 │ └─────────────────────────────────────────────────────────────────┘HNSW 是当前工业界最主流的 ANN 算法在高召回率区间90%仍能保持毫秒级查询性能。2.3 相似度度量L2 距离与内积向量相似度有两种主要的度量方式欧氏距离L2 Distance计算向量在欧氏空间中的直线距离数值越小表示越相似。L2(A, B) sqrt(sum((Ai - Bi)^2))适用场景图像特征、音频特征等未经归一化处理的原始向量。内积Inner Product计算向量的点积数值越大表示越相似。IP(A, B) sum(Ai * Bi)适用场景经过归一化处理的文本向量。余弦相似度与归一化向量的内积等价。在 Doris 中这两个指标通过metric_type参数指定-- L2 距离数值越小越相似INDEXidx_l2(embedding)USINGANN PROPERTIES(metric_typel2_distance)-- 内积数值越大越相似INDEXidx_ip(embedding)USINGANN PROPERTIES(metric_typeinner_product)重要提醒如果你使用 text-embedding-3-small 这类经过归一化的模型生成的向量必须使用内积作为度量方式因为归一化向量的 L2 距离与余弦相似度不是线性关系。三、HNSW 向量索引详解3.1 算法原理多层图结构的艺术HNSWHierarchical Navigable Small World由 Malkov 和 Yashunin 于 2016 年提出核心思想是用分层图结构实现高效的近似最近邻搜索。层3: ○────────○ 最稀疏搜索入口 │ │ 层2: ○───○───○───○ 中等密度 /│\ /│\ /│\ ○ ○ ○ ○ ○ ○ ○ ○ ○ 最稠密叶子层构建阶段每个向量被随机分配到多个层级遵循指数衰减分布层数越高向量越少在每一层为新向量构建邻居连接使用 ef_construction 参数控制搜索范围高层的边更长但数量少适合快速定位低层的边更短但数量多适合精细搜索查询阶段从最高层开始贪心地沿着最近的邻居移动当无法继续改进时下降到下一层重复直到最底层使用 ef_search 参数控制搜索深度这种设计的精妙之处在于高层的稀疏性保证了搜索的跳远能力避免陷入局部最优底层的稠密性保证了搜索的精细度确保高召回率。3.2 索引参数配置详解Doris 提供了丰富的 HNSW 参数让用户可以根据场景需求进行精细调优CREATETABLEdoc_embeddings(idBIGINT,doc_textTEXT,embedding ARRAYFLOATNOTNULL,INDEXidx_ann(embedding)USINGANN PROPERTIES(index_typehnsw,-- 必填固定为 hnswmetric_typel2_distance,-- 必填l2_distance 或 inner_productdim768,-- 必填必须与向量实际维度一致max_degree32,-- 可选默认 32ef_construction40,-- 可选默认 40ef_search32-- 可选默认 32也可通过会话变量设置))ENGINEOLAPDUPLICATEKEY(id)DISTRIBUTEDBYHASH(id)BUCKETS16;参数影响分析┌────────────────┬──────────────┬──────────────┬──────────────┐ │ 参数 │ 取值范围 │ 对召回率的影响 │ 对性能的影响 │ ├────────────────┼──────────────┼──────────────┼──────────────┤ │ max_degree │ 8 - 128 │ 值越大召回率越高│ 内存占用增加 │ │ ef_construction│ 16 - 512 │ 值越大召回率越高│ 构建时间增加 │ │ ef_search │ 16 - 1024 │ 值越大召回率越高│ 查询延迟增加 │ └────────────────┴──────────────┴──────────────┴──────────────┘在我的实际调优经验中以下参数组合是大多数场景的起始点高性能场景召回率 98%max_degree128, ef_construction512, ef_search256均衡场景召回率 ~95%max_degree64, ef_construction128, ef_search64低成本场景召回率 90%max_degree32, ef_construction64, ef_search323.3 量化压缩策略高维向量的一大挑战是存储成本。一个 10 亿条、768 维的向量数据集原始大小约为 3TB10^9 × 768 × 4 bytes。Doris 支持多种量化策略来压缩索引┌─────────────────────────────────────────────────────────────────┐ │ 量化压缩策略对比 │ ├────────────────┬────────────┬────────────┬──────────────────────┤ │ 类型 │ 压缩比 │ 召回率损失 │ 适用场景 │ ├────────────────┼────────────┼────────────┼──────────────────────┤ │ FLAT原始 │ 1x │ 0% │ 数据量小追求高精度 │ │ SQ8标量量化 │ ~3x │ 5-10% │ 大规模数据平衡方案 │ │ SQ4四位量化 │ ~6x │ 10-15% │ 超大规模成本敏感 │ │ PQ乘积量化 │ ~20x │ 15-25% │ 极大规模召回可妥协 │ └────────────────┴────────────┴────────────┴──────────────────────┘标量量化Scalar Quantization, SQ将每个 float324 bytes压缩为 1 byteSQ8或 4 bitsSQ4。实现简单精度损失较小但压缩比有限。乘积量化Product Quantization, PQ将高维向量分割成多个子空间每个子空间独立量化。压缩比可以很高但精度损失较大。在 Doris 中量化策略通过quantizer参数指定INDEXidx_vec(embedding)USINGANN PROPERTIES(quantizersq8-- flat, sq8, sq4, pq)我的实战建议在大多数生产环境中SQ8 是最佳选择。它提供了 3 倍的存储节省召回率损失控制在 5% 以内同时构建速度比 PQ 快 5-10 倍。四、向量检索函数与语法4.1 近似距离函数Doris 提供了两个核心的距离计算函数l2_distance_approximate()计算 L2 距离数值越小越相似。SELECTid,title,l2_distance_approximate(embedding,[0.1,0.2,...768维])ASdistanceFROMarticlesWHEREl2_distance_approximate(embedding,[0.1,0.2,...])1.0ORDERBYdistanceASCLIMIT10;inner_product_approximate()计算内积数值越大越相似。SELECTid,title,inner_product_approximate(embedding,query_vector)ASscoreFROMarticlesORDERBYscoreDESCLIMIT10;4.2 TopN 最近邻查询TopN 查询是最常见的向量检索场景返回与查询向量最相似的 N 条记录SELECTid,title,author,publish_date,l2_distance_approximate(embedding,:query_vector)ASdistanceFROMknowledge_baseORDERBYdistanceASCLIMIT20;执行计划分析使用 EXPLAINEXPLAINSELECTid,title,l2_distance_approximate(embedding,:query_vector)ASdistFROMknowledge_baseORDERBYdistLIMIT10;------------------------------------------------------------------------------|ExplainString|------------------------------------------------------------------------------|PLANFRAGMENT0||OUTPUT EXPRS:idtitledistance(l2_distance_approximate)||SORT INFO(distance(l2_distance_approximate)ASC)||TOP-N(memory65536)||EXCHANGEIDENTITY||PLANFRAGMENT1||OUTPUT EXPRS:idtitleembedding||HNSW SCAN0:embedding[typearrayfloat],[l2_distance100]|------------------------------------------------------------------------------4.3 范围查询距离阈值过滤除了 TopN 查询有时我们需要找到所有距离小于某个阈值的结果-- 找到与查询向量距离小于 0.5 的所有文档SELECTid,title,l2_distance_approximate(embedding,:query_vector)ASdistanceFROMknowledge_baseWHEREl2_distance_approximate(embedding,:query_vector)0.5ORDERBYdistance;范围查询的执行流程是HNSW 索引先进行粗筛找到候选集然后在候选集上进行精确计算返回满足阈值条件的结果。4.4 结合结构化过滤向量检索与结构化查询的结合是最考验引擎能力的场景。Doris 的实现采用了预过滤机制SELECTid,title,category,l2_distance_approximate(embedding,:query_vector)ASdistanceFROMproductsWHEREcategory电子产品-- 结构化过滤条件ANDpriceBETWEEN100AND1000-- 另一个结构化条件ANDl2_distance_approximate(embedding,:query_vector)0.8ORDERBYdistanceASCLIMIT20;执行计划1. 先用结构化条件过滤出候选商品如 10 万条 2. 在候选集上构建临时 HNSW 索引或利用已有索引加速 3. 执行向量相似度计算 4. 返回 Top20 结果这种设计的优势是避免了在大规模全量数据上做向量计算劣势是如果过滤条件过于严格可能导致候选集过小影响召回率。五、性能优化与成本权衡5.1 索引构建与内存管理HNSW 索引的一个关键约束是必须全量驻留内存。这意味着索引的内存占用必须小于机器的可分配内存。索引内存占用的估算公式内存占用 ≈ 原始向量大小 × 量化系数 × HNSW 开销系数 其中 - FLAT 量化系数 1.0 - SQ8 量化系数 0.3 - SQ4 量化系数 0.15 - PQ 量化系数 0.05 - HNSW 开销系数 ≈ 1.2多层图结构额外开销以 SIFT-1M 数据集100 万条128 维为例原始大小100万 × 128 × 4 bytes 512 MB FLAT 索引512 MB × 1.2 ~614 MB SQ8 索引512 MB × 0.3 × 1.2 ~185 MB PQ 索引512 MB × 0.05 × 1.2 ~31 MB5.2 量化压缩的实战经验在我的实际项目中量化策略的选择需要综合考虑以下因素数据规模数据量越大压缩收益越明显但也要警惕召回率损失累积。业务容忍度风控场景对召回率要求极高不适合激进压缩推荐场景可以适当牺牲召回率换取性能。模型特性某些 Embedding 模型如 OpenAI text-embedding对量化损失更敏感建议实测验证。以下是我在多个项目中总结的经验数据场景 │ 数据规模 │ 推荐量化 │ 预期召回率 ──────────────────┼───────────┼──────────┼────────── 高质量知识库 │ 1000万 │ FLAT │ 99% 企业知识管理 │ 1000万-1亿│ SQ8 │ 95-98% 通用推荐系统 │ 1亿-10亿 │ SQ8/PQ混合│ 90-95% 实时行为分析 │ 10亿 │ PQ │ 85-90%5.3 查询性能调优ef_search 动态调整ef_search 是在查询时控制召回率和延迟的关键参数。Doris 允许在会话级别动态调整-- 低延迟场景可接受召回率下降SEThnsw_ef_search32;-- 高召回场景延迟增加但结果更准确SEThnsw_ef_search256;冷加载优化首次查询前索引需要从磁盘加载到内存。建议在服务启动时执行一次热身查询SELECT1FROMdoc_embeddingsWHEREl2_distance_approximate(embedding,[0.0,0.0,...])1000LIMIT1;这个查询会触发索引加载之后的真实查询将直接命中缓存。并发控制Doris 的 MPP 架构天然支持高并发查询。实测数据SIFT-1M 数据集768维向量┌──────────────┬─────────┬────────────────┬────────────────┬────────────┐ │ 并发数 │ QPS │ 平均延迟(秒) │ P95延迟(秒) │ 召回率100 │ ├──────────────┼─────────┼────────────────┼────────────────┼────────────┤ │ 10 │ 163 │ 0.061 │ 0.066 │ 0.9931 │ │ 40 │ 607 │ 0.066 │ 0.077 │ 0.9931 │ │ 80 │ 859 │ 0.093 │ 0.130 │ 0.9931 │ └──────────────┴─────────┴────────────────┴────────────────┴────────────┘ 测试环境16C64GBmax_degree128ef_construction512ef_search128六、实战建表示例6.1 文档向量化存储表这是最常见的向量检索场景——将文档向量化后存入 DorisCREATETABLEdoc_store(idBIGINTNOTNULLCOMMENT文档ID,title STRINGNOTNULLCOMMENT文档标题,contentTEXTNOTNULLCOMMENT文档正文,tags ARRAYSTRINGCOMMENT标签列表,author STRINGCOMMENT作者,publish_dateDATECOMMENT发布日期,embedding ARRAYFLOATNOTNULLCOMMENT文档向量化结果,-- HNSW 向量索引INDEXidx_vec(embedding)USINGANN PROPERTIES(index_typehnsw,metric_typel2_distance,dim768,max_degree64,ef_construction128,quantizersq8),-- 倒排索引支持关键词过滤INDEXidx_title(title)USINGINVERTED PROPERTIES(parserstandard),INDEXidx_tags(tags)USINGINVERTED PROPERTIES(parserstandard))DUPLICATEKEY(id)DISTRIBUTEDBYHASH(id)BUCKETS16PROPERTIES(replication_num1,storage_mediumSSD);6.2 商品推荐表电商场景的向量检索需要支持实时查询和历史数据关联CREATETABLEproduct_recommendations(product_idBIGINTNOTNULLCOMMENT商品ID,product_name STRINGNOTNULLCOMMENT商品名称,category_idINTCOMMENT品类ID,brand_idINTCOMMENT品牌ID,priceDECIMAL(10,2)COMMENT价格,embedding ARRAYFLOATNOTNULLCOMMENT商品特征向量,INDEXidx_product_vec(embedding)USINGANN PROPERTIES(index_typehnsw,metric_typeinner_product,dim512,max_degree32,ef_construction64,quantizersq8))DUPLICATEKEY(product_id)DISTRIBUTEDBYHASH(product_id)BUCKETS32PROPERTIES(replication_num3);6.3 增量索引构建对于已有数据的情况可以先建表再构建索引-- 步骤1创建表不包含索引CREATETABLEexisting_docs(idBIGINTNOTNULL,embedding ARRAYFLOATNOTNULL)ENGINEOLAPDUPLICATEKEY(id)DISTRIBUTEDBYHASH(id)BUCKETS16;-- 步骤2导入数据INSERTINTOexisting_docsSELECT*FROMexternal_source;-- 步骤3创建索引定义CREATEINDEXidx_annONexisting_docs(embedding)USINGANN PROPERTIES(index_typehnsw,metric_typel2_distance,dim768);-- 步骤4触发异步索引构建BUILDINDEXidx_annONexisting_docs;-- 步骤5查看构建进度SHOWBUILDINDEXWHERETableNameexisting_docs;-- 构建完成后索引自动生效七、避坑指南实战中的常见问题7.1 维度不匹配问题向量维度与索引定义不一致导致查询报错或结果异常。原因Embedding 模型版本更新、ETL 流程 bug、数据源不一致。解决方案-- 在 ETL 流程中校验维度SELECTCOUNT(*)astotal,COUNT(DISTINCTarray_size(embedding))asdistinct_dimsFROMsource_table;-- 异常数据过滤SELECT*FROMsource_tableWHEREarray_size(embedding)!768;7.2 内存溢出问题向量数据过大索引构建时 OOM。解决方案选择更激进的量化策略分批构建索引增加机器内存降低 max_degree 和 ef_construction 参数-- 使用更保守的参数构建索引CREATEINDEXidx_annONlarge_table(embedding)USINGANN PROPERTIES(max_degree16,ef_construction32);7.3 召回率下降问题线上查询的召回率明显低于预期。排查步骤-- 1. 检查 segment 数量Segment 过大影响召回率SHOWTABLETSFROMtable_name;-- 2. 手动触发 compactionALTERTABLEtable_name COMPACT;-- 3. 调整 ef_search 参数SEThnsw_ef_search512;八、性能基准测试与选型建议8.1 常用数据集工业界使用最广泛的向量检索基准数据集┌──────────────────┬───────────────┬─────────────┬─────────────────┐ │ 数据集 │ 向量数量 │ 向量维度 │ 来源 │ ├──────────────────┼───────────────┼─────────────┼─────────────────┤ │ SIFT-1M │ 1,000,000 │ 128 │ 计算机视觉 │ │ GIST-1M │ 1,000,000 │ 960 │ 地理搜索 │ │ SPACEV-1M │ 1,000,000 │ 100 │ 文本相似度 │ │ TEXT2IMAGE-1M │ 1,000,000 │ 512 │ 图文检索 │ │ DEEP-1B │ 1,000,000,000 │ 96 │ 深度学习特征 │ └──────────────────┴───────────────┴─────────────┴─────────────────┘8.2 Doris vs 其他方案对比维度Doris 4.0MilvuspgvectorElasticsearch向量检索性能★★★★★★★★★★★★★☆☆★★★☆☆结构化查询★★★★★★★☆☆☆★★★★★★★★★☆运维复杂度★★★☆☆★★★☆☆★★★★★★★★★☆生态集成★★★★★★★★★☆★★★★★★★★★★成本效率★★★★☆★★★☆☆★★★★★★★★☆☆九、总结HNSW 向量索引是 Doris 4.0 在 AI 领域最具战略意义的技术突破。它将向量检索能力深度融入 MPP 分析型数据库的内核使得用户可以在同一个引擎中完成结构化查询、全文检索和向量搜索。理解 HNSW 的原理是调优的前提。多层图结构、ef_construction 和 ef_search 参数、量化压缩策略——这些知识点构成了向量检索工程师的核心技能树。在实际项目中我建议遵循先验后优的原则先用默认参数验证功能正确性再根据性能瓶颈逐步调优。向量检索是一个需要数据驱动的领域不同的数据分布、不同的查询模式都可能需要不同的参数组合。最后不要忽视量化压缩这把双刃剑。它可以大幅降低成本但也可能侵蚀召回率。在生产环境中务必建立完善的 A/B 测试机制持续监控召回率指标。