650GB de dados (Delta Lake no S3): Polars vs. DuckDB vs. Daft vs. Spark

 (dataengineeringcentral.substack.com)
8 pontos por GN⁺ 2025-11-16 | 1 comentários | Compartilhar no WhatsApp
  • Dados Delta Lake de 650GB armazenados no S3 e um experimento comparando o desempenho de Polars, DuckDB, Daft e Spark ao processá-los em um ambiente de nó único
  • Em uma instância EC2 com 32GB de memória, foi verificado se cada engine consegue processar dados em grande escala, explorando o potencial de um único nó em comparação com o Spark baseado em cluster
  • DuckDB levou 16 minutos, Polars 12 minutos, Daft 50 minutos e PySpark mais de 1 hora, confirmando a viabilidade prática de processamento mesmo em nó único
  • O Polars não oferece suporte a Deletion Vector, enquanto apenas o DuckDB oferece esse recurso, o que cria diferenças em compatibilidade com Lake House
  • No fim, o experimento demonstra que frameworks de nó único podem processar grandes volumes de dados mesmo em hardware de baixo custo, levantando a necessidade de repensar a dependência de computação distribuída

Fadiga de cluster e a alternativa de nó único

  • À medida que o custo e a complexidade de operar clusters Lake House baseados em SaaS aumentam, surge a menção ao fenômeno de “cluster fatigue”
  • Antes, usava-se Spark por falta de alternativas além do Pandas, mas com a chegada de DuckDB, Polars e Daft (D.P.D.), ampliou-se a possibilidade de processamento em nó único
  • O D.P.D. permite processar datasets maiores que a memória (LTM) e realizar operações de alta velocidade
  • O texto apresenta duas opções, distribuída e não distribuída, e enfatiza o conceito de “Single Node Rebellion”

Configuração do ambiente de teste

  • Criação de uma tabela Delta Lake no S3 com cerca de 650GB de dados armazenados (a meta era 1TB, mas foi interrompida)
  • Execução de DuckDB, Polars e Daft em uma instância EC2 (32GB RAM, 16 CPU), seguida de comparação com Spark
  • Os dados consistem em dados simulados no formato de postagens de redes sociais; foi criado um Python dict, convertido em um Daft DataFrame e salvo como arquivos Parquet
  • Depois, os arquivos Parquet foram convertidos em uma tabela Delta Lake no Databricks, com particionamento por ano e mês
  • Excluindo o log Delta, foram confirmados cerca de 650GB de dados

Limitações de memória e necessidade de streaming

  • Como era necessário processar 650GB em um nó único com 32GB de memória, foi levantada a necessidade de executar consultas em modo de streaming
  • Citando uma issue do GitHub do Polars, o texto menciona casos em que se pede suporte a escrita em streaming para Iceberg
  • Reforça-se a necessidade de suporte nativo para que frameworks modernos como Polars e DuckDB possam ler e gravar formatos Lake House em streaming

Resultados dos testes por engine

  • DuckDB
    • Único com suporte a Deletion Vector
    • Conseguiu processar 650GB de dados em apenas 16 minutos em uma máquina Linux com 32GB
    • Código simples e arquivo de saída gerado corretamente
  • Polars
    • A falta de suporte a Deletion Vector impõe limitações em ambientes Lake House
    • Exige o uso da Lazy API (Scan/Sink)
    • Concluiu o processamento em 12 minutos, mais rápido que o DuckDB
  • Daft
    • Baseado em Rust, com boa experiência de uso, mas foi o mais lento, com 50 minutos de processamento
    • Funcionamento estável confirmado em tarefas relacionadas a Iceberg
  • PySpark (Databricks Single Node)
    • Levou mais de 1 hora, executado sem tuning
    • Menor eficiência em comparação com as engines de nó único
    • O objetivo do experimento era menos a velocidade e mais validar a viabilidade prática de um nó único

Conclusão e implicações

  • O experimento demonstrou que frameworks de nó único conseguem processar grandes volumes de dados Lake House
  • Mesmo em hardware de baixo custo, foi possível obter tempos de execução razoáveis e uma estrutura de código simples
  • DuckDB, Polars e Daft oferecem desempenho prático mesmo sem clusters distribuídos
  • O texto mostra que computação distribuída não é a única solução possível e sugere a necessidade de repensar a arquitetura moderna de Lake House
  • Por meio do conceito de “Single Node Rebellion”, destaca-se o potencial de uma abordagem de engenharia de dados mais eficiente em custo

Leituras relacionadas

1 comentários

 
GN⁺ 2025-11-16
Comentários do Hacker News
  • Sou engenheiro de software na Eventual e queria agradecer por compartilhar o benchmark do Daft que nossa equipe criou
    O Daft é um motor de processamento de dados de alto desempenho para workloads de IA, que funciona tanto em nó único quanto em ambientes distribuídos
    Com este benchmark, descobrimos bastante espaço para melhorar a paralelização e o pipeline. Em especial, havia muitos pontos a otimizar no leitor de deltalake e no operador de groupby
    Pretendemos refletir essas melhorias nas próximas releases, e mais detalhes podem ser vistos no GitHub, Twitter, LinkedIn
    Se o Daft parecer interessante, você pode experimentá-lo diretamente com pip install daft
    • Fico curioso se há planos de expor o Daft como backend do ibis. Isso pareceria ótimo para testar com troca suave entre diferentes engines
    • Isso parece uma conta criada para divulgar a empresa
  • Awk? Há um artigo interessante relacionado — Command-line tools can be 235x faster than your Hadoop cluster
  • 650GB? São dados pequenos o bastante para caber até no meu celular
    Em vez de tooling excessivo, é só usar ferramentas GNU
    Como referência, é um texto antigo, mas ainda interessante — command-line tools can be 235x faster than your Hadoop cluster
    • Agora já é diferente da era do Hadoop de 2014 tratada naquele texto
      Se você tentar agregar 650GB de dados JSON com ferramentas de CLI, vai ser difícil acompanhar o desempenho de processamento paralelo do DuckDB ou do ClickHouse. Eu até tentei com GNU Parallel, mas houve limites
    • Se fossem 650TB, a conversa seria completamente diferente. Esse artigo é só um microbenchmark
      Na prática, você precisa de um catálogo de dados e de jobs baseados em cluster
    • Compartilha este vídeo junto com a piada: “esqueci como se contam números tão pequenos”
  • Eu frequentemente uso DuckDB para lidar com “biggish data” em um único nó
    Em vez de Delta ou Iceberg, faço consultas percorrendo diretamente arquivos Parquet
    Baixo resultados consultados no BigQuery para arquivos Parquet locais (cerca de 1GB cada) e analiso com DuckDB. São dados bem maiores que a RAM, mas funciona bem
    Às vezes também comparo a diferença de desempenho em agregações entre BigQuery e DuckDB para dividir o trabalho entre as duas engines. Esse tipo de combinação é uma parte divertida da engenharia de dados
    • Algo na faixa de 650GB dá para processar tranquilamente até em filesystem local. Não precisa de ferramenta complexa
  • Este benchmark parece ter sido totalmente dominado pela largura de banda da NIC
    Com o máximo de 10Gbps de uma instância c5.4xlarge, levaria no mínimo 9 minutos para ler 650GB do S3
    Pequenas diferenças na forma de fazer o agendamento de I/O provavelmente tiveram grande impacto nos resultados
    Na verdade, pode até ser mais econômico usar uma instância maior e terminar mais rápido
    • Seria interessante testar também em um desktop comum ou em um notebook decente
      O armazenamento NVMe é muito mais rápido que o S3, e uma CPU local de 8 a 16 núcleos pode até superar a nuvem
      O S3 é um ótimo produto, mas não chega perto do desempenho de armazenamento local
    • É bem provável que a consulta real não tenha varrido todos os arquivos, e sim usado leituras por faixa de bytes no S3 para processar só algumas colunas
      A distribuição dos tamanhos de arquivo e o skew das chamadas de API provavelmente foram variáveis mais importantes
      Concordo totalmente com a ideia de que “uma instância maior pode acabar saindo mais barata”
    • O valor do experimento é meio incerto
      O Spark é adequado para datasets grandes com múltiplos estágios e, ao usar S3 como backend, o gargalo de rede aparece diretamente no custo
      O desempenho em nó único de DuckDB/Polars é impressionante, mas isso é como colocar um avião e uma moto para correr na pista
    • 10Gbps é muito pouco. No Google, usavam NICs de 400Gbps e controle de congestionamento TCP aprimorado
      Diferenças assim são parte do motivo de tanta gente se cansar de computação distribuída
    • Concordo com esse ponto. Há uma lição que aprendi em Wall Street há 30 anos — antes de testar o desempenho de um sistema, entenda primeiro o máximo teórico
      Quando você identifica os limites de recursos e expressa o desempenho real como proporção desse limite, tudo fica bem mais claro
  • Este texto é uma matéria mal apresentada em dois aspectos
    1. Na prática, provavelmente houve column pruning, então só 2 colunas + metadados foram acessados
    2. A maior parte do tempo deve ter ficado presa ao I/O do S3, e o limite de conexões simultâneas provavelmente teve mais impacto
      É bom terem testado vários sistemas, mas eu gostaria que tivessem tratado de forma mais séria consultas maiores que a memória
    • É importante que a consulta seja uma projeção que retorna só uma parte dos 650GB totais
      O DuckDB é forte em streaming acima da memória, mas o Polars ainda é imaturo nesse ponto
      As configurações padrão do S3 não bloqueiam leitura paralela, então no fim o gargalo provavelmente foi a largura de banda de rede da VM
  • Recentemente precisei processar alguns TB de dados JSON, e o problema eram os inúmeros arquivos pequenos de 10~20MB
    O ClickHouse foi o mais rápido, e o DuckDB foi o melhor em simplicidade e estabilidade
    Flink e PySpark foram de 3 a 5 vezes mais lentos, e Dask e Ray também lentos demais
    Hoje em dia, recomendo começar com DuckDB ou ClickHouse para a maioria dos workloads. Minha estratégia padrão é substituir por DuckDB quando o Pandas fica lento
    • Fico curioso se você primeiro converteu os dados JSON para outro formato, ou se trabalhou diretamente sobre JSON
  • O Polars depende de delta-rs para suportar Delta Lake, e essa implementação não suporta Deletion vectors
    Mesmo com uma biblioteca de nó único, dá para lidar tranquilamente com algo em torno de 1TB, e só acima de 10TB faria sentido migrar para Spark
    Issue relacionada
    • Muita gente vai cedo demais para o Spark porque “é fácil paralelizar com Spark”
      Mas em muitos casos dá para resolver com ferramentas melhores
      No passado, um engenheiro júnior levou 18 horas processando centenas de JSONs de 5GB com concatenação de strings em Python,
      mas, trocando por ferramentas simples de console e multiprocessing, caiu para 35 minutos
      O essencial é a escolha da ferramenta adequada
  • Presto (AWS Athena) talvez seja uma alternativa melhor e mais rápida. Eu gostaria de testar 650GB de dados também em ambiente local
    • O nome do Presto agora é Trino
      O custo de manutenção e execução é muito baixo, e é uma ferramenta com ótimo custo-benefício
  • O novo formato de catálogo DuckLake do DuckDB também parece um bom candidato para teste — ducklake.select
    • O recurso de flush inline de dados do DuckLake ainda está em alfa
      Para resolver o problema de surgirem arquivos Parquet demais em escritas pequenas em lote, o DuckLake os armazena inline em um DBMS (como Postgres)
      Só recentemente surgiu a funcionalidade de reescrevê-los em Parquet, mas ainda precisa amadurecer
      Documentação relacionada
    • O formato DuckLake tem um problema de dependência de SQL do tipo ovo ou galinha
      É preciso representar o catálogo em um banco SQL, mas a vantagem do Parquet é justamente evitar essa complexidade
      Se o catálogo também fosse baseado em Parquet, talvez virasse um formato auto-bootstrapável