Biblioteca de DataFrame em Python Ibis descontinua os backends Pandas e Dask

• Os backends pandas e dask foram descontinuados e serão removidos na versão 10.0
• Não há diferença de funcionalidade entre o backend pandas e o backend DuckDB padrão, e o DuckDB oferece desempenho muito superior
• pandas DataFrame ainda pode ser usado no Ibis como formato para troca de dados, mas executar consultas usando pandas não será mais suportado
• A maior parte da lógica também se aplica ao backend dask, e o dask continua sendo um ótimo projeto que deve seguir sendo usado fora do Ibis

Por que pandas? E a história do Ibis

• No início do Ibis, existia apenas o backend Impala
• O backend Postgres foi adicionado, mas a instalação era complexa, então os usuários não conseguiam testar o Ibis com facilidade
• Era necessário um modo de experimentar a API do Ibis sem infraestrutura adicional além de um notebook
• Na época, a resposta óbvia foi conectar o backend pandas, o único engine de DataFrame em memória disponível

As dificuldades do backend Pandas

• pandas era a melhor escolha na época, mas não se encaixava bem no modelo de análise de dados do Ibis
• O backend pandas é fundamentalmente diferente dos outros backends e contém a maior quantidade de código especial
• pandas é essencialmente um engine de execução imediata, enquanto o Ibis usa um modelo de execução adiada
• Fazer a interface do pandas funcionar de forma adiada é difícil
• O backend pandas é mais lento do que os outros backends e exige milhares de linhas de código para isso
• O NaN do pandas e o NULL do Ibis são conceitos fundamentalmente diferentes, mas precisavam ser tratados como se fossem a mesma coisa
  • No pandas, o NaN era usado como marcador de valor ausente, mas isso causava problemas de compatibilidade com outros backends
  • NULL representa valor ausente, enquanto NaN representa “não é um número”; são conceitos fundamentalmente diferentes
• Os novos tipos baseados em Arrow do pandas são uma grande melhoria, mas ainda apresentam problemas

Isso causa confusão para novos usuários

• As pessoas tendem a preferir o que já conhecem
• Ao usar o Ibis pela primeira vez, é preciso escolher tanto o Ibis quanto um backend
• Novos usuários frequentemente relatam que “o Ibis é lento”
• Na maioria dos casos, isso aconteceu porque estavam usando o backend pandas
• Se tivessem usado DuckDB ou Polars, poderiam ter começado com muito mais facilidade

Equivalência de funcionalidades

• O motivo mais forte para remover o backend pandas é a redundância
• O backend DuckDB consegue consultar pandas DataFrames de forma transparente, suporta vários formatos de UDF e pode ler e gravar diversos formatos como parquet, CSV e JSON
• DuckDB é fácil de instalar, roda localmente, é muito rápido e interage bem com o ecossistema Python

Resumo do GN⁺

• Adotar o DuckDB como backend padrão parece ter sido uma decisão muito acertada. Ele é fácil de instalar, roda localmente, é muito rápido e interage bem com o ecossistema Python. Esse também era o motivo pelo qual o Ibis inicialmente adicionou o pandas como backend
• O fato de que o pandas ainda pode ser usado como formato de troca de dados é uma boa notícia para usuários atuais de pandas. Não é necessário abandonar completamente o código existente
• No entanto, deixar de usar pandas para execução de consultas parece ser a direção correta. O modelo de execução ansiosa do pandas não combina com o modelo de execução adiada do Ibis. Por isso, o backend pandas costuma ser muito mais lento do que usar pandas diretamente
• À medida que o Ibis passa a suportar cada vez mais backends, manter código ajustado para um backend específico tende a ficar cada vez mais difícil. Remover o backend pandas deve tornar a base de código mais limpa e mais fácil de manter
• Se usar o backend DuckDB consegue substituir toda a funcionalidade do pandas, não parece haver motivo para manter o backend pandas. Pelo contrário, isso pode confundir novos usuários

[yangeok]

Na prática, muita gente ainda usa bastante o pandas, que é o mais familiar mesmo,,

[GN⁺]

Comentários no Hacker News

• NaN é o resultado de 0/0 e significa que o valor existe, mas não pode ser conhecido com precisão

  • NULL significa que o valor em uma determinada posição é desconhecido
  • As implementações de NaN e NULL são diferentes, mas não são totalmente sem relação
  • None do Python é diferente de NaN e NULL

• Existem muitos mecanismos de computação melhores que o pandas

  • O pandas continua sendo usado por causa da base de código existente e das integrações com terceiros
  • Para trabalhos com poucos dados, o pandas é suficientemente adequado

• Nos últimos meses, substituí o pandas por ibis em novos projetos

  • A sintaxe do ibis é mais flexível que a do pandas
  • O encadeamento de operações torna os trechos de código mais portáveis
  • O backend do DuckDB é muito rápido
  • A comunidade é muito ativa e amigável
  • Estou divulgando o ibis para os meus colegas

• O recurso de multi-índice do pandas é o mais poderoso

  • Também pode ser usado em colunas
  • Não tenho certeza de como as novas ferramentas vão lidar com esse recurso

• Fico curioso se consideraram o Polars

  • No grupo, odeiam pandas, então usam Polars como padrão

• O pandas é extensível para novos tipos de coluna

  • Não tenho certeza se o Polars oferece suporte a isso

• O valor do Ibis não está em poder usar DuckDB

  • Mesmo que surja uma nova ferramenta, a sintaxe continua funcionando

• Nunca ouvi muito sobre o Ibis

  • Se eu sair do pandas, é menos provável que eu experimente Ibis
  • Novos frameworks estão deixando pandas/numpy para trás, mas vou esperar até que compatibilidade e casos de borda sejam resolvidos
  • Não me importo de esperar alguns milissegundos a mais

• A API de biblioteca do pandas nem sempre é intuitiva

  • Há o problema de NaN/None, mas isso é um inconveniente menor

• O motivo para usar pandas é o ecossistema integrado

  • Ao ler dados de arquivos json, arquivos csv, dict de Python etc. e visualizar com plotly, o pandas é conveniente
  • Se o Ibis for compatível com DataFrames do pandas, não me importo muito com o backend