Die Pipe-Syntax von BigQuery: SQL einfacher, schneller und lesbarer machen

William Karr03. Nov 2025

6 Minuten gelesen

So verwenden Sie die BigQuery-Pipe-Syntax

Jeder, der mit SQL SQL ist eine Sprache mit gemischten Gefühlen. Sie ist leistungsstark, standardisiert und ausdrucksstark – aber gleichzeitig eine der unintuitivsten Sprachen, wenn es um das Lesen und die Wartung großer Datenmengen geht. Je komplexer die Abfrage wird, desto schwieriger ist es zu verstehen, was genau passiert und in welcher Reihenfolge.

Das liegt daran, dass SQL nicht in der Reihenfolge abläuft, die man erwartet. Man beginnt mit dem Schreiben SELECTDie Datenbank verarbeitet das aber nicht zuerst. Die Engine beginnt mit dem FROM Die Abfrage verknüpft die Daten, filtert und aggregiert sie und wendet erst später Sortierung und Projektion an. Das Ergebnis ist eine Abfrage, die geschrieben wird rückwärts im Verhältnis zur Art und Weise der Ausführung.

Diese Diskrepanz zwischen Syntax und Ausführung macht SQL sowohl kognitiv anspruchsvoll als auch rechenintensiv. Analysten greifen daher häufig auf Unterabfragen oder Common Table Expressions (CTE) zurück.CTEsUm einen Top-Down-Ablauf zu simulieren, wird unnötige Komplexität und Redundanz erzeugt. Selbst erfahrene Benutzer verbringen am Ende ihre Zeit damit, verschachtelte Logikblöcke zu debuggen, anstatt sich auf das eigentliche Problem zu konzentrieren.

Um das zu erwähnen, BigQuery Die `supports1s`-Anweisungen werden in der Reihenfolge ihres Lesens ausgeführt. Anstatt die Logik von innen nach außen zu schreiben, wird sie schrittweise wie in einer Datenpipeline implementiert – jede Zeile repräsentiert eine separate Transformation. Das Ergebnis ist SQL, das leichter verständlich, einfacher zu debuggen und für die moderne Datenanalyse deutlich intuitiver ist.

Die obige Abbildung veranschaulicht das Kernproblem, das die Pipe-Syntax löst. Im traditionellen SQL ist die syntaktische Reihenfolge (Wie Sie eine Abfrage schreiben) ist nicht mit dem übereinstimmen semantische Ordnung (wie die Datenbank es tatsächlich verarbeitet). Zum Beispiel: SELECT Erscheint zwar ganz oben, wird aber von der Engine erst ausgewertet, nachdem das Zusammenführen, Filtern, Gruppieren und Sortieren abgeschlossen ist.

Diese Sequenz stellt den logischen und syntaktischen Ablauf einer BigQuery-Pipe-Abfrage dar – von oben nach unten, von links nach rechts – und spiegelt damit wider, wie die Datenbank die Daten tatsächlich verarbeitet.

VON: Der Ausgangspunkt jeder Pipe-Abfrage. Definiert die Ausgangstabelle oder -unterabfrage, von der die Daten fließen. In der Pipe-Syntax: FROM kann als eigenständige, gültige Abfrage fungieren und dient als Eingang zu einer sequenziellen Pipeline.
BEITRETEN: Erweitert die aktuelle Tabelle um zusätzliche Spalten und Zeilen aus einer anderen Tabelle oder Unterabfrage. Kann mehrmals nacheinander verwendet werden (|> JOIN table USING (key)), wodurch linksverschachtelte Join-Bäume ohne verschachtelte Unterabfragen lesbar werden.
EINSTELLEN: Aktualisiert die vorhandenen Spaltenwerte an Ort und Stelle (|> SET column = expression). Funktionen wie SELECT * REPLACE(...) in Standard-SQL, ist aber lesbarer und modularer, wenn es als Pipeline-Schritt verwendet wird.
VERLÄNGERN: Fügt dem bestehenden Datensatz berechnete Spalten hinzu (|> EXTEND expression AS new_columnÄhnlich wie SELECT *, new_column in Standard-SQL, ermöglicht aber die inkrementelle Erstellung abgeleiteter Felder zwischen anderen Operationen wie Joins und Filtern.
FALLEN: Entfernt eine oder mehrere Spalten aus dem aktuellen Datensatz (|> DROP column_nameEntspricht SELECT * EXCEPT(column) wird in Standard-SQL verwendet und dient häufig dazu, die Ausgabe zu vereinfachen oder die Größe der Zwischendaten zu reduzieren.
WO: Filtert Zeilen, die eine Bedingung erfüllen (|> WHERE conditionKann an beliebiger Stelle in der Datenverarbeitungskette, vor oder nach der Aggregation, erscheinen, wodurch die Notwendigkeit unterschiedlicher Schlüsselwörter wie HAVING oder QUALIFY entfällt.
AGGREGAT: Führt vollständige Tabellen- oder gruppierte Aggregationen durch (|> AGGREGATE SUM(column) AS total GROUP BY categoryErsetzt GROUP BY und Aggregatfunktionen innerhalb von SELECT, vereinfacht die Syntax und bringt sie in Einklang mit der logischen Reihenfolge der Operationen.
SORTIEREN NACH: Sortiert Zeilen in aufsteigender oder absteigender Reihenfolge (|> ORDER BY column DESCErzeugt eine sortierte Ergebnistabelle, auf die Operatoren wie … folgen können. LIMIT.
GRENZE: Beschränkt die Anzahl der Zeilen im Ergebnis (|> LIMIT 10Funktioniert nach ORDER BY oder auf ungeordneten Tabellen, wobei die natürliche Reihenfolge der Filter und Aggregationen erhalten bleibt.
ANRUF: Führt eine Tabellenwertfunktion oder ein Modell des maschinellen Lernens unter Verwendung der aktuellen Tabelle als Eingabe aus (|> CALL ML.PREDICT(MODEL project.model_name)Dadurch entfällt die Notwendigkeit verschachtelter Funktionsaufrufe, was einen linearen und lesbaren Arbeitsablauf ermöglicht.
WÄHLEN: Definiert die endgültige Projektion der Spalten, die in die Ausgabe aufgenommen werden sollen (|> SELECT column1, column2). Dient als Abschlussvorgang in einer Pipeline, ähnlich dem letzten SELECT in einer Standard-SQL-Abfrage.

Nachfolgend sind die häufigsten Szenarien aufgeführt, in denen die Pipe-Syntax die SQL-Logik vereinfacht und so für übersichtlichere und schnellere Abfragen sorgt.

Datenaggregation ohne Unterabfragen

Bei Aggregationen fängt SQL an, sich wie auf dem Kopf stehend zu fühlen. Wenn man etwas zählen und dann diese Zählungen zählen möchte, landet man plötzlich im Klammerchaos.

SQL

SELECT c_count, COUNT(*) AS custdist
FROM (
  SELECT c_custkey, COUNT(o_orderkey) AS c_count
  FROM customer
  JOIN orders ON c_custkey = o_custkey
  WHERE o_comment NOT LIKE '%unusual%packages%'
  GROUP BY c_custkey
)
GROUP BY c_count
ORDER BY custdist DESC;

Pipe-Syntax

FROM customer
|> JOIN orders ON c_custkey = o_custkey
   AND o_comment NOT LIKE '%unusual%packages%'
|> AGGREGATE COUNT(o_orderkey) AS c_count GROUP BY c_custkey
|> AGGREGATE COUNT(*) AS custdist GROUP BY c_count
|> ORDER BY custdist DESC;

Verschachtelungen und doppelte Gruppierungen gehören der Vergangenheit an. Jeder Schritt ist logisch aufgebaut und kann unabhängig voneinander angepasst werden, ohne die gesamte Abfrage neu schreiben zu müssen.

Reinigung und Umgestaltung von Säulen Schritt für Schritt

Wenn Sie Text in Kleinbuchstaben umwandeln, Summen berechnen und überflüssige Spalten entfernen müssen, zwingt Sie Standard-SQL dazu, mehrere Stellen neu zu schreiben. SELECT Pipe-Anweisungen. Die Pipe-Syntax führt ein SET, EXTEND und DROP Operatoren, damit Sie Änderungen nacheinander anwenden können.

SQL

SELECT o_custkey, ROUND(o_totalprice) AS total_price
FROM (
  SELECT
    o_custkey,
    o_totalprice,
    LOWER(o_orderstatus) AS o_orderstatus
  FROM orders
)
WHERE total_price > 1000;

Pipe-Syntax

FROM orders
|> SET o_orderstatus = LOWER(o_orderstatus)
|> EXTEND ROUND(o_totalprice) AS total_price
|> WHERE total_price > 1000
|> SELECT o_custkey, total_price;

Jeder Vorgang baut auf dem vorherigen auf, wodurch Transformationen leichter nachvollzogen und Logik wiederverwendet werden kann.

Filtern nach der Aggregation ohne Berücksichtigung von „HAVING“

Eine Besonderheit von SQL ist, dass sich die Ausführungszeit von Filtern je nach Klausel ändert. WHERE vor der Gruppierung und HAVING danach, aber in Wirklichkeit filtern beide nur Zeilen. Die Pipe-Syntax ermöglicht Ihnen die Verwendung von WHERE gleichbleibend, egal wo man es platziert.

SQL

SELECT department, COUNT(*) AS emp_count
FROM employees
WHERE active = TRUE
GROUP BY department
HAVING COUNT(*) > 5;

Pipe-Syntax

FROM employees
|> WHERE active = TRUE
|> AGGREGATE COUNT(*) AS emp_count GROUP BY department
|> WHERE emp_count > 5;

Jetzt können Sie Filter in der gleichen Reihenfolge schreiben, in der Sie darüber nachdenken: zuerst die Daten filtern, dann gruppieren und dann die Ergebnisse erneut filtern.

Abfragen ohne temporäre Tabellen debuggen

In Standard-SQL erfordert die Überprüfung eines Zwischenergebnisses entweder das Erstellen einer temporären Tabelle oder das Einbetten des Codes in mehrere CTEs. Mit der Pipe-Syntax können Sie die Abfrage bis zu einem beliebigen Punkt in der Pipeline ausführen.

SQL

WITH filtered AS (
  SELECT * FROM orders WHERE o_totalprice > 500
),
summed AS (
  SELECT o_custkey, SUM(o_totalprice) AS total
  FROM filtered GROUP BY o_custkey
)
SELECT * FROM summed WHERE total > 10000;

Pipe-Syntax

FROM orders
|> WHERE o_totalprice > 500
|> AGGREGATE SUM(o_totalprice) AS total GROUP BY o_custkey
|> WHERE total > 10000;

Jeder Teil der Abfrage ist einzeln ausführbar, sodass Sie die Daten in jeder Phase einsehen können. Dies ermöglicht ein übersichtlicheres und interaktiveres Debugging und Iteration.

Verkettung von Modellen und Funktionen ohne Verschachtelung

Bei der Arbeit mit Tabellenwertfunktionen oder BigQuery ML-Modellen kann die Verschachtelung schnell unübersichtlich werden. Die Pipe-Syntax ersetzt diese verschachtelten Aufrufe durch eine lineare Verkettung mit CALL.

SQL

SELECT *
FROM ML.PREDICT(
  MODEL `project.sentiment_model`,
  (SELECT text FROM reviews)
);

Pipe-Syntax

SELECT text FROM reviews
|> CALL ML.PREDICT(MODEL `project.sentiment_model`);

Wenn Sie mehrere Modelle oder Transformationen anwenden, fügen Sie einfach zusätzliche CALL-Zeilen hinzu – Klammern sind nicht erforderlich.

Pivotieren von Daten ohne verschachtelte Auswahlen

Das Pivotieren von Daten war schon immer ein mühsamer Prozess, der oft mehrere Unterabfragen erforderte. Die Pipe-Syntax vereinfacht ihn zu einer einzigen, fließenden Sequenz.

SQL

SELECT *
FROM (
  SELECT n_name, c_acctbal, c_mktsegment
  FROM customer JOIN nation USING (n_nationkey)
)
PIVOT(SUM(c_acctbal) FOR n_name IN ('PERU', 'KENYA', 'JAPAN'));

Pipe-Syntax

FROM customer
|> JOIN nation USING (n_nationkey)
|> SELECT n_name, c_acctbal, c_mktsegment
|> PIVOT(SUM(c_acctbal) FOR n_name IN ('PERU', 'KENYA', 'JAPAN'));

Die Abfrage liest sich nun wie eine Geschichte: Man beginnt mit den Daten, verknüpft sie, wählt aus, was man braucht, und pivotiert dann.

Warum die Pipe-Syntax alles verändert

Die Pipe-Syntax erfindet SQL nicht neu – sie verdeutlicht es. Sie bewahrt alle Stärken der deklarativen Struktur von SQL, beseitigt aber den kognitiven Aufwand, Logik rückwärts zu schreiben.

Für Datenwissenschaftler, Analysten und Ingenieure bedeutet das: