数据科学

在 NVIDIA GB200 NVL72 上使用 GPU 加速的 Presto 运行低延迟分析工作负载

Presto 是一个开源分布式 SQL 引擎,可对超大型数据集快速运行交互式查询。在 NVIDIA GPU 上,Presto 可为分析查询工作负载提供峰值性能,并为用户和智能体提供低延迟。GPU 加速的 Presto 可降低分析工作负载的延迟,让您和智能体畅通无阻并尽可能快地进行迭代。

本文将介绍如何使用单节点 NVIDIA DGX B200 和多节点 NVIDIA GB200 NVL72 在扩展分析基准测试中高效执行多 GPU Presto。我们还强调了 NVIDIA GPUDirect Storage (GDS) 在与 IBM Storage Scale System 数据源搭配使用时对 NVIDIA GB200 NVL72 上的高 I/ O 吞吐量的重要性。

如需详细了解 GPU 加速的 Presto 以及 UcxExchange 对于 GPU 工作者之间高性能通信的重要性,请参阅使用 GPU 原生 Velox 和 NVIDIA cuDF 加速大规模数据分析

GPU 加速的 Presto 如何提供峰值性能?

GPU 加速的 Presto 使用 NVIDIA cuDF 算法实现峰值性能,并使用 NVIDIA NVLink 实现更快的 GPU 到 GPU 通信。配备 8 个 GPU 的单个 DGX B200 节点可支持 8 个 Presto GPU worker,这些 worker 均通过 NVLink 5.0 连接,双向带宽高达 1800 GB/ 秒。与在英特尔至强 6642Y 服务器的 8-10 个节点上运行的 Presto CPU 相比,DGX B200 上的 GPU 加速 Presto 具有明显的性能优势。

本文重点介绍衍生自 TPC-H 的基准测试,其中包含 22 个分析查询,使用 parquet 文件数据源,并在此演示中将十进制类型替换为浮点类型。测量的查询运行时包括 SQL 解析、计划优化、工作进程执行和返回最终结果。运行时的测量方法是:对每个查询运行 5 次,并取最后 4 个值的平均值。使用 Presto、Velox 和 cuDF 的源版本收集基准测试数据。有关全面的构建、部署和基准测试脚本,请参阅 rapidsai/velox-testing GitHub 存储库。

图 1 比较了多节点 CPU Presto 和单节点多 GPU Presto 的查询运行时。用于扩展因子 1K 的 Presto CPU 配置使用了 Presto C++ worker、8 个双插槽英特尔至强 6642Y 服务器节点 (具有 250 GiB 系统内存) ,以及一个包含 parquet 文件的 Lustre 数据源。在扩展系数为 3K 时,Presto CPU 配置使用相同服务器的 10 个节点。Presto CPU 配置在基准测试中热运行,工作节点使用 Velox 异步数据缓存,协调节点使用 软亲和性来提高缓存利用率。Presto GPU 配置使用一个 NVIDIA DGX B200,其中包含不同数量的活动 GPU 和热缓存拼接数据源。

在规模系数为 1K (约 1 TB 数据集) 的情况下,GPU 加速的 Presto 可将延迟降低 2.5 倍至 8 倍,具体取决于活动 GPU 的数量。使用一个 B200 GPU 运行的 Presto GPU 的运行时间比使用 8 个节点的 Presto CPU 集群快 2.5 倍,使用 8 个 B200 GPU 运行的 Presto GPU 的运行时间比使用 8 个节点的 Presto CPU 集群快 8.2 倍。在规模系数为 3K (约 3 TB 数据集) 的情况下,Presto GPU 可将延迟降低 3 至 8 倍。使用三个 B200 GPU 运行的 Presto GPU 的运行时间比使用 10 节点的 Presto CPU 集群快 3.6 倍,使用 8 个 B200 GPU 运行的 Presto GPU 的运行时间比使用 10 节点的 Presto CPU 集群快 7.8 倍。

GPU 加速的 Presto 如何在 GB200 NVL72 上横向扩展?

GPU 加速的 Presto 还可横向扩展到多个节点,在 NVLink 连接的系统 (例如 NVIDIA GB200 NVL72) 上具有出色的观察性能。NVIDIA GB200 NVL72 系统共包含 18 个节点,每个节点包括 2 个 Grace CPU、4 个 B200 GPU 和 4 个 ConnectX-7 (CX7) 400 Gbps 网络接口卡。集群中的 GPU 均通过 NVLink 连接,为计算和存储之间的流量开放网络。

在 GPU 加速的 Presto 基准测试中,NVL72 集群与 IBM Storage Scale 搭配使用,后者是一个数据存储系统,拥有 20 个存储节点,容量为 10 PB,峰值带宽约为 4.5 TiB/s。IBM Storage Scale (以前称为 IBM Spectrum Scale 或 GPFS) 是一个集群化、符合 POSIX 标准的并行文件系统,通过 InfiniBand/ RoCE 提供原生远程直接内存访问 (RDMA) 传输。NVIDIA GDS 和 IBM Storage Scale 相结合,可让文件数据直接从存储设备移动到 GPU 显存,从而绕过主机 CPU 和系统内存反弹缓冲区。

图 2 比较了 NVL72 GB200 集群中由 TPC-H 衍生的扩展因子 10K 和 30K 的总查询运行时,突出显示了集群启动期间最重要的 I/ O 和通信优化。图 2 所示的查询运行时数据使用了 18 个总节点中的 8 个活动节点,对应参与分析工作负载的 32 个 Presto GPU worker。

首次运行条件使用了 POSIX 读取到 IBM Storage Scale、未优化的 I/ O 参数和未调整的 UcxExchange 配置。通过启用 GDS 并将 I/ O 任务大小从 4 MiB 增加到 16 MiB ( IBM Storage Scale 的建议大小) ,下一个条件设备读取和 16 MiB I/ O 任务交付速度比之前快 30%。

在使用 16 个 I/ O 线程 (而非 4 个 I/ O 线程) 时,由于 NVLink 饱和度更好,下一个条件加 16 个 I/ O 线程可将运行时间进一步缩短约 17%。由于交换批量较大且 GPU 空闲时间较少,最终的条件加重重新批处理和问题 11 重写将运行时间再缩短 35%。总体而言,I/ O 和通信优化将查询运行时间缩短了 64%。

Q11 rewrite 将 SELECT 语句修改为 INSERT INTO 语句,将 Q11 的运行时间从 50 秒缩短到 2 秒。我们观察到,Q11 作为 SELECT 语句导致集群中的 GPU 利用率缩短了约 5%,原因是在默认的 HttpExchange 上,GPU 工作进程向协调者发送查询结果时出现瓶颈。将问题 11 作为 INSERT INTO 语句运行,可使用基于 GPU 的 Parquet Writer 将结果高效存储在 IBM Storage Scale 中。

接下来,我们计划提高在 Presto 中从工作节点到协调节点发送结果的吞吐量,在不调整查询的情况下保持较高的 GPU 利用率。

如何使用 GDS 实现更快、更轻量的 I/ O

在采用 IBM Storage Scale 的 NVL72 集群上,GDS 是实现峰值性能和性价比的关键工具。IBM Storage Scale 支持两种主要数据路径:POSIX 在复制到 GPU 显存之前先在客户端页面池中读取该阶段数据,以及 GDS 使用 RMDA 读取填充 GPU 显存的数据。GDS 具有拓扑感知能力,可确保从 CX7 网卡到 GPU 显存的数据路径始终位于同一 NUMA 节点内。本研究中的 IBM Storage Scale 版本对于 POSIX 读取没有拓扑感知能力,因此这些读取会产生额外的暂存缓冲区副本以及 NUMA 边界交叉的惩罚。

我们在两种 I/ O 配置中分析了由 TPC-H 衍生的 10K 性能:标称分页池大小为 50 GiB 的 POSIX cold 和绕过缓存的 GDS cold。在使用两个节点 ( 8 个 GPU) 运行规模系数 10K 时,我们发现 GDS 读取相比 POSIX 读取具有显著优势。在 2 个节点和 8 个 GPU 上,由于反弹缓冲区复制和 NUMA 边界交叉导致 POSIX 速度减慢,GDS 冷读取的运行时间比 POSIX 冷读取快 2 倍。由于数据路径高效且主机资源消耗减少,我们预计 GDS 读取将成为在采用 IBM Storage Scale 的 NVL72 上实现性能和成本效益的首选方法。

开始使用 GPU 加速的 Presto

无论您是运行交互式仪表板,还是夜间作业,GPU 加速的 Presto 都能为您的分析工作负载提供低延迟和高吞吐量。

通过集成在 IBM watsonx.data 平台中,GPU 加速的 Presto 现在已准备好在生产工作负载上进行测试。注册以在 watsonx.data 上访问 GPU 加速的 Presto 技术预览

对于对 Presto 测试和部署感兴趣的开发者和工程师,请参阅 Presto Native gpu-nightly 标签,位于 Presto DockerHub。如需了解详情,请参阅 GPU 加速的 Presto C++ 入门

标签