Do GPUs Really Need New Tabular File Formats?

Ce papier démontre que les goulots d'étranglement de performance des scans GPU dans les fichiers Parquet proviennent de configurations sous-optimales centrées sur le CPU plutôt que du format lui-même, et montre que l'application de paramètres adaptés aux GPU peut augmenter la bande passante de lecture effective jusqu'à 125 Go/s sans modifier la spécification Parquet.

L'essentiel

Imaginez que vous possédiez une immense bibliothèque de livres (vos données) stockée dans un entrepôt (votre disque dur). Vous disposez également d'un bibliothécaire robot ultra-rapide (votre GPU) dont la tâche consiste à lire ces livres et à répondre à des questions.

Pendant des années, la bibliothèque a été organisée selon un système de classement spécifique appelé Parquet. Ce système a été conçu en pensant à un bibliothécaire humain : il regroupe les livres en petites piles gérables qu'un humain peut facilement saisir une par une.

Cependant, le bibliothécaire robot est différent. Il ne se contente pas de saisir une pile à la fois ; il possède des milliers de mains et peut saisir des dizaines de piles simultanément. Mais comme la bibliothèque est toujours organisée pour les humains, le robot passe la majeure partie de son temps à attendre la prochaine pile qui lui est remise, ou il n'utilise qu'une infime fraction de ses mains. Le robot est incroyablement rapide, mais l'organisation de la bibliothèque le freine.

L'article pose une question simple : Avons-nous besoin d'inventer un tout nouveau système de classement uniquement pour les robots ?

Les auteurs répondent : Non. Il suffit simplement de réorganiser les livres existants en suivant quelques règles simples.

Voici comment ils ont résolu le problème, en utilisant quatre « règles de la route » principales :

1. La règle « Plus de piles » (Augmenter le nombre de pages)

• Le problème : L'ancien système regroupait toutes les données d'une section dans un seul livre géant et lourd. Le robot tentait de le lire, mais il ne pouvait utiliser qu'une seule main à la fois car le livre était trop volumineux pour être divisé.
• La solution : Ils ont découpé ces livres géants en de nombreuses pages plus petites et plus fines. Désormais, le robot peut saisir 100 pages à la fois avec ses 100 mains.
• Le résultat : Le robot n'attend plus ; il est occupé à utiliser toutes ses mains simultanément.

2. La règle « Grands cartons » (Augmenter la taille des groupes de lignes)

• Le problème : L'ancien système envoyait au robot des colis minuscules, de la taille d'un timbre-poste. Même si le robot est rapide, le camion de livraison (la connexion entre le disque dur et le robot) se retrouve encombré par trop de petits colis.
• La solution : Ils ont commencé à envoyer d'énormes cartons de déménagement complets au lieu de timbres-poste.
• Le résultat : Le camion de livraison peut désormais rouler à pleine vitesse, alimentant constamment le robot en données.

3. La règle « Emballage intelligent » (Flexibilité de l'encodage)

• Le problème : L'ancien système emballait les livres selon une méthode générique, unique pour tous. Parfois, cela réduisait la taille des livres, mais souvent, cela n'apportait pas grand-chose.
• La solution : Ils ont examiné chaque livre individuellement et choisi la meilleure façon de le réduire. Si un livre contenait beaucoup de mots répétés, ils utilisaient un code spécial pour le rendre minuscule. Si un livre était déjà court, ils le laissaient tel quel.
• Le résultat : Les livres occupent moins d'espace sur l'étagère, le camion de livraison a donc moins de poids à transporter, ce qui accélère l'ensemble du processus.

4. La règle « Ne l'emballer pas » (Pas de compression inutile)

• Le problème : Parfois, l'ancien système enveloppait les livres dans du papier bulle lourd (compression) même lorsque les livres étaient déjà petits. Le robot devait alors perdre du temps à les déballer, ce qui gaspillait de l'énergie.
• La solution : Ils ont décidé : « Si le papier bulle ne rend pas le colis significativement plus petit, ne l'utilisez pas. »
• Le résultat : Le robot gagne du temps en sautant l'étape du déballage pour les livres qui n'en avaient pas besoin.

Le grand final : Le robot contre l'humain

Les auteurs ont testé cette nouvelle organisation.

• L'ancienne méthode : Le robot était lent, utilisant à peine ses superpouvoirs.
• La nouvelle méthode : En réorganisant simplement les fichiers Parquet existants (sans inventer un nouveau format), ils ont rendu le robot 125 fois plus rapide en termes de vitesse de lecture des données.

Ils ont également démontré que lorsque le robot travaille en synchronisation avec le camion de livraison (en chevauchant la lecture et le traitement), il devient encore plus efficace. En fait, ce robot réorganisé était si rapide qu'il a presque atteint la limite de vitesse théorique du camion de livraison lui-même.

La conclusion

L'article conclut que nous n'avons pas besoin de brûler la bibliothèque pour en reconstruire une nouvelle à partir de zéro. Nous devons simplement reclasser les livres avec quelques ajustements intelligents.

En ajustant la façon dont les données sont emballées et regroupées, le format Parquet existant peut déjà fonctionner à la vitesse de l'éclair sur les GPU modernes. Cela évite à tous d'avoir à apprendre un nouveau système et maintient la compatibilité avec tous les anciens logiciels, tout en offrant l'énorme boost de vitesse que nous souhaitions.

Résumé technique

Résumé technique : Les GPU ont-ils vraiment besoin de nouveaux formats de fichiers tabulaires ?

Énoncé du problème

Apache Parquet est le format de fichier en colonnes de facto dans les systèmes analytiques modernes, pourtant ses lignes directrices de configuration par défaut sont façonnées par des moteurs d'exécution centrés sur le CPU. À mesure que le traitement de données accéléré par GPU devient prédominant, les fichiers Parquet optimisés pour les CPU sous-utilisent souvent sévèrement le matériel GPU, créant un goulot d'étranglement de performance artificiel. Malgré des tests étendus côté CPU, la lecture de Parquet reste un goulot d'étranglement majeur dans l'analyse accélérée par GPU ; par exemple, l'équipe NVIDIA RAPIDS rapporte qu'environ 85 % du temps d'exécution du benchmark TPC-H est consacré aux scans Parquet plutôt qu'aux opérateurs de requête. Cela soulève la question de recherche centrale : Les GPU ont-ils vraiment besoin de nouveaux formats de fichiers tabulaires, ou les configurations Parquet existantes peuvent-elles être optimisées pour atteindre des performances élevées ?

Méthodologie

Les auteurs ont mené une étude systématique pour évaluer comment les choix de configuration de Parquet affectent les performances de scan GPU. La configuration expérimentale utilisait un seul GPU NVIDIA A100 lisant la plus grande table TPC-H SF300 (lineitem) depuis des SSD NVMe locaux via GPUDirect Storage (GDS). L'étude a employé PystachIO, un système analytique accéléré par GPU qui chevauche entièrement les E/S et le calcul GPU, construit sur la bibliothèque NVIDIA RAPIDS cuDF.

La méthodologie comprenait :

1. Établissement de la référence : Génération de fichiers Parquet utilisant les paramètres par défaut de DuckDB (une seule page par chunk de colonne, 122 880 lignes par groupe de lignes (RG), encodages Parquet V1 et compression standard).
2. Itération de configuration : Modification systématique des paramètres de fichier pour tester quatre dimensions spécifiques :
   • Nombre de pages : Augmentation du nombre de pages par RG pour correspondre aux tailles de grilles de noyaux GPU.
   • Taille du groupe de lignes (RG) : Augmentation du nombre de lignes par RG pour créer des unités d'E/S plus grandes adaptées au GDS.
   • Flexibilité d'encodage : Autorisation de la sélection par chunk des encodages optimaux parmi les schémas Parquet V1 et V2.
   • Sélectivité de compression : Saut de la compression pour les chunks de colonne où la réduction de taille ne dépasse pas un seuil spécifique (10 %).
3. Développement d'outils : Les auteurs ont développé un outil de réécriture Parquet (écrit en Rust) pour transformer les fichiers Parquet existants en ces configurations optimisées sans altérer la spécification du format de fichier.
4. Métriques de performance : L'évaluation s'est concentrée sur la bande passante de lecture effective (taille brute logique des données divisée par le temps d'exécution du scan) et le temps d'exécution de bout en bout des requêtes TPC-H (Q6 et Q12) à travers différentes échelles de jeu de données (jusqu'à SF1000).

Contributions et insights clés

L'article présente quatre insights principaux dérivés des résultats expérimentaux :

1. Optimisation du nombre de pages : Les noyaux de décodage GPU se parallélisent sur les pages. Les configurations par défaut entraînent souvent trop peu de pages, laissant le GPU sous-utilisé. L'augmentation du nombre de pages à 100 ou plus améliore considérablement l'efficacité du décodage et la bande passante du bus de stockage.
2. Optimisation de la taille du RG : La pile d'E/S GPU (GDS) se comporte différemment des piles CPU, préférant de grandes unités d'E/S (échelle de MiB) pour saturer la bande passante de stockage. Les tailles de RG par défaut (résultant en des chunks d'environ 100 Ko) sont sous-optimales. L'augmentation des tailles de RG à des millions de lignes (par exemple 10 M de lignes) permet au GDS de saturer les SSD.
3. Flexibilité d'encodage : Restreindre les encodages à Parquet V1 limite l'efficacité de la compression. Permettre la sélection de la taille encodée la plus petite parmi les schémas V1 et V2 (par exemple, utiliser Delta Binary Packed pour les entiers) améliore les ratios de compression. Cela réduit le goulot d'étranglement des E/S et exploite un décodage V2 efficace sur les GPU.
4. Éviter la compression inutile : Appliquer aveuglément la compression ajoute une surcharge de décompression. L'étude montre que sauter la compression lorsque la réduction de taille est inférieure à un seuil de 10 % améliore les performances, en particulier dans les scénarios où le GPU est limité par le calcul (par exemple, lors de la lecture depuis plusieurs SSD).

Résultats

En appliquant ces configurations conscientes du GPU à des fichiers Parquet entièrement conformes, les auteurs ont obtenu les résultats suivants :

• Bande passante effective : La configuration optimisée a atteint jusqu'à 125 Go/s de bande passante de lecture effective utilisant 4 SSD, une amélioration spectaculaire par rapport à la référence.
• Évolutivité : La bande passante effective a évolué linéairement avec le nombre de SSD lorsque la flexibilité d'encodage était appliquée, tandis que les configurations de référence saturées précocement.
• Performance des requêtes : Sur les requêtes TPC-H (Q6 et Q12), le système GPU utilisant des fichiers Parquet optimisés a considérablement surpassé les systèmes CPU (ClickHouse et DuckDB) et est resté proche du temps d'exécution minimum théorique (défini par la bande passante SSD).
• Aucun nouveau format requis : L'étude démontre que des performances GPU élevées peuvent être atteintes sans passer à un nouveau format de fichier, préservant ainsi les avantages d'interopérabilité de l'écosystème Parquet.

Importance et revendications

L'article soutient que de nouveaux formats de fichiers ne sont pas strictement nécessaires pour l'analyse GPU haute performance. Au contraire, l'écart de performance est largement une conséquence de choix de configuration sous-optimaux hérités des paramètres par défaut centrés sur le CPU.

• Conseils pratiques : Ce travail fournit les premiers conseils pratiques sur l'optimisation de Parquet pour les bases de données GPU, permettant une accélération substantielle par la configuration plutôt que par le remplacement du format.
• Référence pour les travaux futurs : Les auteurs établissent une référence solide pour les futurs formats de fichiers GPU. Ils affirment que tout nouveau format proposé doit surpasser ces configurations Parquet optimisées (qui atteignent ~125 Go/s) plutôt que de simplement s'améliorer par rapport aux paramètres par défaut non optimisés.
• Préservation de l'écosystème : En maintenant la compatibilité avec la spécification et l'écosystème Parquet existants, l'approche proposée évite les coûts associés à la migration vers des formats propriétaires ou nouveaux.
• Agnosticisme matériel : Bien que centré sur les GPU, l'outil de réécriture n'est pas spécifique au matériel ; il applique des configurations basées sur les caractéristiques du matériel cible, suggérant que des requêtes fréquentes sur n'importe quel matériel pourraient bénéficier d'une telle réécriture.

Les auteurs concluent que, bien que de nouveaux formats ciblant le décodage en mémoire GPU existent, le goulot d'étranglement dominant dans les scénarios réels reste les E/S de stockage. Par conséquent, optimiser le format Parquet existant pour maximiser le débit de stockage et minimiser la surcharge de décompression est une étape critique et immédiate avant d'envisager des conceptions de formats de fichiers entièrement nouveaux.