NVIDIA 中国开发者日活动 中国・苏州 | 2025 年 11 月 14 日 了解详情
数据科学

GPU 原生 Velox 和 NVIDIA cuDF 加速大规模数据分析

随着工作负载规模的扩大以及对高效数据处理需求的提升,相比基于 CPU 的系统,采用 GPU 加速的数据库和查询引擎在性价比方面展现出显著优势。GPU 凭借其高显存带宽和大规模并行线程能力,特别适合处理计算密集型任务,如多表连接、复杂聚合运算和字符串处理等。随着 GPU 节点可用性的持续提升以及 GPU 算法在功能覆盖上的不断拓展,GPU 数据处理的实现正变得前所未有的便捷。

通过解决性能瓶颈,数据和业务分析师如今能够查询大规模数据集,实时获取洞察并深入探索各类分析场景。

为满足不断增长的需求,IBM 与 NVIDIA 正在合作将 NVIDIA cuDF 集成至 Velox 执行引擎,从而在 PrestoApache Spark 等广泛应用的平台上实现原生 GPU 查询执行。该项目为开源项目。

Velox 与 cuDF 如何协同工作以执行查询计划的翻译

Velox 充当中间层,将来自 Presto 和 Spark 等系统的查询计划转换为由 cuDF 支持的可执行 GPU 工作流,如图 1 所示。更多详细信息请参阅 扩展 Velox——基于 cuDF 实现 GPU 加速

在本文中,我们将分享 Presto 和 Spark 在 Velox 中使用 GPU 后端的初步性能测试结果,并深入探讨相关细节。

  • 端到端 Presto 加速
  • 扩展 Presto 以支持多 GPU 并行执行
  • 在 Apache Spark 中实现 CPU 与 GPU 的混合执行
Flow chart illustrating the architecture of a data processing system involving Velox and cuDF, which is integrated with other tools like Spark and Presto.
图1展示了查询从 Presto 或 Apache Spark 流向 Velox 引擎的过程,随后在引擎内部被转换为由 cuDF 支持的可执行 GPU 工作流。

将整个 Presto 查询计划迁移至 GPU,以提升执行速度

查询处理的第一步是将接收到的 SQL 命令转换为查询计划,并在集群的每个节点上分配相应的执行任务。在各个工作节点上,Velox 的 cuDF 后端从 Presto 协调器获取查询计划,利用 GPU 算子对计划进行重写,随后执行该计划。

将 Velox 与 cuDF 结合用于执行 Presto 计划时,需优化适用于 TableScan、HashJoin、HashAggregation 和 FilterProject 等算子的 GPU 实现。

  • 表扫描: Velox 的表扫描功能已在 CPU 上实现扩展,并与 cuDF 中的 GPU I/O、解压缩和解码组件兼容。
  • HashJoin: 支持的连接类型已扩展,涵盖左连接、右连接和内连接,同时支持过滤条件及空值语义处理。
  • HashAggregation: 引入了流式接口,用于管理部分聚合和最终聚合过程。

总体而言,Velox 的 cuDF 后端通过扩展 Operator,能够在 Presto 中实现端到端的 GPU 执行,充分复用 Presto 的 SQL 解析器、优化器和协调器功能。

该团队在 TPC-H 衍生的 Presto TPC-H 基准测试中,使用支持 Presto C++ 和 Presto-on-GPU worker 类型的 Parquet 数据源,收集了查询运行时的数据。需要注意的是,由于 Presto C++ 在标准配置下无法完成第 21 号查询,因此下图展示了其余 21 个成功执行查询的总运行时间。请注意,Presto C++ 无法使用 标准配置选项 完成 Q21,因此图中突出了 21 个成功查询的总运行时间。

如图2所示,在规模系数为1000的条件下,Presto C++在AMD 7965WX上的运行时间为1246秒,在NVIDIA RTX PRO 6000 Blackwell Workstation上的运行时间为133.8秒,在NVIDIA GH200 Grace Hopper Superchip上的运行时间为99.9秒。此外,我们在GH200上使用CUDA托管显存执行了Q21(见图2中的星号标注),在完整查询集上,Presto GPU的运行时间达到148.9秒。

Bar chart with an X-axis showing categories for Presto C++ on CPU and Presto on NVIDIA GPU results and Y-axis showing runtime in seconds.
图2展示了在TPC-H基准测试定义的22个查询中,有21个查询的运行时间结果(在CPU上使用单节点Presto C++执行,与在NVIDIA GPU上以1000倍扩展系数执行的对比)。

多 GPU 的 Presto 可加快数据交换速度,并缩短查询运行时间

在分布式查询执行中,Exchange 是一个关键的运算符,用于管理同一节点内工作线程之间以及不同节点之间的数据传输。GPU 加速的 Presto 采用基于 UCX 的 Exchange 算子,支持将整个执行流程在 GPU 上完成。UCX(统一通信 X 框架)是一种开源通信库,专为提升高性能计算(HPC)应用的通信性能而设计。其核心利用高带宽的 NVLink 实现节点内的高效连接,同时通过 RoCE 或 InfiniBand 支持节点间的高速通信。

Velox 支持多种 Exchange 类型,以应对不同类型的数据移动需求,包括分区、合并和广播。分区交换通过哈希函数对输入数据进行分区,并将各分区发送至其他工作进程以进行后续处理。合并交换则从多个工作进程中接收输入分区,将其合并为一个有序的输出分区。广播交换会在单个工作进程中加载数据,然后将其复制到所有其他工作进程。目前,GPU 交换功能正在集成到 Velox 的 cuDF 后端,相关实现已可在 Velox 主分支中使用。 implementation is available on mainline Velox.

如图3所示,Presto通过基于UCX的新型交换机制在GPU上实现了高效的性能表现,尤其在GPU之间具备高带宽的节点内连接时优势显著。在8-GPU的NVIDIA DGX A100节点上,Exchange Operator使用NVLink相比传统的Presto基准HTTP交换方式,性能提升超过6倍。实验中分别采用基准HTTP交换方法和基于UCX的cuDF交换方法在GPU上收集Presto的执行结果。在使用8个GPU工作节点的配置下,Presto能够在不依赖统一内存管理的情况下,通过默认的异步内存分配机制顺利完成全部22个查询任务。

请注意,图 3 展示的是基于 Presto Coordinator 和冷缓存远程数据源的多节点执行计划,而图 2 显示的是单节点热缓存下的运行时结果,两者执行环境不同,因此不具备直接可比性。

Bar chart with an X-axis showing categories for Presto C++ and Presto on GPU results and Y-axis showing runtime in seconds.
图3展示了在NVIDIA DGX A100(配备8个A100 GPU)上,使用Presto GPU执行TPC-H基准测试中定义的22个查询的运行时间结果,测试规模因子为1000。

Apache Spark 中的 CPU 与 GPU 混合执行

尽管 Presto 的集成侧重于端到端的 GPU 执行,而 Apache Spark 与 Apache Gluten 和 cuDF 的集成目前则聚焦于卸载特定的查询阶段。该功能可将工作负载中计算密集的部分分配至 GPU,从而在包含 CPU 和 GPU 节点的混合集群中高效利用 GPU 资源。

例如,TPC-DS Query 95 在 SF100 规模下,其第二阶段属于计算密集型任务,可能拖慢 CPU 集群的整体运行速度。若将该阶段卸载至 GPU 执行,可显著提升性能,同时释放 CPU 资源,使其继续服务于其他查询或工作负载。

如图4所示,即使表扫描的第一阶段在CPU上执行,只要将第二阶段卸载到GPU,借助CPU与GPU之间的高效协同,仍可实现更短的总体运行时间。实验条件为:纯CPU方案使用8个vCPU,而CPU+GPU方案则使用8个vCPU和1个NVIDIA T4 GPU(g4dn.2xlarge实例)。

Bar chart with an X-axis showing categories for Second Stage execution on CPU and GPU. Y-axis shows runtime in seconds.
图4展示了在规模系数为100的条件下,使用单节点、单GPU执行查询95的运行时间结果(依据Gluten TPCDS中的定义)。 tpcds,执行与单节点,单GPU在规模因子100

参与基于 GPU 驱动的大规模数据分析

推动在共享执行引擎 Velox 中实现 GPU 加速,为数据处理生态系统中的各类下游系统带来性能提升。该团队正与多家公司的贡献者协作,在 Velox 中开发可复用的 GPU 算子,以加速 Presto、Spark(通过 Gluten)及其他系统。这一方法有助于减少重复开发、简化维护工作,并推动整个开放数据栈的技术创新。

我们很高兴向社区成员分享这一开源作品,并诚挚期待您的反馈。诚邀您参与交流与探讨:

致谢

许多开发者为这一工作做出了贡献。来自 IBM 的贡献者包括 Zoltán Arnold Nagy、Deepak Majeti、Daniel Bauer、Chengcheng Jin、Louis Garcés-Erice、Sean Runey 和 Ali LeClerc;来自 NVIDIA 的贡献者包括 Greg Kimball、Karthikeyan Natarajan、Devavret Makkar、Shruti Shivakumar 和 Todd Mostak。

 

标签