Por que estamos ensinando Pandas em vez de SQL?

Foto de no

Era uma vez um aluno que estava ansioso para aprender ciência de dados.

Ele perguntou às pessoas o que deveria fazer e elas lhe disseram para aprender pandas. Ele vasculhou a web em busca de cursos de dados e todos apresentavam pandas. Então o aluno aprendeu pandas e conseguiu um emprego na academia, onde todos trabalhavam com pandas.

Então ele trabalhou com pandas por muitas luas, até que pudesse fatiar dataframes enquanto dormia. Quando terminou, ele se juntou a um bootcamp de dados: eis que eles estavam ensinando pandas. Quando ele terminou, o bootcamp o contratou para ensinar pandas.

Então chegou o momento em que o aluno entrou em sua primeira empresa. Seu mestre queria que ele processasse alguns dados.

“Vou usar pandas”, disse o aluno.

"O inferno que você vai!" disse o mestre. “Usamos S—Q—L aqui”, ele retorquiu, enfatizando cada letra com um golpe de bastão.

“Mas... Mas... Verbosidade... Fealdade... Falta de funções... Aninhamento sem fim... E as junções, as junções são horríveis!...“

“Se você não pode ver a floresta, então não deve tocar nas árvores”, disse o mestre, batendo-lhe na cabeça.

O aluno foi esclarecido.

Ou assim ele pensou; na verdade, o golpe do mestre o deixou tão atordoado que seu julgamento foi temporariamente prejudicado.

Muitas luas depois, após um doloroso retraimento, o aluno entendeu SQL. A partir daí não sentiu mais necessidade de usar pandas, e o mestre nunca mais lhe deu um golpe.

SQL >> Pandas

O koan acima é autobiográfico, embora eu deva observar que nenhum de meus supervisores jamais me bateu (mesmo quando deveria).

Não mudou muito desde que comecei. A maioria dos currículos dos bootcamps de dados apresenta um investimento pesado em pandas (junto com os notebooks Jupyter), enquanto o SQL é, na melhor das hipóteses, uma reflexão tardia.

Pesquise “ciência de dados” na Udemy e você verá os principais cursos mencionando Python (que inevitavelmente inclui pandas) e R, às vezes até Scala. Muito poucos deles mencionam SQL.

Eu acho isso ruim, tanto do ponto de vista de valor quanto do ponto de vista pedagógico.

O problema do valor

Se você estiver fazendo análises padrão, o SQL é simplesmente uma ferramenta melhor do que os pandas. É mais simples, mais claro, mais poderoso e eficiente. Também é mais fácil de entender, compartilhar e reproduzir. Há uma razão pela qual tem sido a língua franca da análise de dados por décadas.

Se você está se concentrando no Pandas em detrimento do SQL, está perdendo a oportunidade de ser um profissional de dados melhor e mais eficaz.

Claro, há coisas que os pandas fazem melhor, e eu as exploro brevemente no final do artigo. Mas, no geral, quando se trata de análises puras, o SQL é difícil de superar.

As pessoas muitas vezes não percebem que os pandas apresentam uma sobrecarga significativa em termos de complexidade, ineficiência, idiossincrasia e oportunidades de confusão.

O Problema de Aprendizagem

Suspeito que a ênfase excessiva nos pandas prejudique os estudantes de dados. Na minha experiência, há um ponto em que fazer mais pandas resulta em anti-aprendizagem , ou seja, a pessoa simplesmente fica mais confusa com o tempo.

Os novos alunos, em particular, experimentam questões estranhas que os confundem e que compensam com a memorização cega.

Eles também adquirem maus hábitos que são difíceis de abandonar mais tarde, como repetir linhas quando poderiam usar operações de tabela; criação de colunas com tipos mistos; salvar dados em CSV; modificação de dados no local; entupindo a memória com várias cópias e fatias do mesmo dataframe... Eu poderia continuar.

Parte disso vem do Python ser uma linguagem extremamente tolerante, que sobrecarrega o usuário para não fazer coisas ruins (como a Series pandas com tipos mistos). Parte disso vem do fato de que os pandas aceitam (embora não necessariamente encorajem) uma abordagem imperativa.

Por exemplo, se um aluno deseja combinar dados de duas tabelas, nada o impede de usar este algoritmo:

1. Percorrer a table1

2. Para cada linha da table1 , escaneie toda a table2 para uma pesquisa

3. Atualize a linha na table1 a partir dos dados na table2

   
   

Sim, isso obviamente é muito ruim. Mas os iniciantes não sabem nada melhor.

Em contraste, a abordagem declarativa do SQL torna mais difícil fazer coisas ruins.

A programação declarativa força o usuário a pensar em termos do resultado que deseja ver, em vez de como produzi-lo . Isso dá a eles o espaço de que precisam para se concentrar na lógica por trás de sua análise, em vez de ficarem constantemente atolados em problemas e bugs estranhos.

O SQL também força os alunos a pensar em tabelas (ou seja, modelo relacional) e operações em nível de coluna, o que é altamente benéfico quando seu primeiro instinto é repetir tudo.

Finalmente, aprender SQL produz um maior retorno sobre o investimento devido à sua universalidade e portabilidade.

Isenção de responsabilidade

Eu não odeio pandas. Foi minha ferramenta básica de análise por dois anos e ainda a uso para meus projetos pessoais. Fico feliz em ver as pessoas aprendendo.

Mas estou tentando ver a foto maior. Acho que enfatizar demais os pandas em detrimento do SQL faz mais mal do que bem . Especialmente quando se trata de iniciantes, que estão aprendendo sobre o Pandas MultiIndex antes de poderem fazer um GROUP BY adequado.

Prospect

Na próxima seção, analiso alguns dos aspectos mais estranhos dos pandas e os comparo diretamente com o SQL.

O objetivo, mais uma vez, não é rebaixar os pandas, mas ampliar a perspectiva do leitor sobre as ferramentas à sua disposição.

Vamos nos aprofundar.

 SELECT * FROM opinionated_comparison WHERE sql > pandas

Comparação

Selecionando Colunas

Em uma única instrução, o SELECT do SQL permite:

1. Escolha as colunas que deseja e a ordem em que devem ser retornadas.

   
   

2. Crie novas colunas com base em combinações e transformações de colunas existentes.

   
   

3. Renomeie as colunas.

   
   

Este exemplo seleciona todas as colunas, exceto uma, e cria uma nova coluna com base em uma combinação linear de duas outras colunas:

 SELECT * EXCEPT (first_name), equity_comp / total_comp * 100 AS percent_equity FROM salaries

A seleção de colunas do pandas permite apenas escolher e ordenar as colunas. Se você quiser renomear ou transformar alguns, precisará de várias instruções e muitas pessoas cairão no erro de transformar os dados no local (consulte a imutabilidade abaixo).

Iniciantes ficam confusos porque selecionar uma única coluna requer um conjunto de colchetes ( df[”first_name”] ) enquanto selecionar várias colunas requer um conjunto duplo de colchetes ( df[[”first_name”, "last_name"]] ).

O maior problema que tenho com os pandas aqui é a notação de ponto: o fato de você poder selecionar colunas como esta: df.first_name .

Isso é muito mais fácil do que usar colchetes e aspas, então as pessoas acabam preferindo por pura preguiça. Pelo menos foi o que aconteceu comigo: ainda uso a notação de ponto automaticamente, mesmo sabendo que é ruim.

Os problemas aparecem quando você tem uma coluna chamada count ou shape ou diff ou qualquer outro dos muitos atributos padrão de um dataframe (você pode vê-los todos com dir(df) ).

Ao tentar acessá-los com a notação de ponto, você obterá o atributo em vez da coluna e seu código será interrompido.

Portanto, o pandas tem três maneiras de selecionar colunas: duas para obter uma única coluna (das quais uma é ruim, mas mais atraente!) E uma terceira para selecionar várias colunas.

Selecionando Linhas

No SQL, para selecionar linhas específicas, basta usar a instrução WHERE (consulte Filtragem abaixo).

Selecionar linhas no Pandas é... complexo. Para ver o quão complexo, verifique o . Ou mergulhe em um .

Limitar-me-ei a um único exemplo. Cada DataFrame tem um Index . O índice padrão é uma sequência de inteiros: [0,1,2,3,4,5...] .

Naturalmente, a maioria das pessoas assume que o índice representa a cardinalidade das linhas. Na verdade, os números são apenas rótulos categóricos! Eles também podem ser letras aleatórias como ['x', 'z', 'a'] . Não há cardinalidade implícita.

Para obter uma linha por seu índice, você usa df.loc . Mas para selecionar pela cardinalidade da linha, você usa df.iloc . Com o índice padrão, esses dois métodos fornecem o mesmo resultado.

O que só aumenta a confusão, porque a qualquer momento seu índice pode mudar para algo completamente aleatório como [7, 2, 2, 'c', True, None] . Sim, tudo isso é permitido! E não há restrições para evitá-lo (consulte Restrições abaixo).

Imagine que você escreveu seu código assumindo que o índice representava a cardinalidade da linha. Agora:

• df.loc[7] retornará a primeira linha
• df.loc[2] retornará uma fatia do dataframe em vez de uma linha (porque ocorre mais de uma vez no índice)
• df.loc[None] retornará uma linha real!

• 
  

Eu não estou chorando, você está chorando.

E sim: o mesmo método pode retornar um valor escalar, uma linha ou uma fatia do dataframe dependendo de como o índice é composto. Os reconhecem essa loucura:

Outros métodos, como indexação, podem dar resultados surpreendentes. Normalmente, a indexação com um escalar reduzirá a dimensionalidade . Fatiar um DataFrame com um escalar retornará um Series . Fatiar uma Series com um escalar retornará um escalar. Mas com [index] duplicados, este não é o caso.

E lembre-se, não há restrição para impedir que o índice contenha duplicatas. Eu não posso começar a dizer quantas dores de cabeça isso me causou.

(Além de todos os métodos de seleção que mencionamos, pandas também tem df.at e df.iat para valores únicos. Outra coisa a lembrar e evitar confusão.)

Filtragem

No SQL, a filtragem é direta. Escreva WHERE , insira quantas instruções quiser e encadeie-as com operadores lógicos. Os colchetes oferecem mais controle sobre a estruturação das expressões.

Por exemplo, a consulta a seguir filtra pessoas com mais de 30 anos e que atendem a pelo menos uma das duas condições: mais de 5 anos de mandato ou remuneração de patrimônio inferior a 50:

 SELECT * from salaries WHERE age > 30 AND (tenure > 5 OR equity_comp < 50)

Como isso se parece em Pandas?

 new_df = df[(df["age"] > 30) & ((df["tenure"] > 5) | (df["equity_comp"] < 50))]

Eca. Divirta-se explicando isso para iniciantes.

Concedido, você provavelmente não escreveria assim porque é muito feio. Você executaria a filtragem em várias instruções: o que significa mais linhas de código, variáveis e repetição.

Os filtros Pandas são baseados em um método chamado . Toda operação de filtragem ocorre em duas etapas:

1. Você pega uma Series (que é o objeto da coluna) e executa cada elemento por meio de um teste booleano. Transformando-a assim em uma nova Series composta por valores booleanos (verdadeiro ou falso).

   
   

2. Você seleciona o dataframe com esta coluna, o que acaba excluindo as linhas onde a Series booleana contém um valor falso.

   
   

Observe a suposição oculta aqui? A Series usada para filtrar e o dataframe que está sendo filtrado precisam compartilhar o mesmo índice, na mesma ordem. Isso nem sempre é garantido.

Na prática, a indexação booleana significa que, ao filtrar, você sempre deve repetir a variável do dataframe, por exemplo, salaries[salaries["cash_comp"] > 20] . Isso é muito chato quando você está escrevendo muito código! Veja o exemplo acima: a variável dataframe é referenciada 4 vezes.

Também posso dizer por experiência que a indexação booleana não é fácil de entender para iniciantes. Algumas pessoas nunca entendem o mecanismo subjacente. Eles apenas memorizam o padrão de codificação.

(O método df.query() parece fornecer .)

Agrupamento

Não há grandes queixas aqui. Mas o SQL está definitivamente mais próximo do inglês. Esses dois são equivalentes:

 SELECT AVG(cash_comp), SUM(tenure) FROM salaries GROUP BY department

 grouped_df = df.groupby('department').agg({"cash_comp": np.mean, "tenure": np.sum})

Junta-se

SQL tem um tipo de junção. Chama-se JOIN . Claro, pode ser esquerdo/direito e interno/externo, mas o uso é bastante direto.

O Pandas tem dois métodos: join e merge . Nunca entendi por que precisamos de dois. join deve funcionar em índices, merge deve funcionar em qualquer coluna.

Mas se você olhar para os documentos [ ][ ] cada um deles parece suportar índices e colunas. eu sou confusão. (Se você estiver em dúvida, sugiro sempre escolher merge , pois join é mais um método herdado.)

O SQL facilita muito o JOIN com base em uma cadeia de condições lógicas, como: ingresso por função, mas apenas se o salário de Londres for maior do que o de Washington ou a pessoa tiver mais tempo de mandato.

 SELECT * FROM london_hq lhq JOIN washington_hq whq ON lhq.role = whq.role AND (lhq.salary > whq.salary OR lhq.tenure > whq.tenure)

Tanto quanto eu sei, isso não é possível com os pandas. Ao ingressar (ou mesclar), você só pode usar a condição de igualdade.

Portanto, você teria que primeiro executar o JOIN na role , acompanhar a origem de cada coluna e depois filtrar o resultado.

No entanto, eu argumentaria que essas condições pertencem legitimamente ao JOIN e não são menos relevantes por não usar a comparação de igualdade.

Digitando

Uma das principais vantagens do SQL é que cada coluna tem um tipo bem definido. Além disso, as colunas não podem ter tipos mistos. Isso evita muitos bugs e dores de cabeça a longo prazo.

Quando você carrega dados em pandas, a maioria das colunas é digitada automaticamente como object . Isso pode significar uma das três coisas:

1. A coluna contém apenas strings

2. A coluna contém objetos Python que não são um tipo de dados primitivo, por exemplo, lista ou dicionário

3. A coluna contém tipos mistos

   
   

Quando você vê o tipo de dados do object , nunca sabe qual é o caso. Eu acho isso muito chato.

Ao contrário do SQL, você pode carregar dados com tipos mistos em pandas: eles serão simplesmente digitados como object .

O Pandas não o força a especificar um esquema e segui-lo. Isso lhe dá um prêmio de velocidade quando você está começando, mas muitas vezes você paga caro por isso em futuros bugs e confusão.

Isso é especialmente problemático para iniciantes que não estão atentos às armadilhas comuns. Por exemplo, quando eu estava trabalhando com Pandas, muitas vezes eu tentava uma operação datetime, apenas para perceber que a coluna datetime era feita de strings (portanto classificada como object ). Eu ingenuamente faria isso:

 df['Date'] = df['Date'].astype('datetime64[ns]')

E seguir em frente, apenas para descobrir muito mais tarde que o analisador de datas do Pandas interpretou mal minhas strings e as datas não faziam sentido.

Arquivos e CSVs

Sejamos honestos: a maioria das pessoas armazena seus dataframes como CSV. Os alunos Pandas são bem-vindos, ou melhor, encorajados a fazer isso. Esta é uma má ideia!

Claro, os CSVs são legíveis por humanos e... suas vantagens terminam aqui. Suas desvantagens são:

• Ao converter para CSV, você perde todas as informações sobre os tipos de esquema e coluna. Tudo volta ao texto.

  
  

• CSVs são propensos a erros de formatação, corrupção e análise incorreta.

  
  

• CSVs são difíceis de compactar, o que aumenta os custos de armazenamento.

  
  

• , o que significa que diferentes programas criam CSVs de maneiras diferentes, e o usuário tem que descobrir como analisá-los. Isso pode rapidamente se transformar em uma experiência infernal, como qualquer profissional de dados pode atestar.

  
  

A perda de esquema é normalmente o maior problema para as pessoas que trabalham em pandas. Esta é uma situação comum:

1. Seu trabalho começa com um CSV. Desde que você tenha descoberto a formatação correta, a codificação, a especificação de caracteres de citação e o restante dos para o read_csv do pandas, você o carregará em um dataframe. Agora você precisa gastar tempo explorando as colunas, convertendo cada coluna para o tipo correto, cuidando de quaisquer bugs que apareçam no processo e verificando se o resultado final faz sentido. (Ou você pode começar a trabalhar imediatamente e enfrentar muitos bugs mais tarde).

   
   

2. Depois que seu trabalho estiver concluído, você terá um novo dataframe. O que você vai fazer com isso? Por que, salve-o como um CSV. Agora todo o seu trabalho anterior na definição do esquema se foi, pois o dataframe é despejado no texto.

   
   

3. Você precisa carregar o novo dataframe para outro fluxo de trabalho. Isso significa carregar o CSV que você acabou de descarregar. Espero que você tenha escrito funções que possam restaurar o esquema com sucesso, ou você terá que fazer todo o trabalho novamente (desde que você se lembre do que cada coluna deveria fazer).

   
   

4. Quer compartilhar o CSV com um amigo ou publicá-lo no GitHub? É melhor você compartilhar o código que pode reimputar o esquema e esperar que eles estejam dispostos e sejam capazes de executá-lo. Ou eles ficarão com uma bolha de texto e terão que repetir todo o trabalho de imputação de esquema do zero.

   
   

Parece absurdo? Já vi isso ser feito inúmeras vezes . Eu mesmo fiz isso! Mas agora eu me pergunto: por que ensinamos as pessoas a trabalhar assim? O que justifica tamanha loucura e crueldade?

Existem duas soluções aqui.

Se você realmente precisa trabalhar em pandas, exporte seus dataframes no Parquet.

Ou você pode trabalhar em SQL e evitar todos os problemas. Afinal, um banco de dados é o melhor lugar para armazenar dados.

Pergunte a si mesmo: Por que preciso de uma camada de arquivo? Se você está simplesmente lendo alguns dados, processando-os e armazenando os resultados, provavelmente não. Carregue do banco de dados, trabalhe no banco de dados, salve no banco de dados. É simples assim. Precisa compartilhar dados externamente? Exportação em Parquet.

O mundo não precisa de mais CSVs.

Nota: algumas pessoas tentam resolver o problema do esquema seus quadros de dados. .

A conserva é ineficiente e insegura (nunca abra uma conserva em que você não confia!). Um dataframe em conserva só pode ser aberto dentro do Python e deve acontecer dentro do mesmo ambiente de biblioteca (sobre o qual o usuário pode não saber absolutamente nada). Se os pandas que lêem o picles forem de uma versão diferente dos pandas que o escreveram, o arquivo pode ficar ilegível!

Nulos

O SQL usa valores NULL para indicar dados ausentes. Você pode facilmente filtrar nulos.

 SELECT * FROM salaries WHERE equity_comp IS NOT NULL AND cash_comp IS NOT NULL

No Pandas, os valores ausentes podem ser qualquer um destes:

• O None nativo do Python (que o Pandas exibe como None , mas trata como nan )

• numpy.nan

• pandas.NA

• pandas.NaT (para datas e horas)

  
  

Vamos nos concentrar no numpy.nan , que é o mais comum:

• O tipo deste objeto é float , então esqueça de detectá-lo com verificações de tipo.

• É verdade, então esqueça os testes booleanos. bool(np.nan) é True .

• Ele falha no teste de igualdade, pois numpy.nan == numpy.nan é falso. nan não é igual a si mesmo!

• Usar nan em uma operação não lança uma exceção, apenas significa que o resultado é nan .

  
  

Isso não é divertido?

A única maneira de detectar um nan é usar pandas.isna() . Tudo bem, depois de ler os documentos e esquecer todos os seus instintos pitônicos. Ainda assim, esse comportamento é extremamente confuso para iniciantes.

Veja como você pode replicar a consulta acima no Pandas:

 new_df = df.dropna(subset=["equity_comp", "cash_comp"])

Restrições

são importantes no SQL. Eles permitem que você especifique regras que mantêm seus dados seguros e consistentes. Por exemplo, a chave primária, que serve como identificador único para cada linha, deve ser única e não nula.

Pandas não tem nada parecido.

A coisa mais próxima de uma chave primária em pandas é o índice. Infelizmente, o valor do índice pode ser repetido e nulo (sim, você pode ter um índice com valores None ).

Os usuários geralmente trabalham com a suposição implícita de que o índice é uma chave primária, uma ideia reforçada pelo fato de que o índice padrão é feito de números inteiros: [0,1,2,3,4...] . Portanto, as pessoas tendem a usar o índice para referenciar linhas específicas, por exemplo, df.loc[2] .

É um tolo ato de fé. Isso se torna evidente ao concatenar ou mesclar diferentes dataframes. Muitas vezes, índices semelhantes são misturados e você obtém um índice parecido com este: [0,1,2,2,2,3...] .

Pandas não lança nenhum aviso sobre isso, então você não percebe a princípio. Mas da próxima vez que você usar df.loc[2] , seu código será interrompido porque, em vez de uma única linha, ele retornará um dataframe com três linhas.

Muitas lágrimas irão fluir antes de você descobrir que precisa executar reset_index() no dataframe mesclado para que cada linha obtenha um valor exclusivo novamente.

Além disso, as restrições SQL permitem que você execute verificações no momento da gravação. Se você tentar inserir um valor nulo em uma coluna que carrega a restrição NOT NULL , você obterá uma exceção e a gravação incorreta não acontecerá. O Pandas só permite a execução de verificações na leitura. Isto é, se você se lembrar de fazê-lo.

Operações Vetorizadas

Este é principalmente um ponto pedagógico. O Pandas, como se sabe, permite e até incentiva operações vetorizadas (onde todos os elementos de uma série são acessados em paralelo).

Mas muitas pessoas que trabalham em Python não pensam assim automaticamente. Eles começaram aprendendo loops e agora, , eles querem usar esses loops.

Quando eles começam com os pandas, eles logo descobrem os métodos iterrows e itertuples , que permitem que eles façam um loop no dataframe por linhas.

Quase inevitavelmente, eles caem em padrões de looping novamente, porque nada os força a pensar em vetores. Isso faz com que eles escrevam códigos terríveis que são executados muito lentamente.

Comecei a focar no SQL depois de uma longa experiência com pandas. Toda vez que me deparava com um problema de SQL, meu instinto era criar uma solução em loop. Frustrantemente, o SQL não me permitiu fazer isso.

Sua sintaxe declarativa me forçou a pensar em termos de operações de coluna, JOINs e funções de janela. Gradualmente, construí um novo conjunto de modelos mentais que me tornaram um analista melhor.

Acho que os alunos devem criar confiança na manipulação de dados em SQL antes de começar com pandas. Eles estarão mais bem equipados para entender quando o loop por linha é inevitável, o que é raro.

Imutabilidade

Você carrega um dataframe na memória. Você precisa modificar esse dataframe. Você o altera no local ou cria uma cópia? Você deve atualizar as colunas existentes ou criar novas?

E se você precisar criar várias fatias de dataframe e, em seguida, trabalhar em cada fatia? Você deve armazenar cada fatia em uma variável separada ou usar a mesma variável para manter diferentes fatias sucessivamente?

Quando as pessoas trabalham em pandas, elas tendem a fazer todas essas coisas ao mesmo tempo. Logo fica difícil acompanhar todas as variáveis que contêm dataframes, fatias de dataframes e fatias de fatias, e saber como os dados foram adicionados ou modificados.

(Nem sempre escrevo pandas, mas quando o faço, obtenho a .)

E como a maioria das pessoas usa pandas com notebooks, esses problemas se somam às e acabam causando grandes dores de cabeça.

Essa é uma das razões pelas quais acho que os pandas não são a melhor opção para análise de dados.

Ao processar dados em SQL, você não altera os dados originais. A UPDATE não é usada na análise. Em vez disso, você cria pipelines de tabelas e exibições que representam seleções diferentes.

Quando precisar salvar seus resultados, crie novas tabelas (ou adicione linhas a tabelas de destino existentes, mas sem modificar ou remover linhas anteriores). Isso respeita o princípio da imutabilidade : nunca modifique ou exclua dados de origem. Isso torna seu processo seguro, transparente e fácil de replicar.

Sim, você pode respeitar a imutabilidade dos pandas, mas não é óbvio que você deva fazê-lo, e muitas pessoas nunca aprendem a fazê-lo. O que você normalmente vê é a imutabilidade no nível dos arquivos : as pessoas geralmente carregam um CSV e geram um novo CSV. Mas para o trabalho que acontece no meio? Qualquer coisa serve.

(A maioria dos métodos pandas são teoricamente “puros” porque retornam um novo dataframe em vez de modificar o anterior. Mas todos eles fornecem a opção inplace que altera um dataframe no local. E as pessoas o usam com gosto.)

Quando os pandas não são suficientes

Se você fizer um trabalho sério com pandas, acabará atingindo uma parede de desempenho. Os dados que você está analisando são muito grandes ou suas necessidades de processamento são muito altas.

Eu vi isso com frequência quando fazia pesquisas com pandas. Quando isso acontecia, meus colegas e eu pesquisávamos no Google “tornar os pandas mais rápidos” e encontrávamos inúmeros artigos sobre esse assunto polêmico, que por sua vez propunham inúmeros hacks, otimizações e bibliotecas PyPI que prometiam resolver o problema.

Se você estiver nessa situação, verifique os recursos disponíveis. Especialmente aqueles que explicam como . Mas não tenha muitas esperanças. Existem limites rígidos para o que os pandas podem fazer. Tudo bem: não foi projetado para ser o fim de todas as análises de dados.

As duas melhores alternativas quando você precisa dimensionar suas cargas de trabalho de dados são:

• . O Spark é um mecanismo para análises em larga escala e processamento de dados paralelizados. O PySpark permite aproveitá-lo com o Python e usa uma sintaxe que lembra os pandas. Ele ainda tem API de pandas.

  
  

• Armazém de dados . Um sistema para armazenar e analisar dados em grande escala (pense em terabytes e petabytes). Armazéns de dados modernos são executados na nuvem para que você possa aproveitar o poder dos sistemas distribuídos sem gerenciar nenhum servidor. O BigQuery, a solução de armazenamento de dados do Google Cloud, . Armazéns de dados geralmente funcionam com SQL. (Se você quiser experimentar o BigQuery gratuitamente, )

Quando o Pandas é melhor?

Eu não quero que você evite os pandas. É uma ferramenta incrível que definitivamente vale a pena aprender.

Há casos em que o pandas é uma escolha melhor do que o SQL. Não vou entrar em detalhes aqui, mas aqui está uma lista rápida:

• Ao integrar com outros fluxos de trabalho Python, por exemplo, você está fazendo aprendizado de máquina ou deseja usar uma biblioteca de visualização Python.

  
  

• Quando você precisa de algumas estatísticas rápidas. O método describe() é muito útil.

  
  

• Quando você precisa fazer uma análise rápida, sem se preocupar com escala ou reprodutibilidade. Embora o Excel ou o Planilhas Google também funcionem.

  
  

• Se você estiver criando aplicativos Python. Pandas pode ser a maneira mais rápida de passar de uma estrutura de dados arbitrária para uma tabela e vice-versa.

  
  

• Quando você realmente precisa de fluxos de trabalho e loops imperativos. Por exemplo, construindo simulações de Markov.

  
  

• Quando você precisa escrever ou reutilizar funções incomuns. Pandas é ótimo em aplicar funções Python arbitrárias.

  
  

• Se você tem um fluxo de trabalho altamente dinâmico e parametrizado.

Conclusão

Espero que este artigo tenha estimulado você a pensar mais profundamente sobre SQL e pandas e seus pontos fortes e fracos relativos.

Acredito que a tendência atual dos dados tenha oscilado muito a favor dos pandas e que você ignore o SQL por sua própria conta e risco.

Aqui está o meu conselho:

• Se você é um aprendiz : estude SQL e aprenda a usá-lo para suas análises. Você não vai se arrepender.

  
  

• Se você é um designer de currículo : afogue seus alunos em SQL até que eles sonhem em tabelas e falem em letras maiúsculas. É um amor difícil e eles vão te odiar por isso, mas quando dia eles vão entender. (Não bata na cabeça deles.)

  
  

• Se você é um mentor : tente afastar gradualmente seus alunos do Pandas e incentivá-los a tentar problemas em SQL.

  
  

Adoraria iniciar uma conversa. Sinta-se à vontade para deixar um comentário, ou adicione-me no .