图谱动态｜学苑周刊 NO.235

本周推荐的是arxiv 2025.8上的论文：Rethinking Analytical Processing in the GPU Era。

背景与动机

图形处理单元（GPU）在分析型数据库工作负载中的广泛应用长期以来一直受到几个根本性限制的阻碍。传统障碍包括有限的GPU内存容量、通过PCIe互连的数据传输瓶颈、高昂的硬件成本，以及构建生产级GPU优化SQL引擎所需的大量工程投入。然而，近期硬件和软件的进步从根本上改变了这一格局，开创了作者们所称的数据分析“GPU时代”。

这一转变体现在GPU硬件能力的显著提升上。内存容量已从2016年的16 GB增加到最新一代的288 GB，同时互连带宽也大幅增长——NVLink带宽在2016年至2024年间从80 GB/s增至900 GB/s，而PCIe带宽到2024年将达到256 GB/s。此外，GPUDirect Storage等技术使GPU能够直接访问存储系统，绕过CPU的参与，消除了传统的数据传输瓶颈。

图：GPU内存容量演进，显示从2016年16 GB (P100) 到2025年288 GB (B300) 的显著增长，虚线表示预计增长。

在软件方面，可组合数据系统和开源GPU库的成熟显著降低了工程障碍。Substrait等标准为查询计划提供了统一的中间表示，而libudf、RMM (RAPIDS Memory Manager) 和NCCL等库则分别为关系操作、内存管理和分布式通信提供了高度优化的GPU原语。

系统架构与设计

Sirius围绕两个核心设计原则构建，这使其区别于现有方法。

第一个是GPU原生执行，其中GPU作为主要执行引擎，而非仅仅是加速器。与将GPU加速附加到现有CPU优化引擎的混合CPU-GPU系统不同，Sirius将整个查询计划在GPU上执行视为默认路径，CPU主要作为不受支持操作的备用方案。

第二个原则是即插即用加速，通过标准接口实现与现有数据库系统的无缝集成。Sirius消费以Substrait格式表示的查询计划，使其能够作为任何Substrait兼容主机系统的加速器，而无需对现有代码库进行重大修改。

系统架构由几个关键组件组成：

查询执行引擎：采用流水线执行模型，其中查询计划被划分为由CPU线程协调GPU任务执行的流水线。在每个流水线内部，它使用类似于DuckDB的推式执行模型。该引擎大量利用libudf实现大多数物理运算符，提供了在libudf实现和自定义CUDA内核之间切换的灵活性。

缓冲区管理器：管理GPU内存，该内存分为数据缓存（预分配用于缓存数据）和数据处理（由RMM管理用于中间结果）。管理器处理列式格式转换，尽可能采用零拷贝优化，尤其是在Arrow派生格式之间。

交换服务层：通过使用NCCL原语进行节点间数据交换，实现高速GPU到GPU通信，从而编排分布式查询执行。它将交换建模为专用的物理运算符，支持广播、混洗、合并和多播操作。

论文、讨论链接：https://www.alphaxiv.org/overview/2508.04701v2，感兴趣的读者可以关注。