CPU ou GPU ? Velox et cuDF accélèrent le SQL Presto jusqu'à 4×

On part d'un goulot bien connu : Presto est né comme moteur SQL distribué pour big data sur CPU, et le temps de requête gonfle avec le volume. Dans la vidéo, Roy et William (NVIDIA) montrent comment briser ce plafond avec le GPU. Le travail vient d'IBM, NVIDIA et la communauté Presto ; l'objectif est d'ajouter un moteur accéléré par GPU au-dessus d'un entrepôt existant sans déplacer les données. La promesse est simple : au lieu du Presto en Java, faire tourner Presto avec Velox — une couche d'exécution en C++ — pour disperser le même SQL sur du matériel parallèle. Comme élargir une route à une voie à huit voies — même voiture, plus de voies.

Un bref rappel sur Presto et Velox aide. Né chez Facebook en 2012, Presto est un moteur SQL distribué open source qui sépare stockage et calcul, avec un coordinator et des workers qui scalent. En 2019 la communauté s'est scindée en PrestoDB et Trino ; PrestoDB vit aujourd'hui sous prestodb/presto et la Presto Foundation, hébergée par la Linux Foundation. Le Presto classique tourne en Java. Velox, construit par Meta, est une bibliothèque d'exécution C++ vectorisée et colonnaire — le cœur de Presto C++ / Presto Native. Elle supprime l'overhead JVM et exécute le même plan en vecteurs près du matériel. Couplée à cuDF, ce plan se répartit sur les cœurs GPU. Analogie : remplacer un orchestre Java par une petite équipe C++ qui monte directement sur scène.

La magie GPU vient de NVIDIA cuDF et de son extension cuDF-X. Membre de RAPIDS (désormais NVIDIA CUDA-X), cuDF est une bibliothèque DataFrame GPU — adossée à libcudf et pylibcudf — qui parallélise joins, agrégations, filtres et tris sur des milliers de cœurs CUDA. La vidéo le reflète : prendre un data frame, joindre, agréger, calculer — tout accéléré sur GPU. Le goulot est le transfert des données vers la mémoire GPU (VRAM). Le point de William est clé : pousser une requête de 100 lignes vers le GPU n'a pas de sens, le coût de transfert efface le gain. Mais sur 179 millions de lignes groupées et triées en masse, le parallélisme l'emporte. Les tests GB200 NVL72 et DGX B200 de 2026 confirment la même idée — si les données passent entre opérateurs sans quitter la mémoire GPU via NVLink, la latence chute.

La mise en place pratique tient en trois notebooks, tous dans le dépôt Prestorials de la Presto Foundation. Le premier monte un cluster Presto Native avec Docker Compose. Étapes nettes : créer les répertoires metastore et warehouse sur l'hôte, écrire les fichiers de config Presto, puis lancer coordinator et worker via docker compose. Une cellule de vérification montre les deux composants Running — un coordinator CPU et un worker CPU. Puis quelques requêtes simples confirment la santé du cluster. C'est un labo Presto minimal qui opère sur les données de l'hôte au lieu de construire un entrepôt de zéro — un terrain de jeu en une commande que les équipes infra adorent.

Le deuxième notebook ajoute la volumétrie. Le jeu de données est celui synthétique d'IBM pour la lutte anti-blanchiment (AML). On le trouve sur Kaggle sous "IBM Transactions for Anti Money Laundering" et aussi sur Hugging Face ; le nombre de lignes varie selon l'échelle, environ 176 millions à grande échelle. Il imite des transactions financières — virements, achats, paiements carte — et sert largement en recherche GNN et fondation models. Le notebook le charge dans le warehouse et vérifie encore que le cluster répond avec des requêtes simples. Cette étape fixe le volume réaliste du benchmark ; synthétique mais proche du prod en forme et en échelle pour une charge analytique.

Le troisième notebook apporte la nouveauté : copier l'entrepôt existant et ajouter le moteur GPU par-dessus. On voit dans l'Explorer la config et les métadonnées dupliquées à l'identique, puis quelques propriétés GPU ajoutées avant de démarrer le cluster GPU. Le démarrage semble rapide, mais la première vérification affiche encore Starting ; le second essai passe à Running. Puis un smoke test : select star limit 1. William note que la première requête prend environ une seconde car elle charge les binaires en VRAM — ce warm-up est attendu. Puis un choix de conception assumé : le côté GPU est en lecture seule. L'idée est d'éviter que deux écrivains ne corrompent les mêmes fichiers pendant que rapports et jobs tournent encore sur le cluster CPU ; le moteur GPU ne fait que lire. Si vous ne comptez faire tourner que le moteur GPU, vous pouvez lever la restriction.

Et le face-à-face. La même requête — pas monstrueuse, mais groupement et tri sur toutes les lignes et dix lignes retournées — est envoyée séquentiellement aux deux moteurs. Le code ouvre des connexions et curseurs séparés pour CPU et GPU dans une boucle et chronomètre chaque exécution. Le résultat est net à l'écran : environ 6 secondes côté CPU, 1,6 seconde côté GPU. Soit 3,75× plus rapide, arrondi à quatre à cinq fois dans le commentaire. Le delta Docker est tout aussi minimal : image coordinator prestodb/presto:latest contre gpu-nightly, worker prestodb/presto-native:latest contre gpu-nightly ; une cellule de comparaison côte-à-côte dans le thème clair de Jupyter souligne la différence de deux lignes. Copiez l'entrepôt, basculez le tag d'image, ajoutez quelques propriétés GPU — le gain est à portée.

En zoom arrière, l'image s'assemble. Les trois notebooks Prestorials montrent comment poser un second étage plus rapide à côté d'un entrepôt de production sans déplacer les données et en gardant le même SQL. L'intégration IBM + NVIDIA Velox + cuDF, décrite dans le papier d'atelier VLDB arXiv 2606.24647 de mars 2026, s'attaque à deux problèmes durs : acheminer les données du stockage vers les opérateurs GPU et garder les échanges entre opérateurs en mémoire GPU. Les premières évaluations sur requêtes dérivées de TPC-H rapportent jusqu'à 6× de gain coût/performance. La vidéo apporte une preuve labo concrète sur 179 millions de lignes : 6 contre 1,6 seconde. La conclusion est pratique : pour essayer Presto accéléré GPU, clonez Prestorials, lancez les mêmes notebooks et partagez votre speedup en commentaire.