Do GPUs Really Need New Tabular File Formats?

Este artigo demonstra que os gargalos de desempenho de varredura em GPU em arquivos Parquet decorrem de configurações subótimas centradas na CPU e não do próprio formato, e mostra que a aplicação de configurações conscientes de GPU pode aumentar a largura de banda de leitura efetiva para 125 GB/s sem alterar a especificação do Parquet.

O essencial

Imagine que você tem uma biblioteca massiva de livros (seus dados) armazenada em um armazém (seu disco rígido). Você também tem um bibliotecário robô super-rápido (sua GPU), cuja função é ler esses livros e responder perguntas.

Por anos, a biblioteca foi organizada usando um sistema de arquivamento específico chamado Parquet. Esse sistema foi projetado pensando em um bibliotecário humano: agrupa os livros em pequenas pilhas gerenciáveis que um humano pode facilmente pegar uma a uma.

No entanto, o bibliotecário robô é diferente. Ele não pega apenas uma pilha por vez; ele tem milhares de mãos e pode agarrar dezenas de pilhas simultaneamente. Mas como a biblioteca ainda está organizada para humanos, o robô passa a maior parte do tempo esperando que a próxima pilha seja entregue a ele, ou está usando apenas uma fração minúscula de suas mãos. O robô é incrivelmente rápido, mas a organização da biblioteca está o impedindo.

O artigo faz uma pergunta simples: Precisamos inventar um sistema de arquivamento totalmente novo apenas para robôs?

Os autores dizem: Não. Em vez disso, precisamos apenas reorganizar os livros existentes usando algumas regras simples.

Veja como eles resolveram o problema, usando quatro "regras da estrada" principais:

1. A Regra "Mais Pilhas" (Aumentar a Contagem de Páginas)

• O Problema: O antigo sistema colocava todos os dados de uma seção em um único livro gigante e pesado. O robô tentava lê-lo, mas só podia usar uma mão por vez porque o livro era grande demais para ser dividido.
• A Solução: Eles cortaram esses livros gigantes em muitas páginas menores e mais finas. Agora, o robô pode pegar 100 páginas de uma vez com suas 100 mãos.
• O Resultado: O robô não está mais esperando; está ocupado usando todas as suas mãos ao mesmo tempo.

2. A Regra "Caixas Grandes" (Aumentar o Tamanho do Grupo de Linhas)

• O Problema: O antigo sistema enviava ao robô pacotes minúsculos, do tamanho de selos postais. Mesmo que o robô seja rápido, o caminhão de entrega (a conexão entre o disco e o robô) fica congestionado com muitos pacotes minúsculos.
• A Solução: Eles começaram a enviar caixas de mudança enormes e de tamanho completo em vez de selos postais.
• O Resultado: O caminhão de entrega agora pode dirigir na velocidade máxima, mantendo o robô constantemente alimentado com dados.

3. A Regra "Embalagem Inteligente" (Flexibilidade de Codificação)

• O Problema: O antigo sistema embalava os livros usando um método genérico, "tamanho único". Às vezes isso tornava os livros menores, mas muitas vezes não ajudava muito.
• A Solução: Eles olharam para cada livro individualmente e escolheram a melhor maneira de encolhê-lo. Se um livro tivesse muitas palavras repetidas, usaram um código especial para torná-lo minúsculo. Se um livro já fosse curto, deixaram-no como estava.
• O Resultado: Os livros ocupam menos espaço na estante, então o caminhão de entrega tem menos peso para carregar, tornando todo o processo mais rápido.

4. A Regra "Não Envolva" (Sem Compressão Desnecessária)

• O Problema: Às vezes, o antigo sistema envolvia os livros em plástico bolha pesado (compressão) mesmo quando os livros já eram pequenos. O robô então tinha que gastar tempo desembalando-os, o que desperdiçava energia.
• A Solução: Eles decidiram: "Se o plástico bolha não tornar o pacote significativamente menor, não o use."
• O Resultado: O robô economiza tempo pulando a etapa de desembalar livros que não precisavam disso.

O Grande Final: O Robô vs. O Humano

Os autores testaram essa nova organização.

• O Jeito Antigo: O robô era lento, mal usando seus superpoderes.
• O Jeito Novo: Apenas reorganizando os arquivos Parquet existentes (sem inventar um novo formato), eles tornaram o robô 125 vezes mais rápido em termos de velocidade de leitura de dados.

Eles também mostraram que, quando o robô trabalha em sincronia com o caminhão de entrega (sobrepondo leitura e processamento), ele se torna ainda mais eficiente. Na verdade, esse robô reorganizado era tão rápido que quase atingiu o limite de velocidade teórico do próprio caminhão de entrega.

A Conclusão

O artigo conclui que não precisamos queimar a biblioteca e construir uma nova do zero. Precisamos apenas reorganizar os livros com alguns ajustes inteligentes.

Ao ajustar como os dados são embalados e agrupados, o formato Parquet existente já pode rodar em velocidade relâmpago em GPUs modernas. Isso poupa a todos o trabalho de aprender um novo sistema e mantém todo o software antigo compatível, enquanto ainda obtém o enorme impulso de velocidade que desejávamos.

Resumo técnico

Resumo Técnico: As GPUs Realmente Precisam de Novos Formatos de Arquivos Tabulares?

Declaração do Problema

O Apache Parquet é o formato de arquivo colunar de fato em sistemas analíticos modernos, no entanto, suas diretrizes de configuração padrão são moldadas por engines de execução centradas em CPU. À medida que o processamento de dados acelerado por GPU se torna prevalente, arquivos Parquet otimizados para CPUs frequentemente subutilizam severamente o hardware de GPU, criando um gargalo de desempenho artificial. Apesar de extensos testes do lado da CPU, a leitura de Parquet permanece um grande gargalo na análise acelerada por GPU; por exemplo, a equipe da NVIDIA RAPIDS relata que aproximadamente 85% do tempo de execução do benchmark TPC-H é gasto em varreduras de Parquet em vez de operadores de consulta. Isso levanta a questão central de pesquisa: As GPUs realmente exigem novos formatos de arquivos tabulares, ou as configurações existentes do Parquet podem ser otimizadas para alcançar alto desempenho?

Metodologia

Os autores conduziram um estudo sistemático para avaliar como as escolhas de configuração do Parquet afetam o desempenho de varredura em GPU. O ambiente experimental utilizou uma única GPU NVIDIA A100 lendo a maior tabela do TPC-H SF300 (lineitem) a partir de SSDs NVMe locais via GPUDirect Storage (GDS). O estudo empregou o PystachIO, um sistema analítico acelerado por GPU que sobrepõe totalmente I/O e computação em GPU, construído sobre a biblioteca NVIDIA RAPIDS cuDF.

A metodologia envolveu:

1. Estabelecimento de Linha de Base: Geração de arquivos Parquet usando as configurações padrão do DuckDB (página única por chunk de coluna, 122.880 linhas por Grupo de Linhas (RG), codificações Parquet V1 e compressão padrão).
2. Iteração de Configuração: Modificação sistemática dos parâmetros do arquivo para testar quatro dimensões específicas:
   • Contagem de Páginas: Aumentando o número de páginas por RG para corresponder aos tamanhos de grade de kernel da GPU.
   • Tamanho do Grupo de Linhas (RG): Aumentando o número de linhas por RG para criar unidades de I/O maiores adequadas ao GDS.
   • Flexibilidade de Codificação: Permitindo a seleção por chunk das codificações ótimas de ambos os esquemas Parquet V1 e V2.
   • Seletividade de Compressão: Ignorando a compressão para chunks de coluna onde a redução de tamanho não excede um limite específico (10%).
3. Desenvolvimento de Ferramenta: Os autores desenvolveram uma ferramenta de reescrita de Parquet (escrita em Rust) para transformar arquivos Parquet existentes nessas configurações otimizadas sem alterar a especificação do formato de arquivo.
4. Métricas de Desempenho: A avaliação focou na largura de banda de leitura efetiva (tamanho bruto lógico dos dados dividido pelo tempo de execução da varredura) e no tempo de execução de consulta ponta a ponta para consultas TPC-H (Q6 e Q12) em várias escalas de conjunto de dados (até SF1000).

Principais Contribuições e Insights

O artigo apresenta quatro insights principais derivados dos resultados experimentais:

1. Otimização da Contagem de Páginas: Os kernels de decodificação da GPU paralelizam-se através das páginas. Configurações padrão frequentemente resultam em poucas páginas, deixando a GPU subutilizada. Aumentar a contagem de páginas para 100 ou mais melhora significativamente a eficiência de decodificação e a largura de banda do barramento de armazenamento.
2. Otimização do Tamanho do RG: A pilha de I/O da GPU (GDS) comporta-se de forma diferente das pilhas de CPU, preferindo unidades de I/O maiores (escala de MiB) para saturar a largura de banda de armazenamento. Tamanhos de RG padrão (resultando em chunks de ~100 KB) são subótimos. Aumentar os tamanhos de RG para milhões de linhas (por exemplo, 10 milhões de linhas) permite que o GDS sature os SSDs.
3. Flexibilidade de Codificação: Restringir codificações ao Parquet V1 limita a eficiência de compressão. Permitir a seleção do menor tamanho codificado de ambos os esquemas V1 e V2 (por exemplo, utilizando Delta Binary Packed para inteiros) melhora os índices de compressão. Isso reduz o gargalo de I/O e aproveita a decodificação V2 eficiente em GPUs.
4. Evitar Compressão Desnecessária: Aplicar compressão cegamente adiciona sobrecarga de descompressão. O estudo mostra que ignorar a compressão quando a redução de tamanho está abaixo de um limiar de 10% melhora o desempenho, particularmente em cenários onde a GPU está limitada por computação (por exemplo, ao ler de múltiplos SSDs).

Resultados

Ao aplicar essas configurações conscientes de GPU a arquivos Parquet totalmente compatíveis, os autores alcançaram os seguintes resultados:

• Largura de Banda Efetiva: A configuração otimizada alcançou até 125 GB/s de largura de banda de leitura efetiva usando 4 SSDs, uma melhoria dramática sobre a linha de base.
• Escalabilidade: A largura de banda efetiva escalou linearmente com o número de SSDs quando a flexibilidade de codificação foi aplicada, ao passo que as configurações de linha de base saturaram precocemente.
• Desempenho de Consulta: Nas consultas TPC-H (Q6 e Q12), o sistema de GPU usando arquivos Parquet otimizados superou significativamente os sistemas de CPU (ClickHouse e DuckDB) e permaneceu próximo do tempo de execução mínimo teórico (definido pela largura de banda do SSD).
• Nenhum Novo Formato Necessário: O estudo demonstra que alto desempenho em GPU pode ser alcançado sem mudar para um novo formato de arquivo, preservando os benefícios de interoperabilidade do ecossistema Parquet.

Significado e Alegações

O artigo argumenta que novos formatos de arquivo não são estritamente necessários para análise de GPU de alto desempenho. Em vez disso, a lacuna de desempenho é amplamente uma consequência de escolhas de configuração subótimas herdadas de padrões centrados em CPU.

• Orientação Prática: O trabalho fornece a primeira orientação prática sobre como otimizar o Parquet para bancos de dados de GPU, permitindo aceleração substancial através de configuração em vez de substituição de formato.
• Linha de Base para Trabalho Futuro: Os autores estabelecem uma forte linha de base para futuros formatos de arquivo de GPU. Eles afirmam que qualquer novo formato proposto deve superar essas configurações otimizadas de Parquet (que alcançam ~125 GB/s) em vez de meramente melhorar sobre padrões não otimizados.
• Preservação do Ecossistema: Ao manter a compatibilidade com a especificação e o ecossistema Parquet existentes, a abordagem proposta evita os custos associados à migração para formatos proprietários ou novos.
• Agnosticismo de Hardware: Embora focado em GPUs, a ferramenta de reescrita não é específica de hardware; ela aplica configurações com base nas características do hardware de destino, sugerindo que consultas frequentes em qualquer hardware podem se beneficiar de tal reescrita.

Os autores concluem que, embora existam novos formatos voltados para decodificação na memória da GPU, o gargalo dominante em cenários do mundo real permanece o I/O de armazenamento. Portanto, otimizar o formato Parquet existente para maximizar a vazão de armazenamento e minimizar a sobrecarga de descompressão é um passo crítico e imediato antes de considerar designs de formatos de arquivo totalmente novos.