Apache Doris向量检索引擎实现

陈林忠百度大数据平台部2024.12.14 分享嘉宾 陈林忠 百度大数据平台部资深研发工程师ApacheDorisCommitter主要从事分布式存储、分布式数据库的研发工作 目录 什么是向量检索01 ApacheDoris怎么做向量检索02 遇到的问题及解法03 未来规划04 01什么是向量检索 非结构化数据在迅猛增长 结构化数据 •文字•日期•数字等 非结构化数据 •图片•音频•视频、文本等 面对海量非结构数据，如何去处理分析挖掘价值？ 如何表示非结构化数据 向量Embeding •向量维度比较高，常见的768/1536/4096维•捕捉原来实体特征信息，具有语义信息•相似的实体在向量空间中比较接近 单模态EmbedingModel •文本:text-embedding-ada-002•图像:ResNet50•音频:PANNs 多模态EmbedingModel •SigLIP•Unum 如何度量向量与向量之间的相似性 cosine(余弦距离) •向量的夹角•适用推荐场景 L2(欧式距离) •两个点之间的绝对距离•适用cv场景，例如人脸识别、以图搜图 L1(曼哈顿距离) •维度的绝对差相加来计算距离•适用推荐场景 inner_product(内积) •维度的相乘相加来计算距离•适用模型深度学习模型训练 如何在海量向量中快速找到与目标接近K个向量 ApproximateNearestNeighbor •HNSW•FAISS•ScaNN•DiskANN•.... 算法性能评价 •召回率•QPS 向量ANN索引（ApproximateNearestNeighbor） •排序方式：按照距离排序•近似查找 向量检索总结 向量数据库 路径1：专用向量数据库 路径2：通用数据库(TP/AP)+向量索引 •极致性能 •天然继承原有数据库的基础能力（高可用,拓展性等）•实现ALL-in-one查询（标量+向量） 向量数据库=向量检索+用户接口+高可用+拓展性+备份/恢复+运维工具等 ApacheDoris向量检索 ApacheDoris如何实现向量索引 •语法支持建表查询语法适配 向量计算 支持多种距离函数ann谓词下推 •向量存储array类型… 向量索引索引构建索引查询 语法支持：建表 •通过INDEXUSINGANN指定索引类型为ANN索引，目前只支持diskann•通过PROPERTIES中的算法参数，指定具体的ANN算法以及算法的参数 •各算法特有参数，以算法名称加下划线开头 语法支持：查询语法 topk查找 范围查找 •topk查询:通过orderby+limit实现•混合查询：wherepredicate+orderby+limit 向量类型 业内常见做法开发专门的向量类型：例vector(N) •N表示向量维度•向量每个元素用float32表示 首版采用自带Array类型来存储向量：array 专用向量类型开发 •array在底层存储需要记录offset，有一定的额外开销•在向量检索领域维度一般是固定的 距离函数 支持4种距离函数（2.1版本） •cosine_distance•l2_distance•l1_distance•inner_product 索引库选型：HNSWvsDiskAnn 目标：海量数据、高召回率、低延迟 HNSW内存型索引问题 DiskANN •成本低:单机10亿，4TB，挂1块SSD•稳定性：与Doris索引加载逻辑保持一致、按需从磁盘加载 •成本高:100w，768维，占用4G内存•稳定性稍差：冷启动，加载，波动大 索引库选型：DiskAnn性能 HNSW(内存型) DiskANN(SSD) DiskANN(HDD) •QPS：624•召回率：98%•avg延迟：13ms•ioutil：100%•单跑：2ms •QPS：30•召回率：99.4%•avg延迟：60ms•ioutil：100%•单跑：20ms •QPS：323•召回率：99.7%•avg延迟：13ms•单跑：1ms 6并发，100w，768维，取top10性能对比 diskann支持多次场景适用 性能 •相对于HNSW性能也有明显优势缺点•比较吃IO，可以通过加磁盘解决•内存•SSD•HDD 遇到的问题及解法 Doris适配DiskAnn过程中存在的问题 DiskAnn功能改造：支持idfilter，实现混合查找 混合查找 select*fromvector_table wherecity="北京"ORDERBYdistance_function('[0.1,0.2,0.3,....,0.1]',question_embedding)limit10; 步骤 •先按照标量条件过滤•把结果下推向量检索•向量检索只在下推的向量中取topk DiskAnn功能改造：性能优化 问题：当过滤的节点过多，查询性能慢，最坏情况全图遍历，才能找到结果 解法：设置过滤比例，当过滤节点占比达到一定占比时退化为暴力检索，不走索引，默认值90% DiskAnn功能改造：索引文件合并 问题：索引文件爆炸，分区数*分桶数*rowset个数*segment个数*diskann索引文件数 解法: 影响： •成本：存算分离场景，S3按请求次数收费•性能:文件越多，open慢•复杂度：生命周期管理(副本恢复、GC、备份恢复) •文件合并，diskann索文件合并为1个大文件•重写diskann的reader逻辑，从大文件读取索引 DiskAnn功能改造-支持直接传入向量 优化1-Compaction资源隔离-独立的Compaction线程 100w，768维，索引构建5分钟 问题：影响其他表的Compaction过程，导致版本堆积，性能下降 解法：存在ann索引表的Compaction过程，由独立的后台线程负责 优化2-全局延迟物化 例子:selectcontent,distance_function(vector,[0.1,0.2,0.3...])asscorefromvector_tableorderbyscoreasclimit10 未来规划 ThanksforWatching！