Syntaxe Pipe de BigQuery : Rendre SQL plus simple, plus rapide et plus lisible

Toute personne ayant travaillé avec SQL connaît la relation amour-haine qui va avec. SQL est puissant, standardisé et expressif, mais c’est aussi l’un des langages les moins intuitifs à lire et à maintenir à grande échelle. Plus votre requête est approfondie, plus il devient difficile de comprendre ce qui se passe réellement et dans quel ordre.

C’est parce que SQL ne se déroule pas dans l’ordre que vous pensez. Tu commences par écrire SELECTmais la base de données ne traite pas cela en premier. Le moteur démarre avec le FROM puis joint les données, les filtre, les agrège et n’applique que plus tard le tri et la projection. Le résultat est une requête écrite en arrière par rapport à la façon dont il est exécuté.

Cette inadéquation entre la syntaxe et l’exécution rend SQL à la fois lourd sur le plan cognitif et coûteux en termes de calcul. Les analystes s’appuient souvent sur des sous-requêtes ou des expressions de table communes (CTE) pour simuler un flux de haut en bas, ajoutant une complexité et une redondance inutiles. Même les utilisateurs expérimentés finissent par déboguer des blocs logiques imbriqués au lieu de se concentrer sur le problème qu’ils résolvent.

Pour résoudre ce problème, BigQuery prend en charge syntaxe du tube (|>)une évolution de SQL qui fait des requêtess s’exécutent dans le même ordre dans lequel ils sont lus. Au lieu d’écrire la logique à l’envers, vous l’écrivez étape par étape, comme un pipeline de données : chaque ligne représentant une transformation distincte. Le résultat est un SQL plus facile à comprendre, plus facile à déboguer et beaucoup plus intuitif pour l’analyse moderne des données.

L’image ci-dessus illustre le problème principal résolu par la syntaxe des tubes. En SQL traditionnel, le ordre syntaxique (comment vous écrivez une requête) n’est pas aligné avec le ordre sémantique (comment la base de données le traite réellement). Par exemple, SELECT apparaît en haut, mais le moteur ne l’évalue qu’après avoir effectué la jointure, le filtrage, le regroupement et le tri.

Cette séquence représente le flux logique et syntaxique d’une requête canal BigQuery (de haut en bas, de gauche à droite) reflétant la manière dont la base de données traite réellement les données.

• DEPUIS: Le point de départ de toute requête pipe. Définit la table ou la sous-requête initiale à partir de laquelle les données circulent. Dans la syntaxe des tuyaux, FROM peut être autonome en tant que requête valide et sert d’entrée à un pipeline séquentiel.
• REJOINDRE: Étend la table actuelle avec des colonnes et des lignes supplémentaires provenant d’une autre table ou sous-requête. Peut être utilisé plusieurs fois de suite (|> JOIN table USING (key)), rendant les arbres de jointure profonds à gauche lisibles sans sous-requêtes imbriquées.
• ENSEMBLE: Met à jour les valeurs des colonnes existantes en place (|> SET column = expression). Des fonctions comme SELECT * REPLACE(...) en SQL standard mais est plus lisible et modulaire lorsqu’il est utilisé comme étape de pipeline.
• ÉTENDRE: Ajoute des colonnes calculées à l’ensemble de données existant (|> EXTEND expression AS new_column). Semblable à SELECT *, new_column en SQL standard mais permet la création incrémentielle de champs dérivés entre d’autres opérations telles que les jointures et les filtres.
• BAISSE: Supprime une ou plusieurs colonnes de l’ensemble de données actuel (|> DROP column_name). Équivalent à SELECT * EXCEPT(column) en SQL standard et est souvent utilisé pour simplifier la sortie ou réduire la taille des données intermédiaires.
• OÙ: Filtre les lignes qui satisfont une condition (|> WHERE condition). Peut apparaître n’importe où dans le pipeline, avant ou après l’agrégation, éliminant ainsi le besoin de différents mots-clés comme HAVING ou QUALIFY.
• AGRÉGAT: Effectue des agrégations de table complète ou groupées (|> AGGREGATE SUM(column) AS total GROUP BY category). Remplace GROUP BY et les fonctions d’agrégation dans SELECT, simplifiant la syntaxe et l’alignant sur l’ordre logique des opérations.
• COMMANDER PAR : Trie les lignes par ordre croissant ou décroissant (|> ORDER BY column DESC). Produit un tableau de résultats ordonné qui peut être suivi par des opérateurs tels que LIMIT.
• LIMITE: Limite le nombre de lignes dans le résultat (|> LIMIT 10). Fonctionne après ORDER BY ou sur des tables non ordonnées, en préservant la séquence naturelle des filtres et des agrégations.
• APPEL: Exécute une fonction table ou un modèle d’apprentissage automatique en utilisant la table actuelle comme entrée (|> CALL ML.PREDICT(MODEL project.model_name)). Élimine le besoin d’appels de fonctions imbriqués, créant ainsi un flux de travail linéaire et lisible.
• SÉLECTIONNER: Définit la projection finale des colonnes à inclure dans la sortie (|> SELECT column1, column2). Sert d’opération de fermeture dans un pipeline, similaire à l’opération finale SELECT dans une requête SQL standard.

Vous trouverez ci-dessous les scénarios les plus courants dans lesquels la syntaxe des tubes simplifie la logique SQL, rendant les requêtes plus propres et plus rapides à utiliser.

Agrégation de données sans sous-requêtes

Les agrégations sont l’endroit où SQL commence à se sentir à l’envers. Si vous voulez compter quelque chose, alors comptez ces comptes, vous vous retrouvez soudainement entre parenthèses en enfer.

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;

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;

Fini l’emboîtement ou le double regroupement. Chaque étape se déroule logiquement et peut être modifiée indépendamment sans réécrire l’intégralité de la requête.

Nettoyer et transformer les colonnes étape par étape

Lorsque vous devez mettre du texte en minuscules, calculer des totaux et supprimer des colonnes supplémentaires, le SQL standard vous oblige à réécrire plusieurs colonnes. SELECT déclarations. La syntaxe des tuyaux introduit SET, EXTENDet DROP opérateurs afin que vous puissiez appliquer les modifications dans l’ordre.

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;

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

Chaque opération s’appuie sur la précédente, ce qui facilite le traçage des transformations et la réutilisation de la logique.

Filtrage après agrégation sans se souvenir de « HAVING »

L’une des bizarreries de SQL est que le timing des filtres change en fonction de la clause. Vous utilisez WHERE avant de regrouper et HAVING après, mais en réalité, les deux filtrent simplement les lignes. La syntaxe Pipe vous permet d’utiliser WHERE de manière cohérente, peu importe où vous le placez.

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

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

Vous pouvez désormais écrire des filtres dans le même ordre dans lequel vous les envisagez : filtrez d’abord les données, puis regroupez-les, puis filtrez à nouveau sur les résultats.

Requêtes de débogage sans tables temporaires

En SQL standard, la vérification d’un résultat intermédiaire nécessite soit de créer une table temporaire, soit d’encapsuler le code dans plusieurs CTE. Avec la syntaxe pipe, vous pouvez exécuter la requête jusqu’à n’importe quel point du pipeline.

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;

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

Chaque préfixe de la requête est exécutable seul, ce qui signifie que vous pouvez « jeter un œil » aux données à tout moment. C’est une manière plus propre et plus interactive de déboguer et d’itérer.

Chaînage de modèles et de fonctions sans imbrication

Lorsque vous travaillez avec des fonctions table ou des modèles BigQuery ML, l’imbrication peut rapidement devenir illisible. La syntaxe Pipe remplace ces appels imbriqués par un chaînage linéaire à l’aide de CALL.

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

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

Si vous appliquez plusieurs modèles ou transformations, vous empilez simplement des lignes CALL supplémentaires, aucune parenthèse n’est requise.

Pivotement des données sans sélections imbriquées

Le pivotement des données a toujours été un processus fastidieux, nécessitant souvent des couches de sous-requêtes. La syntaxe des tuyaux le simplifie en une seule séquence fluide.

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'));

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'));

La requête se lit désormais comme une histoire : commencez par vos données, rejoignez-les, sélectionnez ce dont vous avez besoin, puis pivotez.

Pourquoi la syntaxe des tuyaux change la donne

La syntaxe des tuyaux ne réinvente pas SQL, elle le clarifie. Il préserve tout ce qui est puissant dans la structure déclarative de SQL, mais supprime la surcharge cognitive liée à l’écriture logique à rebours.

Pour les data scientists, les analystes et les ingénieurs, cela signifie :

• Requêtes plus faciles à lire, à écrire et à déboguer
• Plus besoin de jongler avec les sous-requêtes ou les CTE pour des tâches simples
• Une logique simplifiée qui reflète votre façon de penser réellement
• Meilleures performances et moins d’opérations redondantes

La syntaxe des tubes de BigQuery est SQL adaptée à l’ère moderne des données : linéaire, intuitive et optimisée pour les analyses du monde réel.