Os pandas agora são mais rápidos que o data.table?

15

https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping

Os benchmarks data.table não são atualizados desde 2014. Ouvi dizer que Pandasagora é mais rápido do que data.table. Isso é verdade? Alguém já fez benchmarks? Eu nunca usei Python antes, mas consideraria mudar se pandaspode vencer data.table?

— xiaodai
fonte

7

Essa é uma péssima razão para mudar para python.

— Matthew Drury

2

@MatthewDrury como assim? Os dados e a manipulação deles são 80% do meu trabalho. Apenas 20% é para montagem de modelos e apresentação. Por que não escolher aquele que me fornece os resultados mais rapidamente?

— Xiaodai # 25/17

2

Tanto python quanto R são linguagens estabelecidas com enormes ecossistemas e comunidades. Reduzir a escolha para uma única biblioteca é adorar uma única árvore em uma vasta floresta. Mesmo assim, a eficiência é apenas uma preocupação entre muitos, mesmo para uma única biblioteca (quão expressiva é a interface, como ela se conecta a outra biblioteca, quão extensível é a base de código, quão abertos são seus desenvolvedores). Eu argumentaria que a própria escolha é uma falsa dicotomia; ambas as comunidades têm um foco diferente, o que confere aos idiomas pontos fortes diferentes.

— Matthew Drury

3

você tem uma floresta enorme que é boa para 20% do trabalho? então não faça uma escolha que afete 80% do seu trabalho? nada me impede de usar o panda para fazer a preparação de dados e depois modelar em R python ou Julia. Eu acho que meu pensamento é sólido. se o panda for mais rápido do que eu devo escolher como minha principal ferramenta.

— Xiaodai 25/10

1

Você pode encontrar o pacote reticulado em R de interesse / uso. Além disso, cada vez mais esforços têm sido feitos para que o R trabalhe / brinque com bancos de dados (consulte esforços como o dbplyr ).

— slackline

13

Um colega e eu conduzimos alguns estudos preliminares sobre as diferenças de desempenho entre os pandas e a tabela de dados. Você pode encontrar o estudo (dividido em duas partes) em nosso Blog (você pode encontrar a parte dois aqui ).

Concluímos que há algumas tarefas em que os pandas superam claramente o data.table, mas também os casos em que o data.table é muito mais rápido. Você pode conferir e informar o que acha dos resultados.

EDIT:
Se você não quiser ler os blogs em detalhes, aqui está um breve resumo de nossa configuração e nossas descobertas:

Configuração

Comparamos pandase data.tableem 12 diferentes conjuntos de dados simulados nas seguintes operações (até agora), que chamamos de cenários.

Recuperação de dados com uma operação de seleção seletiva
Filtragem de dados com uma operação de seleção condicional
Operações de classificação de dados
Operações de agregação de dados

Os cálculos foram realizados em uma máquina com Intel i7 de 2,2 GHz com 4 núcleos físicos, 16 GB de RAM e um disco rígido SSD. As versões de software eram OS X 10.13.3, Python 3.6.4 e R 3.4.2. As respectivas versões de bibliotecas utilizadas foram 0,22 para pandas e 1.10.4-3 para data.table

Resultados em poucas palavras

data.tableparece ser mais rápido ao selecionar colunas ( pandasem média, leva 50% mais tempo)
pandas é mais rápido na filtragem de linhas (aproximadamente 50% em média)
data.tableparece ser consideravelmente mais rápido na classificação ( pandasàs vezes é 100 vezes mais lento)
adicionar uma nova coluna aparece mais rápido com pandas
resultados agregados são completamente misturados

Observe que tentei simplificar o máximo possível os resultados para não aborrecê-lo até a morte. Para uma visualização mais completa, leia os estudos. Se você não conseguir acessar nossa página, envie-me uma mensagem e eu encaminharemos nosso conteúdo. Você pode encontrar o código para o estudo completo no GitHub . Se você tem idéias de como melhorar nosso estudo, envie um e-mail para nós. Você pode encontrar nossos contatos no GitHub.

— Tobias Krabel
fonte

1

Como você pode ter lido da minha resposta, eu já digo que os resultados são mistos. Esclareça se devo ser mais específico em minha resposta, potencialmente elaborando alguns números.

— Tobias Krabel

1

"O seu acesso a este site foi limitado." Não consigo acessar o site no meu telefone nem no meu computador de trabalho.

— Xiaodai

1

Lamento ler isso. Eu mesmo verifiquei no meu telefone e não tive problemas. Poderia ter algo a ver com o país do qual você tenta se conectar?

— Tobias Krabel

1

"4 núcleos físicos" = 8 núcleos lógicos. Também ajuda dizer qual Intel i7 2.2GHz específico (qual geração? Qual variante? -HQ?) E qual tamanho de cache. E para o SSD, quais velocidades de leitura e gravação?

— smci 2/08/19

Como eles se comparam aos quadros de dados Julia e JuliaDB?

— skan

13

Alguém já fez benchmarks?

Sim, o benchmark que você vinculou na sua pergunta foi atualizado recentemente para a versão recente do data.table e pandas. Além disso, outro software foi adicionado. Você pode encontrar um benchmark atualizado em https://h2oai.github.io/db-benchmark
Infelizmente, ele está programado na máquina de memória de 125 GB (não 244 GB como a original). Como resultado, os pandas e ask não conseguem tentar dados de groupby1e9 linhas (50 GB csv) porque ficam sem memória ao ler dados. Portanto, para pandas vs data.table, é necessário examinar 1e8 linhas (5GB) de dados.

Para não apenas vincular o conteúdo que você está solicitando, colo horários recentes para essas soluções.

observe que esses horários estão desatualizados,
visite https://h2oai.github.io/db-benchmark para obter horários atualizados

| in_rows|question              | data.table| pandas|
|-------:|:---------------------|----------:|------:|
|   1e+07|sum v1 by id1         |      0.140|  0.414|
|   1e+07|sum v1 by id1:id2     |      0.411|  1.171|
|   1e+07|sum v1 mean v3 by id3 |      0.574|  1.327|
|   1e+07|mean v1:v3 by id4     |      0.252|  0.189|
|   1e+07|sum v1:v3 by id6      |      0.595|  0.893|
|   1e+08|sum v1 by id1         |      1.551|  4.091|
|   1e+08|sum v1 by id1:id2     |      4.200| 11.557|
|   1e+08|sum v1 mean v3 by id3 |     10.634| 24.590|
|   1e+08|mean v1:v3 by id4     |      2.683|  2.133|
|   1e+08|sum v1:v3 by id6      |      6.963| 16.451|
|   1e+09|sum v1 by id1         |     15.063|     NA|
|   1e+09|sum v1 by id1:id2     |     44.240|     NA|
|   1e+09|sum v1 mean v3 by id3 |    157.430|     NA|
|   1e+09|mean v1:v3 by id4     |     26.855|     NA|
|   1e+09|sum v1:v3 by id6      |    120.376|     NA|

Em 4 de 5 perguntas, o data.table é mais rápido e podemos ver que ele é melhor.
Basta notar esta horários são a partir de agora , onde id1, id2e id3são campos de caracteres. ~~Esses serão alterados em breve para categórico~~ CONCLUÍDO . Além disso, existem outros fatores que possam afetar esses horários no futuro próximo (como ~~agrupamento em paralelo~~ DONE ). Também adicionaremos benchmarks separados para dados com NAs e ~~várias cardinalidades~~ CONCLUÍDAS .

Outras tarefas estão chegando a esse projeto de benchmarking contínuo; portanto, se você estiver interessado join,sort , reade outros não se esqueça de verificá-lo mais tarde.
E é claro que você pode enviar comentários no repositório de projetos!

— jangorecki
fonte

1

E o JuliaDB?

— skan

1

@skan, você pode acompanhar o status disso em github.com/h2oai/db-benchmark/issues/63 #

— jangorecki

1

Boa resposta - AFAICT: os benchmarks que você vincula foram executados na mesma VM? Ou seja, nas mesmas condições, os pandas e o DASK precisam de mais de 128 GB de RAM para a tabela de 50 GB, enquanto os outros podem executar sob essa restrição? Nesse caso, também reflete minhas experiências com os pandas sendo muito ineficientes em RAM para muitas coisas normais do dia-a-dia em tabelas moderadas (~ 10 GB), e é um problema muito maior na maioria das vezes do que a velocidade de execução. (que é muito mais perto e comércios-off frente e para trás, em qualquer caso, dependendo da carga de trabalho específica.)

— jkf

@ jkf sim, exatamente. A máquina tem 128 GB de memória porque estamos planejando testar o processamento de mem no conjunto de dados de 500 GB (10e9 linhas). Atualmente, apenas spark e pydatatable suportam isso, que também será adicionado em breve à clickhouse.

— Jangorecki 20/04/19

@jangorecki, que é uma referência extremamente útil. Muito obrigado pelo esforço. Estou um pouco intrigado com o fato de o dask não digerir o conjunto de dados de 50 GB. O Dask tem o tamanho da partição como um dos parâmetros (por exemplo, blocksizein read_csv). Você tentou evitar chamar compute()e despejar a saída no disco para evitar a montagem de toda a tabela de saída na memória?

— Mykhailo Lisovyi

3

Não, de fato, se o tamanho do conjunto de dados é muuuuuuito grande, o panda trava, você está basicamente preso ao dask, o que é péssimo e você não pode nem fazer um simples grupo por soma. O dplyr pode não ser rápido, mas não estraga.

Atualmente, estou trabalhando em um pequeno conjunto de dados 2G e um simples print(df.groupby(['INCLEVEL1'])["r"].sum()) travamento do dask.

Não encontrou esse erro com o dplyr.

Portanto, se os pandas puderem lidar com o conjunto de dados, eu uso os pandas, caso contrário, atenha-se à tabela de dados R.

E sim, você pode converter o DASK de volta para o dataframe do pandas com um simples. df.compute() Mas leva um tempo bastante longo, portanto, você pode esperar pacientemente o carregamento do panda ou a leitura da tabela de dados.

— Chenying Gao
fonte

1

Não sabia que Dask era tão ruim. Talvez você queira experimentar o disk.frame de R? github.com/xiaodaigh/disk.frame Eu sou o autor

— xiaodai 19/03/19

1

Eu sei que este é um post antigo, mas achei que vale a pena mencionar - o uso de feather (em R e em Python) permite operar em quadros de dados / tabelas de dados e compartilhar esses resultados por meio de feather.

Veja a página do github de feather

— Don Quixote
fonte

Segfaults para conjuntos de dados médios e grandes

— jangorecki