OceanBase 论文又上新两篇论文被国际顶会收录，破解AI 函数与查询优

OceanBase数据库官方博客

304人浏览 · 2026-08-06 10:16:48

OceanBase数据库官方博客 · 2026-08-06 10:16:48 发布

近日，从学术领域传来好消息，OceanBase 联合国内外多所高校共同完成的 2 篇论文斩获国际顶会认可，均被数据库领域顶会 PVLDB 2026 Industry Track 收录。以下为论文内容介绍：

当 AI 函数以 Python UDF 的形式走进数据库引擎，Python 的多线程并行却沦为“伪并行”——看似多线程同时执行，实则排队轮流跑，紧耦合的调度器也无法匹配 GPU、远程服务器等多样化计算资源。

OceanBase 与华东师范大学徐辰教授团队合作的 IMLane 以“可组合框架”的思路破局。

IMLane 的设计理念是：不针对单个数据库做定制优化，而是构建一个可组合的框架——一次开发，多处复用。IMLane 以 C++ 库的形式存在，可以像插件一样编译链接到不同数据库引擎中，只需实现轻量的数据转换接口即可完成集成。

最终，在 OceanBase 上实现 7.48 倍平均加速，在 DuckDB 上实现 5.04 倍平均加速。

IMLane 整体架构：可组合框架设计

IMLane 由三个核心组件构成：DBEnd 库、协调器和后端执行器。

DBEnd 库作为插件编译链接到数据库引擎中，提供数据转换接口和调度操作；
协调器是框架的核心，包含 AI 函数调度器和 Lane 管理器，负责调度请求和管理资源生命周期；
后端执行器在独立进程中嵌入运行时（如 Python 解释器），执行 AI 函数并通过 Lane 将结果返回给数据库引擎。

为了在数据库引擎进程和 AI 函数执行进程之间高效传输数据，IMLane 引入了 Lane 的概念。

一个 Lane 是一个聚合资源单元，可以包含 CPU 核心、GPU 单元或远程资源。每个 Lane 拥有独立的输入/输出缓冲区和信号量，用于协调数据库引擎进程和 AI 函数执行进程之间的数据流。

为了适配不同数据库的内部数据格式，IMLane 设计了基于 C++ 模板特化的 DataConverter 接口。每种数据库只需实现自己的模板特化版本，即可完成内部格式与 ArrowLane 之间的双向转换。这正是 IMLane “可组合”的关键——数据库引擎无需修改核心代码，只需实现轻量的转换接口。以 OceanBase 和 DuckDB 为例，集成代码量分别约为 800 行和 500 行。

IMLane 的后端执行器是可插拔的。默认的 Python Executor 直接在工作进程中调用 AI 函数；同时提供了 Ray Executor，可以将 AI 函数调度到 Ray 集群上执行，支持分布式推理。

IMLane 方案一：让并行真正有效

IMLane 的第一个核心方案是进程级并行执行。既然 GIL 是进程内的锁，那么绕开它的最直接方式就是——每个 AI 函数执行实例跑在独立进程中。

IMLane 为每个 AI 函数执行实例创建独立的 Python 解释器进程。数据库引擎进程负责数据扫描和关系算子执行，AI 函数在独立的工作进程中完成模型推理。进程之间通过共享内存进行数据传输，避免了序列化/反序列化的开销。

进程级并行执行：每个 AI 函数实例运行在独立进程中

Python 社区也在尝试解决 GIL 问题，比如 PEP 703 提出的 no-GIL 方案和子解释器（sub-interpreter）机制。IMLane 选择进程级并行，是当前最成熟、兼容性最好的解决方案。

数据在进程间传输需要一个高效的中间格式。IMLane 选择 Apache Arrow——一种列式内存格式，天然支持零拷贝的共享内存访问。IMLane 定义了 ArrowLane 数据类型，将数据库内的行存或列存格式转换为 Arrow 表，通过共享内存传递给 AI 函数执行进程，避免了数据拷贝和序列化。

IMLane****方案二：让调度匹配资源

解决了并行执行问题后，第二个挑战是调度。

IMLane 的思路是：把 AI 函数的调度从数据库引擎的调度器中解耦出来，交给一个独立的、资源感知的调度器。

在 IMLane 中，AI 函数不再随流水线任务一起被数据库调度器调度。取而代之的是，IMLane 为 AI 函数维护独立的调度队列。数据库引擎完成数据扫描后，将数据批次放入 Lane 的输入缓冲区；IMLane 的调度器根据当前可用资源，将 AI 函数调度到合适的 Lane 上执行。

资源感知的独立调度：AI 函数拥有自己的调度队列

这种解耦设计带来了三个好处：

AI 函数可以绑定到最适合的计算资源（CPU、GPU 或远程服务器）；
调度器可以感知异构资源的空闲状态，避免资源闲置；
数据库引擎和 AI 函数的调度互不干扰，各自独立扩展。

在此基础上，IMLane 进一步引入了分批异步调度策略。

传统方式下，数据库引擎按分区整块调度——数据量大的分区拖慢整体进度，数据量小的分区又让资源闲置。IMLane 将数据拆分为更小的批次，按需分配给空闲的 Lane 执行，让每个 Lane 都保持忙碌。

分批调度：数据按批次分发执行

异步感知调度：异构资源被充分利用

同时，调度是异步的：数据库引擎在扫描下一批数据的同时，上一批数据已经在 Lane 上进行 AI 推理，两者交替推进、互不等待。这让 CPU 扫描、GPU 推理、远程计算等异构资源真正并行起来，不再互相阻塞。

对于 OceanBase 这样的磁盘型数据库，异步调度还带来了一个额外收益：磁盘 I/O 与 AI 函数执行的重叠——数据库引擎在扫描表的同时，AI 函数可以在工作进程中并行执行，无需等待整个表扫描完成。

实验验证：7.48 倍与 5.04 倍加速从何而来

实验在两种数据库引擎上进行：OceanBase Paetica 4.3（磁盘型分布式数据库）和 DuckDB 0.10.1（内存型分析数据库）。

硬件环境为 Intel Xeon Gold 6240R（48 核）、128GB 内存、NVIDIA Tesla V100 GPU；远程环境包含 4 个节点，每节点配备 Xeon Gold 6248R 和 RTX A6000 GPU。实验设计了 7 个查询（Q1-Q7），覆盖三种典型场景：

Q1-Q2 使用 RF 和 GBDT 模型，对 10GB级别数据（2000-4000 万行）做批量预测；
Q3-Q4 使用 SVM 和 NB 模型，对增量数据（100 万行）做推理；
Q5 使用 GPU 加速的 DNN 做本地推理，Q6 使用 RNN 做远程 CPU 推理，Q7 使用 LLM（Qwen3 1.7B）做远程 GPU 推理。

先看整体数字。在 OceanBase 上，IMLane(exec)——即仅启用进程级并行——就实现了平均 5.47 倍的加速。在此基础上叠加解耦调度（IMLane(sched)），进一步获得 1.37 倍提升，合计 7.48 倍平均加速。作为对比，IMBridge（通过批处理缓解 GIL 问题的现有方案）在 OceanBase 上仅获得 2.03 倍加速。

在 DuckDB 上，IMLane(exec) 实现平均 3.33 倍加速，IMLane(sched) 再获 1.51 倍提升，合计 5.04 倍平均加速。IMBridge 在 DuckDB 上仅为 1.4 倍。IMLane的进程级并行不受批次大小影响，在各类查询上均展现出显著性能优势。

共享内存 + Arrow 格式的进程间数据传输方案高效可靠，进程间数据交换不构成性能瓶颈。

同时，我们将 IMLane 与三种主流方案进行对比：pandas（单线程 Python）、SparkSQL（进程并行 + 外部数据拉取）和 Ray.data（分布式数据处理）。这些方案都将数据从数据库中导出后在外部执行 AI 函数。

结果显示，IMLane(OB) 比 pandas 快 2.65 倍，比 SparkSQL 快 1.87 倍，比 Ray.data 快 1.19 倍；IMLane(DuckDB) 比 pandas 快 4.02 倍，比 SparkSQL 快 2.82 倍，比 Ray.data 快 1.8 倍。

IMLane 的性能优势主要来自两点：一是避免了将数据从数据库导出的额外传输开销；二是解耦调度更好地匹配了异构资源需求。

在 Q1 和 Q3 等大数据量查询上，SparkSQL和 Ray.data 甚至无法在 4 小时内完成，而 IMLane 则在分钟级别返回结果。

总结与展望

IMLane 用两个核心设计回答了“如何让数据库里的 AI 函数跑得快”这个问题：进程级并行执行绕开 GIL，让并行真正生效；资源感知的解耦调度，让计算资源被充分匹配和利用。

作为一个可组合框架，IMLane 只需实现轻量的 DataConverter 接口即可集成到不同数据库引擎中，在 OceanBase 和 DuckDB 上均验证了有效性。

实验结果证明，共享内存 + Arrow 的进程间数据传输方案高效可靠，进程级并行带来了显著的性能提升。更重要的是，IMLane 的解耦调度设计为异构资源的充分利用提供了可能——GPU 、远程服务器、甚至 LLM 推理服务，都可以以Lane为单元被灵活调度，让数据库引擎真正成为 AI 时代的数据处理中心。

未来，随着 AI 函数在数据分析中的普及，异构资源的调度需求只会更加多样——更多的 GPU 类型、更复杂的远程推理场景、更大规模的 LLM。IMLane 以可组合框架的形态为此预留了充分的扩展空间，一次开发，多处复用。

参数化查询优化 PQO 是数据库系统中的经典问题：同一条 SQL 查询会被反复执行，但每次输入的参数不同。参数一变，数据选择性、访问路径、Join 顺序乃至最优执行计划都可能发生变化。如何在不引入过高优化开销的前提下，为不同参数快速选择高质量执行计划，是现代数据库优化器面临的重要挑战。

由南洋理工大学、OceanBase 团队与昆士兰大学联合完成的论文《Towards Industrial-Scale Parametric Query Optimization》提出 ScalePQO，一个面向工业级负载的参数化查询优化框架。

该方法已在 OceanBase 上完成实现与验证，在六组工作负载上取得稳定效果，相比 OceanBase 原生优化器最高实现 1.62 倍加速，相比已有学习型 PQO 方法 RankPQO 最高提升至 1.23 倍。

核心理念：相似模板共享模型，变化负载驱动更新

ScalePQO 的核心理念可以概括为两点：让相似的查询模板共享模型，让变化的参数分布驱动系统更新。

过去的方法通常走向两个极端：每个模板一个模型，效果较好但不可扩展；所有模板一个模型，开销较低但效果下降。ScalePQO 选择中间路径：先把优化行为相似的模板聚成簇，再为每个簇训练一个共享排序模型。这样既减少了模型数量，又保留了模型对相似模板的适配能力。

同时，ScalePQO 不再假设负载长期不变。系统会持续监测相邻时间窗口之间的参数分布变化。当变化明显时，ScalePQO 在后台触发模型微调和缓存计划更新，并在下一个时间窗口启用更新后的模型和计划集合。

**ScalePQO怎么做：模板聚类+**在线自适应

针对大规模查询模板和参数分布漂移两个问题，ScalePQO 采用“离线聚类+ 在线适应”的整体思路。

在离线阶段，ScalePQO 首先对查询模板进行聚类。

一个直接做法是根据 SQL 文本或结构相似度进行划分，但这类方法只能反映语法相似性，并不一定能反映查询优化行为的相似性。两个 SQL 看起来相似，不代表它们在不同参数下会选择相似的执行计划；两个 SQL 结构不同，也可能具有相近的计划选择规律。

因此，ScalePQO 采用基于学习表示的模板聚类方法。系统先训练一个全局排序模型，让模型学习参数、执行计划和查询性能之间的关系；随后利用模型生成每个查询模板的表示向量，再基于这些表示对模板进行聚类。这样，同一簇中的模板不仅在结构上相近，更重要的是在优化行为上相近。最后，ScalePQO 为每个模板簇训练一个共享排序模型，在减少模型数量的同时，保留对相似模板的适配能力。

在线阶段，当一个新的参数化查询到来时，系统首先识别其所属模板，并提取参数向量；随后调用对应模板簇的排序模型，对缓存中的候选计划进行打分，选择最适合当前参数的执行计划。被选中的计划会被转换为优化器hint，引导 OceanBase生成最终执行计划。

同时，ScalePQO 会把在线查询划分为连续时间窗口，并使用 KL 散度监测相邻窗口之间的参数分布变化。当参数分布变化较小时，系统只进行轻量级模型微调；当变化较大时，则增加模型更新和缓存计划更新力度，将更适合当前负载的新计划加入缓存。

这一过程在后台执行，不阻塞当前查询服务，更新后的模型和计划集合会在下一个时间窗口生效。通过这种方式，ScalePQO 既能支撑大规模查询模板，又能持续适应业务负载变化。