Foto de no Pedro Gonzalez Unsplash 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 da análise de dados por décadas. língua franca 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 , ou seja, a pessoa simplesmente fica mais confusa com o tempo. fazer mais pandas resulta em anti-aprendizagem 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 pandas com tipos mistos). Parte disso vem do fato de que os pandas aceitam (embora não necessariamente encorajem) uma abordagem imperativa. Series Por exemplo, se um aluno deseja combinar dados de duas tabelas, nada o impede de usar este algoritmo: Percorrer a table1 Para cada linha da , escaneie toda a para uma pesquisa table1 table2 Atualize a linha na a partir dos dados na table1 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. . 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. A programação declarativa força o usuário a pensar em termos do resultado que deseja ver, em vez de como produzi-lo O SQL também força os alunos a (ou seja, modelo relacional) e operações em nível de coluna, o que é altamente benéfico quando seu primeiro instinto é repetir tudo. pensar em tabelas 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 . Especialmente quando se trata de iniciantes, que estão aprendendo sobre o Pandas antes de poderem fazer um adequado. enfatizar demais os pandas em detrimento do SQL faz mais mal do que bem MultiIndex GROUP BY 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 do SQL permite: SELECT Escolha as colunas que deseja e a ordem em que devem ser retornadas. Crie novas colunas com base em combinações e transformações de colunas existentes. 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 ( ) enquanto selecionar várias colunas requer um conjunto duplo de colchetes ( ). df[”first_name”] 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 ou ou ou qualquer outro dos muitos atributos padrão de um dataframe (você pode vê-los todos com ). count shape diff 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 (consulte Filtragem abaixo). WHERE Selecionar linhas no Pandas é... complexo. Para ver o quão complexo, verifique o . Ou mergulhe em um . guia inicial do usuário tutorial típico de 30 minutos Limitar-me-ei a um único exemplo. Cada DataFrame tem um . O índice padrão é uma sequência de inteiros: . Index [0,1,2,3,4,5...] Naturalmente, a maioria das pessoas assume que o índice representa a cardinalidade das linhas. os números são apenas rótulos categóricos! Eles também podem ser letras aleatórias como . Não há cardinalidade implícita. Na verdade, ['x', 'z', 'a'] Para obter uma linha por seu índice, você usa . Mas para selecionar pela cardinalidade da linha, você usa . df.loc 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 . Sim, tudo isso é permitido! E não há restrições para evitá-lo (consulte Restrições abaixo). [7, 2, 2, 'c', True, None] Imagine que você escreveu seu código assumindo que o índice representava a cardinalidade da linha. Agora: retornará a primeira linha df.loc[7] retornará uma fatia do dataframe em vez de uma linha (porque ocorre mais de uma vez no índice) df.loc[2] retornará uma linha real! df.loc[None] Eu não estou chorando, você está chorando. E sim: o pode retornar um valor escalar, uma linha ou uma fatia do dataframe dependendo de como o índice é composto. Os reconhecem essa loucura: mesmo método pandas docs Outros métodos, como indexação, podem dar resultados surpreendentes. Normalmente, a indexação com um escalar . Fatiar um com um escalar retornará um . Fatiar uma com um escalar retornará um escalar. Mas com [index] duplicados, este não é o caso. reduzirá a dimensionalidade DataFrame Series Series 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 e para valores únicos. Outra coisa a lembrar e evitar confusão.) df.at df.iat Filtragem No SQL, a filtragem é direta. Escreva , insira quantas instruções quiser e encadeie-as com operadores lógicos. Os colchetes oferecem mais controle sobre a estruturação das expressões. WHERE 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: indexação booleana Você pega uma (que é o objeto da coluna) e executa cada elemento por meio de um teste booleano. Transformando-a assim em uma nova composta por valores booleanos (verdadeiro ou falso). Series Series Você seleciona o dataframe com esta coluna, o que acaba excluindo as linhas onde a booleana contém um valor falso. Series Observe a suposição oculta aqui? A usada para filtrar e o dataframe que está sendo filtrado precisam compartilhar o mesmo índice, na mesma ordem. Isso nem sempre é garantido. Series Na prática, a indexação booleana significa que, ao filtrar, você sempre deve repetir a variável do dataframe, por exemplo, . Isso é muito chato quando você está escrevendo muito código! Veja o exemplo acima: a variável dataframe é referenciada 4 vezes. salaries[salaries["cash_comp"] > 20] 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 parece fornecer .) df.query() um método melhor para filtragem 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 . Claro, pode ser esquerdo/direito e interno/externo, mas o uso é bastante direto. JOIN O Pandas tem dois métodos: e . Nunca entendi por que precisamos de dois. deve funcionar em índices, deve funcionar em qualquer coluna. join merge join merge 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 , pois é mais um método herdado.) 1 2 merge join 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 , acompanhar a origem de cada coluna e depois filtrar o resultado. role 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 . Isso pode significar uma das três coisas: object A coluna contém apenas strings A coluna contém objetos Python que não são um tipo de dados primitivo, por exemplo, lista ou dicionário A coluna contém tipos mistos Quando você vê o tipo de dados do , nunca sabe qual é o caso. Eu acho isso muito chato. object 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 ). Eu ingenuamente faria isso: object 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. O formato CSV é subespecificado A perda de esquema é normalmente o maior problema para as pessoas que trabalham em pandas. Esta é uma situação comum: 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 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). muitos argumentos read_csv 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. 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). 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 . Eu mesmo fiz isso! Mas agora eu me pergunto: por que ensinamos as pessoas a trabalhar assim? O que justifica tamanha loucura e crueldade? inúmeras vezes 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: 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. Por que preciso de uma camada de arquivo? O mundo não precisa de mais CSVs. Nota: algumas pessoas tentam resolver o problema do esquema seus quadros de dados. . conservando Esta é uma idéia terrível 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 nativo do Python (que o Pandas exibe como , mas trata como ) None None nan numpy.nan pandas.NA (para datas e horas) pandas.NaT Vamos nos concentrar no , que é o mais comum: numpy.nan O tipo deste objeto é , então esqueça de detectá-lo com verificações de tipo. float É verdade, então esqueça os testes booleanos. é . bool(np.nan) True Ele falha no teste de igualdade, pois é falso. não é igual a si mesmo! numpy.nan == numpy.nan nan Usar em uma operação não lança uma exceção, apenas significa que o resultado é . nan nan Isso não é divertido? A única maneira de detectar um é usar . Tudo bem, depois de ler os documentos e esquecer todos os seus instintos pitônicos. Ainda assim, esse comportamento é extremamente confuso para iniciantes. nan pandas.isna() 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. As restrições 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: . Portanto, as pessoas tendem a usar o índice para referenciar linhas específicas, por exemplo, . [0,1,2,3,4...] 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 , seu código será interrompido porque, em vez de uma única linha, ele retornará um dataframe com três linhas. df.loc[2] Muitas lágrimas irão fluir antes de você descobrir que precisa executar no dataframe mesclado para que cada linha obtenha um valor exclusivo novamente. reset_index() 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 , 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. NOT NULL 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. por Guido Quando eles começam com os pandas, eles logo descobrem os métodos e , que permitem que eles façam um loop no dataframe por linhas. iterrows itertuples 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 .) configuração com aviso de cópia E como a maioria das pessoas usa pandas com notebooks, esses problemas se somam às e acabam causando grandes dores de cabeça. armadilhas típicas dos notebooks 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 não é usada na análise. Em vez disso, você cria pipelines de tabelas e exibições que representam seleções diferentes. UPDATE 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 : nunca modifique ou exclua dados de origem. Isso torna seu processo seguro, transparente e fácil de replicar. imutabilidade Sim, você 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 : as pessoas geralmente carregam um CSV e geram um novo CSV. Mas para o trabalho que acontece no meio? Qualquer coisa serve. pode arquivos (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 que altera um dataframe no local. E as pessoas o usam com gosto.) inplace 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. usar melhor os pandas 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. PySpark . 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, ) Armazém de dados pode processar 100 bilhões de linhas ou 7 terabytes de dados em 30 segundos escrevi sobre isso aqui. Quando o Pandas é melhor? Eu não quero que você evite os pandas. É uma ferramenta incrível que definitivamente vale a pena aprender. 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: Há 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 é muito útil. describe() 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ê precisa de fluxos de trabalho e loops imperativos. Por exemplo, construindo simulações de Markov. realmente 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: : estude SQL e aprenda a usá-lo para suas análises. Você não vai se arrepender. Se você é um aprendiz : 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 designer de currículo : tente afastar gradualmente seus alunos do Pandas e incentivá-los a tentar problemas em SQL. Se você é um mentor Adoraria iniciar uma conversa. Sinta-se à vontade para deixar um comentário, ou adicione-me no . escreva-me um e-mail LinkedIn
