Polars 2.0: por que as junções não mantêm mais a ordem das linhas
Polars 2.0 executa collect em um mecanismo de streaming por padrão.
Polars 2.0 executa collect em um mecanismo de streaming por padrão. Para join, group_by e unpivot, o lançamento não garante mais a ordem das linhas de entrada, a menos que você defina maintain_order ou sort explicitamente. Em nossa execução no polars 2.0.0, uma junção interna de 2.000.000 de linhas retornou as linhas fora da ordem de entrada por padrão e manteve a ordem com maintain_order definido. O lançamento também ativa o "spilling" fora do núcleo e torna as alegações de benchmark do próprio fornecedor.
Leia a edição escrita (Inglês) ↗
O que este vídeo aborda
- Chamar collect() em uma consulta "lazy" agora usa o mecanismo de streaming por padrão, que não garante a ordem das linhas para join, group_by e unpivot.
- O guia de migração diz que a ordem não é mais a ordem pré-2.0 e não é garantida; ele recomenda uma classificação explícita se você depender dela.
- Em nossa execução, uma junção interna padrão retornou ordem de entrada Falso; maintain_order="left_right" na junção retornou Verdadeiro. Uma máquina, uma execução, uma forma de junção.
- O "spilling" fora do núcleo está ativado por padrão: ele começa em cerca de 80% da RAM, com um orçamento de disco padrão de 64 GB. Junções e group_by fora do núcleo estão no roteiro.
- collect_schema() detecta uma coluna ausente antes que qualquer dado seja lido, mas um "cast" que falha em apenas um valor só falha em collect().
- A comparação TPC-H e TPC-DS é a própria execução do fornecedor em dados derivados, e sua nota de rodapé diz que os resultados não são comparáveis a benchmarks oficiais.
Transcrição traduzida
Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.
Por que a ordem padrão mudou?
0:00 Você acha que uma junção devolve suas linhas na ordem em que você as escreveu. Polars 2.0 parou de prometer isso, por padrão, de propósito. Neste vídeo: por que o padrão mudou? O que isso trouxe? E qual dos seus scripts quebra primeiro? Este é o The Daily Diff, por baixo do capô. Polars é uma biblioteca de DataFrame de código aberto: um mecanismo de tabela que você chama do Python,
0:20 com seu núcleo escrito em Rust. É gratuito sob a licença MIT, e você o instala com pip install polars. Um detalhe primeiro. A chave que traz a ordem antiga de volta é um argumento para a própria junção. Voltarei a isso no final. Desde 2.0, collect executa o mecanismo de streaming por padrão. Streaming divide a consulta em blocos que são executados em paralelo, e os blocos terminam quando terminam.
0:42 Para junção, agrupamento e "unpivot", o lançamento não promete uma ordem. Quem é atingido primeiro? Quem compara a saída a um arquivo salvo, linha por linha. Esse teste pode passar no seu laptop e falhar em uma máquina diferente. Em seguida, o guia de migração.
O que o guia de migração promete?
0:57 Ele diz que a ordem exata das linhas mostrada acima não é garantida. Portanto, se você depende da ordem, classifique explicitamente. O "out-of-core" também está ativado por padrão. Ele começa a "espalhar" para o disco em cerca de oitenta por cento da RAM, com um orçamento de sessenta e quatro gigabytes. Classificação, funções de janela e muitas expressões podem "espalhar" agora. Junções e agrupamentos estão chegando.
O benchmark é uma luta justa?
1:17 Polars diz que supera DataFusion e DuckDB nos benchmarks TPC-H e TPC-DS. Os números vêm de suas próprias execuções, em dados derivados, e sua nota de rodapé diz que não são comparáveis a resultados oficiais. Seus próprios números dizem que Polars fica cerca de 3,8 vezes mais rápido de dezesseis núcleos para cento e noventa e dois, no TPC-H. Eles também dizem que os threads extras da máquina grande diminuem as consultas pequenas.
O que vemos quando o executamos?
1:41 Executamos a mesma junção duas vezes no Polars 2.0.0. A execução padrão embaralha as linhas. Com a flag, a ordem de entrada sobrevive. Encontre as junções que alimentam um teste. Qualquer junção sem uma classificação depois dela é uma decisão de ordem de linha que você nunca tomou. Polars 2.0 é mais rigoroso com os tipos.
Mais rigoroso significa mais cedo?
1:58 A verificação de esquema detecta uma coluna ausente antes que qualquer dado seja lido. Não consegue detectar um "cast" que falha em uma linha, porque esse erro espera pelos dados. Agora o loop que abri.
Como faço para recuperar a ordem antiga?
2:08 A chave está na junção. Defina maintain_order na junção ou adicione uma classificação depois dela. O guia sugere a classificação. A flag de junção manteve a ordem em nossa execução, com a ordem do lado esquerdo mantida como esquerda, direita. Veredito, por baixo do capô: NEEDS REVIEW.
Qual é o veredito?
2:22 Eu revisaria cada junção antes de fazer o upgrade. Tem alguma pergunta sobre isso? Coloque-a nos comentários. E esse é o diff de hoje. Sou Niko da Axrisi. Faça o merge com responsabilidade.
Fontes
- Release of Polars 2.0Polars (pola.rs)
- Polars 2.0 upgrade guidePolars documentation
- Polars homepagePolars (pola.rs)
- polars-2.0-benchmark repositoryPolars on GitHub
- Release of Polars 2.0 (Hacker News discussion)Hacker News



