Les bibliothèques R et / ou Python modernes rendent-elles SQL obsolète?

Je travaille dans un bureau où SQL Server est l'épine dorsale de tout ce que nous faisons, du traitement des données au nettoyage en passant par le munging. Mon collègue est spécialisé dans l'écriture de fonctions complexes et de procédures stockées pour traiter méthodiquement les données entrantes afin qu'elles puissent être standardisées et mises en œuvre dans des rapports, des visualisations et des projets d'analyse. Avant de commencer ici, j'avais très peu d'expérience avec SQL, à part écrire les requêtes les plus élémentaires. La grande majorité de mon travail de préparation à l'analyse a été entièrement effectuée dans R. Mon patron insiste pour que j'améliore mes compétences SQL, même s'il semble y avoir très peu de tâches qui ne peuvent pas être effectuées plus efficacement et avec beaucoup moins de lignes de code en utilisant R des packages comme dplyr, data.table et tidyr (pour n'en nommer que quelques-uns). Ma question est - est-ce que cela a du sens?

Il y a quelques semaines, je me suis retrouvé confronté à la tâche d'obtenir une liste de noms de colonnes pour chaque ligne d'un tableau qui répondait à certains critères et de les concaténer en un vecteur de chaînes. Il y avait un délai serré et à l'époque, je rencontrais un blocage et je ne pouvais pas tout à fait comprendre le problème. J'ai demandé à mon patron, qui à son tour a demandé à mon collègue d'écrire un script TSQL pour résoudre le problème. Pendant qu'il y travaillait, j'ai trouvé un moyen de le faire en écrivant une fonction assez simple et en l'appliquant sur la trame de données. Mon collègue est revenu avec son script environ deux heures plus tard. Il s'agissait d'au moins 75 lignes comprenant deux boucles imbriquées. Je lui ai demandé d'avertir quand la course serait terminée et il a dit que cela prendrait plusieurs heures. Pendant ce temps, mon script R a pu parcourir les 45 000 enregistrements en environ 30 secondes.

Ai-je raison de supposer que R est un bien meilleur choix pour le nettoyage et la fusion des données? Peut-être que le développeur SQL de mon bureau est tout simplement incompétent? Je suis curieux de savoir si quelqu'un qui a travaillé à la fois avec R et SQL (ou Python et SQL d'ailleurs) a des idées à ce sujet.

R et SQL sont deux bêtes complètement différentes. SQL est un langage que vous pouvez utiliser pour interroger des données stockées dans des bases de données comme vous l'avez déjà vécu. Les avantages de SQL par rapport à R résident principalement dans le fait du serveur de base de données (MS SQL, Oracle, PostgreSQL, MySQL, etc.).

La plupart, sinon la totalité, des serveurs de bases de données modernes permettent à plusieurs utilisateurs d'interroger des données à partir de la même source de données et d'insérer, de mettre à jour et de supprimer des données dans les mêmes tables tout en garantissant la cohérence des données. Ceci est essentiel pour, par exemple, enregistrer une transaction bancaire. Pouvez-vous imaginer gérer une banque sur R? C'est là qu'interviennent les serveurs de bases de données. Ils garantissent les propriétés ACID des procédures exécutées sur la base de données. ACID signifie atomicité, simultanéité, isolement et durabilité (voir la description d'ACID sur wikipedia ). R est une plate-forme mono-utilisateur où tout se passe en mémoire. Donc, si votre ordinateur cesse de fonctionner à mi-chemin dans une grande opération, vos données ne seront pas stockées. Vous êtes également la seule personne qui peut accéder aux données. Pour être clair, R n'est pas considéré comme une alternative pour les serveurs de base de données et / ou SQL.

Un autre avantage principal des serveurs de bases de données est qu’une bonne conception de la base de données garantira que vous pourrez interroger votre base de données rapidement en optimisant les requêtes. Pour atteindre cette base de données, les serveurs gardent une trace de la conception d'une table. Voir pour une discussion complète de ce sujet la page wiki . R ne peut pas effectuer d'optimisation de requête. Une mauvaise conception de la base de données peut ralentir l'exécution de vos requêtes. Les serveurs de base de données peuvent également effectuer une optimisation sur des requêtes qui interrogent plusieurs tables si les clés étrangères sont correctement utilisées dans la conception de la base de données.

Le langage SQL a une syntaxe très différente et je partage votre expérience selon laquelle il est plus court d'écrire des étapes de fusion de données en utilisant la table de données ou la syntaxe dplyr. Cependant, parfois vos données sont trop volumineuses pour R ou vous devez stocker les résultats dans la base de données dans le cadre d'un travail par lots périodique, qui nécessitera de coder votre logique en SQL.

D'après mon expérience, il existe des cas d'utilisation particuliers pour SQL et R / Python. SQL est idéal pour stocker des données critiques pour l'entreprise et pour permettre à plusieurs personnes d'accéder, de modifier, d'insérer et de supprimer des données dans un environnement centralisé. Pour tout transfert de données ponctuel, R et Python sont parfaits. Si votre fusion de données doit être exécutée périodiquement, vous devrez porter votre script R / Python sur SQL.

Ce ne sont même pas vraiment comparables. SQL est un langage destiné à accéder aux données, R est un langage destiné à travailler avec les données.

SQL n'est pas un outil efficace pour le munging car il est difficile de voir les étapes intermédiaires et lorsqu'il génère des erreurs, il est peu probable qu'il traite de la forme / qualité / structure de vos données.

Mon flux de travail est généralement:

1. Obtenir des données brutes à partir d'une requête SQL (dans R)
2. Construire une routine de munging
3. Si possible, réécrivez la requête SQL pour accomplir le munging que j'ai accompli dans R

Sachez également que tous les consommateurs de données n'utilisent pas R, mais que beaucoup interfèrent toujours avec la plate-forme de leur choix avec des données utilisant SQL.

la bibliothèque (dbplyr) a la bonne approche: tout écrire en R (en utilisant le tidyverse) et laisser la bibliothèque juste à temps "compiler" le code R en SQL bas niveau.

Étant donné que tous les mungings ne sont pas traduisibles, une autre approche est celle adoptée par SQL Server: laissez les extraits de code R être invoqués à partir des commandes SQL "select".

D'après mon expérience, l'approche 1., 2., 3. mentionnée par HEITZ est possible avec une alternative pour 3. où vous réécrivez vos données de R (data.table) dans MySQL.

Les étapes complètes sont donc MySQL-> data.table-> MySQL

Si vous vous assurez que vous utilisez la syntaxe data.table où vous ne copiez pas le DT, il est également compatible avec la RAM.

En un mot NON . SQL est un moyen puissant, concis et flexible pour décrire et résumer des données structurées semi-structurées et même non structurées - lorsqu'une couche d'interpréteur appropriée est placée au-dessus. Soit dit en passant, sqlest considéré comme un incontournable pour les scientifiques des données.

SQL est un moyen concis et puissant pour effectuer ses opérations principales de:

• projections ( sélectionnez ..)
• filtrage ( où ..)
• regroupement / filtrage ( regrouper par et avoir )
• agrégations de base ( nombre , somme , avg ..)
• rejoint

La véritable puissance vient de la combinaison des résultats à l'aide de vues intégrées . Quand je dois faire que je vais utiliser l' un sqldf, pandasql, pysparkSql/ sparkSqlou une connexion directe de SGBDR. Écrire la même chose de la manière la plus concise possible avec data.table(beaucoup mieux que data.frame) ou datatable(mieux que pandas) est encore plus maladroit, beaucoup plus maladroit ou presque impossible selon la complexité des requêtes tentées.

Pour le data munging : c'est une autre histoire: certaines opérations s'expriment facilement en sql et d'autres pas tellement. Cependant, lorsque vous incorporez UDFs, il y a une plus grande latitude de ce qui peut être réalisé. Ma tâche actuelle comprend un certain nombre de tâches UDFpour effectuer des opérations telles que les opérations d' intersection client , les agrégations personnalisées et les méthodes de notation personnalisées .