Do GPUs Really Need New Tabular File Formats?

Dieser Artikel zeigt, dass Engpässe bei der GPU-Scan-Leistung in Parquet-Dateien auf suboptimale, CPU-zentrierte Konfigurationen und nicht auf das Format selbst zurückzuführen sind, und belegt, dass die Anwendung GPU-bewusster Einstellungen die effektive Lesebandbreite auf 125 GB/s steigern kann, ohne die Parquet-Spezifikation zu ändern.

Das Wesentliche

Stellen Sie sich vor, Sie haben eine riesige Bibliothek von Büchern (Ihre Daten), die in einem Lagerhaus (Ihre Festplatte) gespeichert sind. Sie haben auch einen superschnellen Roboter-Bibliothekar (Ihre GPU), dessen Aufgabe es ist, diese Bücher zu lesen und Fragen zu beantworten.

Seit Jahren ist die Bibliothek mit einem bestimmten Ablagesystem namens Parquet organisiert. Dieses System wurde mit einem menschlichen Bibliothekar im Sinn entwickelt: Es gruppiert Bücher in kleine, handliche Stapel, die ein Mensch leicht einzeln aufnehmen kann.

Der Roboter-Bibliothekar ist jedoch anders. Er nimmt nicht nur einen Stapel nach dem anderen auf; er hat Tausende von Händen und kann Dutzende von Stapeln gleichzeitig greifen. Da die Bibliothek jedoch immer noch für Menschen organisiert ist, verbringt der Roboter die meiste Zeit damit, auf den nächsten Stapel zu warten, oder er nutzt nur einen winzigen Bruchteil seiner Hände. Der Roboter ist unglaublich schnell, aber die Organisation der Bibliothek bremst ihn aus.

Die Arbeit stellt eine einfache Frage: Müssen wir ein brandneues Ablagesystem nur für Roboter erfinden?

Die Autoren sagen: Nein. Stattdessen müssen wir nur die vorhandenen Bücher mit ein paar einfachen Regeln neu anordnen.

So haben sie das Problem mit vier Haupt„Verkehrsregeln" gelöst:

1. Die „Mehr Stapel"-Regel (Erhöhung der Seitenzahl)

• Das Problem: Das alte System legte alle Daten eines Abschnitts in ein einziges riesiges, schweres Buch. Der Roboter versuchte, es zu lesen, konnte aber nur eine Hand gleichzeitig benutzen, weil das Buch zu groß war, um es aufzuteilen.
• Die Lösung: Sie zerschnitten diese riesigen Bücher in viele kleinere, dünnere Seiten. Jetzt kann der Roboter mit seinen 100 Händen 100 Seiten gleichzeitig greifen.
• Das Ergebnis: Der Roboter wartet nicht mehr herum; er ist damit beschäftigt, alle seine Hände gleichzeitig zu nutzen.

2. Die „Große Kisten"-Regel (Erhöhung der Zeilengruppen-Größe)

• Das Problem: Das alte System sandte dem Roboter winzige, briefmarkengroße Pakete. Obwohl der Roboter schnell ist, wird der Lieferwagen (die Verbindung zwischen dem Laufwerk und dem Roboter) mit zu vielen winzigen Paketen verstopft.
• Die Lösung: Sie begannen, riesige, vollgepackte Umzugskartons statt Briefmarken zu senden.
• Das Ergebnis: Der Lieferwagen kann nun mit voller Geschwindigkeit fahren und den Roboter kontinuierlich mit Daten versorgen.

3. Die „Intelligente Verpackung"-Regel (Kodierungsflexibilität)

• Das Problem: Das alte System verpackte die Bücher mit einer generischen, „Einheitsgröße"-Methode. Manchmal machte dies die Bücher kleiner, aber oft half es nicht viel.
• Die Lösung: Sie betrachteten jedes Buch einzeln und wählten die beste Methode, um es zu verkleinern. Wenn ein Buch viele wiederholte Wörter enthielt, verwendeten sie einen speziellen Code, um es winzig zu machen. Wenn ein Buch bereits kurz war, ließen sie es unverändert.
• Das Ergebnis: Die Bücher nehmen weniger Platz im Regal ein, sodass der Lieferwagen weniger Gewicht zu tragen hat, was den gesamten Prozess beschleunigt.

4. Die „Nicht einwickeln"-Regel (Keine unnötige Komprimierung)

• Das Problem: Manchmal wickelte das alte System Bücher in schwere Luftpolsterfolie (Komprimierung), selbst wenn die Bücher bereits klein waren. Der Roboter musste dann Zeit damit verbringen, sie auszuwickeln, was Energie verschwendete.
• Die Lösung: Sie entschieden: „Wenn die Luftpolsterfolie das Paket nicht erheblich kleiner macht, verwenden Sie sie nicht."
• Das Ergebnis: Der Roboter spart Zeit, indem er den Auswickselschritt für Bücher überspringt, die ihn nicht benötigten.

Das große Finale: Der Roboter gegen den Menschen

Die Autoren testeten diese neue Anordnung.

• Der alte Weg: Der Roboter war langsam und nutzte seine Superkräfte kaum.
• Der neue Weg: Indem sie nur die vorhandenen Parquet-Dateien neu organisierten (ohne ein neues Format zu erfinden), machten sie den Roboter in Bezug auf die Datenlesegeschwindigkeit 125-mal schneller.

Sie zeigten auch, dass der Roboter noch effizienter wird, wenn er im Takt mit dem Lieferwagen arbeitet (überlappendes Lesen und Verarbeiten). Tatsächlich war dieser neu organisierte Roboter so schnell, dass er fast die theoretische Geschwindigkeitsgrenze des Lieferwagens selbst erreichte.

Das Fazit

Die Arbeit kommt zu dem Schluss, dass wir die Bibliothek nicht niederbrennen und von Grund auf neu bauen müssen. Wir müssen nur die Bücher mit ein paar intelligenten Anpassungen neu ins Regal stellen.

Indem man anpasst, wie die Daten gepackt und gruppiert werden, kann das bestehende Parquet-Format bereits auf modernen GPUs mit Blitzgeschwindigkeit laufen. Das erspart allen die Mühe, ein neues System zu erlernen, und hält alle alten Softwarekomponenten kompatibel, während gleichzeitig der massive Geschwindigkeitsvorteil erzielt wird, den wir wollten.

Technische Zusammenfassung

Technische Zusammenfassung: Benötigen GPUs wirklich neue tabellarische Dateiformate?

Problemstellung

Apache Parquet ist das de-facto spaltenorientierte Dateiformat in modernen analytischen Systemen, doch seine Standardkonfigurationsrichtlinien werden von CPU-zentrierten Ausführungsmotiven geprägt. Da GPU-beschleunigte Datenverarbeitung zunehmend verbreitet ist, führen Parquet-Dateien, die für CPUs optimiert sind, häufig zu einer starken Unterauslastung der GPU-Hardware und erzeugen einen künstlichen Leistungsengpass. Trotz umfangreicher Tests auf der CPU-Seite bleibt das Lesen von Parquet-Dateien ein wesentlicher Engpass in der GPU-beschleunigten Analytik; so berichtet das NVIDIA RAPIDS-Team, dass etwa 85 % der Laufzeit des TPC-H-Benchmarks auf Parquet-Scans entfallen und nicht auf Abfrageoperatoren. Dies wirft die zentrale Forschungsfrage auf: Benötigen GPUs wirklich neue tabellarische Dateiformate, oder können bestehende Parquet-Konfigurationen optimiert werden, um hohe Leistung zu erzielen?

Methodik

Die Autoren führten eine systematische Studie durch, um zu bewerten, wie sich Parquet-Konfigurationsentscheidungen auf die GPU-Scan-Leistung auswirken. Das experimentelle Setup verwendete eine einzelne NVIDIA A100-GPU, die die größte TPC-H SF300-Tabelle (lineitem) von lokalen NVMe-SSDs über GPUDirect Storage (GDS) einlas. Die Studie setzte PystachIO ein, ein GPU-beschleunigtes analytisches System, das I/O und GPU-Berechnung vollständig überlappt und auf der NVIDIA RAPIDS cuDF-Bibliothek aufbaut.

Die Methodik umfasste:

1. Etablierung einer Baseline: Erzeugung von Parquet-Dateien mit den Standardeinstellungen von DuckDB (eine Seite pro Spaltendatenblock, 122.880 Zeilen pro Zeilengruppe (RG), Parquet-V1-Kodierungen und Standardkomprimierung).
2. Konfigurationsiteration: Systematische Änderung von Dateiparametern zur Prüfung vier spezifischer Dimensionen:
   • Seitenanzahl: Erhöhung der Anzahl der Seiten pro RG, um den Grid-Größen von GPU-Kernen zu entsprechen.
   • Zeilengröße (RG-Größe): Erhöhung der Anzahl der Zeilen pro RG, um größere I/O-Einheiten zu schaffen, die für GDS geeignet sind.
   • Kodierungsflexibilität: Ermöglichung der pro-Block-Auswahl optimaler Kodierungen aus sowohl Parquet-V1- als auch V2-Schemata.
   • Selektive Komprimierung: Überspringen der Komprimierung für Spaltendatenblöcke, bei denen die Größenreduktion einen bestimmten Schwellenwert (10 %) nicht überschreitet.
3. Entwicklung eines Tools: Die Autoren entwickelten ein Parquet-Rewriter-Tool (in Rust geschrieben), um bestehende Parquet-Dateien in diese optimierten Konfigurationen zu transformieren, ohne die Dateiformatspezifikation zu ändern.
4. Leistungsmetriken: Die Bewertung konzentrierte sich auf die effektive Lesebandbreite (logische Rohdatengröße dividiert durch Scan-Laufzeit) und die End-to-End-Abfragelaufzeit für TPC-H-Abfragen (Q6 und Q12) über verschiedene Datenskalen (bis SF1000).

Hauptbeiträge und Erkenntnisse

Die Arbeit präsentiert vier zentrale Erkenntnisse, die aus den experimentellen Ergebnissen abgeleitet wurden:

1. Optimierung der Seitenanzahl: GPU-Decoding-Kerne parallelisieren über Seiten hinweg. Standardkonfigurationen führen häufig zu zu wenigen Seiten, wodurch die GPU unterausgelastet bleibt. Eine Erhöhung der Seitenanzahl auf 100 oder mehr verbessert die Decodiereffizienz und die Speicherbus-Bandbreite erheblich.
2. Optimierung der RG-Größe: Der GPU-I/O-Stack (GDS) verhält sich anders als CPU-Stacks und bevorzugt größere I/O-Einheiten (im MB-Bereich), um die Speicherbandbreite voll auszulasten. Standard-RG-Größen (die zu Blöcken von ca. 100 KB führen) sind suboptimal. Eine Erhöhung der RG-Größen auf Millionen von Zeilen (z. B. 10 Millionen Zeilen) ermöglicht es GDS, SSDs voll auszulasten.
3. Kodierungsflexibilität: Die Beschränkung auf Parquet-V1-Kodierungen limitiert die Komprimierungseffizienz. Die Auswahl der kleinsten kodierten Größe aus sowohl V1- als auch V2-Schemata (z. B. die Nutzung von Delta Binary Packed für Integer-Werte) verbessert die Komprimierungsraten. Dies reduziert den I/O-Engpass und nutzt effiziente V2-Decodierung auf GPUs.
4. Vermeidung unnötiger Komprimierung: Blindes Anwenden von Komprimierung fügt Dekompressions-Overhead hinzu. Die Studie zeigt, dass das Überspringen der Komprimierung, wenn die Größenreduktion unter einem Schwellenwert von 10 % liegt, die Leistung verbessert, insbesondere in Szenarien, in denen die GPU rechenlimitiert ist (z. B. beim Lesen von mehreren SSDs).

Ergebnisse

Durch die Anwendung dieser GPU-bewussten Konfigurationen auf vollständig konforme Parquet-Dateien erzielten die Autoren folgende Ergebnisse:

• Effektive Bandbreite: Die optimierte Konfiguration erreichte eine effektive Lesebandbreite von bis zu 125 GB/s unter Verwendung von 4 SSDs, eine dramatische Verbesserung gegenüber der Baseline.
• Skalierbarkeit: Die effektive Bandbreite skalierte linear mit der Anzahl der SSDs, wenn Kodierungsflexibilität angewendet wurde, wohingegen Baseline-Konfigurationen frühzeitig sättigten.
• Abfrageleistung: Bei TPC-H-Abfragen (Q6 und Q12) übertraf das GPU-System mit optimierten Parquet-Dateien CPU-Systeme (ClickHouse und DuckDB) erheblich und blieb nahe am theoretischen Minimum der Laufzeit (definiert durch die SSD-Bandbreite).
• Kein neues Format erforderlich: Die Studie zeigt, dass hohe GPU-Leistung erreicht werden kann, ohne zu einem neuen Dateiformat zu wechseln, wodurch die Interoperabilitätsvorteile des Parquet-Ökosystems erhalten bleiben.

Bedeutung und Behauptungen

Die Arbeit argumentiert, dass neue Dateiformate für hochleistungsfähige GPU-Analytik nicht zwingend erforderlich sind. Stattdessen ist die Leistungslücke weitgehend eine Folge suboptimaler Konfigurationsentscheidungen, die von CPU-zentrierten Standards übernommen wurden.

• Praktische Anleitung: Die Arbeit bietet die erste praktische Anleitung zur Optimierung von Parquet für GPU-Datenbanken und ermöglicht eine erhebliche Beschleunigung durch Konfiguration statt durch Formatersetz.
• Baseline für zukünftige Arbeiten: Die Autoren etablieren eine starke Baseline für zukünftige GPU-Dateiformate. Sie behaupten, dass jedes vorgeschlagene neue Format diese optimierten Parquet-Konfigurationen (die ~125 GB/s erreichen) übertreffen muss, anstatt sich lediglich auf unoptimierte Standards zu verbessern.
• Erhaltung des Ökosystems: Durch die Aufrechterhaltung der Kompatibilität mit der bestehenden Parquet-Spezifikation und dem Ökosystem vermeidet der vorgeschlagene Ansatz die Kosten, die mit der Migration zu proprietären oder neuen Format verbunden sind.
• Hardware-Unabhängigkeit: Obwohl der Fokus auf GPUs liegt, ist das Rewriter-Tool nicht hardware-spezifisch; es wendet Konfigurationen basierend auf den Eigenschaften der Zielhardware an, was darauf hindeutet, dass häufige Abfragen auf jeder Hardware von einer solchen Umwandlung profitieren könnten.

Die Autoren schließen, dass zwar neue Formate existieren, die eine Decodierung im GPU-Innerspeicher anvisieren, der dominante Engpass in realen Szenarien jedoch nach wie vor das Speicher-I/O ist. Daher ist die Optimierung des bestehenden Parquet-Formats zur Maximierung des Speicher-Durchsatzes und zur Minimierung des Dekompressions-Overheads ein kritischer, unmittelbarer Schritt, bevor entirely neue Dateiformat-Designs in Betracht gezogen werden.