Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics

TL;DR

Vortex tackles the memory capacity bottleneck in GPU-accelerated data analytics by redistributing IO from all GPUs to a single target GPU. It introduces the Exchange primitive and an IO-decoupled programming model with ExKernels and a Pipelined Executor to process data that does not fit in GPU memory. Through tailored operators for sort and hash join and a late-materialization strategy, Vortex achieves substantial end-to-end improvements over CPU-only and prior GPU baselines, notably on Star Schema Benchmark workloads. The approach demonstrates significant practical impact by delivering up to several-fold speedups and strong price-performance advantages in multi-GPU servers, with manageable interference from concurrent AI workloads.

Abstract

Despite the high computational throughput of GPUs, limited memory capacity and bandwidth-limited CPU-GPU communication via PCIe links remain significant bottlenecks for accelerating large-scale data analytics workloads. This paper introduces Vortex, a GPU-accelerated framework designed for data analytics workloads that exceed GPU memory capacity. A key aspect of our framework is an optimized IO primitive that leverages all available PCIe links in multi-GPU systems for the IO demand of a single target GPU. It routes data through other GPUs to such target GPU that handles IO-intensive analytics tasks. This approach is advantageous when other GPUs are occupied with compute-bound workloads, such as popular AI applications that typically underutilize IO resources. We also introduce a novel programming model that separates GPU kernel development from IO scheduling, reducing programmer burden and enabling GPU code reuse. Additionally, we present the design of certain important query operators and discuss a late materialization technique based on GPU's zero-copy memory access. Without caching any data in GPU memory, Vortex improves the performance of the state-of-the-art GPU baseline, Proteus, by 5.7$\times$ on average and enhances price performance by 2.5$\times$ compared to a CPU-based DuckDB baseline.

Figures (14)

• Figure 1: Evolution of GPU system topology.
• Figure 2: Multiple paths between GPU0 and CPU.
• Figure 3: Pipelining data forwarding.
• Figure 4: The interface of Exchange operation.
• Figure 5: The implementation details of Exchange operation.