Desempenho Distribuído vs. Nó Único em Benchmarks TPC-H do Polars

A comparação de desempenho entre o Polars em configuração distribuída e em nó único revela nuances cruciais para arquitetos de dados. O estudo utilizou um setup com especificações agregadas similares: 128 vCPUs e 512GB de RAM, porém implementadas de formas diferentes. A versão distribuída consistiu em 32 instâncias m8i.xlarge, enquanto o nó único usou uma m8i.32xlarge. O benchmark TPC-H (na implementação PDS-H de 1TB) mostrou que, para queries intensivas em I/O, a configuração distribuída teve vantagem, pois a largura de banda de rede agregada (até 400 Gbps de burst) superou o limite de 50 Gbps do nó único. Isso é especialmente visível em operações como a Q6, que é quase puramente leitura de dados do S3 com filtragem.

Por outro lado, queries com múltiplos joins (como Q8 e Q9) performaram melhor no nó único. O overhead do shuffle de dados pela rede no ambiente distribuído neutralizou os ganhos de paralelização. Além disso, a arquitetura NUMA (Non-Uniform Memory Access) em instâncias de nó único maiores pode introduzir gargalos. A engine de streaming do Polars, com seu mecanismo de work stealing, pode degradar o desempenho em máquinas com múltiplas zonas NUMA, como a m8i.32xlarge. O teste em uma r8i.16xlarge, com um único nó NUMA, confirmou que a execução de nó único é mais rápida para a maioria das queries, exceto as que dependem intensamente de I/O de rede.

A abordagem do Polars em demonstrar a força da sua engine evoluiu. Se antes, conforme a equipe Polars já havia comparado em uma publicação anterior, o foco era o desempenho da sua engine distribuída contra o Apache Spark, agora o cenário é outro. O ponto é avaliar a própria engine distribuída contra a performance aclamada do Polars em nó único. Essa mudança de foco reflete a maturidade da oferta distribuída e a busca por um entendimento mais aprofundado dos cenários ideais para cada tipo de arquitetura. É uma evolução na estratégia de benchmarking que serve de guia para os usuários.

Olhando para o futuro, a equipe planeja implementar bloom filters pushdown entre os estágios de processamento. Essa melhoria técnica tem o potencial de reduzir drasticamente o volume de dados movimentados durante as operações de shuffle, o que poderia alterar o veredito atual sobre o desempenho em queries com múltiplos joins, tornando a performance distribuída mais competitiva nesses cenários.

Para engenheiros de dados e arquitetos, a decisão entre escalar verticalmente (nó único) ou horizontalmente (distribuído) vai muito além da simples capacidade de CPU e RAM. Este estudo do Polars sublinha que a natureza das cargas de trabalho, intensiva em I/O ou em processamento de joins, e até mesmo a arquitetura física das máquinas (como o NUMA e a capacidade de rede) são fatores determinantes. O CEVIU News já apontou, na matéria de 1 de junho de 2026 sobre o CostBench da ClickHouse, a importância de avaliar a relação custo-performance, e este novo benchmark do Polars reforça que a solução mais rápida nem sempre é a mais eficiente ou a mais barata para cada caso de uso específico.

A compreensão detalhada desses tradeoffs permite otimizar custos e garantir a escalabilidade adequada para diferentes pipelines de dados, evitando surpresas de desempenho. É fundamental para projetar sistemas de dados que sejam performáticos e sustentáveis a longo prazo, considerando as particularidades de cada provedor de nuvem e de cada workload.