Melhores Práticas para Dados de Alto Desempenho

Pipelines vetorizados e conscientes da memória em Rust - regras para Polars, Arrow e ETL de produção.

Como Usar Esta Lista

• Aplique os itens A-C ao projetar um novo pipeline antes de escrever código.
• Revise os itens D-F antes de enviar para produção ou cron.
• Releia após incidentes envolvendo OOM (Out Of Memory), deriva de esquema ou varreduras lentas.
• Marque as caixas nas descrições de PR para alterações que tocam dados.

A - Esquema e Ingestão

• Declare os dtypes de CSV explicitamente. A inferência transforma IDs numéricos em strings e quebra junções (joins) downstream.
• Versiona o esquema Parquet de saída. Consumidores falham rapidamente em vez de ler tipos incorretos.
• Normaliza timestamps para UTC na ingestão. Fusos horários mistos causam skew de junção silencioso entre arquivos.
• Rejeita ou quarentena linhas ruins com métricas contadas. Falha de job baseada em threshold é melhor que drops silenciosos.
• Prefira Parquet em vez de CSV para qualquer coisa consultada duas vezes. Compressão e estatísticas se pagam imediatamente.

B - Execução e Memória

• Use Polars preguiçoso (lazy) por padrão para trabalho baseado em arquivos. Empurre filtros e seleções de colunas antes de collect().
• Colete uma vez no final de uma cadeia preguiçosa. Coletas intermediárias multiplicam memória e CPU.
• Faça streaming ou processe em chunks quando a entrada exceder ~40% da RAM. Partials de HashMap mesclam apenas as chaves que você precisa.
• Projete colunas cedo em varreduras Parquet. Tabelas largas penalizam select * em object stores.
• Execute transformações CPU-bound em spawn_blocking dentro do Axum. Proteja o pool de I/O do Tokio.

C - Interoperabilidade e Formatos

• Use Arrow IPC ou Parquet para passagem para Python. Arrays de linha JSON não escalam além de megabytes.
• Fixe as versões do Polars e PyArrow no CI. Incompatibilidades de tipos de extensão aparecem como erros de decodificação.
• Documente nullable vs non-nullable por coluna. Arrow e Parquet impõem isso nas fronteiras.
• Codifique como dicionário dimensões de string de baixa cardinalidade. Reduz a memória e acelera group-by.
• Alinhe o tamanho do grupo de linhas (128K-1M linhas) com os padrões de consulta. Grupos minúsculos adicionam sobrecarga de metadados; grupos enormes prejudicam o pushdown.

D - Operações e Confiabilidade

• Escreva saídas atomicamente (arquivo temporário + renomear). Falha no meio da escrita não deve publicar Parquet corrompido.
• Emita logs estruturados por estágio com contagens de linhas. Spans do tracing tornam jobs noturnos depuráveis.
• Retorne códigos de saída de CLI distintos para erros de uso, dados ou sistema. Orquestradores precisam de retentativas corretas.
• Faça benchmark do tamanho do chunk em hardware representativo. Padrões de laptop não se transferem para servidores de 512GB.
• Limite o payload HTTP e o custo da consulta em serviços de dados. Resumos ilimitados são vetores de DoS (Denial of Service).

E - Cultura de Desempenho

• Meça com POLARS_MAX_THREADS ajustado por implantação. Serviços colocalizados podem precisar de menos threads.
• Compare com pandas baseline apenas uma vez. Ganhos em Rust devem ser rastreados em benchmarks de CI, não em anedotas.
• Explique planos preguiçosos durante o desenvolvimento. .explain(true) pega pushdown ausente antes da produção.
• Prefira expressões vetorizadas em vez de loops de linha. for manual sobre linhas abre mão de SIMD e paralelismo.
• Faça spill ou push de joins pesados para um banco de dados quando a cardinalidade da chave explodir. Hash joins em processo não são infinitos.

FAQs

Relacionados

• Data Basics - orientação da seção
• Polars - detalhes de execução preguiçosa
• Streaming & Large Data - memória limitada
• Building Data CLIs & Services - forma operacional

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.