Polars: processe DataFrames maiores que a memória usando todos os núcleos do seu PC

Por que o Polars incomoda o pandas (e por que você deveria se importar)

Quem chega ao Polars geralmente vem de um mesmo tipo de frustração: um conjunto de dados que cabe no disco, mas não na memória RAM — ou uma transformação que roda em um único núcleo enquanto os outros quinze ficam ociosos. O Polars é uma biblioteca de DataFrames escrita em Rust sobre o formato de memória Apache Arrow, e seu ganho de velocidade vem menos da linguagem e mais do modelo de execução.

A ideia central: em vez de executar cada operação na hora, você descreve o trabalho como uma cadeia de expressões, e o motor de consulta do Polars planeja como executá-las — distribuindo o trabalho por todos os núcleos disponíveis e pulando colunas desnecessárias. É exatamente esse funcionamento que o novo cheat sheet da KDnuggets organiza em uma única referência prática.

Os dois conceitos que destravam tudo

1. scan_csv + collect: avaliação preguiçosa

A diferença entre read_csv e scan_csv resume o modelo. Enquanto o read_csv carrega o arquivo inteiro para a memória imediatamente, o scan_csv lê apenas o cabeçalho e fica esperando. Tudo o que você encadeia depois é uma descrição de intenção — nada executa até o collect().

import polars as pl

# Lazy: nada é lido de verdade ainda
lf = pl.scan_csv("dados_grandes.csv")

# Encadeia transformações sem executar
resultado = (
    lf.filter(pl.col("valor") > 100)
      .group_by("regiao")
      .agg(pl.col("valor").sum())
      .collect()  # só aqui o trabalho acontece
)

Essa folga dá ao otimizador espaço para “empurrar” seus filtros até a leitura do arquivo — o Polars lê apenas as colunas que o pipeline realmente usa. Para arquivos maiores que a memória, o collect(engine="streaming") processa em blocos em vez de desistir.

2. over(): janelas que leem como colunas normais

O segundo grande trunfo é o over(). Ele roda uma agregação por grupo, mas devolve um valor para cada linha — ou seja, calcular a participação de cada região no total dela mesma, ou um ranking dentro de uma categoria, dispensa o clássico group_by-e-join.

df.with_columns(
    (pl.col("vendas") / pl.col("vendas").sum().over("regiao")).alias("share_regiao"),
    pl.col("vendas").rank("dense", descending=True).over("categoria").alias("ranking")
)

null vs NaN: a confusão mais comum

No Polars, null significa “valor ausente” e NaN é um valor float real. São estados diferentes, com métodos diferentes. Tratar os dois como a mesma coisa é um dos tropeços mais frequentes de quem migra do pandas.

O que o cheat sheet cobre

• Verbos centrais:select, filter, with_columns;
• Agrupamento e remodelagem:group_by, agg, pivot, unpivot;
• Lógica condicional:when / then / otherwise;
• Junções (joins) e operações de concatenação;
• Expressões de janela via over();
• Processamento em streaming para dados que não cabem em memória.

✅ O que você ganha

• Desempenho real em CPUs multicore, sem configuração extra;
• Processamento de arquivos maiores que a RAM (modo streaming);
• API de expressões mais previsível e menos “mágica” que o pandas;
• Menor consumo de memória graças ao formato Arrow e à leitura seletiva de colunas.

⚠️ O que você não ganha

• O ecossistema colossal de bibliotecas que assumem pandas por padrão;
• Curva de aprendizado zero — o modelo lazy exige reaprender a pensar;
• Compatibilidade total: alguns fluxos com dependências antigas ainda pedem pandas.

Vale a pena migrar agora?

Para pipelines de dados que já sofrem com performance ou tamanho de arquivo, sim — o ganho costuma ser imediato. Para análises exploratórias rápidas e notebooks com poucos dados, o pandas continua perfeitamente adequado. O ponto do cheat sheet da KDnuggets é justamente dar a você a superfície de trabalho completa do Polars em uma página só, para decidir com informação — não com ansiedade de hype.