Por que as pessoas preferem o Pandas ao SQL?


69

Uso SQL desde 1996, portanto, posso ser tendencioso. Eu usei o MySQL e o SQLite 3 extensivamente, mas também usei o Microsoft SQL Server e Oracle.

A grande maioria das operações que eu já vi feitas com o Pandas pode ser feita mais facilmente com o SQL. Isso inclui filtrar um conjunto de dados, selecionar colunas específicas para exibição, aplicar uma função a valores e assim por diante.

O SQL tem a vantagem de ter um otimizador e persistência de dados. O SQL também possui mensagens de erro claras e compreensíveis. O Pandas tem uma API um tanto enigmática, na qual às vezes é apropriado usar uma única [ stuff ], outras vezes você precisa [[ stuff ]]e outras vezes .loc. Parte da complexidade dos pandas decorre do fato de haver muita sobrecarga acontecendo.

Então, eu estou tentando entender por que o Pandas é tão popular.


Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .
22818 Sean Owen

Respostas:


51

A primeira pergunta real é por que as pessoas são mais produtivas com abstrações do DataFrame do que abstrações SQL puras.

TLDR; O SQL não é voltado para o processo (humano) de desenvolvimento e depuração, os DataFrames são.

O principal motivo é que as abstrações do DataFrame permitem construir instruções SQL, evitando o aninhamento detalhado e ilegível. O padrão de escrever rotinas aninhadas, comentando-as para verificá-las e, em seguida, descomentando-as é substituído por linhas únicas de transformação. Naturalmente, você pode executar as coisas linha por linha em um repl (mesmo no Spark) e visualizar os resultados.

Considere o exemplo, de adição de uma nova transformação (coluna desconectada de cadeia de caracteres) a uma tabela, agrupando-a e fazendo algumas agregações. O SQL fica muito feio. O Pandas pode resolver isso, mas faltam algumas coisas quando se trata de realmente big data ou em partições específicas (talvez melhoradas recentemente).

Os DataFrames devem ser vistos como uma API de alto nível para rotinas SQL, mesmo que com os pandas eles não sejam renderizados para algum planejador SQL.

-

Você provavelmente pode ter muitas discussões técnicas sobre isso, mas estou considerando a perspectiva do usuário abaixo.

Uma razão simples pela qual você pode ver muito mais perguntas sobre a manipulação de dados do Pandas, em oposição ao SQL, é que usar SQL, por definição, significa usar um banco de dados e muitos casos de uso hoje em dia exigem apenas bits de dados para ' tarefas únicas (feitas em .csv, API da Web etc.). Nesses casos, carregar, armazenar, manipular e extrair de um banco de dados não é viável.

No entanto, considerando os casos em que o caso de uso pode justificar o uso de Pandas ou SQL, você certamente não está errado. Se você quiser executar muitas tarefas repetitivas de manipulação de dados e persistir as saídas, eu sempre recomendo tentar acessar o SQL primeiro. Pelo que vi, a razão pela qual muitos usuários, mesmo nesses casos, não usam o SQL é dupla.

Em primeiro lugar, a principal vantagem do pandas sobre o SQL é que ele faz parte do universo Python, o que significa que, de uma só vez, posso carregar, limpar, manipular e visualizar meus dados (posso até executar o SQL através do Pandas ...). A outra é, simplesmente, que muitos usuários não sabem a extensão dos recursos do SQL. Todo iniciante aprende a 'sintaxe de extração' do SQL (SELECT, FROM, WHERE etc.) como um meio de obter seus dados de um banco de dados para o próximo local. Alguns podem pegar algumas das mais avançadas sintaxes de agrupamento e iteração. Mas, depois disso, tende a haver um abismo bastante significativo no conhecimento, até que você chegue aos especialistas (DBA, Data Engineers, etc.).

tl; dr: Geralmente, isso depende do caso de uso, da conveniência ou de uma lacuna no conhecimento sobre a extensão dos recursos do SQL.


2
Eu acho que o SQL, em grande parte sendo definido, desempenha um papel importante, quando muitas pessoas de outras áreas técnicas estão acostumadas a lidar com dados linha por linha. Considere também que os dados é na maior parte apenas dados para pandas mas os motores SQL diferentes suportam diferentes construído em funções que pode ficar descontroladamente chato rápido se você tem que cortar e mudar durante a sua jornada de trabalho
Dave

3
Eu não diria que não é viável. Se você conseguir colocar os dados em um quadro de dados do pandas, provavelmente poderá inseri-los em um banco de dados PostgreSQL. Mas, por um lado, provavelmente é mais esforço e tempo do que você economizaria.
jpmc26

2
Concordo que algumas abordagens de ETL parecem ser decisões centradas em programadores. Ou seja, eles preferem manipular os dados e apresentar essa carga "perfeita" ao banco de dados. No entanto, como você indica, se isso puder ser feito através de várias consultas SQL, a camada programática extra é desnecessária. Exatamente o que eu enfrentei recentemente. Como o OP e sua resposta indicam, pode ser que as pessoas "da velha escola" ou centradas no DBA olhem para ele e digam, por que não fazê-lo no SQL (até mesmo várias consultas simples!). Dito isso, eu achei os pandas muito poderosos para conjuntos de dados extremamente diversos.
SaltySub2

11
@SaltySub Apenas um ponto em mudar as coisas da camada programática para o SQL: é um ponto justo e pode ser perfeitamente válido, mas ir até o enterro da lógica do aplicativo nos procedimentos SQL pode trazer seu próprio sabor especial de dor de cabeça.
Electric Head

11
@ElectricHead Concordo que é preciso haver um equilíbrio certo. Se uma série de consultas SQL puder executar as tarefas adequadamente, pode ser mais fácil e eficiente. Por outro lado, como você indica, se for necessário colocar uma quantidade enorme de lógica nos procedimentos SQL, etc., os pandas devem ser fortemente considerados. Especialmente como acima, se você estiver usando diferentes tipos de banco de dados - as diferenças de sintaxe SQL podem ficar muito salgadas.
SaltySub2

29

Por mais que haja sobreposição na aplicação dessas duas coisas, isso compara maçãs com laranjas.

O pandas é um kit de ferramentas de análise de dados implementado no Python, uma linguagem de programação de uso geral. SQL é uma linguagem específica de domínio para consultar dados relacionais (geralmente em um sistema de gerenciamento de banco de dados relacional, como exemplos de SQLite, MySQL, Oracle, SQL Server, PostgreSQL etc.).

SQL implica

  • trabalhando com dados em um RDBMS * que podem ou não ser apropriados para a carga de trabalho, mesmo que seja apenas um pequeno banco de dados SQLite,
  • conhecimento do domínio do banco de dados (como usuário final, desenvolvedor e / ou administrador; a sugestão de que "o SQL é mais rápido" muitas vezes vejo é uma enorme simplificação excessiva) e
  • superar a curva de aprendizado não insignificante no uso eficaz do SQL, particularmente em aplicativos especializados, como análise de dados (em oposição à criação de relatórios simples de dados simples).

* Vale ressaltar o fato de que o SQL é tão específico do domínio que está se tornando muito menos relevante para trabalhar com alternativas cada vez mais comuns aos bancos de dados relacionais, como os bancos de dados NoSQL . Isso representa uma mudança fundamental na maneira como os dados são armazenados e estruturados, e realmente não existe uma maneira universalmente comum de acessá-los, como o desenvolvimento da padronização SQL que se pretende alcançar.

O Python, por outro lado (os pandas são razoavelmente "pitônicos", portanto é válido aqui) é flexível e acessível a pessoas de diversas origens. Ele pode ser usado como uma "linguagem de script", como uma linguagem funcional e uma linguagem OOP com todos os recursos. Os recursos de visualização e a interoperabilidade da fonte de dados são incorporados aos pandas, mas você pode incorporar o que o Python pode fazer no seu fluxo de trabalho (que é a maioria das coisas); o ecossistema Python científica inchou e inclui grandes ferramentas como Jupyter Notebook e essenciais SciPy bibliotecas como matplotlib e numpy (que pandas baseia-se). Elementos significativos da análise de dados dos pandas são R-inspirado e você geralmente não encontrará estatísticos se perguntando se eles usam R (ou possivelmente cada vez mais pandas!) sobre colocar tudo em um banco de dados e escrever suas análises em SQL.

Não estou dizendo que os pandas são melhores que o SQL ou vice-versa, mas o SQL é uma ferramenta muito específica do domínio, enquanto os pandas fazem parte de um ecossistema gigante, flexível e acessível. Trabalho com sistemas de dados geoespaciais, dos quais bancos de dados relacionais são uma grande parte, e o SQL é uma ferramenta poderosa e essencial. No entanto, os pandas são uma parte igualmente, se não mais essencial, do meu kit de ferramentas do dia-a-dia, e o SQL é frequentemente relegado à busca de dados - talvez com algum pré-processamento - para que eu possa fazer isso com os pandas.


11
Esta é a única resposta verdadeira, deve ser a escolhida. SQL e Pandas são duas coisas diferentes, não entendo que comparação as pessoas estão tentando fazer.
gented

Eu suspeito que é uma perspectiva do usuário final escrever algo semelhante ao código para buscar e massagear alguns dados de algum lugar e cuspir alguns números. Não estou totalmente surpreso; Eu tive uma experiência em primeira mão de como os analistas de dados apresentaram um banco de dados Oracle antigo, mas de outra forma não digno de nota, nem sequer tiveram a primeira idéia do que é e como se conectar a ele e muito menos obter dados. Acredito que isso traga uma falta fundamental de entendimento da tecnologia - na verdade, acrescentei um pouco para enfatizar a rapidez com que o mal-entendido escopo do SQL cai.
Cabeça elétrica

Eu desafiaria sua parte por ser irrelevante para situações NoSQL. Considere, por exemplo, os avanços que o PostgreSQL fez com seu armazenamento JSON.
jpmc26

Eu tentei escolher minhas palavras com cuidado; O PostgreSQL ainda é um RDBMS, apesar de fazer muitas coisas bem (como o SQL Server, apesar de suportar gráficos). Mas relaxei um pouco a redação, porque ainda é um bom ponto: existe algum crossover e, o mais importante, existem APIs SQL para alguns sistemas NoSQL. É um cruzamento, porém, o SQL não é uma linguagem universal e nem todos os dados são estruturados de forma relacional.
Cabeça elétrica

Eu acho que você pode fazer tudo em SQL que é possível em pandas. O SQL não é flexível, mas é muito otimizado.
Mídia

22

Primeiro, os pandas não são tão populares. Eu uso pandas e SQL. Primeiro, tento entender a tarefa - se ela pode ser feita no SQL, prefiro o SQL porque é mais eficiente que os pandas. Tente trabalhar com dados grandes (10.000.000 x 50). Tente fazer alguma operação de agrupamento em SQL e pandas. Você vai entender.

Eu uso pandas onde é útil, como dividir os valores de uma coluna em uma matriz e fazer algumas coisas nela (como escolher apenas alguns valores dessa matriz). Agora, esse tipo de tarefa é relativamente difícil de codificar no SQL, mas os pandas facilitarão sua tarefa.


Essa ineficiência é específica para os pandas? Eu fiz bastante manipulação de dados na memória em C # e achei bastante fácil e eficiente, desde que cabesse na memória e fosse instantâneo (ou seja, não é necessário atualizar índices de maneira incremental à medida que os dados mudam).
CodesInChaos

pandas deve ser conveniente rapidamente, mas isso não quer dizer que não seja rápido se você usá-lo corretamente. No final, executar uma consulta SQL aos dados em um banco de dados não é mágico - requer recursos como qualquer coisa, é apenas que (se você fizer isso da maneira certa!), Esperamos que você esteja usando recursos em servidores de banco de dados robustos e cuidadosamente configurados . Acertar seu pipeline em pandas ou similares (por exemplo, transmitir dados em vez de carregar tudo na memória) vai determinar o sucesso de alguns esforços.
Electric Head

@CodesInChaos Existe esta resposta de pandas vs SQl - qr.ae/TUIpzE . Lá são descritas as vantagens e desvantagens do uso de pandas.
Ankit Seth

12

Sou uma daquelas pessoas que usaria (no meu caso) o dplyr de R (a linguagem, não necessariamente a ferramenta) em todos os casos, se eu pudesse, mesmo sabendo o meu SQL.

O principal benefício que vejo nos pipelines Pandas / dplyr / data.table é que as operações são atômicas e podem ser lidas de cima para baixo.

No SQL, você precisa analisar o script inteiro, pulando (o que está sendo resumido, o que está sendo juntado e como - esquerda? Interior? Direita ?, existem filtros aplicados?) Para entender completamente o que está acontecendo.

Em Pandas et al, cada etapa do pipeline é independente, faz alguma coisa com os dados de entrada e retorna os dados de saída, esse processo seqüencial facilita o raciocínio sobre o que está acontecendo, uma vez que existe um estado claramente definido para cada operação, e não apenas sobre um nível de consulta.

E sim, você pode fazer WITHinstruções e coisas do tipo, mas isso requer muito mais código e não está claro qual objeto está sendo usado em comparação com a tubulação.


6

Sou relativamente novo no Pandas / Python, mas tenho mais de 20 anos como SQLServer DBA, arquiteto, administrador, etc. Adoro o Pandas e estou me esforçando para sempre tentar fazer as coisas funcionarem no Pandas antes de retornar ao meu conforto, aconchegante mundo SQL.

Por que os RDBMSs são melhores: A vantagem dos RDBMSs são os anos de experiência em otimizar a velocidade da consulta e as operações de leitura de dados. O que é impressionante é que eles podem fazer isso, equilibrando simultaneamente a necessidade de otimizar a velocidade de gravação e gerenciar o acesso altamente simultâneo. Às vezes, essas despesas gerais adicionais oferecem vantagens ao Pandas quando se trata de casos de uso simples e de usuário único. Mas, mesmo assim, um DBA experiente pode ajustar um banco de dados para ser altamente otimizado para velocidade de leitura e velocidade de gravação. Os DBAs podem tirar proveito de coisas como otimização de armazenamento de dados, dimensionamento estratégico de páginas em disco, preenchimento / preenchimento de páginas, estratégias de controlador de dados e particionamento de disco, planos de E / S otimizados, fixação de dados na memória, planos de execução predefinidos, indexação, compactação de dados , e muitos mais. Tenho a impressão de muitos desenvolvedores de Pandas que eles não Não entendo a profundidade disponível lá. O que eu acho que geralmente acontece é que, se o desenvolvedor do Pandas nunca tiver dados grandes o suficiente para precisar dessas otimizações, eles não apreciarão quanto tempo eles podem salvar você imediatamente. O mundo RDBMS tem 30 anos de experiência otimizando isso, portanto, se a velocidade bruta em grandes conjuntos de dados for necessária, os RDBMS poderão ser vencidos.

Por que o Python / Pandas é melhor: Dito isto, a velocidade não é tudo e, em muitos casos de uso, não é o fator determinante. Depende de como você está usando os dados, se eles são compartilhados e se você se importa com a velocidade do processamento. Os RDBMSs geralmente são mais rígidos em suas estruturas de dados e sobrecarregam o desenvolvedor por ser mais determinístico com as formas de dados. Pandas permite que você fique mais livre aqui. Além disso, e esse é o meu motivo favorito, você está em uma verdadeira linguagem de programação. As linguagens de programação oferecem infinitamente mais flexibilidade para aplicar lógica avançada aos dados. É claro que também há um rico ecossistema de módulos e estruturas de terceiros que o SQL não pode chegar perto. Ser capaz de passar de dados brutos até a apresentação na web ou a visualização de dados em uma base de código é MUITO conveniente. Também é muito mais portátil. Você pode executar o Python em praticamente qualquer lugar, incluindo blocos de anotações públicos que podem estender o alcance dos seus resultados para chegar às pessoas mais rapidamente. Os bancos de dados não se destacam nisso.

Meu conselho? Se você se formar em conjuntos de dados cada vez maiores, deve fazê-lo e aprender como o RDBMS pode ajudar. Eu já vi milhões de linhas, junções de várias tabelas e consultas agregadas resumidas, ajustadas de 5 minutos a 2 segundos. Ter esse entendimento no seu cinto de ferramentas apenas o torna um cientista de dados mais bem-formado. Você pode fazer tudo no Pandas hoje, mas algum dia poderá ter uma tarefa em que RDBMS é a melhor escolha.


5

Coisas que o Pandas pode fazer, que o SQL não pode fazer

  1. df.describe()
  2. Plotagem, por exemplo df['population'].plot(kind='hist')
  3. Use um dataframe diretamente para treinar algoritmos de aprendizado de máquina

Coisas que os pandas podem fazer, eu não sabia que o SQL também

  1. Exportar para CSV: df.to_csv('foobar.sv'). Isso é importante quando você deseja mostrar algo ao proprietário de uma empresa que deseja trabalhar com o Excel. E existe df.to_exceltambém. Mas no SQL, você pode fazer SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(obrigado, vy32!)

11
Agradável. Embora a maioria delas pareça funções que poderiam ser implementadas no SQL. (SQL tem exportação diretamente CSV).
vy32

Você poderia me enviar uma consulta que exporte para CSV? (Eu só sei ferramentas que fazem isso para alguns bancos de dados baseados em SQL, mas eu nunca vi uma consulta ... assim que eu duvido que isso é parte da especificação SQL)
Martin Thoma

11
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table; Veja dev.mysql.com/doc/refman/8.0/en/select-into.html
vy32

Muito obrigado, vy! Acho que vou ajustar a minha resposta quando estou em casa :-)
Martin Thoma

Coisa certa. Lembre-se, o arquivo acaba no servidor SQL, não no cliente.
vy32

3

A única coisa não abordada nessas respostas que eu gostaria de mencionar é que isso também depende de como você está usando o SQL. Tome arcpy, por exemplo. Por alguma razão, nenhuma das funções do arcpy.da possui um recurso execute many. Isso é realmente estranho, porque praticamente todas as outras bibliotecas python sql fazem. A instrução Where nas funções arcpy.da também é limitada a cerca de 120 caracteres. Isso significa essencialmente que, se você tem um número relativamente alto de coisas que está tentando fazer com o banco de dados, sua única opção real é chamar a função arcpy.da escolhida várias vezes, alterando a instrução where a cada vez que você faz. Existem alguns truques que você pode usar para acelerar esse processo - você pode iterar partes de seu conjunto de dados, por exemplo - mas literalmente cada um desses truques é muito mais lento do que usar apenas um arcpy.da. searchcursor para carregar sua tabela inteira em um quadro de dados do pandas e, em seguida, manipulá-la usando pandas, numpy e, se seus dados forem realmente tão massivos, execute. Eu preciso enfatizar aqui que os pandas não são apenas um pouco mais rápidos neste caso. É nojento mais rápido. É muito mais rápido que eu estava literalmente rindo de mim mesma por não fazer isso antes. O uso de pandas reduziu o tempo de execução de um script de mais de uma hora - esqueço se esse foi o salto de 3,5 horas ou de 1,5 horas - para literalmente 12 minutos. é tão mais rápido que eu estava literalmente rindo de mim mesma por não fazer isso antes. O uso de pandas reduziu o tempo de execução de um script de mais de uma hora - esqueço se esse foi o salto de 3,5 horas ou de 1,5 horas - para literalmente 12 minutos. é tão mais rápido que eu estava literalmente rindo de mim mesma por não fazer isso antes. O uso de pandas reduziu o tempo de execução de um script de mais de uma hora - esqueço se esse foi o salto de 3,5 horas ou de 1,5 horas - para literalmente 12 minutos.

Uma coisa a notar é que, embora eu pudesse fazer isso com o sql, levaria muito mais tempo para aprender. Eu precisaria aprender operações especificamente para sql no Access - foi aí que os dados desse script terminaram - - o sql no Access não era tão robusto quanto eu precisava quando estava realmente pensando em fazer isso -, ou Eu teria que gravar todos os meus dados em um banco de dados sqlite3, manipulá-los e colocá-los no Access. Embora isso possa ter me dado resultados de desempenho semelhantes, teria tornado meu script mais difícil de modificar no futuro.

Então sim, às vezes Pandas e é estritamente melhor do que usar as opções sql que você tem à sua disposição . Tudo o que eu precisaria fazer no sql foi feito com uma função nos pandas. Você também pode usar a sintaxe sql com os pandas, se desejar. Há poucas razões para não usar pandas e sql em conjunto.

Mais uma coisa que quero mencionar sobre o Pandas e o numpy é que essas duas bibliotecas são, por natureza, abordagens baseadas em conjuntos. Você pode percorrer quadros de dados e compilação de séries com essas bibliotecas, mas é realmente difícil modificar dados nessas estruturas assim, para que você acabe escrevendo código mais eficiente - baseado em conjunto - com essas duas bibliotecas apenas porque é muito mais fácil Faz. Ser "guiado", se não for orientado a usar abordagens baseadas em conjuntos, não é algo que experimentei com SQL.

Mais uma coisa maciça que esqueci de mencionar com os pandas. Dinheiro . O Pandas é uma ferramenta que muitos trabalhos de ciência de dados desejam que você saiba como usar. Praticamente todos os trabalhos em Data Science que eu já paguei mais do que trabalhos do tipo gerenciamento de banco de dados. A única exceção a isso que notei está na Engenharia de Dados, mas já vi muito menos dessas ofertas de emprego. Pandas parece que você ganha mais dinheiro de relance.


5
Talvez seja triste que, quando se trata de trabalhos modernos, seja sobre ter as palavras-chave certas em seu currículo, em oposição às abordagens adotadas para solucionar um problema (supondo que você possa aprender a palavra-chave relativamente rápido). É como se a palavra da moda fosse mais importante do que a solução de problemas. Quando a solução de problemas para o X deve envolver o aprendizado e o uso da tecnologia A, B, C, não o contrário. Eu me pergunto se a maioria das equipes de desenvolvimento agora destrói as coisas por causa de palavras-chave e tendências, e depois pensa em resolver problemas como algo secundário ou "antiquado" porque você não sabia / usou a palavra-chave.
SaltySub2

11
@ElectricHead na minha experiência, se você estiver escrevendo sua própria função envolvendo sql em python, é mais fácil usar mal o cursor e escrever consultas ruins do que usar pandas / numpy. É preciso lembrar que nem todos os módulos / bibliotecas sql são iguais. No meu caso, com o arcpy.da.SearchCursors e similares, não há realmente uma boa maneira de fazer algo com vários registros de maneira eficiente por causa de limitações estranhas. Se eu usar pandas / numpy, torna-se uma boa maneira de fazer as coisas, e é isso que eu quero ao usar python.

11
Ahhh, tudo bem. Você quer dizer um pipeline SQL caseiro através de uma implementação python dbapi vs usando numpy / pandas? Nesse caso, sim, entendi, nenhum argumento meu lá; cuidados necessários! Ele me leu como SQL simples vs com o qual você obviamente precisa entender as operações definidas, mas descobrirá isso rapidamente ao executar consultas tolas de um cliente de banco de dados.
Electric Head

11
@ Steve Sim, não impedirá que as pessoas tentem modificar coisas dinamicamente em loops em pandas ou similares :) Acho que entender o SQL ajuda a trabalhar efetivamente em pandas (não é como se eles escondessem a semelhança em alguns conceitos).
Cabeça elétrica

11
@Steve De fato, os pandas também são poderosos ... Acho que uma das minhas frustrações são desenvolvedores e gerentes, inclusive eu, não gastando tempo suficiente avaliando soluções e perseguindo tendências (onde há dinheiro envolvido para promover a auto / empresa). Mas mesmo na prototipagem enxuta / mvp, seria necessário estabelecer as bases apropriadas para o dimensionamento. SQL, noSQL e Pandas ... todos têm seus propósitos para as tarefas e projetos apropriados em diferentes estágios. No ano passado, o noSQL para um protótipo lean / mvp certamente me ajudou em mais de uma maneira. O SQL teria sido um exagero por isso.
SaltySub2

3

Pensei em acrescentar que faço muitas análises de dados baseadas em séries temporais, e os pandas resamplee reindexmétodos são inestimáveis ​​para isso. Sim, você pode fazer coisas semelhantes no SQL (costumo criar uma DateDimensiontabela para ajudar com consultas relacionadas a datas), mas acho os métodos do pandas muito mais fáceis de usar.

Além disso, como outros disseram, o restante da minha modelagem está em Python, e muitas vezes tenho chamadas pela web ou arquivos CSV.


2

Tentarei responder a essa pergunta com base em minha própria experiência. Em contraste com as outras respostas, prefiro Sqlaprendizado profundo e coisas relacionadas a big data. Existem inúmeras razões para isso. Como pode ser visto aqui ,

O Pandas fornece uma experiência de análise de dados intuitiva, poderosa e rápida em dados tabulares. No entanto, como o Pandas usa apenas um segmento de execução e exige que todos os dados estejam na memória de uma só vez, ele não se adapta bem a conjuntos de dados muito além da escala de gigabytes.

Os mecanismos sql geralmente mantêm as chaves ou colunas especiais em estruturas de dados como a árvore para facilitar as operações CRUD. Essa estrutura de dados mantém o status de todos os dados no banco de dados. Isso não é o que os pandas podem fazer porque não podem acessar todos os dados simultaneamente. Por outro lado, ele não pode executar algumas operações, mesmo com seu parâmetro chunk usado em read_csv. Como exemplo, você não pode ter operações em lote diretas para grandes conjuntos de dados que sua memória não pode acomodar. Quaisquer outras tarefas que dependem de todo o conjunto de dados precisam de codificação extra. Tudo isso pode ser tratado no Sql sem codificação extra, apenas com uma consulta simples. Operações SQL simples são usadas apenas sem nenhum medo sobre a memória.B+

Outra diferença é que as operações CRUD no Sql podem ser aplicadas distribuídas com políticas de autorização diferentes, o que não é possível em pandas.

Não é para dizer o que é melhor, tudo depende da sua tarefa. Para computação em larga escala, prefiro Sql e, para pequenas, prefiro pandas.

Existem outras coisas que não estão nos pandas que são realmente importantes para uma experiência rápida de extração de dados, a qual me referirei mais adiante. Por enquanto, basta dar uma olhada aqui .


1

O Panda é mais popular, já que o python, na forma de notebooks jupyter, é a caixa de ferramentas mais popular usada pelo cientista de dados na área de redes neurais. Python está se tornando "o" idioma. É até possível usar o back-end do SQL, mas você não está vinculado ao SQL apenas com o panda.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.