在智能驾驶、多模态搜索等场景中，数据规模正在快速增长。一条查询往往不只是“找最相似的几个样本”，还需要同时满足车型、时间、设备、区域等业务条件，并进一步完成关联、统计和分析。
这类查询对传统向量检索方案提出了新的挑战。很多方案通常把向量搜索作为独立服务：应用先调用检索系统得到结果，再把结果交给数据库或分析引擎继续处理。随着数据规模扩大，数据搬运、结果拼接和多套系统之间的协同都会增加额外开销。
Doris 与 Lance 的结合提供了一种不同方式：让 Lance 负责多模态数据存储和向量、全文索引，让 Doris 负责查询规划、分布式执行以及后续 SQL 分析。用户可以直接查询已有 Lance 数据集，在一次 SQL 中完成条件过滤、向量检索、关联、聚合和排序。
为了验证这种方式在大规模场景下的效果，本文使用真实智能驾驶数据进行了测试。**在 10 亿规模数据上执行“向量检索＋四条件过滤”查询时，Doris + Lance 用时 2.32 秒，Ray + pylance 用时 25.228 秒，后者耗时约为前者的 10.87 倍**。测试条件为 Top-K 20,000、召回率 95%、开启缓存、无并发。（完整测试详见后文）
要理解这些性能差异，需要先了解 Doris 如何读取 Lance 数据、如何规划检索任务，以及向量检索结果如何继续参与 SQL 查询。下面先介绍 Doris 与 Lance 的整体架构。
## 一、整体架构

要让 Doris 直接查询 Lance 数据，首先需要理解两者在查询链路中的职责划分，以及一次查询如何从数据读取进入 SQL 执行流程。
一个 Lance 数据集包含数据文件、数据版本信息、数据分片（Fragment）和索引。Doris 会读取这些信息，再决定如何执行查询。其中，FE 负责规划任务，BE 负责读取数据和执行检索。检索结果可以直接交给 Doris 的其他算子，继续做关联和聚合。
![https://developer.qcloudimg.com/http-save/yehe-10695849/9b79fedfd5841dbbdadc75858c732dc0.png](https://developer.qcloudimg.com/http-save/yehe-10695849/9b79fedfd5841dbbdadc75858c732dc0.png)
Doris 提供两种 Catalog 接入方式：Filesystem Catalog 通过目录查找数据集，REST Catalog 通过 Lance Namespace 服务查找数据集。底层数据可以放在本地文件系统、S3 兼容对象存储或 OSS 中。临时查询时，也可以使用支持 Lance 格式的文件表值函数（TVF）直接访问数据集。
Doris 通过 `vector_search()` 提供向量检索，通过 `full_text_search()` 使用 Lance 全文索引（FTS）。全文检索支持匹配任一关键词（Match OR）、全部关键词（Match AND）和短语（Phrase）。短语查询要求索引保存词的位置；默认的严格覆盖模式要求当前数据版本中的所有分片都有索引，缺少索引的分片不会自动补做 Flat Search。两种检索入口都能接入后续 SQL 分析；如果需要合并向量与文本排名，需要明确设计结果合并和打分规则。
一条查询主要经过三个步骤：
1. **规划任务**。FE 读取表结构、数据版本、分片列表和索引覆盖范围，确定列类型、需要读取的列，以及任务如何拆分。一次查询使用固定的数据版本。
2. **执行读取**。BE 通过 lance-c 调用 Lance，读取 Arrow 格式的数据，再转换成 Doris 内部使用的 Block，交给后续算子处理。
3. **继续分析**。检索结果可以用于关联（Join）、聚合、排序和分页，也可以与 Doris 内表或其他 Catalog 中的数据一起查询。

这样，检索和后续分析就可以在 SQL 中完成。应用无需先取出 Lance 的结果，再另写一套关联和统计逻辑。
## 二、并行检索

架构确定了查询链路后，下一步的问题是：如何让大规模数据上的向量检索充分利用集群资源。
要让多个 BE 一起检索，首先要把任务分好。如果任务划分不合理，多个任务可能重复读取同一段索引；如果任务太少，又难以充分利用多个 BE。
Doris 按 Lance 的**物理索引段**拆分检索任务。索引段是索引的一部分，Fragment 是数据分片，两者的划分方式不同：一个索引段可以覆盖多个 Fragment。Doris 会读取它们的对应关系，再安排扫描任务。
![https://developer.qcloudimg.com/http-save/yehe-10695849/cb2abf3d4129221ef1b2265a980ed579.png](https://developer.qcloudimg.com/http-save/yehe-10695849/cb2abf3d4129221ef1b2265a980ed579.png)
执行向量检索时，FE 先找到与查询列、距离计算方式匹配的索引，再把索引段分配给 BE 并行检索。对于当前数据版本中尚未建好索引的分片，Doris 会安排 Flat Search，也就是直接扫描数据来搜索。这部分结果也会参与最后的合并。
各个任务返回候选结果后，Doris 会统一排序，选出全局 Top-K，即候选中排名最靠前的 K 条记录。因此，已有索引的数据可以走索引检索，未被索引覆盖的数据也能参与查询。向量检索使用近似最近邻搜索（ANN）时，召回率仍取决于索引类型和搜索参数。
普通的条件查询也能利用索引。例如，部分等值、范围、IN 和数组标签匹配条件，可以使用 Lance 的 BTree、Bitmap 或 LabelList 索引。满足条件时，Doris 同样按索引段组织扫描，并扫描未被索引覆盖的数据。能否使用索引，取决于具体条件和索引类型。
索引分段会影响并行效果。分段合理，多个 BE 就能分担工作；分段过细，则会增加任务调度、索引打开和结果合并的开销。实际配置时，需要结合数据分布、BE 数量和查询并发来选择。
## 三、检索前过滤

并行能够提高计算资源利用率，但如果搜索范围本身过大，仍然需要处理大量无关数据。因此，对于带业务条件的向量检索，过滤发生的时机会直接影响查询效率。
带条件的向量检索，关键在于过滤发生的时间。例如，只查某种车型时，可以先限定车型，再搜索相似记录。如果先找出相似记录、再删除车型不符的结果，就可能得不到足够多的结果。
Doris 的 `vector_search()` 和 `full_text_search()` 用 `filter` 指定过滤条件，用 `prefilter` 控制何时过滤。默认情况下，**prefilter 是 false。**需要先过滤再检索时，应明确设置 `"prefilter"="true"`。
![https://developer.qcloudimg.com/http-save/yehe-10695849/deecbf2d5613b4cd5d2646a33a515b88.png](https://developer.qcloudimg.com/http-save/yehe-10695849/deecbf2d5613b4cd5d2646a33a515b88.png)
下面的 SQL 演示如何在指定车型和区域内搜索。示例使用四维向量，返回 Top-20；后文性能测试的 Top-K 为 20,000。表名、列名和值均为演示数据，实际使用时，向量维度和距离计算方式 `metric` 应与数据及索引匹配。
```
SELECT scene_id, scene_text, resource_uri, _distanceFROM vector_search( &nbsp; &nbsp;"table" = "lance_demo.autodrive.scene_samples", &nbsp; &nbsp;"column" = "embedding", &nbsp; &nbsp;"query_vector" = "[0.12, 0.34, 0.56, 0.78]", &nbsp; &nbsp;"top_k" = "20", &nbsp; &nbsp;"metric" = "cosine", &nbsp; &nbsp;"filter" = "vehicle_type = 'sedan' AND region_code = 'zone_a'", &nbsp; &nbsp;"prefilter" = "true", &nbsp; &nbsp;"use_index" = "true")ORDER BY _distance ASC, scene_id;​
```设置 `prefilter=true` 后，Lance 会先应用函数中的过滤条件，再选择检索候选。如果条件能用上标量索引，就可以通过索引缩小搜索范围；否则，仍可能需要扫描数据来判断条件。过滤能节省多少工作，取决于索引是否可用，以及能排除多少数据。
默认的 `prefilter=false` 会先选出候选，再应用函数中的 `filter`。写在函数外层的 SQL `WHERE` 则由 Doris 继续过滤返回结果。这两种方式都可能删掉已经找到的记录，使最终结果少于 K 条。
对于普通 Lance 扫描，Doris 也能把支持的 SQL 过滤条件交给 Lance 执行，尽早减少读取的数据。Join 过程中产生的部分 Runtime Filter（运行时过滤条件），也可以转换成 IN 或范围条件交给 Lance。这取决于条件和数据类型是否兼容；使用检索函数时，仍需通过 `prefilter` 明确控制过滤顺序。
## 四、按需读列

除了搜索范围，数据读取方式也会影响查询性能。向量检索通常只需要计算距离和排序，但最终返回结果时又需要展示大量文本和属性信息。如果这些列过早读取，会造成额外的数据访问成本。
检索结果往往还要展示文本、标签和资源路径。如果每个任务一开始就读取这些列，很多数据会在 Top-K 排序后被丢弃，白白增加读取和传输的开销。
Doris 可以把符合条件的向量检索和全文检索分成两次读取：先选结果，再补读展示列。
![https://developer.qcloudimg.com/http-save/yehe-10695849/12542fc2465ef0c6b24028eef84f6cfb.png](https://developer.qcloudimg.com/http-save/yehe-10695849/12542fc2465ef0c6b24028eef84f6cfb.png)
第一次读取检索、过滤和计算必需的数据，返回行号、距离或分数，以及后续计算需要的列。等 Doris 选出全局 Top-K 后，第二次再按行号读取这些记录的其他展示列。
这样，最终未入选的记录就可以少读、少传一些列。查询仍会读取检索和过滤所需的数据，节省的是可以推迟到最后读取的部分。返回记录较少、每条记录附带的文本或属性较多时，这项优化尤其有用。
两次读取使用同一个数据版本，保证先检索到的记录与后面补读的内容一致。Doris 还支持按版本、时间或命名引用选择 Lance 快照，方便重复查询同一版本的数据。
## 五、缓存与诊断

前面的优化主要减少单次查询需要处理的数据量，而缓存进一步减少重复查询中的固定开销。
连续查询同一个数据集时，往往会反复访问相同的索引和文件。缓存可以减少重复加载索引、解析元数据，以及从对象存储读取数据的开销。
Doris 在每个 BE 内共享 Lance Session。普通扫描、向量检索、全文检索和按行号补读数据，都可以复用其中相应的缓存。
![https://developer.qcloudimg.com/http-save/yehe-10695849/aa64a7f87e3ae4120f53e8abdd90bd50.png](https://developer.qcloudimg.com/http-save/yehe-10695849/aa64a7f87e3ae4120f53e8abdd90bd50.png)
每个 BE 分别管理自己的缓存，BE 之间不共享缓存池。缓存容量也只是内存使用的一部分：扫描任务、数据预读和排序等操作还会占用额外内存。
查询慢在哪里，可以通过 `EXPLAIN`、Query Profile 和 BE 指标来查看。执行计划能帮助检查任务划分；Profile 可以进一步查看打开数据集、加载索引、远端读取、格式转换和补读列等环节的耗时。索引和元数据缓存的命中率、占用量是 BE 级别的统计，可能包含多个查询的访问。
排查时，可以先确认查询用了索引还是 Flat Search，再看时间主要花在过滤、数据读取、检索还是补读列上。这样更容易找到需要调整的环节。
## 六、SQL 分析

向量检索的最终目的通常不是返回几个相似结果，而是基于这些结果继续完成业务分析。因此，检索结果能否直接参与 SQL 执行，是衡量一体化查询能力的重要环节。
向量检索或全文检索返回的结果，可以像表一样参与 SQL 查询。Doris 将检索输出交给后续的关联、聚合和排序算子处理。例如，先从 Lance 中找出相似样本，再关联 Doris 内表中的标签，最后统计这些样本的类别分布。这些操作可以写在一条 SQL 中，由 Doris 执行。
![https://developer.qcloudimg.com/http-save/yehe-10695849/ba2449a118008106db2c3d97ae55258a.png](https://developer.qcloudimg.com/http-save/yehe-10695849/ba2449a118008106db2c3d97ae55258a.png)
下面的示例先检索符合车型和区域条件的 Top-20 样本，再关联 Doris 内表 `internal.demo.scene_labels`，按场景类别统计数量。假设 Lance 数据集中的 `scene_id` 唯一，标签表也为每个 `scene_id` 保存一条记录。表名、字段和值均为演示数据，四维向量和距离计算方式需要按实际数据及索引调整。
```
WITH candidates AS ( &nbsp; &nbsp;SELECT scene_id &nbsp; &nbsp;FROM vector_search( &nbsp; &nbsp; &nbsp; &nbsp;"table" = "lance_demo.autodrive.scene_samples", &nbsp; &nbsp; &nbsp; &nbsp;"column" = "embedding", &nbsp; &nbsp; &nbsp; &nbsp;"query_vector" = "[0.12, 0.34, 0.56, 0.78]", &nbsp; &nbsp; &nbsp; &nbsp;"top_k" = "20", &nbsp; &nbsp; &nbsp; &nbsp;"metric" = "cosine", &nbsp; &nbsp; &nbsp; &nbsp;"filter" = "vehicle_type = 'sedan' AND region_code = 'zone_a'", &nbsp; &nbsp; &nbsp; &nbsp;"prefilter" = "true", &nbsp; &nbsp; &nbsp; &nbsp;"use_index" = "true" &nbsp; &nbsp;) &nbsp; &nbsp;ORDER BY _distance ASC, scene_id &nbsp; &nbsp;LIMIT 20)SELECT &nbsp; &nbsp;COALESCE(l.scene_type, '未分类') AS scene_type, &nbsp; &nbsp;COUNT(*) AS sample_countFROM candidates cLEFT JOIN internal.demo.scene_labels l &nbsp; &nbsp;ON c.scene_id = l.scene_idGROUP BY COALESCE(l.scene_type, '未分类')ORDER BY sample_count DESC, scene_type;
```这条 SQL 分三步执行：`candidates` 定义检索结果，`LEFT JOIN` 按样本 ID 补充类别，`GROUP BY` 统计各类样本的数量。没有匹配标签或类别为空的样本归入“未分类”。应用直接获得统计结果，无需先取回样本，再逐条查标签和计数。
这里统计的是本次返回的 Top-K 样本，反映这批相似样本的类别分布。如果要统计整个数据集，应直接扫描 Lance 表并聚合。示例中的车型和区域条件放在检索函数内，确保在选择候选时就限定搜索范围。
## 七、性能对比

前面的章节介绍了 Doris + Lance 在查询执行中的几个关键机制：并行检索提高资源利用率，提前过滤减少搜索范围，按需读列降低数据读取成本，缓存减少重复访问开销。下面通过实际测试，观察这些机制组合后的查询效果。
下面是一组来自真实智能驾驶场景的测试结果。
测试对比 Doris + Lance 和 Ray + pylance，数据规模分别为 1 亿、5 亿和 10 亿。查询包括纯向量检索，以及叠加设备、时间、车型、地理和四项组合条件的检索，共六类。
测试条件为 **Top-K 20,000、召回率 95%、开启缓存、无并发，耗时单位为秒**。Ray 在 1 亿规模使用 4 个 actor，在 5 亿和 10 亿规模使用 16 个 actor。开启缓存不代表每次查询都命中缓存。现有记录未提供双方硬件配置、Doris BE 数量和耗时统计方式，以下结果仅用于比较本次测试的查询耗时。
### 10 亿规模

![https://developer.qcloudimg.com/http-save/yehe-10695849/fddba4cb29446d9bc293744742d8b8d8.png](https://developer.qcloudimg.com/http-save/yehe-10695849/fddba4cb29446d9bc293744742d8b8d8.png)
![https://developer.qcloudimg.com/http-save/yehe-10695849/ef1f14eaa8db8e51851cf451efc178ff.png](https://developer.qcloudimg.com/http-save/yehe-10695849/ef1f14eaa8db8e51851cf451efc178ff.png)
10 亿规模下，Doris 在地理过滤和四条件过滤查询中分别用时 1.19 秒、2.32 秒，相比 Ray + pylance，耗时均减少约 90.8%。时间过滤查询从 6.044 秒降至 0.73 秒，两者耗时比约为 8.28 倍。
这组结果说明，Doris 在本次“向量检索＋条件过滤”测试中表现较好。前文介绍的索引规划、提前过滤、并行检索和按需读列，共同组成了这类查询的执行过程。由于测试没有逐项关闭这些优化，无法单独计算每项优化的贡献。
### 全部测试结果

![https://developer.qcloudimg.com/http-save/yehe-10695849/867ccfc09117ef772ff2caf3583f41a9.png](https://developer.qcloudimg.com/http-save/yehe-10695849/867ccfc09117ef772ff2caf3583f41a9.png)
![https://developer.qcloudimg.com/http-save/yehe-10695849/15b5b43f694e75363bd77de3ffea589d.png](https://developer.qcloudimg.com/http-save/yehe-10695849/15b5b43f694e75363bd77de3ffea589d.png)
文中“耗时比”按 Ray + pylance 耗时除以 Doris + Lance 耗时计算，大于 1 表示 Doris 更快。18 组测试中，Doris 有 16 组耗时更低。四条件过滤在 1 亿、5 亿和 10 亿规模下的耗时比分别约为 5.39、7.14 和 10.87 倍。
## 八、总结

**该能力预计可于 10 月底发布的 Apache Doris 4.2 版本中提供体验**。Doris 对 Lance 的集成深入到了查询执行的各个环节：按索引段分配任务，让多个 BE 并行检索；提前应用过滤条件，缩小搜索范围；选出 Top-K 后再补读展示列，减少数据读取和传输；通过缓存复用索引、元数据和文件内容。这些机制让 Doris 能够直接利用已有的 Lance 数据和索引，完成检索与分析。
在本文的测试条件下，Doris + Lance 在 18 组查询中有 16 组耗时更低。10 亿规模的“向量检索＋四条件过滤”用时 2.32 秒，Ray + pylance 用时 25.228 秒。这组结果体现了 Doris 处理大规模向量检索与条件过滤组合查询的能力，实际收益仍需结合数据、索引和部署配置评估。
对于社区用户，这意味着可以继续使用 Lance 存储多模态数据，同时通过 Doris 的 SQL 接口完成检索、关联和统计。已有的 Lance 数据集由此可以直接服务于样本筛选、数据探索和业务分析，减少应用侧的数据搬运与结果处理工作。

在智能驾驶、多模态搜索等场景中，数据规模正在快速增长。一条查询往往不只是“找最相似的几个样本”，还需要同时满足车型、时间、设备、区域等业务条件，并进一步完成关联、统计和分析。这类查询对传统向量检索方案提出了新的挑战。很多方案通常把向量搜索作为独立服务：应用先调用检索系统得到结果，再把结果交给数据库或分析引擎继续处理。随着数据规模扩大，数据搬运、结果拼接和多套系统之间的协同都会增加额外开销。Doris 与 Lance 的结合提供了一种不同方式：让 Lance 负责多模态数据存储和向量、全文索引，让 Doris 负责查询规划、分布式执行以及后续 SQL 分析。用户可以直接查询已有 Lance 数据集，在一次 SQL 中完成条件过滤、向量检索、关联、聚合和排序。为了验证这种方式在大规模场景下的效果，本文使用真实智能驾驶数据进行了测试。在 10 亿规模数据上执行“向量检索＋四条件过滤”查询时，Doris + Lance 用时 2.32 秒，Ray + pylance 用时 25.228 秒，后者耗时约为前者的 10.87 倍。测试条件为 Top-K 20,000、召回率 95%、开启缓存、无并发。（完整测试详见后文）要理解这些性能差异，需要先了解 Doris 如何读取 Lance 数据、如何规划检索任务，以及向量检索结果如何继续参与 SQL 查询。下面先介绍 Doris 与 Lance 的整体架构。

Apache Doris 基于 Lance 的向量检索深度解析

随着自动驾驶等多模态应用的发展，大规模数据查询需要同时满足向量检索、条件过滤和业务分析需求。Apache Doris 集成 Lance，支持直接查询 Lance 数据集，并通过并行检索、提前过滤、按需读列和缓存优化提升查询效率。本轮测试中，在 10 亿规模智能驾驶数据的四条件向量检索场景下，Doris + Lance 用时 2

大数据

Doris与Lance集成方案实现10亿级向量检索+条件过滤仅需2.32秒，较Ray+pylance提速10.87倍。该方案支持SQL一体化完成过滤、向量检索、关联与聚合，通过并行索引段检索、prefilter提前过滤、按需读列及缓存机制，在18组测试中16组耗时更低，有效减少多系统数据搬运开销。

对象存储

数据存储

数据缓存

数据分片

性能测试

文件系统

代码解释

数据库

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

bigdata-class

tchoused

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

Apache Doris 基于 Lance 的向量检索深度解析-腾讯云开发者社区-腾讯云

Apache Doris 基于 Lance 的向量检索深度解析

Apache Doris 基于 Lance 的向量检索深度解析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐