BigQuery、SQLパイプ構文が利用可能に

 (cloud.google.com)
13 ポイント 投稿者 GN⁺ 2025-02-18 | 3件のコメント | WhatsAppで共有

Pipe Query Syntaxとは？

  • GoogleSQLの拡張構文で、読みやすく保守しやすい線形構造のクエリを記述可能
  • 既存のGoogleSQL（Standard SQL）と同じ演算をサポート（選択、グループ化、結合、フィルタリングなど）
  • 演算順序を自由に指定でき、ネストしたサブクエリなしでも複雑なクエリを記述可能

Standard SQL vs Pipe Query Syntax

  • Standard SQL
    • 特定の構文順序に従う必要がある
    • 複数の集計を使う場合、CTE（Common Table Expression）またはネストしたサブクエリが必要
    • SELECT、GROUP BY、ORDER BYで重複したカラムを繰り返し記述する必要がある
  • Pipe Query Syntax
    • Pipe演算子をどの順序でも適用可能
    • Pipe演算子を追加するだけで簡単に複数集計が可能
    • カラムは一度だけ宣言すればよい

Pipe Query Syntaxの基本構造

    1. FROM句で開始
    1. |>（Pipe演算子）の後に演算を追加
    1. 複数の |> 演算子をつなげて段階的にクエリを構成
      （例: フィルタリング → 集計 → 結合の順序変更が可能）
  • 主な特性
    • どのクエリにもPipe演算子を追加可能 → 既存のGoogleSQLクエリの末尾に |> 演算子を付けて拡張可能
    • 演算順序が自由 → 任意の順序で、必要な回数だけ演算子を適用可能
    • すべてのGoogleSQL対応環境で利用可能 → クエリ、ビュー、テーブル返却関数などで活用可能
    • 既存のSQL構文と混在して使用可能 → サブクエリは標準SQL、メインクエリはPipe構文で記述可能
    • 前の段階で定義したすべての別名（Alias）を参照可能
    • FROM句から開始可能 → その後に |> 演算子を追加して段階的にクエリを拡張可能

Pipe Query Syntax と Standard SQL の違い

  • FROM句からクエリを開始可能
  • SELECT Pipe演算子は集計を実行しない。AGGREGATE Pipe演算子を使って別途集計を実行
  • WHERE Pipe演算子でフィルタリングを実行。標準SQLのWHERE、HAVING、QUALIFY機能を1つに統合。どの段階でもフィルタリング可能 → 柔軟なクエリ記述が可能

Pipe Query Syntaxの利点

  • 論理的な順序でクエリを記述可能 → クエリの可読性向上
  • 保守が容易 → ネストしたサブクエリなしでも複雑な演算が可能
  • 柔軟な演算順序 → 任意の順序で演算を適用可能
  • フィルタリングがより直感的 → WHEREを活用してさまざまな段階でデータをフィルタリング可能
  • 複雑な集計クエリをより簡単に記述可能 → AGGREGATE演算子を使って明確に集計を実行

Pre-GA 段階での提供であり、現時点ではサポートは限定的

関連記事

3件のコメント

 
carnoxen 2025-02-18

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

かなり見覚えのある演算子ですね
 
halfenif 2025-02-18

先にprqlを見てからGoogleのパイプライン構文を見ると、少し散漫ですね。
 
GN⁺ 2025-02-18
Hacker Newsの意見

  • SQLのパイプ構文が2025年1月30日からDatabricksで実装された

    • 以前はSQLの拡張が難しく、テーブル値関数は複雑だった
    • これで高階関数によるデータ拡張、予測、グループ化などが可能になった
    • 例えば、特定の日付以降の注文をフィルタし、顧客ごとの総支出を集計した後、一定金額以上の顧客をフィルタして顧客情報と結合できる
    • パイプを使った反復的なSQLはGenAIとより相性よく機能する可能性がある

  • PRQLはSQLにコンパイルされる類似のアイデアである

    • 例えば、請求データをフィルタし、手数料を計算した後、収益が一定額以上のデータをフィルタできる

  • SQLの構文拡張が進み続けると複雑さが増す可能性がある

    • SQL実装者には、外部の代替構文をよりよくサポートできるよう、ソースマップなどに注力してほしい
    • 各プロジェクトや個人が、自分に合ったSQL構文の変種を選べるようになる

  • パイプ構文が最初に発表されたとき、SQLiteチームがこれを試してみた

    • パイプ文字は必須ではないことが分かり、パイプ文字が任意でも構文は動作する
    • 個人的には、この方式のほうが見やすいと思う

  • PRQLはSQL DB向けのパイプ指向構文で、新しい言語であるためSQLとの下位互換性はない

    • Googleのような大企業の支援は受けていないが、構文はよりすっきりしている

  • DuckDBでも利用できる

  • パイプの後に">"を入力するのは面倒かもしれない

  • Malloy言語はパイプ構文ではないが、似た分析向け構文を持っている

    • Lookerの共同創業者であるLloyd Tabbが開発した

  • Kusto Query Languageを使うようになって以来、SQLにもこうした機能が備わることを期待している

    • 十分な数のDBが拡張機能としてこれをサポートすれば、実現の可能性はあるだろう