HNSW / IVFPQ、结构化过滤、Join 与 OLAP 分析在一份存算分离内表和一条 SQL 链路中完成。作者周康阿里云开源 OLAP 引擎团队负责人数据说明本文示例均为通用化、参数化示例不包含客户或实际业务数据性能部分仅给出评测方法不披露内部实测结果。先给结论如果业务既要向量 TopK又要严格的租户、时间、权限等过滤并继续执行 Join 与聚合StarRocks 的优势在于把向量检索纳入同一张内表和同一条 SQL 链路。Stella 2.2 提供 HNSW、IVFPQ、结构化过滤、延迟物化与存算分离索引管理适合在线 RAG、语义搜索、推荐和多模态检索。判断 StarRocks 的向量检索能力不能只看是否支持余弦相似度或单次 TopK还要同时看索引类型、召回率、查询延迟、结构化过滤、数据新鲜度、扩缩容和可观测性。例如一个企业知识库需要找出与“对象存储访问超时如何排查”最相关的十段文档一个商品平台希望根据图片寻找外观相似的商品一个具身智能团队希望从历史轨迹中召回与当前失败动作最相似的训练样本。这些对象可以被 Embedding 模型编码成高维向量但传统做法往往是把向量复制到专用向量数据库再把命中的 ID 拉回分析数据库继续执行权限过滤、业务字段查询、Join 和聚合。这套架构能够运行却引入了新的工程成本原始数据、业务字段和向量分散在不同系统数据需要持续同步Schema、删除和更新需要跨系统保持一致向量召回后的权限、时间、租户等过滤通常落在应用层查询慢时很难从一份执行计划中判断问题出在召回、回表还是业务计算。那么能否把向量检索放回数据所在的分析系统EMR Serverless StarRocks Stella 2.2 在存算分离内表中支持向量索引。向量列、结构化字段和业务指标保存在同一张表里用户可以用 SQL 完成 ANN TopK、标量过滤、Join、聚合与结果分析不需要为了语义检索再维护一份独立事实数据。图 1当数据更新快、检索结果还要参与 WHERE、JOIN 与聚合时StarRocks 内表可以把向量、索引和业务字段放在一份数据中由一条 SQL 完成检索与分析。01 StarRocks 为什么需要向量索引而不是逐行计算向量检索的基础是计算查询向量与库内向量之间的距离或相似度。常见度量包括余弦相似度比较两个向量方向是否接近数值越大越相似L2 距离比较向量之间的欧氏距离数值越小越相似内积常用于已经按模型要求完成归一化或具有特定训练目标的向量空间。如果表中只有几千条数据逐行计算并不复杂。问题出现在数据规模扩大后。假设知识库有 100 万段文本每段文本使用 768 维向量表示。一次精确 TopK 查询需要读取候选向量并对大量浮点数执行距离计算然后在所有结果中排序取前十。并发增加后CPU、内存带宽和数据读取都会快速成为瓶颈。传统 OLAP 的 Zone Map、排序键和分区也很难直接解决这个问题。向量相似度由 768 个维度共同决定语义相近的两条记录在物理文件中可能相距很远用一个普通字段排序无法同时表达高维空间中的邻近关系。因此向量检索真正需要解决的不是“如何把距离函数写进 SQL”而是如何在不遍历全部向量的情况下快速缩小候选集如何在召回率、延迟、吞吐与索引成本之间取得平衡如何让向量候选继续参与数据库中的过滤、回表与分析。02 StarRocks 支持哪些向量索引HNSW 还是 IVFPQStella 2.2 内表向量索引提供 HNSW 和 IVFPQ 两类实现。二者都属于 ANNApproximate Nearest Neighbor近似最近邻但优化目标不同。HNSW用分层图快速接近目标HNSW 把向量组织成多层邻接图。查询从稀疏的高层开始以较少的跳转快速靠近目标区域再进入更密集的底层搜索邻居。它的直观优势是低延迟和较高召回率适合在线语义搜索、RAG 召回、推荐和相似内容查询。代价是索引体积、构建内存和构建时间相对较高。两个关键构建参数是M每个节点的最大连接数。增大通常有利于图质量但会增加索引体积efconstruction构建图时保留的候选数量。增大通常能改善召回率但需要更多 CPU、内存和时间。查询时efSearch控制搜索候选规模。它越大通常越有利于召回率但单次查询成本也会升高。IVFPQ先聚类再压缩搜索IVFPQ 先把向量划分到多个倒排聚类中查询时只访问最相关的一部分聚类随后使用乘积量化压缩向量减少索引存储和计算成本。它更适合数据规模较大、对索引体积和内存更敏感的场景。代价是量化会引入精度损失通常需要扩大候选集必要时再用原始向量精排。常用参数包括nlist聚类或倒排列表数量M_IVFPQ子向量数量向量维度必须能被它整除nbits每个子向量的量化位数nprobe查询时探测的聚类数量增大通常能提高召回率也会增加查询开销。如果业务还没有明确的索引容量约束建议先用 HNSW 建立延迟和 RecallK 基线再根据成本决定是否切换到 IVFPQ。维度HNSWIVFPQ主要目标低延迟、高召回降低索引体积与内存成本数据结构分层邻接图倒排聚类 乘积量化典型查询参数efSearchnprobe、max#95;codes主要代价图索引较大、构建资源高量化带来精度损失建议起点在线检索的默认基线大规模、成本敏感场景图 2HNSW 优先低延迟和高召回IVFPQ 优先大规模和索引成本建议先用 HNSW 建立 RecallK 与延迟基线再按成本评估 IVFPQ。03 存算分离内表如何管理向量索引Stella 2.2 的关键变化不只是增加USING VECTOR语法而是让向量索引进入存算分离内表的完整生命周期。索引与 Segment 一起管理内表数据以 Segment 为基本物理单元。每个满足条件的 Segment 可以生成独立向量索引文件索引文件写入共享存储并纳入 Lake Tablet 元数据管理。这意味着计算节点不需要永久持有本地索引副本。查询到来时计算节点按需读取或复用缓存中的索引计算组扩缩容后新节点也可以从共享存储恢复检索能力。向量索引文件同时进入精确 Vacuum 跟踪数据版本回收时可以识别仍被元数据引用的索引避免索引生命周期与表数据脱节。异步构建与回退保证新数据可见持续写入会产生小 Segment。若每次写入都立即构建完整图索引构建开销可能超过查询本身。因此Stella 2.2 支持通过阈值控制索引构建并支持异步创建索引。当某个 Segment 还没有可用索引或索引文件暂时缺失时系统可以只对该部分数据回退为逐行距离计算再与已经建立索引的 Segment 结果合并。这种“索引搜索 暴力搜索”的混合路径优先保证数据写入后仍可被查询。它也说明了为什么生产评测不能只看索引算法Segment 数量、索引覆盖率、冷缓存和新写入比例都会影响最终 P99。先召回 Row ID再延迟读取业务列向量索引首先返回候选 Row ID 与距离分数。完成局部 TopK 和全局合并后引擎再读取候选对应的标题、URL、标签或其他业务字段。对于包含长文本、JSON 或大字段的宽表这种延迟物化可以避免在召回阶段读取大量最终不会返回的数据。向量检索仍处于 StarRocks 的 Scan、Pipeline 和 Profile 体系中因此后续的过滤、Join 和聚合不需要绕出 SQL 引擎。04 如何用 SQL 完成向量检索、过滤与分析下面以企业知识库为例。示例使用 768 维文本 Embedding 和余弦相似度为便于阅读查询向量以[...]省略实际使用时必须传入完整的 768 个浮点数。创建 HNSW 索引CREATETABLEknowledge_chunks(chunk_idBIGINTNOTNULL,tenant_idBIGINTNOTNULL,categoryVARCHAR(64),titleVARCHAR(512),content STRING,updated_atDATETIME,embedding ARRAYFLOATNOTNULL,INDEXidx_embedding(embedding)USINGVECTOR(index_typehnsw,dim768,metric_typecosine_similarity,is_vector_normedfalse,M16,efconstruction100))ENGINEOLAPDUPLICATEKEY(chunk_id)DISTRIBUTEDBYHASH(chunk_id)BUCKETS16;生产中应让dim与 Embedding 模型输出维度一致并确保入库向量与查询向量使用同一个模型版本、预处理流程和归一化策略。如果向量已经保存在表中也可以通过CREATE INDEX异步添加索引CREATEINDEXidx_embeddingONknowledge_chunks(embedding)USINGVECTOR(index_typehnsw,dim768,metric_typecosine_similarity,M16,efconstruction100);索引变更完成后再开始性能测试SHOWALTERTABLECOLUMNWHERETableNameknowledge_chunksORDERBYCreateTimeDESCLIMIT1;状态为FINISHED才表示 Schema Change 完成。执行 TopK 语义检索SETann_params{efSearch: 100};SELECTchunk_id,title,content,approx_cosine_similarity(embedding,CAST([...]ASARRAYFLOAT))ASscoreFROMknowledge_chunksORDERBYscoreDESCLIMIT10;余弦相似度越大越相似因此使用降序如果索引采用 L2 距离则应使用approx_l2_distance并按升序排列。要命中内表向量索引查询形态需要满足几个关键条件使用与索引metric_type匹配的近似距离函数查询向量是在优化阶段可确定的常量浮点数组ORDER BY只包含一个向量评分表达式余弦相似度使用DESCL2 距离使用ASC查询包含LIMIT。组合租户、时间与业务过滤向量检索真正进入生产通常不会是“全库找十条”这么简单。权限、租户、内容类型和时间范围都属于必须严格满足的业务边界SELECTchunk_id,title,approx_cosine_similarity(embedding,CAST([...]ASARRAYFLOAT))ASscoreFROMknowledge_chunksWHEREtenant_id:tenant_idANDcategory故障排查ANDupdated_at:start_timeORDERBYscoreDESCLIMIT20;过滤条件是否在向量召回前生效取决于查询形态、索引和实际执行计划。上线前应通过EXPLAIN与 Query Profile 验证而不是仅凭 SQL 书写顺序判断。用精确检索生成 Recall ground truth去掉approx_的距离函数会逐行计算不使用 ANN 索引。它不适合大规模在线请求但可以在受控测试集上生成精确近邻作为 RecallK 的 ground truthSELECTchunk_id,cosine_similarity(embedding,CAST([...]ASARRAYFLOAT))ASscoreFROMknowledge_chunksORDERBYscoreDESCLIMIT100;ANN 的性能数字必须和 RecallK 一起看。只提高 QPS 而不说明召回率可能只是减少了搜索候选只追求接近 100% 的召回也可能付出不必要的延迟和资源成本。05 如何评测 StarRocks 向量检索性能向量检索的性能不能脱离召回质量单独衡量。建议使用公开数据集或脱敏样本固定 Embedding 模型、向量维度、距离度量和查询集合再比较精确检索与 ANN 检索。评测至少应记录以下内容查询性能吞吐、平均延迟、尾延迟与错误率召回质量以精确近邻为基准计算 RecallK必要时补充 nDCG 或人工相关性判断索引成本索引体积、构建时间、CPU 与内存消耗数据链路Segment 数量、索引覆盖率、新写入比例与结构化过滤选择率运行状态冷缓存、预热后缓存、不同并发和不同 TopK 下的结果。报告结果时应同时公开数据口径、版本、参数与测试方法避免只给单一吞吐或延迟数字。上线前还应使用目标生产版本和接近真实查询分布的脱敏样本复测。06 如何确认查询真的使用了向量索引对实际 SQL 执行EXPLAINEXPLAINSELECTchunk_idFROMknowledge_chunksORDERBYapprox_cosine_similarity(embedding,CAST([...]ASARRAYFLOAT))DESCLIMIT10;如果OlapScanNode中出现以下信息表示优化器已经生成向量索引计划VECTORINDEX: ONQuery Profile 中可以重点观察指标含义VectorSearchTime向量索引检索耗时VectorIndexFilterRows向量索引过滤的行数VectorIndexLoadTime索引文件加载耗时VectorIndexCacheHitSegments命中向量索引缓存的 Segment 数VectorIndexCacheMissSegments未命中缓存的 Segment 数如果查询计划命中索引但仍然较慢通常应按以下顺序排查VectorIndexLoadTime是否过高首次查询是否正在从共享存储加载索引是否存在大量小 Segment导致索引加载和局部 TopK 合并被放大某些 Segment 是否低于构建阈值正在回退到逐行计算efSearch或nprobe是否远高于满足召回率目标所需的水平是否返回了长文本、JSON 等不必要的大字段让回表和网络开销掩盖索引收益。07 上线前需要评估哪些成本和限制1. 存储与缓存HNSW 图结构会增加索引文件体积IVFPQ 虽然更紧凑但仍需要存储聚类和量化编码。存算分离降低了本地永久驻留要求却没有消除热索引缓存预算。2. 构建资源大批量导入、Compaction 和 Schema Change 都可能触发索引构建。提高构建并发会缩短完成时间也会提高 CPU 与内存峰值。建议在业务低峰执行存量表加索引并为在线查询预留资源。3. 数据新鲜度新数据可以通过暴力回退参与查询但未索引比例过高时尾延迟仍会增加。业务需要同时定义“写入后多久可查”和“多久进入稳定低延迟索引”两个目标。4. 召回率ANN 返回的是近似结果。生产调优至少需要同时记录 QPS、P95/P99、错误率和 RecallK。对于 RAG、风控或训练数据圈选还应继续评估 nDCG、命中率与人工标注质量。08 内表和 Paimon 湖表怎么选Stella 2.2 同时提供内表与 DLF Paimon 湖表两条向量检索路径。内表更适合数据持续更新希望新写入内容尽快可查在线 RAG、推荐、语义搜索等低延迟请求需要频繁组合结构化过滤、Join 和聚合数据规模中等愿意为更低延迟配置索引与缓存资源。Paimon 湖表更适合图片、视频、音频、文档等多模态资产规模很大强调开放格式、对象存储成本和多引擎共享数据可以批量构建 Global Index训练数据准备、内容治理等场景对检索新鲜度要求相对可控。两条路径不是互相替代。一个常见架构是把长期、多模态资产保存在 Paimon把高频在线知识或热点候选同步到内表应用仍通过 StarRocks SQL 使用相近的过滤、检索和分析逻辑。09 StarRocks 向量检索适合哪些场景综合来看StarRocks 的向量检索能力已经覆盖生产选型的关键环节ANN 索引、SQL 融合、结构化过滤、存算分离、数据新鲜度与查询可观测性。它改变的是语义检索与业务数据之间的距离向量不再需要被复制到一个孤立系统召回结果也不必回到应用层重新拼接。Embedding、租户、权限、标签、事实指标和原始文本可以留在同一张表里由同一套优化器和执行引擎完成召回、过滤、回表与分析。Stella 2.2 进一步把这条链路带到存算分离内表索引随 Segment 管理并持久化到共享存储计算节点按需加载和缓存异步构建与逐行回退保证新数据可见HNSW 与 IVFPQ 则提供不同的性能、召回率和成本平衡。因此StarRocks 更适合已经使用 OLAP 分析、希望增加 RAG、语义搜索、推荐或多模态检索并且需要频繁组合结构化过滤、Join 和聚合的团队。若只需要独立向量召回仍应结合数据规模、更新频率、RecallK 目标、索引成本和运维边界做实测而不是只看单一 QPS 数字。参考资料阿里云 EMR Serverless StarRocksStella 2.2.0发布多模态处理与分析闭环内表与湖表统一检索EMR Serverless StarRocks 内核版本说明StarRocks Vector Index 文档
