Na era da inteligência artificial, a memória se tornou um recurso crítico. Empresas como Micron Technology e Sandisk têm atraído atenção sem precedentes e aumentado preços com forte poder de precificação. Mas para engenheiros de dados que constroem aplicações intensivas, a velha resposta de “adicione mais capacidade” simplesmente não funciona mais quando os orçamentos não acompanham o volume de dados.
O que fazer quando o conjunto de dados dobra mas o cluster não? Um novo artigo prático da Towards Data Science mostra três abordagens progressivas para processar 6,2 milhões de registros de redes sociais sem estourar a memória disponível.
O problema: 6,2 milhões de linhas com tipos mistos
O desafio começa com dados extraídos de uma API de rede social: após o flattening do JSON, 200 colunas com tipos mistos — contagens de reação que podem ser número, string ou null; listas de hashtags que podem ser array, string única ou null. O dataset consome aproximadamente 30 GB, mais do que a instância de memória padrão de um worker na nuvem.
Diferentemente do PySpark, que exige um schema consistente, o Pandas armazena essas colunas como object e não exige que cada linha obedeça ao mesmo schema. Mas o processamento simples com astype(str) falha: a memória se esgota durante as transformações intermediárias do DataFrame.
Solução 1: Chunking manual com Pandas
A técnica de chunking divide cada coluna em blocos — neste caso, 250 mil linhas por vez. O Pandas processa um chunk, libera a memória e avança para o próximo. O pico de memória cai drasticamente e a pipeline se estabiliza. A contrapartida: o tempo de execução aumenta significativamente, já que o chunking usa um único núcleo de CPU e exige um loop manual para agregar os resultados.
Solução 2: Dask e execução paralela automática
O Dask particiona automaticamente o DataFrame e constrói um grafo de tarefas que agenda partições entre os núcleos de CPU disponíveis, reduzindo o tempo de execução. Porém, há uma armadilha: como um Dask DataFrame é composto por múltiplos DataFrames Pandas, se uma coluna contiver valores inconsistentes (strings vazias, None, inteiros, strings), o Dask provavelmente levantará um erro ao inferir o tipo de dados da amostra inicial. A solução é especificar explicitamente os tipos de coluna esperados em vez de depender da inferência automática.
Solução 3: Polars, o motor Rust com API Python
O Polars é uma biblioteca de DataFrame implementada em Rust com API Python. Ele usa o formato colunar Apache Arrow, que minimiza cópias de memória enquanto maximiza a eficiência do cache da CPU. Executa a operação .cast(pl.String) diretamente em código Rust nativo — várias vezes mais rápido que Python e usando apenas uma fração da memória.
Além disso, o Polars constrói um plano de consulta lazy e o otimizador determina o plano de execução mais eficiente antes de ler os dados. No modo streaming, processa os dados sem carregar o dataset inteiro em RAM. O único ponto de atenção é que colunas com tipos muito inconsistentes exigem declaração explícita de schema.
Qual escolher?
Para pipelines estabelecidas com orçamento de engenharia limitado, o chunking com Pandas é a opção mais simples e previsível. Quando há múltiplos núcleos disponíveis e o schema é relativamente estável, o Dask oferece bom equilíbrio entre desempenho e familiaridade. Para novos projetos que exigem velocidade máxima com consumo mínimo de memória, o Polars é a recomendação mais forte — especialmente em ambientes de nuvem onde cada byte de RAM tem custo.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
