Do GPUs Really Need New Tabular File Formats?

Este documento demuestra que los cuellos de botella en el rendimiento de escaneo de GPU en archivos Parquet se deben a configuraciones subóptimas centradas en la CPU y no al formato en sí, y muestra que aplicar configuraciones conscientes de la GPU puede aumentar el ancho de banda de lectura efectivo hasta 125 GB/s sin alterar la especificación de Parquet.

Lo esencial

Imagina que tienes una biblioteca masiva de libros (tus datos) almacenada en un almacén (tu disco duro). También tienes un bibliotecario robot superrápido (tu GPU) cuya tarea es leer estos libros y responder preguntas.

Durante años, la biblioteca se ha organizado utilizando un sistema de archivado específico llamado Parquet. Este sistema fue diseñado pensando en un bibliotecario humano: agrupa los libros en pilas pequeñas y manejables que un humano puede recoger fácilmente una por una.

Sin embargo, el bibliotecario robot es diferente. No solo recoge una pila a la vez; tiene miles de manos y puede agarrar docenas de pilas simultáneamente. Pero como la biblioteca sigue organizada para humanos, el robot pasa la mayor parte de su tiempo esperando a que le entreguen la siguiente pila, o solo está usando una pequeña fracción de sus manos. El robot es increíblemente rápido, pero la organización de la biblioteca lo está frenando.

El artículo plantea una pregunta sencilla: ¿Necesitamos inventar un sistema de archivado completamente nuevo solo para robots?

Los autores dicen: No. En su lugar, solo necesitamos reorganizar los libros existentes usando unas pocas reglas simples.

Así es como resolvieron el problema, utilizando cuatro "reglas de la carretera" principales:

1. La regla de "Más pilas" (Aumentar el número de páginas)

• El problema: El antiguo sistema ponía todos los datos de una sección en un solo libro gigante y pesado. El robot intentaba leerlo, pero solo podía usar una mano a la vez porque el libro era demasiado grande para dividirlo.
• La solución: Cortaron esos libros gigantes en muchas páginas más pequeñas y delgadas. Ahora, el robot puede agarrar 100 páginas a la vez con sus 100 manos.
• El resultado: El robot ya no está esperando; está ocupado usando todas sus manos a la vez.

2. La regla de "Cajas grandes" (Aumentar el tamaño del grupo de filas)

• El problema: El antiguo sistema enviaba al robot paquetes diminutos del tamaño de un sello postal. Aunque el robot es rápido, el camión de reparto (la conexión entre la unidad de disco y el robot) se obstruye con demasiados paquetes diminutos.
• La solución: Comenzaron a enviar cajas de mudanza enormes y de tamaño completo en lugar de sellos postales.
• El resultado: El camión de reparto ahora puede conducir a toda velocidad, manteniendo al robot constantemente abastecido de datos.

3. La regla de "Empaque inteligente" (Flexibilidad de codificación)

• El problema: El antiguo sistema empaquetaba los libros usando un método genérico, de talla única. A veces esto hacía los libros más pequeños, pero a menudo no ayudaba mucho.
• La solución: Observaron cada libro individualmente y eligieron la mejor manera de reducirlo. Si un libro tenía muchas palabras repetidas, usaron un código especial para hacerlo diminuto. Si un libro ya era corto, lo dejaron como estaba.
• El resultado: Los libros ocupan menos espacio en la estantería, por lo que el camión de reparto tiene menos peso que transportar, lo que hace que todo el proceso sea más rápido.

4. La regla de "No envolverlo" (Sin compresión innecesaria)

• El problema: A veces, el antiguo sistema envolvía los libros en plástico de burbujas pesado (compresión) incluso cuando los libros ya eran pequeños. Luego, el robot tenía que gastar tiempo desenrollándolos, lo que desperdiciaba energía.
• La solución: Decidieron: "Si el plástico de burbujas no hace que el paquete sea significativamente más pequeño, no lo uses".
• El resultado: El robot ahorra tiempo al saltarse el paso de desenrollar los libros que no lo necesitaban.

El gran final: El robot contra el humano

Los autores probaron esta nueva organización.

• La vieja forma: El robot era lento, apenas usando sus superpoderes.
• La nueva forma: Al simplemente reorganizar los archivos Parquet existentes (sin inventar un nuevo formato), hicieron que el robot fuera 125 veces más rápido en términos de velocidad de lectura de datos.

También demostraron que cuando el robot trabaja en sincronía con el camión de reparto (superponiendo la lectura y el procesamiento), se vuelve aún más eficiente. De hecho, este robot reorganizado fue tan rápido que casi alcanzó el límite de velocidad teórica del propio camión de reparto.

La conclusión

El artículo concluye que no necesitamos quemar la biblioteca y construir una nueva desde cero. Solo necesitamos reorganizar los libros con algunos ajustes inteligentes.

Al ajustar cómo se empaquetan y agrupan los datos, el formato Parquet existente ya puede funcionar a la velocidad del rayo en las GPU modernas. Esto ahorra a todos el trabajo de aprender un nuevo sistema y mantiene compatible todo el software antiguo, mientras aún obtenemos el enorme impulso de velocidad que queríamos.

Resumen técnico

Resumen Técnico: ¿Realmente las GPUs Necesitan Nuevos Formatos de Archivos Tabulares?

Declaración del Problema

Apache Parquet es el formato de archivo columnar de facto en los sistemas analíticos modernos, sin embargo, sus directrices de configuración predeterminadas están moldeadas por motores de ejecución centrados en la CPU. A medida que el procesamiento de datos acelerado por GPU se vuelve prevalente, los archivos Parquet optimizados para CPU a menudo subutilizan severamente el hardware de GPU, creando un cuello de botella de rendimiento artificial. A pesar de las pruebas extensas en el lado de la CPU, la lectura de Parquet sigue siendo un cuello de botella importante en la analítica acelerada por GPU; por ejemplo, el equipo de NVIDIA RAPIDS informa que aproximadamente el 85% del tiempo de ejecución del benchmark TPC-H se gasta en escaneos de Parquet en lugar de en operadores de consulta. Esto plantea la pregunta de investigación central: ¿Realmente las GPUs requieren nuevos formatos de archivos tabulares, o pueden las configuraciones existentes de Parquet optimizarse para lograr un alto rendimiento?

Metodología

Los autores realizaron un estudio sistemático para evaluar cómo las elecciones de configuración de Parquet afectan el rendimiento de escaneo en GPU. La configuración experimental utilizó una sola GPU NVIDIA A100 leyendo la tabla más grande de TPC-H SF300 (lineitem) desde SSDs NVMe locales a través de GPUDirect Storage (GDS). El estudio empleó PystachIO, un sistema analítico acelerado por GPU que superpone completamente la E/S y el cómputo de la GPU, construido sobre la biblioteca NVIDIA RAPIDS cuDF.

La metodología involucró:

1. Establecimiento de la Línea Base: Generación de archivos Parquet utilizando la configuración predeterminada de DuckDB (una página por fragmento de columna, 122,880 filas por Grupo de Filas (RG), codificaciones Parquet V1 y compresión estándar).
2. Iteración de Configuración: Modificación sistemática de los parámetros del archivo para probar cuatro dimensiones específicas:
   • Cantidad de Páginas: Aumentar el número de páginas por RG para coincidir con los tamaños de la cuadrícula de kernels de GPU.
   • Tamaño del Grupo de Filas (RG): Aumentar el número de filas por RG para crear unidades de E/S más grandes adecuadas para GDS.
   • Flexibilidad de Codificación: Permitir la selección por fragmento de las codificaciones óptimas de ambos esquemas Parquet V1 y V2.
   • Selectividad de Compresión: Omitir la compresión para fragmentos de columna donde la reducción de tamaño no excede un umbral específico (10%).
3. Desarrollo de Herramientas: Los autores desarrollaron una herramienta de reescritura de Parquet (escrita en Rust) para transformar archivos Parquet existentes en estas configuraciones optimizadas sin alterar la especificación del formato de archivo.
4. Métricas de Rendimiento: La evaluación se centró en el ancho de banda de lectura efectivo (tamaño de datos crudos lógicos dividido por el tiempo de ejecución del escaneo) y el tiempo de ejecución de consultas de extremo a extremo para consultas TPC-H (Q6 y Q12) a través de escalas de conjuntos de datos variables (hasta SF1000).

Contribuciones y Perspectivas Clave

El artículo presenta cuatro perspectivas principales derivadas de los resultados experimentales:

1. Optimización de la Cantidad de Páginas: Los kernels de decodificación de GPU se paralelizan a través de páginas. Las configuraciones predeterminadas a menudo resultan en demasiadas pocas páginas, dejando la GPU subutilizada. Aumentar la cantidad de páginas a 100 o más mejora significativamente la eficiencia de decodificación y el ancho de banda del bus de almacenamiento.
2. Optimización del Tamaño de RG: La pila de E/S de la GPU (GDS) se comporta de manera diferente a las pilas de CPU, prefiriendo unidades de E/S más grandes (escala de MiB) para saturar el ancho de banda de almacenamiento. Los tamaños de RG predeterminados (que resultan en fragmentos de ~100 KB) son subóptimos. Aumentar los tamaños de RG a millones de filas (por ejemplo, 10M filas) permite que GDS sature los SSDs.
3. Flexibilidad de Codificación: Restringir las codificaciones a Parquet V1 limita la eficiencia de compresión. Permitir la selección del tamaño codificado más pequeño de ambos esquemas V1 y V2 (por ejemplo, utilizando Delta Binary Packed para enteros) mejora los ratios de compresión. Esto reduce el cuello de botella de E/S y aprovecha la decodificación eficiente de V2 en GPUs.
4. Evitar la Compresión Innecesaria: Aplicar ciegamente la compresión añade sobrecarga de descompresión. El estudio muestra que omitir la compresión cuando la reducción de tamaño está por debajo de un umbral del 10% mejora el rendimiento, particularmente en escenarios donde la GPU está limitada por cómputo (por ejemplo, al leer desde múltiples SSDs).

Resultados

Al aplicar estas configuraciones conscientes de GPU a archivos Parquet totalmente compatibles, los autores lograron los siguientes resultados:

• Ancho de Banda Efectivo: La configuración optimizada logró un ancho de banda de lectura efectivo de hasta 125 GB/s utilizando 4 SSDs, una mejora dramática sobre la línea base.
• Escalabilidad: El ancho de banda efectivo escaló linealmente con el número de SSDs cuando se aplicó flexibilidad de codificación, mientras que las configuraciones de línea base se saturaron temprano.
• Rendimiento de Consultas: En consultas TPC-H (Q6 y Q12), el sistema GPU utilizando archivos Parquet optimizados superó significativamente a los sistemas de CPU (ClickHouse y DuckDB) y se mantuvo cerca del tiempo de ejecución mínimo teórico (definido por el ancho de banda del SSD).
• No Se Requiere Nuevo Formato: El estudio demuestra que se puede lograr un alto rendimiento en GPU sin cambiar a un nuevo formato de archivo, preservando los beneficios de interoperabilidad del ecosistema Parquet.

Significado y Afirmaciones

El artículo argumenta que los nuevos formatos de archivo no son estrictamente necesarios para la analítica de alto rendimiento en GPU. En cambio, la brecha de rendimiento es en gran medida una consecuencia de elecciones de configuración subóptimas heredadas de los valores predeterminados centrados en la CPU.

• Guía Práctica: El trabajo proporciona la primera guía práctica sobre cómo optimizar Parquet para bases de datos GPU, permitiendo una aceleración sustancial mediante configuración en lugar de reemplazo de formato.
• Línea Base para Trabajo Futuro: Los autores establecen una línea base sólida para futuros formatos de archivos GPU. Afirman que cualquier nuevo formato propuesto debe superar estas configuraciones de Parquet optimizadas (que logran ~125 GB/s) en lugar de simplemente mejorar sobre los valores predeterminados no optimizados.
• Preservación del Ecosistema: Al mantener la compatibilidad con la especificación y el ecosistema Parquet existentes, el enfoque propuesto evita los costos asociados con la migración a formatos propietarios o nuevos.
• Agnosticismo de Hardware: Aunque se centra en GPUs, la herramienta de reescritura no es específica de hardware; aplica configuraciones basadas en las características del hardware objetivo, sugiriendo que las consultas frecuentes en cualquier hardware podrían beneficiarse de dicha reescritura.

Los autores concluyen que, aunque existen nuevos formatos dirigidos a la decodificación en memoria de GPU, el cuello de botella dominante en escenarios del mundo real sigue siendo la E/S de almacenamiento. Por lo tanto, optimizar el formato Parquet existente para maximizar el rendimiento de almacenamiento y minimizar la sobrecarga de descompresión es un paso crítico e inmediato antes de considerar diseños de formatos de archivo completamente nuevos.