Pourquoi les gens préfèrent-ils les pandas à SQL?

J'utilise SQL depuis 1996, donc je peux être partial. J'ai beaucoup utilisé MySQL et SQLite 3, mais j'ai également utilisé Microsoft SQL Server et Oracle.

La grande majorité des opérations que j'ai vues effectuer avec des pandas peuvent être effectuées plus facilement avec SQL. Cela inclut le filtrage d'un jeu de données, la sélection de colonnes spécifiques à afficher, l'application d'une fonction à une valeur, etc.

SQL a l'avantage d'avoir un optimiseur et la persistance des données. SQL contient également des messages d'erreur clairs et compréhensibles. Les pandas ont une API quelque peu cryptique, dans laquelle il est parfois approprié d’utiliser un seul [ stuff ], parfois vous avez besoin [[ stuff ]], et parfois vous avez besoin d’un .loc. Une partie de la complexité des pandas découle du fait qu'il y a tellement de surcharge.

J'essaie donc de comprendre pourquoi les pandas sont si populaires.

La vraie première question est de savoir pourquoi les utilisateurs sont plus productifs avec les abstractions DataFrame que les abstractions SQL pures.

TLDR; SQL n'est pas axé sur le processus de développement (humain) et de débogage, contrairement aux DataFrames.

La raison principale est que les abstractions DataFrame vous permettent de construire des instructions SQL tout en évitant les imbrications verbeuses et illisibles. Le modèle d'écriture de routines imbriquées, de commentaire pour vérification, puis de suppression de commentaire est remplacé par une seule ligne de transformation. Vous pouvez naturellement exécuter les choses ligne par ligne dans une réplique (même dans Spark) et afficher les résultats.

Prenons l'exemple de l'ajout d'une nouvelle colonne transformée (chaîne tronquée) à une table, puis de la regrouper par celle-ci et de procéder à des agrégations. Le SQL devient assez moche. Les pandas peuvent résoudre ce problème, mais il manque certaines choses lorsqu'il s'agit de véritables données massives ou de partitions particulières (peut-être améliorées récemment).

Les DataFrames doivent être considérées comme une API de haut niveau pour les routines SQL, même si avec les pandas, elles ne sont pas du tout rendues à un planificateur SQL.

-

Vous pouvez probablement avoir de nombreuses discussions techniques à ce sujet, mais je considère le point de vue de l'utilisateur ci-dessous.

Une raison simple pour laquelle vous pouvez voir beaucoup plus de questions sur la manipulation de données Pandas par opposition à SQL est que, par définition, utiliser SQL signifie utiliser une base de données, et de nombreux cas d'utilisation de nos jours nécessitent tout simplement des bits de données pour ' tâches ponctuelles (à partir de .csv, web api, etc.). Dans ces cas, le chargement, le stockage, la manipulation et l'extraction d'une base de données ne sont pas viables.

Cependant, dans les cas où le cas d'utilisation peut justifier l'utilisation de Pandas ou de SQL, vous n'avez certainement pas tort. Si vous souhaitez effectuer de nombreuses tâches de manipulation de données répétitives et conserver les sorties, je vous recommande toujours d'essayer d'abord d'utiliser SQL. D'après ce que j'ai vu, la raison pour laquelle de nombreux utilisateurs, même dans ces cas-là, n'utilisent pas SQL est double.

Premièrement, le principal avantage des pandas par rapport à SQL est qu’ils font partie de l’univers plus large de Python, ce qui signifie que je peux charger, nettoyer, manipuler et visualiser mes données en un seul coup (je peux même exécuter SQL par le biais de Pandas ...). L’autre est tout simplement que trop d’utilisateurs ne connaissent pas l’étendue des capacités de SQL. Chaque débutant apprend la «syntaxe d'extraction» de SQL (SELECT, FROM, WHERE, etc.) comme moyen de transférer vos données d'une base de données vers le prochain emplacement. Certains peuvent choisir une syntaxe de groupement et d'itération plus avancée. Mais après cela, il y a un fossé assez important dans la connaissance, jusqu’à ce que vous arriviez aux experts (DBA, ingénieurs de données, etc.).

tl; dr: Cela dépend souvent du cas d'utilisation, de la commodité ou du manque de connaissances sur l'étendue des capacités de SQL.

Bien qu'il y ait un chevauchement dans l'application de ces deux choses, il s'agit de comparer des pommes à des oranges.

pandas est un toolkit d'analyse de données implémenté en Python, un langage de programmation à usage général. SQL est un langage spécifique à un domaine pour interroger des données relationnelles (généralement dans un système de gestion de base de données relationnelle, dont SQLite, MySQL, Oracle, SQL Server, PostgreSQL, etc.).

SQL implique

• Travailler avec des données dans un SGBDR * qui peut être approprié ou non pour la charge de travail, même s'il ne s'agit que d'une petite base de données SQLite,
• connaissance du domaine de la base de données (en tant qu'utilisateur final, développeur et / ou administrateur; la suggestion selon laquelle "SQL est plus rapide" est souvent une simplification excessive), et
• surmonter la courbe d'apprentissage non négligeable d'une utilisation efficace de SQL, en particulier dans des applications spécialisées telles que l'analyse de données (par opposition à la création de rapports simples à partir de données simples).

* Il convient de souligner le fait que SQL est tellement spécifique à un domaine qu'il devient de moins en moins utile pour travailler avec des alternatives de plus en plus courantes aux bases de données relationnelles telles que les bases de données NoSQL . Cela représente un changement fondamental dans la manière dont les données sont stockées et structurées, et il n’existe aucun moyen universellement commun d’y accéder, comme le développement de la normalisation SQL visé.

En revanche, Python (les pandas sont assez "pythoniques", il est donc vrai ici) est flexible et accessible à des personnes de divers horizons. Il peut être utilisé comme "langage de script", comme langage fonctionnel et comme langage POO complet. Les fonctionnalités de visualisation et l'interopérabilité des sources de données font partie intégrante des pandas, mais vous êtes libre d'incorporer tout ce que Python peut faire dans votre flux de travail (ce qui est la plupart des choses). l'écosystème scientifique Python a explosé et comprend de grands outils tels que Jupyter Notebook et essentiels SciPy bibliothèques telles que matplotlib et numpy (qui se base sur pandas). Les éléments significatifs de l'analyse des données des pandas sont R-spirés et vous ne verrez généralement pas les statisticiens dire s'ils utilisent R (ou peut-être de plus en plus de pandas!) pour tout mettre dans une base de données et écrire leurs analyses en SQL.

Je ne dis pas que les pandas valent mieux que SQL ou vice versa, mais SQL est un outil très spécifique à un domaine, alors que les pandas font partie d'un écosystème géant, flexible et accessible. Je travaille avec des systèmes de données géospatiales, dont les bases de données relationnelles représentent une part importante, et SQL est un outil puissant et essentiel. Cependant, les pandas sont une partie tout aussi essentielle, sinon plus, de ma trousse à outils quotidienne, et SQL est souvent relégué à l'extraction de données - peut-être avec un traitement préalable préalable - afin que je puisse faire des choses avec cela.

Premièrement, les pandas ne sont pas très populaires. J'utilise les deux pandas et SQL. J'essaie d'abord de comprendre la tâche: si cela peut être fait en SQL, je préfère le SQL parce qu'il est plus efficace que les pandas. Essayez de travailler sur des données volumineuses (10 000 000 x 50). Essayez de faire une opération groupby à la fois en SQL et en pandas. Tu comprendras.

J'utilise des pandas comme cela est pratique, comme si vous divisiez les valeurs d'une colonne en un tableau et que vous y travailliez (par exemple, choisissez uniquement des valeurs dans ce tableau). Maintenant, ce genre de tâche est relativement difficile à coder en SQL, mais les pandas vous faciliteront la tâche.

Je fais partie de ceux qui utiliseraient (dans mon cas) le dplyr de R (le langage, pas nécessairement l'outil) dans tous les cas si je le pouvais même si je connaissais mon code SQL.

Le principal avantage que je constate dans les pipelines Pandas / dplyr / data.table est que les opérations sont atomiques et peuvent être lues de haut en bas.

En SQL, vous devez analyser tout le script en sautant (qu'est-ce qui est résumé, jointé et comment - à gauche? À l'intérieur? À droite?, Des filtres sont-ils appliqués?) Pour bien comprendre ce qui se passe.

Dans Pandas et al, chaque étape du pipeline est autonome, elle traite les données d’entrée et renvoie les données de sortie. Ce processus séquentiel permet de raisonner plus facilement sur ce qui se passe car il existe un état clairement défini pour chaque opération plutôt que simplement. un niveau de requête.

Et oui, vous pouvez faire des WITHdéclarations et autres, mais cela nécessite beaucoup plus de code et l’objet utilisé n’est pas aussi clair que celui utilisé pour la tuyauterie.

Je suis assez nouveau dans Pandas / Python, mais j'ai plus de 20 ans d'expérience en tant que DBA, architecte, administrateur SQLServer, etc. J'aime les pandas et je m'efforce de toujours essayer de faire fonctionner les choses avant de retourner dans mon confort, monde SQL confortable.

Pourquoi les SGBDR sont meilleurs: L'avantage des SGBDR réside dans leurs années d'expérience dans l'optimisation de la vitesse des requêtes et des opérations de lecture des données. Ce qui est impressionnant, c’est qu’ils peuvent le faire tout en conciliant simultanément la nécessité d’optimiser la vitesse d’écriture et de gérer les accès hautement concurrents. Parfois, ces frais généraux supplémentaires penchent sur l’avantage de Pandas en ce qui concerne les cas d’utilisation simples à utilisateur unique. Mais même dans ce cas, un administrateur de base de données expérimenté peut optimiser une base de données pour une vitesse de lecture supérieure à celle d’écriture. Les administrateurs de bases de données peuvent tirer parti d’optimisations telles que l’optimisation du stockage des données, le dimensionnement stratégique des pages de disque, le remplissage / remplissage de page, les stratégies de contrôleur de données et de partitionnement de disque, les plans d’E / S optimisés, le brochage des données en mémoire, les plans d’exécution prédéfinis, l’indexation et la compression de données. , et beaucoup plus. De nombreux développeurs Pandas ont l’impression qu’ils ne le font pas. t comprendre la profondeur qui est disponible là-bas. Je pense que ce qui se passe habituellement, c’est que si les développeurs de Pandas n’ont jamais accès à des données suffisamment volumineuses pour pouvoir avoir besoin de ces optimisations, ils n’apprécient pas le temps qu’ils peuvent économiser. Le monde des SGBDR a 30 ans d'expérience dans l'optimisation de ce problème. Par conséquent, si un débit brut sur de grands ensembles de données est nécessaire, les SGBDR peuvent être dépassés.

Pourquoi le python et les pandas sont-ils meilleurs: Cela dit, la vitesse ne fait pas tout et dans de nombreux cas d'utilisation, ce n'est pas le facteur déterminant. Cela dépend de la façon dont vous utilisez les données, si elles sont partagées et si vous vous souciez de la rapidité du traitement. Les SGBDR sont généralement plus rigides dans leurs structures de données et obligent le développeur à être plus déterministe avec les formes de données. Les pandas vous permettent d'être plus détendu ici. De plus, et c'est ma raison préférée, vous utilisez un vrai langage de programmation. Les langages de programmation vous donnent une flexibilité infinie pour appliquer une logique avancée aux données. Bien entendu, il existe également un riche écosystème de modules et de frameworks tiers auxquels SQL ne peut s'approcher. Pouvoir très bien passer des données brutes à la présentation Web ou à la visualisation de données dans une base de code est TRÈS pratique. C'est aussi beaucoup plus portable. Vous pouvez exécuter Python presque n'importe où, y compris sur les ordinateurs portables publics, ce qui peut étendre la portée de vos résultats pour atteindre les utilisateurs plus rapidement. Les bases de données n'excèlent pas à cela.

Mon conseil? Si vous vous retrouvez en train de passer à des ensembles de données de plus en plus grands, vous devez franchir le pas et apprendre comment les SGBDR peuvent vous aider. J'ai vu des millions de requêtes d'agrégation résumées réglées entre 5 minutes et 2 secondes. Avoir cette compréhension dans votre ceinture d'outils fait de vous un scientifique des données plus complet. Vous pouvez peut-être tout faire aujourd'hui dans les pandas, mais un jour, vous aurez peut-être une tâche pour laquelle le SGBDR est le meilleur choix.

Ce que les Pandas peuvent faire, ce que SQL ne peut pas faire

1. df.describe()
2. Tracé, par exemple df['population'].plot(kind='hist')
3. Utiliser directement un cadre de données pour l'apprentissage d'algorithmes d'apprentissage automatique

Ce que les Pandas peuvent faire, je ne savais pas que SQL pouvait le faire aussi

1. Exporter vers csv: df.to_csv('foobar.sv'). Cela est important lorsque vous souhaitez montrer quelque chose à un propriétaire d’entreprise qui souhaite utiliser Excel. Et il y a df.to_excelaussi. Mais en SQL, vous pouvez le faire SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(merci vy32!)

La seule chose que je ne voudrais pas mentionner dans ces réponses est que cela dépend aussi de la façon dont vous utilisez SQL. Prenez Arcpy par exemple. Pour une raison quelconque, aucune des fonctions arcpy.da n’a de fonction d’exécution multiple. C'est vraiment étrange car pratiquement toutes les autres bibliothèques python sql le sont. L'instruction Where dans les fonctions arcpy.da est également limitée à environ 120 caractères. Cela signifie essentiellement que si vous essayez de faire assez avec votre base de données, votre seul choix consiste à appeler plusieurs fois votre fonction arcpy.da, en modifiant à chaque fois l'instruction where. Il existe quelques astuces que vous pouvez utiliser pour accélérer ce processus - vous pouvez, par exemple, parcourir plusieurs parties de votre jeu de données - mais chacune de ces astuces est littéralement beaucoup plus lente que d'utiliser un seul fichier arcpy.da. searchcursor pour charger la totalité de votre table dans un bloc de données pandas, puis le manipuler à l'aide de pandas, numpy et, si vos données sont vraiment aussi volumineuses, dask. Je dois souligner ici que les pandas ne sont pas juste un peu plus rapides dans ce cas. C'est dégoûtant plus vite. C'est tellement plus rapide que je me moquais littéralement de ne pas l'avoir fait plus tôt. En utilisant des pandas, le temps d’exécution des scripts a chuté de plus d’une heure - j’oublie s’il s’agissait du saut de 3,5 heures ou de 1,5 heure - à 12 minutes littéralement. C'est tellement plus rapide que je me moquais littéralement de ne pas l'avoir fait plus tôt. En utilisant des pandas, le temps d’exécution des scripts a chuté de plus d’une heure - j’oublie s’il s’agissait du saut de 3,5 heures ou de 1,5 heure - à 12 minutes littéralement. C'est tellement plus rapide que je me moquais littéralement de ne pas l'avoir fait plus tôt. En utilisant des pandas, le temps d’exécution des scripts a chuté de plus d’une heure - j’oublie s’il s’agissait du saut de 3,5 heures ou de 1,5 heure - à 12 minutes littéralement.

Une chose à noter est que bien que j'aurais pu faire cela avec SQL, cela m'aurait pris beaucoup plus de temps à apprendre. J'aurais dû apprendre des opérations spécifiques à SQL dans Access - c'est là que les données de ce script se sont retrouvées - - SQL dans Access n'était pas aussi robuste que j'en avais besoin lorsque je cherchais à faire cela - ou J'aurais dû écrire toutes mes données dans une base de données sqlite3, les manipuler là-bas, puis les mettre dans Access. Bien que cela puisse me donner des performances similaires, cela aurait rendu mon script plus difficile à modifier à l'avenir.

Alors oui, parfois, les Pandas et sont simplement meilleurs que d’utiliser les options SQL que vous avez à votre disposition . Tout ce que j'aurais dû faire en sql a été fait avec une fonction en pandas. Vous pouvez également utiliser la syntaxe SQL avec les pandas si vous le souhaitez. Il y a peu de raisons de ne pas utiliser pandas et sql en tandem.

Une dernière chose que je veux mentionner à propos de Pandas et Numpy est que ces deux bibliothèques sont par nature des approches basées sur les ensembles. Vous pouvez parcourir des images et des séries de données avec ces bibliothèques, mais il est très difficile de modifier des données dans ces structures. faire. Je n’ai pas déjà expérimenté SQL avec des approches basées sur les ensembles.

Une autre chose massive que j'ai oublié de mentionner avec les pandas. L' argent . Les pandas sont un outil que de nombreux emplois liés à la science des données veulent que vous sachiez comment les utiliser. Presque tous les emplois en Data Science que j'ai consultés rapportent plus que les emplois de type gestion de base de données. La seule exception à cela que j'ai remarquée concerne l'ingénierie des données, mais j'ai vu beaucoup moins de ces offres d'emploi. On dirait que les pandas vous rapportent plus d’argent en un coup d’œil.

Je pensais que j'ajouterais que je fais beaucoup d'analyse de données chronologiques, et que les pandas resampleet les reindexméthodes sont précieux pour le faire. Oui, vous pouvez faire des choses similaires en SQL (j'ai tendance à créer un DateDimensiontableau pour aider avec les requêtes relatives aux dates), mais je trouve que les méthodes pandas sont beaucoup plus faciles à utiliser.

En outre, comme d’autres l’ont dit, le reste de ma modélisation est en Python et j’ai souvent des appels Web ou des fichiers CSV.

Je vais essayer de répondre à cette question sur la base de ma propre expérience. Contrairement aux autres réponses, je préfère Sqll'apprentissage en profondeur et les éléments liés aux données volumineuses. Il y a de nombreuses raisons à cela. Comme on peut le voir ici ,

Pandas fournit une expérience d’analyse de données intuitive, puissante et rapide sur des données tabulaires. Toutefois, dans la mesure où Pandas utilise un seul thread d'exécution et nécessite que toutes les données soient en même temps en mémoire, il ne s'adapte pas correctement aux ensembles de données bien au-delà de l'échelle du gigaoctet.

Les moteurs SQL conservent généralement les clés ou les colonnes spéciales dans des structures de données telles que l' arborescence afin de faciliter les opérations CRUD. Cette structure de données conserve le statut de toutes les données de la base de données. Ce n'est pas possible pour les pandas car ils ne peuvent pas accéder à toutes les données simultanément. D'autre part, il ne peut pas effectuer certaines opérations même avec son paramètre chunk utilisé dans read_csv. Par exemple, vous ne pouvez pas effectuer d'opérations directes par lots pour des ensembles de données volumineux si votre mémoire ne les prend en charge. Toutes les autres tâches qui dépendent de l'ensemble de vos données nécessitent un codage supplémentaire. Tous ces éléments peuvent être gérés en SQL sans codage supplémentaire, avec une simple requête. Les opérations simples SQL sont simplement utilisées sans crainte pour la mémoire.$B ^+$

Une autre différence est que les opérations CRUD en Sql peuvent être appliquées avec différentes règles d’autorisation qui ne sont pas possibles dans les pandas.

Il ne s'agit pas de dire lequel est le meilleur, tout dépend de votre tâche. Pour le calcul à grande échelle, je préfère SQL et pour les petits, je préfère les pandas.

Il y a d'autres choses qui ne sont pas présentes dans les pandas et qui sont vraiment importantes pour une expérience rapide d'extraction de données que je mentionnerai plus tard. Pour l'instant, jetez un coup d'oeil ici .

Le panda est plus populaire car le python, sous la forme de cahiers jupyter, est la boîte à outils la plus populaire utilisée par les scientifiques des données dans la zone du réseau neuronal. Python devient "la" langue. Il est même possible d'utiliser le backend SQL, mais vous n'êtes pas lié à SQL uniquement avec Panda.

Pas exactement la réponse à la question, mais puisque je suis moi-même venu ici pour chercher des différences d'application pratique:

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