NEAREST BY Join：Databricks如何在批处理中扩展向量搜索

向量搜索正在走出服务层

向量搜索最初是一个服务层（serving）问题。最经典的应用场景是聊天机器人：当用户提出问题时，系统需要实时将查询转化为向量，并在海量嵌入（embedding）数据中找到最相似的若干条记录，再把这些上下文喂给大语言模型生成回答。这类场景强调低延迟与单点查询，背后往往由专门的向量数据库或在线索引服务支撑。

然而，随着检索增强生成（RAG）与各类嵌入分析逐渐渗透进企业数据管道，向量搜索的需求形态正在发生变化。越来越多的工作负载不再是"一次查询一条"的在线请求，而是"一次性对数百万甚至上亿条记录批量求近邻"的离线分析任务。这正是 Databricks 在其 Runtime 中引入 NEAREST BY Join 所要解决的核心问题。

嵌入（embedding）是将文本、图像或其他非结构化数据映射到高维实数向量空间的技术，语义相近的内容在向量空间中距离也更近。检索增强生成（RAG，Retrieval-Augmented Generation）则是一种将向量检索与大语言模型结合的架构模式：在生成回答之前，先从外部知识库中检索与问题最相关的文本片段，将其作为上下文注入提示词，从而让模型能够引用最新或私有的知识，而不仅依赖训练时的参数记忆。随着 RAG 从原型走向生产，企业知识库的规模往往从数万条增长到数千万条，单次在线查询演变为需要周期性重建索引、批量评估召回质量、定期对全库做语义去重等离线任务，这使得原本为低延迟点查询设计的向量数据库开始显露出批处理场景的局限。

从单点查询到批量近邻连接

传统向量数据库擅长的是服务层的点查询，但当你需要把一张包含海量向量的表与另一张表做"最近邻连接"时，这些工具往往力不从心。典型的批量场景包括：对整个文档库做去重、为每条用户记录找到最相似的商品、在大规模数据集上做语义聚类或召回评估。

这类任务的本质，是把近邻搜索表达成一个 SQL 层面的 Join 操作——对左表的每一行，在右表中找到距离最近的 K 条记录。NEAREST BY 的设计思路，正是让向量近邻检索成为数据查询引擎中的"一等公民"，与常规的 Join、过滤、聚合等算子无缝组合，而不是把数据导出到外部向量库再导回来。

为什么批处理场景需要新算子

在批处理中硬套在线索引有两个痛点。其一是规模：在线向量索引通常为低延迟的单条查询优化，面对数亿行的全表扫描式连接时，吞吐和成本都难以接受。其二是数据流动：把数据搬出湖仓、交给外部服务、再把结果搬回来，既增加了工程复杂度，也破坏了数据治理与一致性。将向量搜索原生嵌入运行时，可以让计算贴近数据，复用引擎已有的分区、并行与资源调度能力。

湖仓（Lakehouse）架构将数据湖的低成本存储与数据仓库的 SQL 查询能力合并在同一平台，Databricks 的 Delta Lake 与 Apache Spark 运行时是其典型实现。在湖仓中，数据天然以分区形式分布在对象存储上，计算引擎可以将任务调度到数据所在节点，实现"计算贴近数据"的就地处理。将向量近邻搜索原生集成到这类运行时，意味着可以直接复用引擎的分区裁剪、向量化执行、自适应查询优化（AQE）等已有机制，而无需为向量负载单独维护一套分布式基础设施。这对于需要跨 PB 级结构化表与向量列做联合分析的场景尤为关键。

近邻搜索在算法层面有精确与近似两大类。精确 K 近邻（KNN）需要遍历所有候选向量，时间复杂度随数据量线性增长，在亿级规模下往往不可接受。近似最近邻（ANN，Approximate Nearest Neighbor）算法通过构建 HNSW（层次化可导航小世界图）、IVF（倒排文件索引）等索引结构，在牺牲极少精度的前提下将搜索复杂度降至次线性，是工业界主流选择。批量近邻连接（Batch KNN Join）的挑战在于，需要对左表中每一行向量独立完成 ANN 查询，同时保证整体吞吐最大化，这要求引擎在分区划分、索引构建与任务并行之间做出系统级协同，而非简单地循环调用单条查询接口。

NEAREST BY Join 的工程价值

把近邻搜索下沉到查询引擎层，意味着开发者可以用熟悉的声明式语法完成原本需要大量胶水代码的工作。向量搜索不再是独立于数据平台之外的"侧系统"，而是能够与湖仓中的结构化、半结构化数据统一调度的能力。

对数据工程团队而言，这降低了构建 RAG 数据预处理、离线召回评估、相似度去重等管道的门槛；对平台而言，这是把"向量"从一种特殊数据类型，提升为可以参与大规模分布式计算的通用能力的重要一步。

结语

向量搜索从服务层的实时点查询，走向批处理层的大规模近邻连接，反映出嵌入技术在企业数据栈中日益普遍的现实。Databricks 的 NEAREST BY Join 试图在湖仓运行时内部原生支持这一需求，让向量检索与传统 SQL 分析融为一体。对于正在构建大规模 RAG 与语义分析管道的团队，这类原生能力值得持续关注。