Polars

 (pola.rs)
4 pontos por GN⁺ 2024-01-09 | 1 comentários | Compartilhar no WhatsApp
  • Biblioteca DataFrame open source voltada para ambientes que precisam de processamento rápido de dados em uma única máquina, com mais de 575 milhões de downloads e mais de 38 mil estrelas no GitHub
  • O núcleo do desempenho está no motor de consultas multithread baseado em Rust, no processamento orientado a colunas, na vetorização, em SIMD e na execução paralela
  • Continua sendo oferecida como biblioteca open source sob licença MIT, e também há o Polars Cloud, que expande workloads de produção com a mesma API
  • Promete ganhos de desempenho superiores a 30x em relação ao pandas; o benchmark derivado TPC-H foi executado em c3-highmem-22 com scale factor 10 e incluindo I/O
  • Suporta CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, os principais bancos de dados, S3 e armazenamento Azure, facilitando a integração com stacks de dados existentes

Formas de oferta do Polars

  • Polars é uma biblioteca open source para manipulação de dados e se posiciona como uma das soluções mais rápidas de processamento de dados em uma única máquina
  • Oferece uma API estruturada e tipada, buscando ao mesmo tempo expressividade e facilidade de uso
  • Os indicadores públicos atuais são os seguintes
    • Mais de 575M de downloads
    • Mais de 38k estrelas no GitHub
  • A documentação inicial pode ser consultada em Get started

  • Polars open source

    • Polars é uma biblioteca open source gratuita sob a licença MIT
    • É oferecida como uma biblioteca DataFrame de alto desempenho, com instalação simples
    • Exemplos de instalação:
      • Python: pip install polars
      • Rust: polars = { version = "x", features = ["lazy", ...]}
      • Node.js: const pl = require('nodejs-polars');

  • Polars Cloud

    • Polars Cloud é uma solução gerenciada que expande consultas Polars em ambientes de notebook para workloads de produção na nuvem ou on-premises
    • Permite escalar usando a mesma API, sem alterar o código
    • Suporta implantação em Cloud ou On-Prem
    • A cobrança ocorre apenas pela execução de consultas
    • É possível experimentar em Polars Cloud

Modelo de desempenho e integração de dados

  • A base do desempenho do Polars é o motor de consultas multithread baseado em Rust e seu design de processamento paralelo
  • A vetorização e o processamento orientado a colunas permitem algoritmos com boa localidade de cache e alto desempenho em processadores modernos
  • Foi comparado com várias soluções em um benchmark TPC-H derivado e independente, com o objetivo de reproduzir tarefas práticas de limpeza de dados
    • É possível obter ganhos de desempenho superiores a 30x em comparação com o pandas
    • O benchmark foi executado em c3-highmem-22 com scale factor 10 e incluindo I/O
    • As consultas estão disponíveis como open source
    • Mais detalhes podem ser vistos em Learn more

  • Usabilidade e otimização de execução

    • O usuário escreve consultas da forma pretendida, e o otimizador de consultas do Polars decide a forma eficiente de execução
    • Divide o trabalho entre os núcleos de CPU disponíveis e executa em paralelo sem configuração adicional nem overhead de serialização
    • Usa o modelo de memória do Apache Arrow para integração com ferramentas de dados existentes
    • O compartilhamento de dados zero-copy pode reduzir o custo de colaboração entre ferramentas
    • Projetado para operar próximo da máquina, sem dependências externas, permitindo controlar API, memória e execução
    • Conjuntos de dados maiores que a memória podem ser processados com a API de streaming, sem precisar carregar todos os dados na memória

  • Formatos de dados suportados

    • O Polars suporta leitura e escrita de formatos de dados comuns, permitindo integração com stacks de dados existentes
    • A cobertura de suporte é a seguinte
      • Text: CSV, JSON
      • Binary: Parquet, Delta Lake, AVRO, Excel
      • IPC: Feather, Arrow
      • Databases: MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
      • Cloud storage: S3, Azure Blob, Azure File

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-09
Comentários do Hacker News

  • Esta página foi claramente escrita para pessoas que já sabem o que estão vendo. Já começa falando de qualidade, não explicando a ferramenta, com algo como “Polars is written from the ground up with performance in mind”, e o resto segue a mesma linha
    Alguém pode me explicar como se eu tivesse 5 anos o que é isso e para que tipo de necessidade é uma boa solução?
    Edit: no fim entendi como uma implementação alternativa do DataFrame do Pandas. Segundo a explicação que achei no Google em https://realpython.com/pandas-dataframe/, um DataFrame é uma estrutura que contém dados bidimensionais e rótulos, muito usada em áreas intensivas em dados como ciência de dados, machine learning e computação científica, e é parecida com uma tabela SQL ou uma planilha do Excel/Calc

    • Esse é justamente um defeito irritante de muitos produtos técnicos. É natural querer falar com o público-alvo — aqui, cientistas de dados que gostam de Pandas, mas acham que ele é lento e pouco flexível —, mas para iniciantes isso passa uma sensação de exclusão
      Eu sou o público-alvo do Polars e faz meses que quero testar, mas continuo adiando. Ainda tenho certa lealdade ao Pandas porque o criador dele, Wes McKinney, escreveu este livro útil explicando ferramentas comuns de análise: https://wesmckinney.com/book/
    • É Pandas, só que rápido. Pandas é a biblioteca original open source de dataframes; é sólida e amplamente usada, mas parece ser mais ampla no escopo e mais lenta do que essa novata. A palavra “dataframe” já é um sinal claro para quem já usou isso
    • Sempre que vejo páginas assim, me sinto mais humilde. “Dataframes for the new Era”: será que eu sequer sei o que é um dataframe? Aí vejo “multithreaded query engine” e penso: isso é tipo um banco de dados?
      Aparece um gráfico comparando com pandas, modin e vaex, mas eu também não conheço nada disso, então acabo pensando que isso não é para mim. Eu gosto de ler e aprender sobre novas tecnologias e projetos, mas aqui não tem nada em que eu consiga me agarrar
      Imagino que seja assim que uma pessoa comum se sente quando eu falo das minhas bobagens de desenvolvimento web
    • Sendo justo, o título da página é “Dataframes for the new Era”, e o link Get Started logo abaixo aponta para a documentação na página do GitHub. O GitHub explica para pessoas com experiência em análise de dados o que é essa biblioteca: https://github.com/pola-rs/polars
    • Estou sendo puxado agora para a área de “dados”, e isso parece um universo paralelo com seu próprio contexto e cultura. Tem muita coisa no estilo “conecte à instância Antelope ou Meringue com a usabilidade do Nincompoop e a performance do ARSE2”
      O interessante no Polars é que ele é parecido com o Pandas, mas usa Arrow, um backend em Rust mais eficiente, e tem coisas como um planejador de consultas, que torna combinações de operações mais eficientes. Em geral, o Polars é muito mais eficiente que o Pandas, então trabalhos que antes exigiam infraestrutura complexa muitas vezes passam a rodar em uma única máquina
      É uma competição muito amigável com o principal desenvolvedor do Pandas, e, pelo que parece, todo mundo gosta disso e há uma boa chance de ele substituir o Pandas com o tempo

  • Posts relacionados:
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - agosto de 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - agosto de 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - janeiro de 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - janeiro de 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - janeiro de 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - dezembro de 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - dezembro de 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - julho de 2020

  • Usei Pandas por alguns anos, mas sempre parecia que eu estava empurrando uma bola morro acima. Até em tarefas simples como joins isso aparecia, e também não dava para esquecer de redefinir o índice
    O Polars parece melhor que o Pandas em quase tudo. É mais rápido, usa múltiplos núcleos, consome menos memória e a API é mais intuitiva. Ainda é uma biblioteca relativamente jovem, então tem desvantagens, mas em um projeto novo pelo menos vale a pena considerar
    Também é excelente poder aproveitar facilmente o ecossistema Rust. Usei plugins diretamente para paralelizar funções e deixei parte de um código geoespacial 100 vezes mais rápido

    • É um pouco irônico usar joins como exemplo. Sempre achei que o maior problema do Pandas era a documentação. Por exemplo, você sabia que existe uma forma de fazer join de dataframes sem usar índices? O nome não é “join”, é merge
      No começo, o Pandas foi fortemente influenciado pela terminologia e pelos padrões de uso do R, e no R “merge” já era um termo comum para “join”. Se você começou a aprender Pandas por volta de 2015 sem já conhecer R, imagino que não tenha sido fácil pegar o jeito rápido
    • Fico curioso para saber o que acham de PRQL(prql-lang.org). Pessoalmente, vejo isso como uma forma de combinar a usabilidade e a experiência de desenvolvimento do Polars ou Pandas com o poder e a universalidade do SQL
      As consultas podem rodar não só em Polars e Pandas, mas também no mecanismo de execução compatível com SQL que você quiser, como DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite etc.
      A sintaxe e a semântica de joins são uma das partes mais complicadas, então isso voltou a ser discutido recentemente. É o núcleo da álgebra relacional e também do R em PRQL. A maioria das transformações básicas do PRQL é uma manipulação simples de listas, como map, filter e reduce, mas joins exigem cuidado para preservar a composição monádica. Deixei algumas ideias aqui: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      Essa issue foi fechada, mas seria ótimo se alguém abrisse uma nova ou marcasse @snth para compartilhar opiniões. Para contextualizar, sou contribuidor do PRQL
    • Fico curioso sobre o que exatamente é difícil na fusão de dataframes no Pandas

  • Quando avaliei, a maior vantagem foi que a API parecia muito mais consistente e fácil de entender do que a do Pandas. Também, com 20 grandes versões do Pandas, era de se esperar
    Só que, por ser bem menos usado, o Copilot não conseguia escrever bem código em Polars. Então por enquanto continuo usando Pandas com Copilot. Foi a primeira vez que senti esse tipo de barreira com uma biblioteca nova no geral

    • Acho que é a primeira vez que vejo alguém dizer publicamente que prefere uma biblioteca por causa do suporte do Copilot. Não estou julgando, só achei interessante
      Ainda assim, o Copilot aprende muito rápido dentro do repositório. Eu uso uma stack extremamente customizada com TS-Plus, um fork de TypeScript que nem o próprio autor usa ou recomenda, e o Copilot consegue gerar um código de TS-Plus bem decente
      Depois de ver alguns exemplos, eu não subestimaria como o Copilot pode ficar bem bom na fase de código repetitivo
    • O suporte do Copilot é um problema de ovo e galinha. Ele precisa treinar com o código de outras pessoas, mas se ninguém escrever código em Polars sem o Copilot, o Copilot também não vai ficar melhor em escrever código em Polars
    • Senti algo parecido ao usar o danfo.js, outra biblioteca de dataframes para js. O Copilot simplesmente alucinava funções e nomes de métodos
      Não era um grande problema porque bastava ler a documentação, mas era irritante ele não conseguir cuspir de imediato o que eu precisava
    • Você reconhece que a API é mais consistente e fácil de entender, mas mesmo assim vai ficar no Pandas só porque o Copilot facilita mais? Para você, e também para a inovação em código aberto, é melhor usar a ferramenta que você mesmo admite ser melhor
      Uso a API do Pandas há muito tempo e sempre detestei. Sou o tipo de pessoa que é bem ativo em continuar melhorando aprendizado, ferramentas, forma de pensar e habilidades
    • A biblioteca Polars muda rápido. Não uso Copilot, mas consegui resultados bem bons com o ChatGPT ao incluir no prompt do sistema informações atualizadas, como por exemplo que with_column virou with_columns, e acrescentar também conteúdo da documentação

  • Quando o suporte a Jupyter foi lançado no Deno, nodejs-polars era uma das bibliotecas centrais de ciência de dados com suporte
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    Pessoalmente não sou da área de ciência de dados, mas considerando que o ecossistema JS/Jupyter ainda está no começo, foi surpreendentemente rápido colocar análises baseadas em pola.rs para rodar em TypeScript
    As bindings de JS claramente ainda têm pontos a melhorar, mas espero que haja iterações e melhorias conforme a acessibilidade aumenta

    • Eu sempre quis algo tipo Pandas em JS, bom saber disso agora

  • O Polars é realmente promissor e o desempenho é impressionante, mas me incomoda comparar vaex, modin e dask todos no mesmo benchmark
    Todas essas bibliotecas são voltadas para processamento de dados fora da memória principal, ou seja, para quando os dados são grandes demais e o cálculo precisa ser distribuído em várias máquinas. Compará-las com uma biblioteca de dataframe para máquina única é estranho, e inevitavelmente elas terão mais overhead, então vão acabar sendo mais lentas
    Eu raramente usaria Polars no mesmo contexto dessas bibliotecas, então é meio engraçado vê-las no benchmark como se fossem equivalentes. Além disso, DuckDB, que pode ser usado no mesmo contexto que Polars e em muitos casos é mais rápido, nem aparece no benchmark
    A engenharia de software do Polars é excelente, e ele não precisa desses benchmarks potencialmente enganosos

    • Não sei quanto às outras, mas o Dask pode ser usado em uma única máquina, e essa é inclusive a forma mais fácil de usá-lo. Ele divide o dataframe em partições e paraleliza as operações processando cada uma em um núcleo
      Dá para obter um ganho de 2 vezes sobre o Pandas sem nenhuma configuração, e em certas operações já vi chegar a 5 vezes
    • Ibis, o dataframe em Python criado pelo fundador do Pandas, usa DuckDB como backend padrão e, tirando algumas exceções de consulta, normalmente vence o Polars nesses benchmarks

  • Não uso o Polars diretamente, mas o utilizo como formato de materialização em fluxos de trabalho com DuckDB
    duckdb.query(sql).pl() é muito mais rápido que duckdb.query(sql).df(). Com Polars, por ser zero-copy, termina praticamente na hora, enquanto no Pandas, se o DataFrame for grande, pode demorar bastante. E dá para manipular como um DataFrame do Pandas, só que com uma sintaxe um pouco diferente
    É muito bom para lidar com conjuntos de dados grandes

  • Parece que deveria existir um corolário para a décima lei de Greenspun(https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)): algo como toda biblioteca de análise de dados suficientemente complexa acaba implementando metade do SQL de forma improvisada, com especificação informal, cheia de bugs e lenta
    Eu uso Pandas de vez em quando e provavelmente também usaria isso, mas sempre penso que teria sido melhor simplesmente colocar os dados em Postgres desde o início
    Não sou especialista em banco de dados e Python é bem mais confortável para mim, mas para selecionar, ordenar, filtrar e fazer joins em dados tabulares, SQL é muito melhor

    • Recomendo dar uma olhada no DuckDB e na extensão duckdb-prql
      O DuckDB permite consultar diretamente em SQL dados em formato Polars, Pandas e Arrow, sem copiar nem duplicar os dados
      O duckdb-prql permite usar PRQL(prql-lang.org) e, pessoalmente, acho que ele combina o poder e a universalidade do SQL com a usabilidade e a experiência de desenvolvimento de Polars ou Pandas. Para constar, sou contribuidor do PRQL
    • Dá para fazer assim, mas se forem consultas “analíticas”, o desempenho provavelmente será bem pior e a flexibilidade e expressividade também tendem a cair
      Em vez disso, vale olhar o DuckDB. A implementação de SQL dele não é improvisada, nem cheia de bugs, nem lenta, nem incompleta. Não sei dizer o quão formal é a especificação, mas ele é compatível com Polars
    • Pessoalmente, acho a sintaxe de lazy dataframe muito superior como frontend para um motor de consultas. O Polars também suporta SQL, mas os bugs normalmente não aparecem no frontend, e sim no motor de consultas
      Para os tipos de consulta feitos nesses motores, o Postgres deve ser uma ordem de grandeza mais lento do que um motor de consultas OLAP
    • O criador do Pandas fez o Ibis com backend Postgres por esse motivo: https://ibis-project.org/backends/postgresql
      É uma abordagem melhor para usar DataFrames em Python junto com SQL

  • Há alguns meses, tentei migrar uma grande base de código em Pandas para Polars. Não gosto muito de fazer análise ou data pipelining em Python, e transformações complexas levam 2 a 5 vezes mais tempo no Pandas do que em Julia ou R(usando dataframes.jl, dplyr)
    Infelizmente, o Polars também não foi a resposta. Havia bugs demais em operações padrão, e a interoperabilidade com Pandas era instável. Isso é um problema porque muitas bibliotecas exigem um DataFrame do Pandas como entrada. A API também é muito verbosa para uma biblioteca moderna de DataFrames, embora ainda seja melhor que Pandas
    Espero que isso melhore com o tempo, mas por enquanto o melhor resultado foi usar DuckDB por cima do Pandas. É tão rápido quanto Polars, mas mais estável e com melhor interoperabilidade
    Espero que algum dia o ecossistema de DataFrames em Python chegue ao ponto do R, em que seja fácil usar juntos tanto uma biblioteca de DataFrames voltada para análise com API intuitiva (dplyr) quanto uma biblioteca de DataFrames de alto desempenho (data.table)

    • Também me incomodei com a verbosidade. O Pandas já é bastante verboso em comparação com algo como data.table, mas o Polars passa mais a sensação de usar uma API do que uma “ferramenta de manipulação de dados”
      Provavelmente eu não usaria para análise exploratória de dados ou pesquisa, mas comecei a usá-lo em alguns scripts de produção por causa do desempenho melhor
      A combinação dplyr + data.table no R ainda é a experiência de manipulação de dados de que mais gosto. Só queria que o R tivesse algo como Matplotlib. O ggplot é nível muito alto e os gráficos básicos são nível muito baixo. O Scikit-Learn também é muito mais modular do que o Caret, então não sinto falta do Caret
    • Fico curioso para saber como você vê o PRQL(prql-lang.org). Ele busca oferecer a usabilidade do dplyr em qualquer lugar onde se use SQL, e compila para SQL
      Pessoalmente, acho que ele combina a experiência de desenvolvimento de dplyr, Polars e Pandas com o poder e a universalidade do SQL. As consultas podem rodar no mecanismo de execução compatível com SQL que você quiser, não só Polars e Pandas, mas também DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite etc.
      Gostaria de ouvir sua opinião nas discussões do GitHub(https://github.com/PRQL/prql/discussions) ou no Discord(https://discord.com/invite/XWxbCrWr). Para constar, sou contribuidor do PRQL
    • Legal ver alguém com experiência usando DataFrames em R, Python e Julia. De qual deles você gosta mais? Os ecossistemas talvez não sejam comparáveis diretamente, mas em termos de tarefas como operações centrais, qual foi o melhor?
    • O Ibis com backend DuckDB também vale uma tentativa. Pessoalmente, também gosto bastante do Polars. Os desenvolvedores, no geral, respondem às issues bem rápido

  • Nossa equipe de ciência de dados avaliou o Polars, mas os resultados foram mistos. Se houver trechos em que desempenho seja crucial, consideraríamos adotá-lo, mas fora isso a visão foi um pouco negativa por causa do custo de substituir o Pandas em dezenas de projetos

    • Acho que essa avaliação faz sentido. Neste momento, parece mais uma hora de experimentar do que de substituir um Pandas que já funciona bem
      A API ainda tem mudanças incompatíveis previsíveis e, ao atravessar vários projetos, isso pode virar um peso de manutenção. Ainda assim, a API já parece mais consistente, e no geral dá a impressão de estar seguindo na direção certa
    • Não é uma boa ideia reescrever todo o código. Mas em código novo vale a pena adotar ou pelo menos avaliar
      Especialmente porque o custo de interoperabilidade com o Pandas é muito baixo e, usando o backend Arrow, a conversão para Pandas com zero-copy também é bem fácil
    • No futuro, há também o https://github.com/fugue-project/fugue
    • Fico curioso para saber se a equipe usa pandasql ou se trabalha principalmente direto com a API do Pandas