SQL wird einfacher: Neue Pipe-Syntax angekündigt

SQL ist seit Jahrzehnten die Lingua Franca für die Analyse strukturierter Daten, und wir haben in den letzten Jahren viel Arbeit investiert, um ANSI SQL und die verschiedenen Erweiterungen zu unterstützen, die die Verwendung von SQL auf Databricks erfreulicher machen. Heute freuen wir uns, die SQL Pipe-Syntax anzukündigen, die größte Erweiterung, die wir in den letzten Jahren vorgenommen haben, um SQL auf eine vollständig abwärtskompatible Weise dramatisch einfacher zu schreiben und zu verstehen.

Eine der größten Herausforderungen in SQL selbst liegt bisher in der Reihenfolge der „Logik“. Beim Schreiben einer Abfrage denken viele Autoren in Bezug auf die folgenden logischen Schritte: Identifizieren der zu abfragenden Tabellen, Verknüpfen dieser, Filtern unerwünschter Zeilen und schließlich Aggregieren. Diese logische Reihenfolge kann wie folgt ausgedrückt werden:

Die SQL-Abfrage für diese Schritte würde wie folgt aussehen:

Anstatt die Schritte in der Reihenfolge (1, 2, 3) zu schreiben, müssen wir sie stattdessen in der Reihenfolge (3, 2, 1) schreiben. Das ist verwirrend, und das Problem verschärft sich nur noch, wenn wir weitere Logik und Schritte zu jeder Abfrage hinzufügen.

DataFrames und die Leute, die sie lieben

Denken wir im Gegensatz dazu über DataFrames nach. Ein großer Grund für die ursprüngliche Popularität von Apache Spark bei Data Scientists ist die leistungsstarke Fähigkeit seiner Scala- und Python-DataFrame-APIs. Programme können diese nutzen, um ihre Logik in einer natürlichen Reihenfolge von Schritten auszudrücken. Ausgehend von der Quelltabelle können Benutzer unabhängige und komponierbare Operationen nacheinander verketten, was den Aufbau komplexer Datentransformationen in einer klaren und intuitiven Sequenz erleichtert.

Dieses Design fördert die Lesbarkeit und vereinfacht das Debugging bei gleichzeitiger Beibehaltung der Flexibilität. Es ist ein Hauptgrund dafür, dass Databricks sein enormes Wachstum in der Branche im Bereich Datenmanagement bisher erzielt hat, und dieser Schwung nimmt heute nur noch weiter zu.

Hier sehen Sie, wie dieselbe Logik in PySpark DataFrames aussieht:

Dieser Ansatz unterstützt flexible Iteration von Ideen. Wir wissen, dass die Quelldaten in einer Datei existieren, daher können wir sofort damit beginnen, einen DataFrame zu erstellen, der diese Daten als Relation darstellt. Nachdem wir ein wenig nachgedacht haben, stellen wir fest, dass wir die Zeilen nach der String-Spalte filtern möchten. OK, also können wir einen .filter-Schritt am Ende des vorherigen DataFrames hinzufügen. Oh, und wir möchten am Ende eine Projektion berechnen, also fügen wir das am Ende der Sequenz hinzu.

Viele dieser Benutzer wünschen sich, dass SQL sich moderneren Datensprachen wie dieser ähnlicher verhält. Historisch gesehen war dies nicht möglich, und Benutzer mussten sich für die eine Denkweise oder die andere entscheiden.

Einführung der neuen SQL Pipe-Syntax!

Schnellvorlauf bis heute: Es ist jetzt möglich, das Beste aus beiden Welten zu haben! Die Pipe-Syntax macht SQL sowohl einfacher zu schreiben als auch zu lesen und später zu erweitern, und befreit uns von dieser Verwirrung, indem sie uns erlaubt, einfach dieselben Schritte in der Reihenfolge zu verwenden, in der wir darüber nachgedacht haben.

Auf der VLDB 2024 Konferenz veröffentlichte Google ein industrielles Paper, das dies als neuen Standard vorschlägt. Query-Processing-Ingenieure haben diese Funktionalität implementiert und sie standardmäßig in Apache Spark 4.0 (Dokumentation) und Databricks Runtime 16.2 (Dokumentation) und neueren Versionen aktiviert. Sie ist abwärtskompatibel mit der regulären SQL-Syntax: Benutzer können ganze Abfragen mit dieser Syntax schreiben, nur bestimmte Unterabfragen oder jede nützliche Kombination.

Das industrielle Paper liefert Abfrage 13 aus dem TPC-H-Benchmark als erstes Beispiel:

Mithilfe der Pipe-Syntax, um dieselbe Logik auszudrücken, wenden wir Operatoren in einer beliebigen Reihenfolge von Anfang bis Ende an:

Und wie funktionieren Aggregationen?

Mit regulärem SQL fügen wir, wenn wir Zeilen basierend auf Spalten- oder Ausdruckswerten zu Gruppen zusammenfassen möchten, eine GROUP BY-Klausel am Ende der zu erstellenden SQL-Abfrage hinzu. Die durchzuführenden Aggregationen bleiben ganz oben in der SELECT-Liste ganz am Anfang der Abfrage stecken, und jeder Ausdruck muss nun entweder:

• Ein Gruppierungsschlüssel sein, in diesem Fall muss die GROUP BY-Klausel eine Kopie des Ausdrucks (oder eine Aliasreferenz oder eine Ordinalzahl) enthalten.
• Eine Aggregatfunktion wie SUM, COUNT, MIN oder MAX sein, die einen Ausdruck basierend auf Spalten der Eingabetabelle akzeptiert, wie z. B. SUM(A + B). Wir können auch Projektionen auf das Ergebnis berechnen, wie z. B. SUM(A) + 1.

Jedes SELECT-Element, das eine dieser Kategorien nicht erfüllt, löst einen Fehler aus, wie z. B. „expression X appeared in the SELECT list but was not grouped or aggregated.“

Die Regeln der WHERE-Klausel ändern sich ebenfalls:

• Wenn sie vor der GROUP BY-Klausel erscheint, filtern wir Zeilen gemäß den angegebenen Kriterien heraus, bevor wir sie zusammen aggregieren.
• Andernfalls ist die Abfrage ungültig und wir erhalten einen seltsamen Fehler. Der Benutzer muss stattdessen eine HAVING-Klausel mit derselben Filterbedingung schreiben, und diese muss nur nach der GROUP BY-Klausel erscheinen, aber nicht davor.
• Die QUALIFY-Klausel dient ebenfalls als weiteres Beispiel dafür, dass separate Syntax zum Filtern je nach Kontext verstanden und verwendet werden muss.

Die Pipe-Syntax löst dies, indem sie jede Aggregationsoperation (mit möglicher Gruppierung) in einen dedizierten Schritt trennt, der jederzeit angewendet werden kann. Nur Ausdrücke mit Aggregatfunktionen im Inneren dürfen in diesem Schritt erscheinen, und Aggregatfunktionen dürfen nicht in |> SELECT-Schritten erscheinen. Wenn der SQL-Autor eine dieser Invarianten vergisst, sind die resultierenden Fehlermeldungen sehr klar und leicht verständlich.

Es ist auch nicht mehr nötig, die Gruppierungsausdrücke zu wiederholen, da wir sie einfach in einer GROUP BY-Klausel schreiben können.

Betrachten wir das vorherige Beispiel mit einer angehängten Aggregation, die eine Ergebnistabelle mit zwei Spalten L und M zurückgibt:

Spaß mit Unterabfragen

Reguläres SQL erfordert im Allgemeinen, dass die Klauseln in einer bestimmten Reihenfolge ohne Wiederholung erscheinen. Wenn wir weitere Operationen auf das Ergebnis einer SQL-Abfrage anwenden möchten, geschieht dies mithilfe einer Tabellenunterabfrage, bei der wir die ursprüngliche Abfrage in Klammern einschließen und sie in der FROM-Klausel einer umschließenden Abfrage verwenden. Die Abfrage am Anfang dieses Beitrags zeigt ein einfaches Beispiel dafür.

Beachten Sie, dass diese Verschachtelung beliebig oft erfolgen kann. Hier ist zum Beispiel die TPC-DS-Abfrage 23:

Das wird mit all den Klammern und Einrückungen unübersichtlich und schwerer zu lesen!

Andererseits ist bei der SQL-Pipe-Syntax überhaupt keine Tabellen-Unterabfragen nötig. Da die Pipe-Operatoren in beliebiger Reihenfolge erscheinen können, können wir einfach neue hinzufügen, und alle Schritte funktionieren weiterhin auf die gleiche Weise.

Einfach loslegen mit Abwärtskompatibilität

Die Pipe-Syntax überarbeitet, wie Autoren SQL schreiben, lesen und erweitern. Es mag eine Herausforderung sein, vom Denken, wie reguläres SQL funktioniert, zu diesem neuen Paradigma zu wechseln. Möglicherweise haben Sie sogar eine große Menge bestehender SQL-Abfragen, die Sie pflegen und später möglicherweise erweitern müssen. Wie können wir das mit zwei SQL-Syntaxen zum Laufen bringen?

Glücklicherweise ist das mit unserer neuen SQL-Syntax kein Problem. Sie ist vollständig mit regulärem SQL interoperabel, wobei jede Abfrage (oder Tabellen-Unterabfrage) mit einer der beiden Syntaxen erscheinen kann. Wir können mit dem Schreiben neuer Abfragen mit der SQL-Pipe-Syntax beginnen und unsere bisherigen beibehalten, wenn nötig. Wir können sogar beginnen, Tabellen-Unterabfragen unserer bisherigen Abfragen durch die neue Syntax zu ersetzen und alles andere gleich zu lassen, wie zum Beispiel nur einen Teil von TPC-H Q13 vom Anfang dieses Beitrags zu aktualisieren:

Da Pipe-Operatoren jeder gültigen Abfrage folgen können, ist es auch möglich, sie an bestehende reguläre SQL-Abfragen anzuhängen. Zum Beispiel:

Probieren Sie es noch heute aus!

Die SQL-Pipe-Syntax kann in Databricks Runtime Version 16.2 und höher ausprobiert werden. Oder laden Sie Apache Spark 4.0 herunter und probieren Sie es in der Open-Source-Welt aus. Die Syntax entspricht dem Industriepapier Pipe Syntax in SQL, sodass die neue Syntax auch mit Google BigQuery und dem Open-Source-Projekt ZetaSQL portierbar ist.

Diese Syntax erzeugt auch in der Community Aufsehen und taucht anderswo auf, was die Portierbarkeit jetzt und in Zukunft erhöht.

Probieren Sie es aus und erleben Sie die Vorteile, SQL-Abfragen für neue und erfahrene Benutzer einfacher zu schreiben, und machen Sie zukünftige Lesbarkeit und Erweiterbarkeit einfacher, indem Sie die Häufigkeit komplexer Unterabfragen zugunsten klarer und zusammensetzbarer Operatoren reduzieren.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag