Do GPUs Really Need New Tabular File Formats?

Dit artikel toont aan dat prestatieknelpunten bij GPU-scans in Parquet-bestanden voortkomen uit suboptimale, op CPU gerichte configuraties in plaats van het formaat zelf, en laat zien dat het toepassen van GPU-bewuste instellingen de effectieve leesbandbreedte kan verhogen tot 125 GB/s zonder de Parquet-specificatie te wijzigen.

De kern

Stel je voor dat je een enorme bibliotheek van boeken (je data) hebt opgeslagen in een magazijn (je harde schijf). Je hebt ook een supersnelle robotbibliothecaris (je GPU) wiens taak het is om deze boeken te lezen en vragen te beantwoorden.

Sinds jaar en dag is de bibliotheek georganiseerd volgens een specifiek archiefsysteem genaamd Parquet. Dit systeem is ontworpen met een menselijke bibliothecaris in gedachten: het groepeert boeken in kleine, hanteerbare stapels die een mens gemakkelijk één voor één kan oppakken.

De robotbibliothecaris is echter anders. Hij pakt niet zomaar één stapel per keer op; hij heeft duizenden handen en kan tientallen stapels tegelijk grijpen. Maar omdat de bibliotheek nog steeds voor mensen is georganiseerd, staat de robot het grootste deel van de tijd te wachten tot de volgende stapel aan hem wordt overhandigd, of gebruikt hij slechts een klein deel van zijn handen. De robot is ongelooflijk snel, maar de organisatie van de bibliotheek houdt hem tegen.

Het artikel stelt een simpele vraag: Moeten we een gloednieuw archiefsysteem uitvinden, speciaal voor robots?

De auteurs zeggen: Nee. In plaats daarvan hoeven we alleen de bestaande boeken te herschikken met een paar eenvoudige regels.

Hier is hoe ze het probleem hebben opgelost, met behulp van vier hoofdrules:

1. De "Meer Stapels"-regel (Verhoog het Aantal Pagina's)

• Het Probleem: Het oude systeem bracht alle data voor een sectie onder in één gigantisch, zwaar boek. De robot probeerde het te lezen, maar kon slechts één hand tegelijk gebruiken omdat het boek te groot was om te splitsen.
• De Oplossing: Ze hakten die gigantische boeken in vele kleinere, dunnere pagina's. Nu kan de robot 100 pagina's tegelijk grijpen met zijn 100 handen.
• Het Resultaat: De robot staat niet meer te wachten; hij is druk bezig al zijn handen tegelijk te gebruiken.

2. De "Grote Dozen"-regel (Verhoog de Grootte van Rijgroepen)

• Het Probleem: Het oude systeem stuurde de robot piepkleine pakketjes, ter grootte van een postzegel. Hoewel de robot snel is, raakt het bezorgvoertuig (de verbinding tussen de schijf en de robot) verstopt door te veel piepkleine pakketjes.
• De Oplossing: Ze begonnen enorme, volledig gevulde verhuisdozen te sturen in plaats van postzegels.
• Het Resultaat: Het bezorgvoertuig kan nu op volle snelheid rijden, waardoor de robot constant van data wordt voorzien.

3. De "Slimme Verpakking"-regel (Coderingsflexibiliteit)

• Het Probleem: Het oude systeem verpakte de boeken met een generieke, alles-in-één-methode. Soms maakte dit de boeken kleiner, maar vaak hielp het niet veel.
• De Oplossing: Ze keken naar elk boek individueel en kozen de beste manier om het te verkleinen. Als een boek veel herhaalde woorden had, gebruikten ze een speciale code om het miniem te maken. Als een boek al kort was, lieten ze het ongemoeid.
• Het Resultaat: De boeken nemen minder ruimte in op het plankje, dus het bezorgvoertuig hoeft minder gewicht te dragen, wat het hele proces sneller maakt.

4. De "Niet Inpakken"-regel (Geen Onnodige Compressie)

• Het Probleem: Soms wikkelde het oude systeem boeken in zware bubbelfolie (compressie), zelfs als de boeken al klein waren. De robot moest dan tijd besteden aan het uitpakken, wat energie verspilte.
• De Oplossing: Ze besloten: "Als de bubbelfolie het pakket niet aanzienlijk kleiner maakt, gebruik het dan niet."
• Het Resultaat: De robot bespaart tijd door het uitpakken over te slaan voor boeken die het niet nodig hadden.

Het Grote Finale: De Robot versus de Mens

De auteurs testten deze nieuwe ordening.

• De Oude Manier: De robot was traag en gebruikte nauwelijks zijn superkrachten.
• De Nieuwe Manier: Door alleen de bestaande Parquet-bestanden te herschikken (zonder een nieuw formaat uit te vinden), maakten ze de robot 125 keer sneller in termen van datasnelheid.

Ze toonden ook aan dat wanneer de robot synchroon werkt met het bezorgvoertuig (lezen en verwerken overlappen), het nog efficiënter wordt. In feite was deze herschikte robot zo snel dat hij bijna de theoretische snelheidslimiet van het bezorgvoertuig zelf bereikte.

De Conclusie

Het artikel concludeert dat we de bibliotheek niet hoeven af te branden en van scratch een nieuwe hoeven te bouwen. We hoeven alleen de boeken op de plank te zetten met een paar slimme aanpassingen.

Door te knutselen aan hoe de data wordt verpakt en gegroepeerd, kan het bestaande Parquet-formaat al met bliksemsnelheid draaien op moderne GPU's. Dit bespaart iedereen de moeite om een nieuw systeem te leren en houdt alle oude software compatibel, terwijl we toch de enorme snelheidswinst krijgen die we wilden.

Technische samenvatting

Technische Samenvatting: Hebben GPU's Nieuwe Tabulaire Bestandsformaten Werkelijk Nodig?

Probleemstelling

Apache Parquet is het de facto kolommatige bestandsformaat in moderne analytische systemen, maar de standaardconfiguratie richtlijnen zijn gevormd door CPU-gerichte uitvoeringsengines. Naarmate GPU-versnelde gegevensverwerking wijdverbreid raakt, worden Parquet-bestanden die voor CPU's zijn geoptimaliseerd, vaak ernstig onderbenut op GPU-hardware, wat een kunstmatige prestatieknelpunt creëert. Ondanks uitgebreide tests aan de CPU-zijde blijft het lezen van Parquet een grote knelpunt in GPU-versnelde analyses; bijvoorbeeld rapporteert het NVIDIA RAPIDS-team dat ongeveer 85% van de runtime van de TPC-H-benchmark wordt besteed aan Parquet-scans in plaats van aan query-operatoren. Dit roept de centrale onderzoeksvraag op: Hebben GPU's werkelijk nieuwe tabulaire bestandsformaten nodig, of kunnen bestaande Parquet-configuraties worden geoptimaliseerd om hoge prestaties te bereiken?

Methodologie

De auteurs voerden een systematische studie uit om te evalueren hoe Parquet-configuratiekeuzes de prestaties van GPU-scans beïnvloeden. De experimentele opstelling gebruikte een enkele NVIDIA A100 GPU die de grootste TPC-H SF300-tabel (lineitem) las van lokale NVMe SSD's via GPUDirect Storage (GDS). De studie maakte gebruik van PystachIO, een GPU-versnelde analytische systeem dat I/O en GPU-berekening volledig overlapt, gebouwd op de NVIDIA RAPIDS cuDF-bibliotheek.

De methodologie omvatte:

1. Basislijn Vaststellen: Genereren van Parquet-bestanden met de standaardinstellingen van DuckDB (één pagina per kolomchunk, 122.880 rijen per Row Group (RG), Parquet V1-encoderingen en standaardcompressie).
2. Configuratie Iteratie: Systematisch aanpassen van bestandsparameters om vier specifieke dimensies te testen:
   • Aantal Pagina's: Verhogen van het aantal pagina's per RG om overeen te komen met de grootte van GPU-kernelroosters.
   • Row Group (RG) Grootte: Verhogen van het aantal rijen per RG om grotere I/O-eenheden te creëren die geschikt zijn voor GDS.
   • Encoderingsflexibiliteit: Toestaan van per-chunk selectie van optimale encoderingen uit zowel Parquet V1- als V2-schema's.
   • Compressie Selectiviteit: Compressie overslaan voor kolomchunks waar de groottevermindering een specifieke drempel (10%) niet overschrijdt.
3. Tool Ontwikkeling: De auteurs ontwikkelden een Parquet herschrijftool (geschreven in Rust) om bestaande Parquet-bestanden om te zetten naar deze geoptimaliseerde configuraties zonder het bestandsformaat specificatie te wijzigen.
4. Prestatiemetingen: Evaluatie concentreerde zich op effectieve leesbandbreedte (logische ruwe gegevensgrootte gedeeld door scanruntime) en end-to-end queryruntime voor TPC-H-query's (Q6 en Q12) over variërende datasetschalen (tot SF1000).

Belangrijkste Bijdragen en Inzichten

Het artikel presenteert vier primaire inzichten afgeleid van de experimentele resultaten:

1. Optimalisatie Aantal Pagina's: GPU-decoderingskernels paralleliseren over pagina's. Standaardconfiguraties resulteren vaak in te weinig pagina's, waardoor de GPU onderbenut blijft. Het verhogen van het aantal pagina's naar 100 of meer verbetert de decoderingsefficiëntie en de bandbreedte van de opslagbus aanzienlijk.
2. Optimalisatie RG Grootte: De GPU I/O-stack (GDS) gedraagt zich anders dan CPU-stacks en prefereert grotere I/O-eenheden (in de orde van MiB) om de opslagbandbreedte te verzadigen. Standaard RG-groottes (die resulteren in chunks van ongeveer 100 KB) zijn suboptimaal. Het verhogen van RG-groottes naar miljoenen rijen (bijvoorbeeld 10 miljoen rijen) stelt GDS in staat om SSD's te verzadigen.
3. Encoderingsflexibiliteit: Het beperken van encoderingen tot Parquet V1 beperkt de compressie-efficiëntie. Het toestaan van de selectie van de kleinste gecodeerde grootte uit zowel V1- als V2-schema's (bijvoorbeeld het gebruik van Delta Binary Packed voor gehele getallen) verbetert de compressieverhoudingen. Dit vermindert de I/O-knelpunt en benut efficiënte V2-decodering op GPU's.
4. Ongewenste Compressie Vermijden: Blind toepassen van compressie voegt decompressie-overhead toe. De studie toont aan dat het overslaan van compressie wanneer de groottevermindering onder een drempel van 10% blijft, de prestaties verbetert, met name in scenario's waar de GPU rekenkracht-gebonden is (bijvoorbeeld bij het lezen van meerdere SSD's).

Resultaten

Door deze GPU-bewuste configuraties toe te passen op volledig compatibele Parquet-bestanden, bereikten de auteurs de volgende resultaten:

• Effectieve Bandbreedte: De geoptimaliseerde configuratie bereikte tot 125 GB/s effectieve leesbandbreedte met 4 SSD's, een dramatische verbetering ten opzichte van de basislijn.
• Schalbaarheid: De effectieve bandbreedte schaalde lineair met het aantal SSD's wanneer encoderingsflexibiliteit werd toegepast, terwijl basislijnconfiguraties vroeg verzadigden.
• Query Prestaties: Op TPC-H-query's (Q6 en Q12) presteerde het GPU-systeem met geoptimaliseerde Parquet-bestanden aanzienlijk beter dan CPU-systemen (ClickHouse en DuckDB) en bleef het dicht bij de theoretische minimale runtime (gedefinieerd door SSD-bandbreedte).
• Geen Nieuw Formaat Vereist: De studie toont aan dat hoge GPU-prestaties kunnen worden bereikt zonder over te schakelen naar een nieuw bestandsformaat, waardoor de interoperabiliteitsvoordelen van het Parquet-ecosysteem behouden blijven.

Betekenis en Aanspraken

Het artikel betoogt dat nieuwe bestandsformaten niet strikt noodzakelijk zijn voor high-performance GPU-analyses. In plaats daarvan is het prestatiegat grotendeels een gevolg van suboptimale configuratiekeuzes die zijn overgeërfd van CPU-gerichte standaarden.

• Praktische Richtlijnen: Het werk biedt de eerste praktische richtlijnen voor het optimaliseren van Parquet voor GPU-databases, waardoor aanzienlijke versnelling mogelijk wordt via configuratie in plaats van vervanging van het formaat.
• Basislijn voor Toekomstig Werk: De auteurs stellen een sterke basislijn vast voor toekomstige GPU-bestandsformaten. Zij stellen dat elk voorgesteld nieuw formaat deze geoptimaliseerde Parquet-configuraties (die ongeveer 125 GB/s bereiken) moet overtreffen, in plaats van slechts een verbetering te zijn ten opzichte van niet-geoptimaliseerde standaarden.
• Behoud van Ecosysteem: Door compatibiliteit te behouden met de bestaande Parquet-specificatie en het ecosysteem, vermijdt de voorgestelde aanpak de kosten die gepaard gaan met migratie naar propriëtaire of nieuwe formaten.
• Hardware Onafhankelijkheid: Hoewel gericht op GPU's, is de herschrijftool niet hardware-specifiek; deze past configuraties toe op basis van de kenmerken van de doelhardware, wat suggereert dat frequente query's op elke hardware kunnen profiteren van dergelijke herschrijving.

De auteurs concluderen dat, hoewel er nieuwe formaten bestaan die gericht zijn op decodering in het GPU-geheugen, de dominante knelpunt in real-world scenario's nog steeds de opslag-I/O is. Daarom is het optimaliseren van het bestaande Parquet-formaat om de opslagdoorvoer te maximaliseren en decompressie-overhead te minimaliseren een kritieke, directe stap voordat volledig nieuwe bestandsformaatontwerpen worden overwogen.