Do GPUs Really Need New Tabular File Formats?

Questo documento dimostra che i colli di bottiglia nelle prestazioni di scansione GPU nei file Parquet derivano da configurazioni subottimali incentrate sulla CPU piuttosto che dal formato stesso, e mostra che l'applicazione di impostazioni consapevoli della GPU può aumentare la banda di lettura effettiva fino a 125 GB/s senza modificare la specifica Parquet.

L'essenziale

Immagina di avere una biblioteca immensa di libri (i tuoi dati) immagazzinata in un magazzino (il tuo hard disk). Hai anche un bibliotecario robot super-veloce (la tua GPU) il cui compito è leggere questi libri e rispondere alle domande.

Per anni, la biblioteca è stata organizzata utilizzando un sistema di archiviazione specifico chiamato Parquet. Questo sistema è stato progettato pensando a un bibliotecario umano: raggruppa i libri in piccole pile gestibili che un umano può facilmente prendere una per una.

Tuttavia, il bibliotecario robot è diverso. Non prende semplicemente una pila alla volta; ha migliaia di mani e può afferrare dozzine di pile simultaneamente. Ma poiché la biblioteca è ancora organizzata per gli umani, il robot passa la maggior parte del tempo ad aspettare la prossima pila da consegnargli, oppure sta usando solo una minuscola frazione delle sue mani. Il robot è incredibilmente veloce, ma l'organizzazione della biblioteca lo sta frenando.

Il documento pone una domanda semplice: Dobbiamo inventare un sistema di archiviazione completamente nuovo solo per i robot?

Gli autori dicono: No. Invece, dobbiamo solo riorganizzare i libri esistenti utilizzando alcune regole semplici.

Ecco come hanno risolto il problema, utilizzando quattro principali "regole della strada":

1. La Regola "Più Pile" (Aumentare il Numero di Pagine)

• Il Problema: Il vecchio sistema metteva tutti i dati di una sezione in un unico libro gigante e pesante. Il robot tentava di leggerlo, ma poteva usare solo una mano alla volta perché il libro era troppo grande per essere diviso.
• La Soluzione: Hanno spezzato quei libri giganti in molte pagine più piccole e sottili. Ora, il robot può afferrare 100 pagine alla volta con le sue 100 mani.
• Il Risultato: Il robot non è più in attesa; è impegnato a usare tutte le sue mani contemporaneamente.

2. La Regola "Scatole Grandi" (Aumentare la Dimensione del Gruppo di Righe)

• Il Problema: Il vecchio sistema inviava al robot pacchetti minuscoli, grandi come francobolli. Anche se il robot è veloce, il camion delle consegne (la connessione tra l'unità disco e il robot) si intasa con troppi pacchetti minuscoli.
• La Soluzione: Hanno iniziato a spedire enormi scatole da trasloco di dimensioni normali invece di francobolli.
• Il Risultato: Il camion delle consegne può ora viaggiare a piena velocità, mantenendo il robot costantemente rifornito di dati.

3. La Regola "Imballaggio Intelligente" (Flessibilità di Codifica)

• Il Problema: Il vecchio sistema imballava i libri utilizzando un metodo generico, "taglia unica". A volte questo rendeva i libri più piccoli, ma spesso non aiutava molto.
• La Soluzione: Hanno esaminato ogni libro individualmente e scelto il modo migliore per ridurlo. Se un libro aveva molte parole ripetute, hanno usato un codice speciale per renderlo minuscolo. Se un libro era già corto, lo hanno lasciato così com'era.
• Il Risultato: I libri occupano meno spazio sugli scaffali, quindi il camion delle consegne ha meno peso da trasportare, rendendo l'intero processo più veloce.

4. La Regola "Non Avvolgerlo" (Nessuna Compressione Inutile)

• Il Problema: A volte, il vecchio sistema avvolgeva i libri in pesante plastica a bolle (compressione) anche quando i libri erano già piccoli. Il robot doveva quindi spendere tempo per srotolarli, il che spreca energia.
• La Soluzione: Hanno deciso: "Se la plastica a bolle non rende il pacchetto significativamente più piccolo, non usarla".
• Il Risultato: Il robot risparmia tempo saltando il passaggio di srotolamento per i libri che non ne avevano bisogno.

Il Gran Finale: Il Robot contro l'Umano

Gli autori hanno testato questa nuova organizzazione.

• Il Vecchio Modo: Il robot era lento, usando a malapena i suoi superpoteri.
• Il Nuovo Modo: Riorganizzando semplicemente i file Parquet esistenti (senza inventare un nuovo formato), hanno reso il robot 125 volte più veloce in termini di velocità di lettura dei dati.

Hanno anche dimostrato che quando il robot lavora in sincronia con il camion delle consegne (sovrapponendo lettura ed elaborazione), diventa ancora più efficiente. In effetti, questo robot riorganizzato era così veloce da avvicinarsi quasi al limite teorico di velocità del camion delle consegne stesso.

La Conclusione

Il documento conclude che non dobbiamo bruciare la biblioteca e costruirne una nuova da zero. Dobbiamo solo riposizionare i libri con alcuni aggiustamenti intelligenti.

Modificando il modo in cui i dati sono imballati e raggruppati, il formato Parquet esistente può già funzionare a velocità fulminea sulle moderne GPU. Questo risparmia a tutti la fatica di imparare un nuovo sistema e mantiene compatibile tutto il software esistente, ottenendo comunque l'enorme aumento di velocità che volevamo.

Sommario tecnico

Riepilogo Tecnico: Le GPU Hanno Davvero Bisogno di Nuovi Formati di File Tabellari?

Enunciato del Problema

Apache Parquet è il formato di file colonnare de facto nei sistemi analitici moderni, eppure le sue linee guida di configurazione predefinite sono plasmate da motori di esecuzione centrati sulla CPU. Con la crescente diffusione dell'elaborazione dati accelerata da GPU, i file Parquet ottimizzati per le CPU spesso sottoutilizzano gravemente l'hardware GPU, creando un collo di bottiglia delle prestazioni artificiale. Nonostante estesi test lato CPU, la lettura di Parquet rimane un collo di bottiglia maggiore nell'analisi accelerata da GPU; ad esempio, il team NVIDIA RAPIDS riporta che circa l'85% del tempo di esecuzione del benchmark TPC-H è dedicato alle scansioni Parquet piuttosto che agli operatori di query. Questo solleva la domanda di ricerca centrale: le GPU richiedono davvero nuovi formati di file tabellari, o le configurazioni Parquet esistenti possono essere ottimizzate per ottenere elevate prestazioni?

Metodologia

Gli autori hanno condotto uno studio sistematico per valutare come le scelte di configurazione di Parquet influenzino le prestazioni di scansione GPU. La configurazione sperimentale ha utilizzato una singola GPU NVIDIA A100 che leggeva la più grande tabella TPC-H SF300 (lineitem) da SSD NVMe locali tramite GPUDirect Storage (GDS). Lo studio ha impiegato PystachIO, un sistema analitico accelerato da GPU che sovrappone completamente I/O e calcolo GPU, costruito sulla libreria NVIDIA RAPIDS cuDF.

La metodologia ha coinvolto:

1. Stabilimento della Baseline: Generazione di file Parquet utilizzando le impostazioni predefinite di DuckDB (una pagina per chunk di colonna, 122.880 righe per Row Group (RG), codifiche Parquet V1 e compressione standard).
2. Iterazione della Configurazione: Modifica sistematica dei parametri dei file per testare quattro dimensioni specifiche:
   • Numero di Pagine: Aumento del numero di pagine per RG per corrispondere alle dimensioni della griglia del kernel GPU.
   • Dimensione del Row Group (RG): Aumento del numero di righe per RG per creare unità I/O più grandi adatte a GDS.
   • Flessibilità di Codifica: Consentire la selezione per chunk delle codifiche ottimali sia dagli schemi Parquet V1 che V2.
   • Selettività della Compressione: Saltare la compressione per i chunk di colonna in cui la riduzione delle dimensioni non supera una soglia specifica (10%).
3. Sviluppo di Strumenti: Gli autori hanno sviluppato uno strumento di riscrittura Parquet (scritto in Rust) per trasformare i file Parquet esistenti in queste configurazioni ottimizzate senza alterare la specifica del formato di file.
4. Metriche delle Prestazioni: La valutazione si è concentrata sulla larghezza di banda di lettura effettiva (dimensione dei dati grezzi logici divisa per il tempo di esecuzione della scansione) e sul tempo di esecuzione delle query end-to-end per le query TPC-H (Q6 e Q12) su diverse scale di dataset (fino a SF1000).

Contributi e Insight Chiave

Il documento presenta quattro insight principali derivati dai risultati sperimentali:

1. Ottimizzazione del Numero di Pagine: I kernel di decodifica GPU si parallelizzano attraverso le pagine. Le configurazioni predefinite spesso risultano in un numero di pagine troppo basso, lasciando la GPU sottoutilizzata. Aumentare il numero di pagine a 100 o più migliora significativamente l'efficienza di decodifica e la larghezza di banda del bus di archiviazione.
2. Ottimizzazione della Dimensione RG: Lo stack I/O GPU (GDS) si comporta diversamente dagli stack CPU, preferendo unità I/O più grandi (scala MiB) per saturare la larghezza di banda di archiviazione. Le dimensioni RG predefinite (che risultano in chunk di ~100 KB) sono subottimali. Aumentare le dimensioni RG a milioni di righe (ad esempio, 10M righe) permette a GDS di saturare gli SSD.
3. Flessibilità di Codifica: Limitare le codifiche a Parquet V1 riduce l'efficienza della compressione. Consentire la selezione della dimensione codificata più piccola sia dagli schemi V1 che V2 (ad esempio, utilizzando Delta Binary Packed per gli interi) migliora i rapporti di compressione. Questo riduce il collo di bottiglia I/O e sfrutta la decodifica V2 efficiente sulle GPU.
4. Evitare Compressioni Inutili: Applicare ciecamente la compressione aggiunge un sovraccarico di decompressione. Lo studio mostra che saltare la compressione quando la riduzione delle dimensioni è inferiore a una soglia del 10% migliora le prestazioni, in particolare negli scenari in cui la GPU è limitata dal calcolo (ad esempio, quando si legge da più SSD).

Risultati

Applicando queste configurazioni consapevoli delle GPU a file Parquet pienamente conformi, gli autori hanno ottenuto i seguenti risultati:

• Larghezza di Banda Effettiva: La configurazione ottimizzata ha raggiunto fino a 125 GB/s di larghezza di banda di lettura effettiva utilizzando 4 SSD, un miglioramento drammatico rispetto alla baseline.
• Scalabilità: La larghezza di banda effettiva è aumentata linearmente con il numero di SSD quando è stata applicata la flessibilità di codifica, mentre le configurazioni baseline si saturavano precocemente.
• Prestazioni delle Query: Sulle query TPC-H (Q6 e Q12), il sistema GPU che utilizza file Parquet ottimizzati ha superato significativamente i sistemi CPU (ClickHouse e DuckDB) ed è rimasto vicino al tempo di esecuzione minimo teorico (definito dalla larghezza di banda degli SSD).
• Nessun Nuovo Formato Richiesto: Lo studio dimostra che elevate prestazioni GPU possono essere ottenute senza passare a un nuovo formato di file, preservando i benefici di interoperabilità dell'ecosistema Parquet.

Significato e Affermazioni

Il documento sostiene che nuovi formati di file non sono strettamente necessari per l'analisi GPU ad alte prestazioni. Invece, il divario di prestazioni è in gran parte una conseguenza di scelte di configurazione subottimali ereditate da default centrati sulla CPU.

• Guida Pratica: Il lavoro fornisce la prima guida pratica sull'ottimizzazione di Parquet per database GPU, consentendo un'accelerazione sostanziale attraverso la configurazione piuttosto che la sostituzione del formato.
• Baseline per Lavori Futuri: Gli autori stabiliscono una solida baseline per i futuri formati di file GPU. Affermano che qualsiasi nuovo formato proposto deve superare queste configurazioni Parquet ottimizzate (che raggiungono ~125 GB/s) piuttosto che migliorare semplicemente rispetto ai default non ottimizzati.
• Preservazione dell'Ecosistema: Mantenendo la compatibilità con la specifica e l'ecosistema Parquet esistenti, l'approccio proposto evita i costi associati alla migrazione a formati proprietari o nuovi.
• Agnosticismo Hardware: Sebbene focalizzato sulle GPU, lo strumento di riscrittura non è specifico per l'hardware; applica configurazioni in base alle caratteristiche dell'hardware di destinazione, suggerendo che query frequenti su qualsiasi hardware potrebbero beneficiare di tale riscrittura.

Gli autori concludono che, sebbene esistano nuovi formati mirati alla decodifica in memoria GPU, il collo di bottiglia dominante negli scenari reali rimane l'I/O di archiviazione. Pertanto, ottimizzare il formato Parquet esistente per massimizzare il throughput di archiviazione e minimizzare il sovraccarico di decompressione è un passo critico e immediato prima di considerare design di formati di file completamente nuovi.