SQL devient plus facile : annonce d'une nouvelle syntaxe de pipe

SQL est le langage de prédilection pour l'analyse de données structurées depuis plusieurs décennies, et nous avons beaucoup travaillé ces dernières années pour prendre en charge SQL ANSI et ses diverses extensions afin de rendre l'utilisation de SQL plus agréable sur Databricks. Aujourd'hui, nous sommes ravis d'annoncer la syntaxe de pipeline SQL, la plus grande extension que nous ayons réalisée ces dernières années pour rendre SQL beaucoup plus facile à écrire et à comprendre, de manière entièrement rétrocompatible.

L'un des principaux défis de SQL lui-même réside jusqu'à présent dans l'ordre de la « logique ». Lors de l'écriture d'une requête, de nombreux auteurs pensent en termes des étapes logiques suivantes : identifier la liste des tables à interroger, les joindre, filtrer les lignes indésirables, et enfin, agréger. Cet ordre logique peut être exprimé de la manière suivante :

La requête SQL pour ces étapes ressemblerait à ceci :

Au lieu d'écrire les étapes dans l'ordre (1, 2, 3), nous devons plutôt les écrire dans l'ordre (3, 2, 1). C'est déroutant et le problème ne fait que s'aggraver à mesure que nous ajoutons plus de logique et d'étapes à chaque requête.

DataFrames et ceux qui les aiment

En revanche, pensons aux DataFrames. Une grande partie de la popularité initiale d'Apache Spark auprès des data scientists réside dans la puissance de ses API DataFrame Scala et Python. Les programmes peuvent les appliquer pour exprimer leur logique dans un ordre naturel des étapes. En partant de la table source, les utilisateurs peuvent enchaîner des opérations indépendantes et composables les unes après les autres, ce qui facilite la construction de transformations de données complexes dans une séquence claire et intuitive.

Cette conception favorise la lisibilité et simplifie le débogage tout en maintenant la flexibilité. C'est une raison majeure pour laquelle Databricks a connu une croissance massive dans le secteur de la gestion des données jusqu'à présent, et cet élan ne cesse de s'accroître aujourd'hui.

Voici à quoi ressemble la même logique dans les DataFrames PySpark :

Cette approche prend en charge l'itération flexible sur les idées. Nous savons que les données sources existent dans un fichier, nous pouvons donc commencer immédiatement en créant un DataFrame représentant ces données comme une relation. Après avoir réfléchi un peu, nous réalisons que nous voulons filtrer les lignes par la colonne de chaîne de caractères. OK, nous pouvons donc ajouter une étape .filter à la fin du DataFrame précédent. Oh, et nous voulons calculer une projection à la fin, donc nous l'ajoutons à la fin de la séquence.

Beaucoup de ces utilisateurs souhaitent que SQL se comporte de manière plus similaire aux langages de données modernes comme celui-ci. Historiquement, cela n'était pas possible, et les utilisateurs devaient choisir l'une ou l'autre façon de penser.

Introduction de la nouvelle syntaxe de pipeline SQL !

Avance rapide jusqu'à aujourd'hui : il est maintenant possible d'avoir le meilleur des deux mondes ! La syntaxe de pipeline rend SQL plus facile à écrire, mais aussi à lire et à étendre plus tard, et nous libère de cette confusion en nous permettant d'utiliser simplement les mêmes étapes dans l'ordre où nous y avons pensé.

Lors de la conférence VLDB 2024, Google a publié un document industriel proposant cela comme nouvelle norme. Les ingénieurs de traitement des requêtes ont implémenté cette fonctionnalité et l'ont activée par défaut dans Apache Spark 4.0 (documentation) et Databricks Runtime 16.2 (documentation) et versions ultérieures. Elle est rétrocompatible avec la syntaxe SQL classique : les utilisateurs peuvent écrire des requêtes entières en utilisant cette syntaxe, seulement certaines sous-requêtes, ou toute combinaison utile.

Le document industriel fournit la requête 13 du benchmark TPC-H comme premier exemple :

En utilisant la syntaxe de pipeline pour exprimer la même logique, nous appliquons les opérateurs en séquence du début à la fin avec un ordre arbitraire :

Amusons-nous avec les sous-requêtes

SQL classique exige généralement que les clauses apparaissent dans un ordre spécifique, sans répétition. Si nous voulons appliquer d'autres opérations sur le résultat d'une requête SQL, la façon de le faire est d'utiliser une sous-requête de table dans laquelle nous encapsulons la requête originale entre parenthèses et l'utilisons dans la clause FROM d'une requête englobante. La requête au début de ce post montre un exemple simple de cela.

Notez que ce nesting peut se produire un nombre arbitraire de fois. Par exemple, voici la requête TPC-DS 23 :

C'est devenu compliqué et difficile à lire avec tous ces niveaux de parenthèses et d'indentation !

En revanche, avec la syntaxe pipe SQL, il n'y a pas besoin de sous-requêtes de table. Comme les opérateurs pipe peuvent apparaître dans n'importe quel ordre, nous pouvons simplement en ajouter de nouveaux à la fin à tout moment, et toutes les étapes fonctionnent de la même manière.

Démarrage facile avec rétrocompatibilité

La syntaxe pipe réorganise la façon dont les auteurs écrivent, lisent et étendent le SQL. Il peut sembler difficile de passer de la façon dont le SQL normal fonctionne à ce nouveau paradigme. Vous pourriez même avoir un grand nombre de requêtes SQL existantes que vous devez maintenir et éventuellement étendre plus tard. Comment pouvons-nous faire fonctionner cela avec deux syntaxes SQL ?

Heureusement, ce n'est pas un problème avec notre nouvelle syntaxe SQL. Elle est entièrement interopérable avec le SQL normal, où toute requête (ou sous-requête de table) peut apparaître en utilisant l'une ou l'autre syntaxe. Nous pouvons commencer à écrire de nouvelles requêtes en utilisant la syntaxe pipe SQL et conserver nos anciennes si nécessaire. Nous pouvons même commencer à remplacer les sous-requêtes de table de nos requêtes précédentes par la nouvelle syntaxe tout en gardant le reste identique, comme la mise à jour d'une partie de TPC-H Q13 à partir du début de ce post :

Comme les opérateurs pipe SQL peuvent suivre n'importe quelle requête valide, il est également possible de commencer à les ajouter à des requêtes SQL normales existantes. Par exemple :

Commencez dès aujourd'hui !

La syntaxe pipe SQL est prête à être essayée dans Databricks Runtime version 16.2 et ultérieures. Ou téléchargez Apache Spark 4.0 et essayez-la dans le monde open source. La syntaxe est conforme au document industriel Pipe Syntax in SQL, donc la nouvelle syntaxe sera portable avec Google BigQuery ainsi qu'avec le projet open source ZetaSQL.

Cette syntaxe commence également à susciter l'enthousiasme dans la communauté et à apparaître ailleurs, augmentant la portabilité maintenant et à l'avenir.

Essayez-la et découvrez les avantages de rendre les requêtes SQL plus simples à écrire pour les nouveaux utilisateurs comme pour les expérimentés, et facilitez la lisibilité et l'extensibilité futures en réduisant l'incidence des sous-requêtes complexes au profit d'opérateurs clairs et composables.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original