AI智能总结
陈林忠百度大数据平台部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<topk>实现•混合查询:wherepredicate+orderby+limit<topk> 向量类型 业内常见做法开发专门的向量类型:例vector(N) •N表示向量维度•向量每个元素用float32表示 首版采用自带Array类型来存储向量:array<float> 专用向量类型开发 •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!