Por que as pessoas preferem o Pandas ao SQL?

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.

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.

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.

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.

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.

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.

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!)

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.

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.

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 .

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.

Não é exatamente a resposta para a pergunta, mas desde que eu mesmo vim aqui para procurar diferenças na aplicação prática:

https://pandas.pydata.org/pandas-docs/stable/getting_started/comparison/comparison_with_sql.html