BigQuery unterstützt jetzt die SQL-Pipe-Syntax

Was ist die Pipe Query Syntax?

• Eine erweiterte Syntax von GoogleSQL, mit der sich Abfragen in einer gut lesbaren und wartungsfreundlichen linearen Struktur schreiben lassen
• Unterstützt dieselben Operationen wie bisheriges GoogleSQL (Standard SQL), etwa Auswahl, Gruppierung, Joins und Filterung
• Die Reihenfolge der Operationen kann frei festgelegt werden, und auch komplexe Abfragen lassen sich ohne verschachtelte Unterabfragen schreiben

Standard SQL vs. Pipe Query Syntax

• Standard SQL
  • Es muss eine bestimmte Syntaxreihenfolge eingehalten werden
  • Bei mehreren Aggregationen sind CTEs (Common Table Expressions) oder verschachtelte Unterabfragen erforderlich
  • Dieselben Spalten müssen in SELECT, GROUP BY und ORDER BY wiederholt angegeben werden
• Pipe Query Syntax
  • Pipe-Operatoren können in beliebiger Reihenfolge angewendet werden
  • Mehrere Aggregationen lassen sich einfach durch Hinzufügen von Pipe-Operatoren durchführen
  • Spalten müssen nur einmal deklariert werden

Grundstruktur der Pipe Query Syntax

• 1. Beginn mit der FROM-Klausel
• 2. Nach |> (Pipe-Operator) eine Operation hinzufügen
• 3. Mehrere |>-Operatoren verketten, um die Abfrage schrittweise aufzubauen
     (Beispiel: Die Reihenfolge von Filtern → Aggregieren → Joinen kann geändert werden)
• Zentrale Eigenschaften
  • Der Pipe-Operator kann jeder Abfrage hinzugefügt werden → bestehende GoogleSQL-Abfragen lassen sich erweitern, indem am Ende ein |>-Operator angehängt wird
  • Die Reihenfolge der Operationen ist frei → Operatoren können in beliebiger Reihenfolge und beliebig oft angewendet werden
  • In allen von GoogleSQL unterstützten Umgebungen nutzbar → einsetzbar in Abfragen, Views, tabellenrückgebenden Funktionen usw.
  • Kann mit bestehender SQL-Syntax kombiniert werden → Unterabfragen können in Standard SQL, die Hauptabfrage in Pipe-Syntax geschrieben werden
  • Auf alle in vorherigen Schritten definierten Aliase kann verwiesen werden
  • Kann mit der FROM-Klausel beginnen → die Abfrage lässt sich anschließend durch Hinzufügen von |>-Operatoren schrittweise erweitern

Unterschiede zwischen Pipe Query Syntax und Standard SQL

• Eine Abfrage kann mit der FROM-Klausel beginnen
• Der SELECT-Pipe-Operator führt keine Aggregation aus. Aggregationen werden separat mit dem AGGREGATE-Pipe-Operator durchgeführt
• Die Filterung erfolgt mit dem WHERE-Pipe-Operator. Er fasst die Funktionen von WHERE, HAVING und QUALIFY aus Standard SQL zusammen. Filterung ist in jeder Phase möglich → ermöglicht flexiblere Abfragen

Vorteile der Pipe Query Syntax

• Abfragen lassen sich in logischer Reihenfolge schreiben → bessere Lesbarkeit
• Leichtere Wartung → auch komplexe Operationen sind ohne verschachtelte Unterabfragen möglich
• Flexible Reihenfolge der Operationen → Operatoren können in der gewünschten Reihenfolge angewendet werden
• Intuitivere Filterung → mit WHERE lassen sich Daten in verschiedenen Phasen filtern
• Komplexe Aggregationsabfragen lassen sich einfacher schreiben → mit dem AGGREGATE-Operator werden Aggregationen klarer formuliert

Wird in der Pre-GA-Phase unterstützt, die Unterstützung ist derzeit noch eingeschränkt

[carnoxen]

https://github.com/tc39/proposal-pipeline-operator

Ein ziemlich vertraut wirkender Operator.

[halfenif]

Wenn man sich zuerst PRQL ansieht und dann Googles Pipeline-Syntax, wirkt sie etwas unruhig.

[GN⁺]

Hacker-News-Kommentare

• Die Pipe-Syntax für SQL wurde am 30. Januar 2025 in Databricks implementiert

  • Zuvor war SQL schwer zu erweitern, und Table-Valued Functions waren komplex
  • Jetzt sind Datenanreicherung, Vorhersagen, Gruppierungen usw. mit Higher-Order Functions möglich
  • Man kann zum Beispiel Bestellungen nach einem bestimmten Datum filtern, dann die Gesamtausgaben pro Kunde aggregieren, anschließend Kunden ab einem bestimmten Betrag herausfiltern und sie mit Kundeninformationen joinen
  • Wiederholbares SQL mit Pipes könnte zusammen mit GenAI besser funktionieren

• PRQL ist eine ähnliche Idee, die zu SQL kompiliert wird

  • Man kann zum Beispiel Rechnungsdaten filtern, Gebühren berechnen und anschließend Datensätze mit Einnahmen ab einem bestimmten Betrag herausfiltern

• Wenn sich die SQL-Syntax weiter ausdehnt, könnte die Komplexität zunehmen

  • Es wäre wünschenswert, wenn sich SQL-Implementierer stärker auf Source Maps und Ähnliches konzentrieren würden, damit externe alternative Syntaxen besser unterstützt werden
  • So könnten einzelne Projekte oder Personen die für sie passende SQL-Syntaxvariante wählen

• Als die Pipe-Syntax erstmals angekündigt wurde, hat das SQLite-Team sie ausprobiert

  • Dabei stellte sich heraus, dass das Pipe-Zeichen nicht zwingend erforderlich ist und die Syntax auch funktioniert, wenn es optional ist
  • Ich persönlich finde, dass diese Variante besser aussieht

• PRQL ist eine pipe-orientierte Syntax für SQL-Datenbanken; da es sich um eine neue Sprache handelt, ist sie nicht abwärtskompatibel zu SQL

  • Es hat nicht die Unterstützung großer Unternehmen wie Google, aber die Syntax ist sauberer

• Funktioniert auch in DuckDB

• Es könnte lästig sein, nach der Pipe ein > einzugeben

• Die Sprache Malloy ist keine Pipe-Syntax, hat aber eine ähnliche analytische Syntax

  • Entwickelt von Lloyd Tabb, Mitgründer von Looker

• Seit ich Kusto Query Language verwendet habe, hoffe ich, dass SQL solche Funktionen ebenfalls bekommt

  • Wenn genug Datenbanken das als Erweiterung unterstützen, könnte das realistisch werden