VLDB 2026新作：Presto上GPU，查询最高快6倍

这篇论文不玩虚的，直接把 Presto 往 GPU 里塞，还专门盯住了最容易拖后腿的数据搬运和跨节点交换。结果很实在：交换密集型查询最高快到 20 倍，整体性价比也能到 6 倍，属于“数据库老系统也能原地起飞”的那类活。

龙哥读论文发布于 2026-08-21 00:20:07 阅读 4 查看原文

#AI应用

🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！ 👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
这篇论文不玩虚的，直接把 Presto 往 GPU 里塞，还专门盯住了最容易拖后腿的数据搬运和跨节点交换。结果很实在：交换密集型查询最高快到 20 倍，整体性价比也能到 6 倍，属于“数据库老系统也能原地起飞”的那类活。

原论文信息如下：

论文标题:
Accelerating Presto with GPUs

发表日期:
2026年06月发表单位:
IBM Research Europe, IBM Data & AI, NVIDIA 原文链接:
https://arxiv.org/pdf/2606.24647v1.pdf 开源代码链接:
已集成到开源 Presto/Velox 仓库

GPU加速数据库，旧瓶装新酒？Presto迎来性能飞跃

数据库想上 GPU，听起来像把跑车发动机塞进老卡车里：能跑是能跑，但先得解决油怎么加、轮子怎么转、货怎么倒这三件事。本文这篇工作做的事情很直接：不是重写一套新数据库，而是把已有的 Presto 往 GPU 上挪，让老系统也能吃到显卡的红利。

这类思路的价值很现实。很多企业已经在用 Presto 跑分析查询，迁移到全新引擎的代价不小；如果能在不大改架构的前提下，把 GPU 的高带宽和并行能力接进来，就相当于给现有系统装了个“外挂涡轮”。

封面图：GPU 版 Presto 的整体加速效果展示。论文的核心信息很朴素也很硬核——先证明 GPU 真能快，再把这条路塞进 Presto 的真实执行链路里。

先说结论：这篇工作最有意思的地方，不是“GPU 算得快”这种老生常谈，而是它把瓶颈拆得很细，最后发现真正拖后腿的往往不是算力，而是数据搬运。数据从存储进来、在算子之间流转、跨节点交换，这些步骤如果还是靠 CPU 当中转站，GPU 再猛也会被堵在收费站前。

数据搬运少，查询跑得快：揭秘GPU加速的关键密码

为了不靠感觉拍脑袋，论文先做了一组“裸奔实验”：不让 Presto 先上场，而是直接用 cuDF、KvikIO、UCX、NVSHMEM 这些底层组件拼出一个最小系统，去测 GPU 到底能跑到什么上限。这里的 cuDF 是 NVIDIA 的 GPU DataFrame 库，专门拿来在 GPU 上做过滤、连接、聚合；KvikIO 负责存储到 GPU 的高速传输；UCX（Unified Communication X，统一通信框架）负责 GPU 之间、节点之间的数据通信；NVSHMEM 是 NVIDIA 的 GPU 端共享内存通信库，适合做多进程 GPU 协作。

图1：用于动机实验的软件架构总览。可以把它理解成一条“GPU 数据高速路”：存储直接喂给 GPU，多个 GPU 之间再用通信框架交换中间结果，尽量不让 CPU 插手。

这组实验给出的第一个结论很扎心：Parquet 读得太慢。Parquet 的层级元数据太多，读的时候要一边解码一边理解结构，GPU 的带宽优势被折腾掉一大截。论文甚至专门做了一个更简单的文件格式，把列拆开、把元数据塞进文件名里，目的不是提议新标准，而是测出“硬件理论上能到哪”。结果很夸张：在自定义格式下，GPU 读入速度能接近理论 I/O 上限，而 Parquet 读入则慢了一个数量级。

这个结论很重要，因为它说明 GPU 数据库优化不能只盯着“算子 kernel 写得漂不漂亮”，还得盯着“数据有没有被折腾得死去活来”。如果每一步都要在 CPU 内存和 GPU 内存之间来回倒腾，性能很容易被搬运成本吃光。

第二个结论更关键：数据要尽量从头到尾待在 GPU 内存里。一旦在算子之间来回切换内存位置，性能就会像接力赛里掉了接力棒，跑得再快也白搭。论文围绕这个目标，验证了三件事：读数据要直进 GPU，算子之间尽量不落回 CPU，分布式场景下 GPU 之间直接交换。

图2：CPU 算子到 GPU 算子的翻译，以及数据所在内存位置的变化。左边是原来的 Velox 算子链，右边是被替换成 cuDF 版本后的执行链；中间那些转换节点，就是为了兼容“有的算子还没搬上 GPU”的现实。

第三个结论则是分布式查询的命门：GPU 之间的交换也得 GPU 原生。如果跨节点传输还是把数据先落到 CPU 内存，再从 CPU 内存送到另一端 GPU，那就相当于专门给性能开了个“二次安检口”。论文提出的 UcxExchange 就是要把这道门拆掉。

从理论到实战：UcxExchange如何实现20倍加速

先把背景捋顺：Presto 原本的交换协议是 HttpExchange，也就是把中间结果序列化成 page，再通过 HTTP 在节点间拉取。这个设计在 CPU 时代没太大问题，但在 GPU 时代就很尴尬——数据先从 GPU 掉回 CPU，再从 CPU 送到另一个 GPU，性能损耗直接拉满。

图4：UcxExchange 架构。源任务把 GPU 中的数据切分并发送，目标任务通过 UCX 直接从远端 GPU 拉取数据，整个过程尽量不经过主机内存。

UcxExchange 的核心其实不复杂，难点在工程细节。它基于 UCX 做 GPU 到 GPU 的异步通信，支持同机的 NVLink、跨机的 RDMA，不行就退回 TCP。传输流程上，先用 active messaging 做握手，再用 tagSend/tagRecv 进行异步收发；数据也分成两部分：CPU 上的元数据和 GPU 上的 packed data。这样做的好处是，接收端先知道自己要分配多大的 GPU 缓冲，再把真正的数据直接收进 GPU 内存。

这套设计为什么能快？因为它把“交换”这个动作从“CPU 中转站模式”改成了“GPU 直达模式”。在交换密集型查询里，这种改动特别值钱。论文报告显示，在某些以交换为主的查询中，GPU 直接交换相比标准 Presto 交换协议，性能最高能提升到 20 倍。

图3：Velox 中 CudfVector 的数据流，表与流绑定。这里的关键是把数据和 CUDA stream 一起封装，算子能异步跑，CPU 驱动线程不用傻等。

要把 GPU 算子塞进 Velox，也不是简单地“把 CPU 版换成 GPU 版”就完事了。Velox 的执行模型是流水线式、异步式的，算子之间还会跨 pipeline 传数据，所以论文做了几件很关键的适配：把数据封装成 CudfVector，里面同时装着 cuDF 表和 CUDA stream；在 pipeline 边界才做同步；表达式从 Velox 的 TypedExpr 翻译到 cuDF 的表达式树；如果某个算子还没 GPU 版，就用 CudfToVelox / CudfFromVelox 做兼容转换。

这里最值得记住的一点是：论文没有假装“所有算子都已经 GPU 化”，而是很务实地做了渐进式迁移。能跑 GPU 的就跑 GPU，不能跑的再回退 CPU。工程上这很诚实，产品上也更容易落地。

多节点横扫30TB：GPU加速Presto的全景图

实验部分可以分成两层看。第一层是动机实验，回答“GPU 到底能跑多快”；第二层是把这些经验塞回 Presto/Velox，回答“真实数据库系统能不能跟上”。为了让结果可比，论文使用了 TPC-H 派生查询，既有聚合，也有多表连接，还有过滤、排序、分组的混合场景，基本覆盖了分析型查询的常见套路。

表2：实验设置汇总。这里列出了硬件、存储、通信和软件栈，方便读者理解后面的性能数字到底是在什么条件下测出来的。

在动机实验里，作者用两台服务器、每台 8 张 A100 GPU、总计 16 张 GPU，配合 160TB 存储和 GDS 直通，先把“硬件上限”摸了一遍。结果显示，只要把数据喂对路，很多查询已经能把 GPU 的带宽吃得很满；但如果 chunk 太大，GPU 会爆显存，chunk 太小又会增加调度和通信开销，所以不同查询会选择不同 partition 数。换句话说，查询计划和资源约束必须一起考虑，不能只看 SQL 语句长什么样。

这张表展示了 10TB 数据规模下若干 TPC-H 类查询的最优执行时间。它的意义不在于“谁是冠军”，而在于说明不同查询对应的瓶颈不同：有的更吃聚合，有的更吃连接，有的则是混合型流水线。

把这些经验放回 Presto/Velox 后，结果就更像一篇“系统工程改造说明书”了。论文报告称，在标准分析基准上，GPU 版 Presto 相比 CPU 版，性价比最高可提升 6 倍；而在交换特别重的查询里，GPU 原生交换相对 HTTP 交换能带来明显的加速，最高接近 20 倍。这个数字背后的逻辑并不神秘：只要数据还留在 GPU 里，GPU 就能持续干活；一旦数据被赶回 CPU，速度优势就像被拔了电源。

图5：在 8×A100 上，HttpExchange 与 UcxExchange 的查询执行时间对比。可以直观看到，GPU 直连交换对交换密集型查询特别友好。

图6：TPC-H Q5 在不同数据规模下的执行时间。随着规模增大，UcxExchange 依然保持明显优势，说明它不是只在小数据上“表演型优秀”。

图7：TPC-H 弱扩展性分析。数据和 worker 数同步增加时，系统能否保持稳定吞吐，决定了它是不是“真能上生产”。

图8：不同 GPU 配置下的总查询运行时间。它说明 GPU 数量、节点形态和查询类型之间会互相影响，不能简单地“多上卡就一定线性起飞”。

图9：AWS 上 Presto GPU 相对 CPU 的价格性能优势。这个图很关键，因为工程落地最终都绕不开一个问题：快，当然好；但值不值，才是采购单上的真命题。

从结果看，这套系统的性能提升并不是靠某一个“神奇算子”撑起来的，而是靠一整条链路协同：存储直达 GPU、算子尽量留在 GPU、交换也尽量 GPU 原生。只要其中任何一段掉链子，整体收益就会明显缩水。这个结论虽然朴素，但对做数据库的人很有用：系统优化经常不是“某个核函数快了多少”，而是“整条流水线有没有少走冤枉路”。

不只是炫技：GPU加速Presto的性价比与未来方向

这篇论文最值得肯定的地方，是它没有把 GPU 加速写成“换卡就赢”的爽文，而是老老实实把限制条件摊开：Parquet 仍然有格式负担，部分算子还没完全 GPU 化，复杂生产负载里还会遇到碎小向量过多、负载倾斜、资源调度不感知 GPU 等问题。换句话说，它已经把门踹开了，但屋里还有不少家具没摆整齐。

不过，这恰恰也是它有价值的地方。因为它证明了一件事：GPU 加速分析数据库不是只能停留在 demo，也不是必须推倒重来。只要系统设计愿意围着“少搬运、多留驻、直交换”这三条原则转，现有数据库也能被改造成更适合 GPU 的样子。

对实际应用来说，这种方案尤其适合分析型工作负载比较重、且已有 Presto/Velox 生态的场景。它不要求用户立刻迁移到全新系统，而是通过开关和组件替换逐步引入 GPU 能力。对企业来说，这种“渐进升级”比“大换血”更容易接受。

未来如果要继续往前走，几个方向很自然：一是让更多 Velox 算子拥有 GPU 版本，减少回退；二是让查询规划器感知 GPU 内存、带宽和拓扑，别让计划“理论上很美，落地时爆显存”；三是进一步优化数据格式和分区策略，让存储层和 GPU 更像一对默契搭档，而不是互相拖后腿的临时工。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是“分析数据库想用 GPU，但总被数据搬运和跨节点交换拖慢”的问题。论文没有另起炉灶，而是把 Presto/Velox 改造成 GPU-aware，让已有系统能更自然地吃到 GPU 加速。

UcxExchange 和 HttpExchange 有什么区别？HttpExchange 是 Presto 原来的 CPU 交换方式，数据要先落到主机内存再传；UcxExchange 则让 GPU 直接交换 GPU 数据，减少 CPU 中转，尤其适合交换密集型查询。

为什么论文反复强调“数据留在 GPU 里”？因为 GPU 真正的优势不只是算得快，而是带宽高、并行强；一旦数据频繁在 CPU 和 GPU 之间搬来搬去，传输开销就会吞掉加速收益。简单说，GPU 最怕的不是不会算，而是一直在搬砖。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆ 不是“发明 GPU 数据库”这种级别的原创，但把 Presto/Velox 真正改成 GPU-aware，而且把交换协议也一起改了，工程创新很扎实。

实验合理度：★★★★☆ 先做裸机上限实验，再回到真实系统验证，逻辑很顺；不足是部分结果依赖手工构建和特定硬件环境，泛化还需更多证据。

学术研究价值：★★★★☆ 它把“GPU 加速数据库”的关键瓶颈拆清楚了，尤其是数据搬运和交换这两块，对后续系统研究很有启发。

稳定性：★★★☆☆ 能跑真实工作负载，也开始用于生产，但仍有算子覆盖、资源调度和复杂负载稳定性问题。

适应性以及泛化能力：★★★☆☆ 对 Presto/Velox 生态很友好，但对其他系统的迁移仍要做不少工程适配。

硬件需求及成本：★★★☆☆ GPU 版能省钱，但前提是有合适的 GPU 集群和高速网络；不是一台普通机器就能随便起飞。

复现难度：★★★☆☆ 代码已集成到开源 Presto/Velox，复现门槛比纯闭源工作低，但完整环境仍需要 GPU 和高速存储支持。

产品化成熟度：★★★☆☆ 已经不是玩具原型，且开始用于客户生产负载；但要大规模稳定落地，还得继续补齐调度、算子覆盖和格式优化。

可能的问题：系统思路很对，但对资源感知调度、Parquet 读写和碎小向量问题的处理还不够彻底，离“无脑全场景通吃”还有距离。

主要参考文献

Daniel Bauer, Luis Garcés-Erice, Deepak Majeti, Zoltán Arnold Nagy, Sean Rooney, Greg Kimball, Devavret Makkar, Todd Mostak, and Karthik Natarajan. Accelerating Presto with GPUs. PVLDB, 19(1), 2026.

Presto 开源仓库与 Velox 相关实现：论文说明其 GPU 支持已集成到开源 Presto/Velox 中。

cuDF、KvikIO、UCX、NVSHMEM：论文中用于 GPU 读写、通信和交换的基础库与框架。

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
GPU数据库、Presto、分布式查询、开源代码，龙哥都帮你盯着点，少走弯路，多跑几倍！ wechat_helper