¿CPU o GPU? Velox y cuDF aceleran el SQL en Presto hasta 4×

Partimos de un cuello de botella conocido: Presto nació como motor SQL distribuido para big data en CPU, y el tiempo de consulta se dispara con el volumen. En el vídeo, Roy y William (NVIDIA) muestran cómo romper ese techo con GPU. El trabajo viene de IBM, NVIDIA y la comunidad Presto; el objetivo es añadir un motor acelerado por GPU sobre un almacén existente sin mover datos. La promesa es simple: en lugar de Presto en Java, ejecutar Presto con Velox — una capa de ejecución en C++ — para distribuir el mismo SQL en hardware paralelo. Como ampliar una carretera de un carril a ocho — mismo coche, más carriles.

Un repaso rápido de Presto y Velox ayuda. Nacido en Facebook en 2012, Presto es un motor SQL distribuido open source que separa almacenamiento y cómputo, escalando con coordinator y workers. En 2019 la comunidad se bifurcó en PrestoDB y Trino; PrestoDB vive hoy bajo prestodb/presto y la Presto Foundation, alojada por la Linux Foundation. El Presto clásico corre en Java. Velox, construido por Meta, es una librería de ejecución C++ vectorizada y columnar — el corazón de Presto C++ / Presto Native. Elimina la sobrecarga de la JVM y ejecuta el mismo plan en vectores cerca del hardware. Emparejado con cuDF, ese plan se dispersa por núcleos GPU. Analogía: reemplazar una orquesta Java por un equipo pequeño y rápido de C++ que sube directo al escenario.

La magia GPU llega vía NVIDIA cuDF y su extensión cuDF-X. Parte de RAPIDS (ahora NVIDIA CUDA-X), cuDF es una librería DataFrame para GPU — respaldada por libcudf y pylibcudf — que paraleliza joins, agregaciones, filtros y sorts en miles de núcleos CUDA. El vídeo lo refleja: tomar un data frame, unir, agregar, calcular — todo acelerado en GPU. El cuello es mover datos a la memoria GPU (VRAM). El punto de William es clave: llevar una consulta de 100 filas a la GPU no tiene sentido, el coste de transferencia borra la ganancia. Pero en 179 millones de filas agrupadas y ordenadas en bloque, el paralelismo gana con claridad. Las pruebas GB200 NVL72 y DGX B200 de 2026 confirman la misma idea — si los datos pasan entre operadores sin salir de la memoria GPU vía NVLink, la latencia cae.

La configuración práctica son tres notebooks, todos en el repositorio Prestorials de la Presto Foundation. El primero levanta un clúster Presto Native con Docker Compose. Pasos nítidos: crear directorios metastore y warehouse en el host, escribir los ficheros de config de Presto y lanzar coordinator y worker vía docker compose. Una celda de verificación muestra ambos componentes en Running — un coordinator CPU y un worker CPU. Luego unas consultas simples confirman la salud del clúster. Es un lab Presto mínimo que opera sobre datos del host en lugar de construir un almacén desde cero — un playground de un comando que encanta a los equipos de infra.

El segundo notebook añade volumen. El dataset es el sintético de IBM para anti-lavado de dinero (AML). Está en Kaggle como "IBM Transactions for Anti Money Laundering" y también en Hugging Face; el número de filas varía por escala, unas 176 millones a gran escala. Imita transacciones financieras — transferencias, compras, pagos con tarjeta — y se usa mucho en investigación GNN y foundation models. El notebook lo carga en el warehouse y verifica de nuevo que el clúster responde con consultas simples. Este paso fija el volumen realista del benchmark; sintético pero cercano a prod en forma y escala para una carga analítica.

El tercer notebook trae la novedad: copiar el almacén existente y añadir el motor GPU encima. En el Explorer se ven config y metadatos duplicados de forma idéntica, luego se añaden algunas propiedades GPU y se arranca el clúster GPU. El arranque parece rápido, pero la primera verificación aún muestra Starting; el segundo intento pasa a Running. Luego una prueba de humo: select star limit 1. William apunta que la primera consulta tarda cerca de un segundo porque levanta los binarios en VRAM — ese warm-up es esperado. Luego una decisión de diseño asumida: el lado GPU queda en solo lectura. La idea es evitar que dos escritores corrompan los mismos ficheros mientras informes y jobs siguen en el clúster CPU; el motor GPU solo lee. Si solo vas a correr el motor GPU, puedes quitar la restricción.

Y el cara a cara. La misma consulta — no monstruosa, pero con agrupación y ordenación sobre todas las filas y diez filas devueltas — se envía secuencialmente a ambos motores. El código abre conexiones y cursores separados para CPU y GPU en un bucle y cronometra cada ejecución. El resultado en pantalla es nítido: unos 6 segundos en CPU, 1,6 segundos en GPU. Es 3,75× más rápido, redondeado a cuatro o cinco veces en la narración. El delta Docker es igual de mínimo: imagen coordinator prestodb/presto:latest frente a gpu-nightly, worker prestodb/presto-native:latest frente a gpu-nightly; una celda de comparación lado a lado en el tema claro de Jupyter subraya la diferencia de dos líneas. Copia el almacén, cambia el tag de imagen, añade unas propiedades GPU — la ganancia está a ese alcance.

Haciendo zoom atrás, la imagen encaja. Los tres notebooks de Prestorials muestran cómo colocar un segundo nivel más rápido junto a un almacén de producción sin mover datos y manteniendo el mismo SQL. La integración IBM + NVIDIA Velox + cuDF, descrita en el paper de taller VLDB arXiv 2606.24647 de marzo de 2026, ataca dos problemas duros: llevar datos del almacenamiento a operadores GPU y mantener los intercambios entre operadores en memoria GPU. Las primeras evaluaciones sobre consultas derivadas de TPC-H reportan hasta 6× de mejora coste/rendimiento. El vídeo aporta una prueba de lab concreta sobre 179 millones de filas: 6 frente a 1,6 segundos. La conclusión es práctica: para probar Presto acelerado por GPU, clona Prestorials, ejecuta los mismos notebooks y comparte tu speedup en comentarios.