Polars 2.0 promete ser 5× mais rápido... então, o que mudou?

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Polars 2.0 Says 5× Faster… So What’s Changed? · Canal: Better Stack · 08:16 · Assistir no YouTube

Tópicos: Dados, bancos de dados e embeddings, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Polars 2.0 troca o mecanismo padrão de execução pelo mecanismo streaming, o que pode acelerar consultas sem exigir mudanças no código. Como consequência, operações como joins e agrupamentos deixam de garantir a ordem original das linhas, a menos que isso seja solicitado explicitamente. A versão também remove ou renomeia APIs antigas e melhora mensagens de erro, mas ainda é uma release candidate, e o ganho de 5× é uma expectativa da equipe, não um resultado acompanhado de uma tabela de benchmark. O vídeo recomenda experimentar a versão em projetos novos, mas esperar em casos sensíveis à ordem das linhas ou que usem group_by_dynamic.

Pontos-chave

O mecanismo streaming passa a ser o padrão e processa os dados em partes, em vez de carregar o conjunto inteiro na memória.
Joins, agrupamentos e outras operações não garantem mais a ordem das linhas por padrão; quando ela importa, é necessário solicitá-la explicitamente.
O streaming ainda não oferece execução out of core: o processamento em partes não significa que conjuntos maiores que a RAM possam ser tratados automaticamente.
A alegação de que o novo mecanismo é 5× mais rápido é uma expectativa da equipe; o vídeo não identifica uma tabela de benchmark que comprove esse número.
A versão remove ou renomeia APIs antigas, como melt, substituído por unpivot, e read_csv, substituído pelo uso de scan_csv seguido de collect.
As mensagens de erro indicam alternativas para APIs removidas, ajudando a atualizar o código.
A release candidate ainda tem bugs conhecidos, incluindo um problema em group_by_dynamic no mecanismo streaming.
O vídeo sugere adotar a versão em projetos novos, mas esperar se o código depender da ordem das linhas ou usar group_by_dynamic.

Capítulos

Início	Capítulo	Resumo
00:00	O que muda no Polars 2.0	O vídeo apresenta a mudança para o mecanismo streaming e a remoção da garantia padrão de ordem das linhas.
02:04	Ordem das linhas e APIs removidas	Uma demonstração mostra como preservar a ordem e explica as principais renomeações e remoções de APIs.
04:40	Desempenho e limites do streaming	O vídeo compara o Polars com outras ferramentas e contextualiza a promessa de 5× mais velocidade e a ausência de execução out of core.
06:44	Problemas da release candidate e recomendação de upgrade	O vídeo cita bugs ainda presentes, explica quando esperar antes de atualizar e conclui que a versão reorganiza a base sem adicionar novos recursos.

Citações

Você não muda uma linha. Mas o Polars também deixa de prometer que suas linhas voltarão na ordem em que você as forneceu. — 00:00

O mesmo código. A ordem não é mais garantida. — 02:34

O novo mecanismo streaming é facilmente cinco vezes mais rápido. — 05:11

Streaming significa processamento em partes e em pipeline. Ainda não significa que seu conjunto de dados possa ser maior que a RAM. — 05:41

O Polars está usando uma grande mudança de versão para realmente limpar a base por baixo de tudo o que já usamos. — 08:16

Conceitos e entidades

Polars (ferramenta): Biblioteca de processamento de dados que oferece uma API de expressões para Python e tem foco em execução em uma única máquina.
pandas (ferramenta): Biblioteca de Python usada amplamente para análise e manipulação de dados, apresentada como referência de comparação para Polars.
streaming engine (conceito): Mecanismo do Polars que processa dados em partes encadeadas, em vez de carregar todo o conjunto de dados de uma vez.
in-memory engine (conceito): Mecanismo do Polars que carrega o conjunto de dados inteiro na memória para executar as etapas da consulta.
DuckDB (ferramenta): Banco de dados descrito no vídeo como uma opção com foco em SQL.
Dask (ferramenta): Ferramenta de computação distribuída citada como alternativa ao Polars.
Spark (ferramenta): Ferramenta de computação distribuída citada como alternativa ao Polars.
Python (conceito): Linguagem para a qual o Polars oferece uma API de expressões e que o vídeo apresenta como a opção mais comum entre seus usuários.
Rust (conceito): Linguagem cuja crate do Polars, segundo o vídeo, ainda estava na versão 0.55 durante a release candidate.
Better Stack (empresa): Canal responsável pelo vídeo sobre as mudanças do Polars 2.0.

Tradução completa (pt-BR)

00:00 A maior concorrente do pandas está prestes a lançar a versão 2.0. A atualização do Polars está quase chegando, e a maior mudança provavelmente não é a que você esperaria. Por padrão, todas as consultas que você já escreveu passam a usar um mecanismo diferente. Você não muda uma linha sequer. O Polars também deixa de prometer que as linhas voltarão na mesma ordem em que você as forneceu. Isso parece uma regressão, mas não é. É o preço para tornar possível a primeira mudança. Com o Polars ganhando mais força na versão 2.0, saiba que ele está dando trabalho ao pandas. Vamos dar uma

00:30 olhada na maior atualização até agora. Certo. Desde o começo, o pandas sempre foi a escolha preferida para a maioria das tarefas com dados. É simples. É usado por muita gente. Não funciona apenas muito bem para análise de dados, mas também é fundamental em machine learning. Então, há algum tempo, surgiu o Polars. Ele sempre foi mais rápido que o pandas. Vamos falar disso agora. Com esta grande atualização 2.0, talvez ele esteja chegando mais perto de ser adotado por mais pessoas. Agora que você conhece rapidamente a história,

01:02 o Polars vem mantendo discretamente dois mecanismos há algum tempo. O que a maioria das pessoas tem usado é o mecanismo em memória. Você pode pensar nele como um armazém. Ele carrega todo o seu conjunto de dados para o espaço de armazenamento. Depois, o armazém executa cada etapa da consulta sobre todo esse espaço. E isso é extremamente rápido, desde que tudo caiba na RAM. O mecanismo de streaming funciona de outra maneira. Em vez de um enorme espaço de armazenamento, ele é mais ou menos como uma linha de montagem. O Polars divide os dados em pequenas partes, que os mantenedores chamam de morsels. Essas partes são dimensionadas

01:34 para caber no cache da CPU. Depois, elas passam pelo plano da consulta. Assim, diferentes partes da consulta podem continuar avançando, em vez de esperar pelo conjunto de dados inteiro. É daí que vem a velocidade e, mais adiante, esse também é o caminho para trabalhar com dados maiores que a memória disponível. Mas há um porém. Se você tem oito trabalhadores numa linha de montagem, eles não necessariamente terminam na mesma ordem em que começaram; com o Polars acontece o mesmo. Então, na versão 2.0, joins, group-bys, unpivots — a documentação literalmente diz “etc.” —

02:04 já não garantem a ordem das linhas, a menos que você a solicite explicitamente. Se você gosta de ferramentas de programação que aceleram seu workflow, não deixe de se inscrever. Temos vídeos novos o tempo todo. Certo, então veja como isso fica na prática. Vou executar uv pip install --pre polars. E lembre-se daquela flag --pre; já voltaremos a ela daqui a pouco. Certo, tenho um lazy frame com as chaves 2, 1, 1, 0. Faço um left join com outro frame. Depois, chamo collect. E veja o resultado. O mesmo código da

02:34 versão 1 do Polars. A ordem já não é garantida. O mesmo código, só está se comportando de maneira diferente. Agora adiciono `maintain_order=

03:06 mudança. Mas a versão 2.0 é estranha porque não é realmente um lançamento de recursos. Na verdade, é só uma limpeza. E há bastante coisa sendo limpa aqui. Originalmente, o Polars tinha pandas. O read_csv agora é apenas scan_csv seguido de collect, por baixo dos panos. O profile do lazy frame foi removido. Melt agora se chama unpivot. Join nulls agora se chama nulls_equal. A conversão direta de um inteiro para categorical foi removida. Agora você pode usar cat 2 para ajudar

03:37 com isso. A conversão direta de uma string para uma data foi removida. Isso é string para date. Ao somar um inteiro com sinal de 64 bits a um inteiro sem sinal de 64 bits, o Polars agora retorna int 128 em vez de transformar o resultado em float e perder precisão silenciosamente. E há ainda mais por vir. Você pode usar concat, que agora se recusa a aceitar alturas incompatíveis, em vez de tentar adivinhar o que você quis dizer. Na verdade, essa é uma escolha inteligente por parte do Polars. Cada item removido gera um erro de atributo

04:08 que informa o que o substituiu. Chame melt e o erro literalmente diz para usar unpivot com index e on. Todos esses erros acabam virando, mais ou menos, um guia de como usar a ferramenta. Execute o código, quebre alguma coisa, corrija exatamente o que quebrou com base no erro e continue. E isso nos leva ao motivo pelo qual o Polars se tornou uma ferramenta usada diariamente por tantas pessoas. O pandas deixa muitos problemas para serem resolvidos em tempo de execução. O Polars tenta detectá-los cedo com tudo isso. Assim, você pode chamar collect_schema e

04:40 descobrir que os tipos estão errados antes de o Polars ler uma única linha. Ele simplesmente antecipa o que está prestes a acontecer e está ficando cada vez mais eficiente. Então, onde o Polars se encaixa? Bem, o DuckDB prioriza SQL. O Polars tem uma API de expressões feita para Python. Também há o Dask e o Spark. Eles são distribuídos. O Polars é focado em uma única máquina. A biblioteca open source em si é open source. O Polars Cloud, não. E esse ponto importante muda as coisas quando chegamos ao desempenho. Agora, este anúncio diz que o novo mecanismo de streaming

05:11 é facilmente cinco vezes mais rápido. Agora, já experimentei o Polars ao longo dos anos e, sim, ele é mais rápido que o pandas, mas nunca consegui velocidades absurdas, como cinco vezes mais rápido. Experimente com conjuntos de dados maiores. Você definitivamente vai notar uma diferença de velocidade. Ela vai variar a cada execução e de acordo com cada conjunto de dados, mas você vai sentir a diferença e realmente vê-la no tempo de execução. E esta é provavelmente a distinção mais importante de todo o lançamento. A parte que permitiria ao mecanismo gravar dados em disco — a execução verdadeiramente out-of-core — ainda não foi lançada. Então, hoje, streaming significa

05:41 processamento em blocos e em pipeline. Ainda não significa que seu conjunto de dados possa ser magicamente maior que a RAM. O número de 5× é uma expectativa do próprio Polars. Não há nenhuma tabela de benchmark na publicação. E, sinceramente, a maioria das pessoas parece estar satisfeita com isso. Muitos usuários pareceram felizes com um lançamento útil, mas sem grandes novidades. Não há um enorme pacote de recursos. Você não precisa realmente aprender nada novo. Enquanto você programa, esses erros vão dizer o que usar no lugar. É só uma limpeza que quebra algumas coisas e faz com que o Polars seja usado da maneira como deveria.

06:12 Mas duas reclamações aparecem repetidamente. A primeira é a ordem das linhas. Se maintain_order tem false como padrão, você pode criar bugs bem desagradáveis no código porque nada falha. Seus números ainda podem estar completamente corretos. Só que ficam associados às linhas em uma ordem diferente. Isso é bem mais difícil de perceber do que uma exceção. A segunda reclamação foi o uso da palavra streaming aqui. As pessoas argumentaram que ela é confusa para um mecanismo que ainda não é verdadeiramente out-of-core. Depois, há bugs reais na release candidate. Desde que a RC foi lançada, há um problema de alta prioridade em que group_by_dynamic gera um erro de datetime fora do intervalo no mecanismo de streaming. Chamar o método limit, embora limit não esteja encerrando a execução antecipadamente depois de um join, e string para datetime pode retornar null onde antes simplesmente gerava erros. Por isso eu disse para você se lembrar do comando de instalação pré-2.0. Isso ainda é uma release candidate e, neste momento, se comporta como uma — o que é normal, certo? Ainda não é a versão completa. Mais uma coisa: o crate de Rust ainda está na versão

06:44 0.55. Então, se você usa Polars com Rust, ainda não existe Polars 2.0 para você. Mas vou presumir que a maioria de nós provavelmente vai usar Python. Agora, você deveria atualizar? Bem, para um projeto novo, sim, eu atualizaria. Estamos adotando novas tecnologias e novas atualizações. Se o seu pipeline já usa sink_parquet ou sink_csv, você já vem usando streaming há todo esse tempo. Mas há alguns casos de uso em que eu simplesmente esperaria, certo? Se o seu código depende da ordem das linhas, não atualize e fique na esperança. Procure por group bys que não

07:14 tenham um sort depois deles. Se você usa group_by_dynamic, eu simplesmente esperaria até tudo isso se estabilizar. E é interessante ver para onde isso provavelmente está indo. Provavelmente será a versão 2.0, mas ainda não é o lançamento oficial. Você pode começar a se familiarizar com ela, mas ainda não está totalmente pronta. O que não para de me chamar a atenção é como este lançamento é incomum. O Polars 2.0 não traz nenhum recurso novo e, ainda assim, muda o comportamento do seu código existente. O novo mecanismo é mais rápido na minha máquina, só não é cinco vezes mais rápido. Então, a versão 2.0 não é empolgante

07:46 tenham uma ordenação depois deles. Se você estiver usando group_by_dynamic, eu simplesmente esperaria tudo isso se estabilizar. E, quero dizer, é legal ver para onde isso provavelmente está indo. Provavelmente será a versão 2.0, mas ainda não é o lançamento oficial. Você pode começar a se familiarizar com ela, mas ainda não está pronta. O que sempre me chama a atenção é como este lançamento parece incomum. Polars 2.0 não traz nenhum recurso novo e, ainda assim, muda o comportamento do seu código existente. O novo engine é mais rápido na minha máquina, só não é cinco vezes mais rápido. Então, a versão 2.0.0 não é empolgante

08:16 porque adiciona um monte de coisas novas. É empolgante porque o Polars está aproveitando uma grande mudança de versão para simplesmente limpar a base de tudo que já estamos usando. Eu sou Josh, da Better Stack. Se você gosta de dicas e truques de programação como este, não deixe de se inscrever. A gente se vê em outro

Transcrição original

[00:00] The biggest competitor to Pandis is about to drop version 2.0. The Polar update is almost here, and the biggest change is probably not the one you’d expect. By default, every query you’ve already written moves onto a different engine. You don’t change a line. Polar also stops promising that your rows come back in the order you gave them. That sounds like regression, though it isn’t. It’s the price of making the first change possible. As Polers gains more traction with 2.0, know it’s giving pandas a run for its money. Let’s take a

[00:30] look at the biggest update yet. All right. Now, from the start of time, pandas has always been the go-to for most data work. It’s simple. It’s used by the masses. Not only works great for data analytics, but it’s also key in machine learning as well. Then a while back came Polus. It’s always been faster than pandas. We’ll talk about that now. With this major 2.0 0 update. It may just be getting closer to more adoption. Since you got the quick backstory,

[01:02] Polers has quietly had two engines for a while. The one most people have been using is the in-memory engine. You can think of that as like a warehouse. It loads your entire data set onto the floor. The warehouse then runs each step of the query across the whole floor. And that is extremely fast as long as everything fits in RAM. The streaming engine works differently. Instead of one giant floor, it’s more or less like an assembly line. Now, Polers chops the data into small pieces the maintainers call more cells. Those pieces are sized

[01:34] to fit in your CPU cache. Then they’re pushed through the query plan. Now, different parts of the query can keep moving instead of waiting on the whole data set. That’s where the speed comes from, and eventually it’s also the path toward working with data larger than your memory. But there’s a catch. If you have eight workers on an assembly line, they don’t necessarily finish in the same order they started and neither does polers. So in 2.0, joins, group buys, unpivots, the docs literally say, etc.

[02:04] No longer guarantee row order unless you explicitly ask for it. If you enjoy coding tools to speed up your workflow, be sure to subscribe. We have videos coming out all the time. Right, so here’s what this actually looks like. I’m going to UV pip install pre-polar. And remember that pre flag, we’re going to circle back to that in a second. Okay, I’ve got a lazy frame with the keys 2110. I left join it to another frame. Then collect. And look at the result. Same code as

[02:34] polar one. Order is no longer guaranteed. Same code. It’s just acting different. Now I add maintain order equals left to the join. I can execute it again. I’ll run it here again. And the original order is back. So this isn’t polar randomly shuffling around our data. It’s polar saying if order matters, you tell it. You have to actually tell it. And there’s another nice detail here. Run the explain function on a query. It’s not hiding the behavior. You just have to know to look for it. That’s the big behavioral

[03:06] change. But 2.0 is strange because this isn’t really a feature release. It’s actually just a cleanup. And there’s a decent amount being cleaned up here. Originally pandas polars. I have read CSV which is now just scan CSV collect underneath that lazy frame profile is gone. Melt now becomes unpivot. Join nils becomes nils equal. Casting an integer directly to categorical is removed. You can use cat 2 now to help

[03:37] with this. Casting a string directly to a date has been removed. That’s string to date. Add a signed and unsigned 64-bit integer together and Polers now gives you int 128 instead of turning it into a float and silently losing more precision. And there’s even more coming. You can add concat that now refuses mismatched heights instead of trying to guess what you meant. This is actually a smart choice on Polar’s part. Every removed thing throws an attribute

[04:08] removed air that tells you what replaced it. call melt and the error literally tells you to use unpivot with index and on all these errors more or less become the guide on how to actually use it. Run the code, break something, fix exactly that break based on the error and just keep going. And that gets to the reason Polers has become a daily driver for so many in the first place. Pandis pushes a lot of problems to runtime. Polers tries to catch them early through all this. So you can call collect schema and you can

[04:40] find out the types are wrong before polers reads a single row. It’s just anticipating what’s about to come and it’s becoming more and more efficient. So where does polus actually fit? Well, duck db is SQL first. Pol is an expression API built for Python. There’s also dask and spark. Those are distributed. Pol is focused on one machine. The open source library itself is open source. The polar cloud is not. And that key thing changes things once we get to performance. Now, this announcement says the new streaming

[05:11] engine is easily five times faster. Now, I’ve played around with Polars over the years, and yeah, it it is faster than Pandas, but I’ve never gotten any crazy speeds like five times faster. Try it out on some larger data sets. You will definitely see a speed difference. It’ll vary each run and with each data set, but you’re going to feel the difference and actually see it in runtime. And this is probably the most important distinction in the whole release. The part that would let the engine spill to disk, true out of core execution, hasn’t landed yet. So today, streaming means

[05:41] chunked and pipeline. It does not yet mean your data set can magically be bigger than RAM. The 5x number is Polus’s own expectation. There’s no benchmark table in the post anywhere. And honestly, most people seem to be fine with that. A lot of users seemed happy with a useful yet boring release. There’s no giant feature dump. You don’t really have to learn anything new. those errors as you’re coding, they’re going to tell you what to replace it with. Just breaking cleanup and sever being used the way it’s supposed to be used.

[06:12] But two complaints keep coming up repeatedly. The first is row order. If maintain order defaults to false, you can create some nasty bugs in the code because nothing crashes. Your numbers can still be completed correct. They’re just attached to rows in a different order. That’s much harder to notice than an exception. The second complaint was the word streaming here. People argued that it’s confusing for an engine that still isn’t truly out of core. Then there are actual release candidate bugs. Since the RC landed, there’s been a p

[06:44] high issue where group by dynamic throws a daytime out of range air on the streaming engine. call the limit method while limit isn’t early exiting after join and string to date time can return nil where it used to just raise errors which is why I told you to remember the install command pre pre 2.0 this is still a release candidate and right now it behaves like one which is fine right it’s not the full version yet one more thing the rust crate is still version

[07:14] 0.55 so if you’re using polers from rust there’s no polars 2.0 know for you yet, but I’m going to assume that most of us are probably just going to be using Python here. Now, should you upgrade? Well, for a new project, yeah, I’d do it right. We are adapting to new technologies, new updates. If your pipeline already uses sync paret or sync CSV, you’ve effectively been using streaming this whole time anyways. But there are a few use cases where I just wait, right? If your code depends on that row order, just don’t upgrade and hope. Go grap for group buys that don’t

[07:46] have a sort after them. If you’re using group eye dynamic, I’d just wait for all this to settle down. And I mean, this is cool to see where this most likely is going. This probably will be 2.0, but it’s not the official release yet. You could get warmed up with it, but it’s not quite there. The thing I keep coming back to is how unusual this release feels. Polar 2.0 ships zero new features, and it still changes what your existing code does. The new engine is faster on my machine, just not five times faster. So, 2.0 0 isn’t exciting

[08:16] because it adds a bunch of new stuff. It’s exciting because Polers is using a major version bump to really just clean up the foundation underneath everything that we’re already using. I’m Josh from Better Stack. If you enjoy coding tips and tricks like this, be sure to subscribe. We’ll see you in another