データ分析

パイプ構文による SQL の変革が BigQuery と Cloud Logging でも可能に

2024年11月19日

Candice Chen

Product Manager, Google Cloud

Jeff Shute

Google Fellow

※この投稿は米国時間 2024 年 10 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

50 年前に発明されて以来、SQL はデータベース業界全体で使用される共通言語となっています。馴染み深い構文と定評あるコミュニティにより、どこでもデータにアクセスできる仕組みが真に民主化されました。しかし実際のところ、SQL は完璧ではありません。SQL の構文には次のような問題点があり、読み書きが難しくなっています。

厳格な構造: クエリは特定の順序に従う必要があり（SELECT … FROM … WHERE … GROUP BY…）、そのとおりにしない場合はサブクエリや他の複雑なパターンが必要になります。
不便な内外のデータフロー: クエリが中ほどから始まり、サブクエリまたは共通テーブル式（CTE）に埋め込まれた FROM 句で始まるロジックが外に向かって構築されます。
冗長で繰り返しの多い構文: SELECT、GROUP BY、ORDER BY、そしてすべてのサブクエリで、同じ列を何度も列挙することになります。皆さんうんざりしているのではないでしょうか。

SQL にはこのような問題があるため、新規ユーザーの場合はさらに難しくなります。エキスパートユーザーであっても、SQL の読み書きには必要以上に労力がかかります。構文がもっと便利になれば、誰もが助かるでしょう。

長年にわたり、複数の代替言語や API が提案されてきました。その一部は、限定的な用途である程度の成功を収めています。Apache Beam や Python DataFrames など、多くはパイプ処理データフローを採用しているため、クエリを自由に作成できます。多くのユーザーは、この構文の方が SQL よりわかりやすく、便利だと感じています。

しかし SQL はあらゆるところで使用されているため、すぐに置き換えられることはないでしょう。新しい言語を学び、ワークロードを新しいツールに移行することは、ほとんどのユーザーにとって負担が大きすぎます。

そこで考えました。SQL に何かを追加することで、SQL のお馴染みの機能や優れた機能をすべて維持しつつ、同じパワーや柔軟性を持たせることはできるでしょうか？答えはイエスです。

SQL パイプ構文の導入: 両方の特長を活かす

Google Cloud では、データ分析を簡単かつ直感的に行えるようにすることを使命としています。そこで、パイプ構文を導入しました。BigQuery と Cloud Logging の SQL でエレガントなパイプ処理データフローが実現する、画期的なイノベーションです。このトピックに関する最新の研究論文については、こちらをご覧ください。

パイプ構文とは簡単に言うと、パイプ構文は標準 SQL 構文の拡張です。SQL が簡単、簡潔、柔軟になります。標準 SQL と同じ基本的な演算子をサポートし、セマンティクスが同じで、構文もほぼ同じですが、演算子を任意の順序で任意の回数適用できます。

仕組み:

クエリを FROM で始めることができます。
演算子は、パイプ記号「|>」を使用して順番に記述します。

各演算子は入力テーブルを使用し、出力テーブルを生成します。

ほとんどのパイプ演算子は標準 SQL と同じ構文を使用します。

SELECT、WHERE、JOIN、ORDER、BY、LIMIT など。

標準構文とパイプ構文は、同じクエリ内でも任意に混在させることができます。

例: BigQuery の公開データセットを使用して、シカゴにおけるタクシーの年間平均利用回数を payment_type（支払いの種類）別に調べるとします。標準構文とパイプ構文で記述すると、以下のようになります。

標準構文を使用する場合、通常はサブクエリを記述する必要があります。

読み込んでいます...

パイプ構文を使用すると、同じクエリがこのようになります。サブクエリは必要ありません。

読み込んでいます...

HSBC における実際の影響

世界的な銀行大手の HSBC は、BigQuery でプレビュー版を試して素晴らしい結果が得られたことを受け、すでにパイプ構文を採用しています。特に大規模な JSON データセットを扱う際、生産性とコードの可読性が大幅に改善しました。

「BigQuery にパイプ構文が追加されて、感激しました。チームですぐにパイプ構文を使用してビジネスレポートの書き換えを行い、今後のレポート、特に大規模な JSON データセットを含むレポートの作成時間を短縮しました。以前は、このようなデータを展開するには広範なフィルタリングと抽出が必要だったため、SQL クエリの作成が手間のかかる反復的な作業になっていました。パイプ構文ではクエリ文字列の最大 80% が再利用可能になり、このプロセスが大幅に効率化されるため、特定のユースケースに注力できます。複雑なクエリの作成やデバッグがはるかに簡単になり、将来的にエンジニアの生産性が大幅に向上するでしょう。今後、さらに多くのユースケースやデータタイプまで拡大してパイプ構文を使用したいと考えています。」- HSBC、GCP クラウド エンジニアリング リード Zoltán Pósfai 氏

SQL 内にパイプ構文を追加する利点

Google は、SQL にパイプ構文を追加することで、SQL 開発者にさまざまなメリットがもたらされると考えています。以下にその一部をご紹介します。

習得しやすい新しい言語を学んで採用することは、特にユーザー数の多い組織にとっては難しいことです。すべてのユーザーが同じ言語とツールを使用するとよいでしょう。パイプ構文は新しい言語ではなく、既存の SQL 言語の新機能です。SQL をすでに知っているユーザーにとっては、構文がほとんど同じで、同じ演算子がすべて備わっているため、パイプ構文の習得は非常に簡単です。

SQL を初めて扱うユーザーにとっては、まずパイプ構文を学ぶ方が簡単です。それでも演算子や一部のセマンティクス（内部結合や外部結合など）を学ぶ必要はありますが、そうした演算子を使用することで、目的のクエリを直接表現し、標準 SQL でクエリを表現する際の複雑さや対策の一部を回避することができます。

移行作業なしの段階的な導入が容易新しい言語やシステムへの移行は、費用や時間がかかり、エラーが発生しやすいものです。パイプ構文は GoogleSQL の機能であるため、使用を開始する前に移行を行う必要はありません。新しい構文は必要に応じて選択的に使用でき、既存のクエリはすべて、引き続き機能します。新しい SQL は、既存の SQL コードと完全に相互運用可能です。たとえば、パイプ構文を使用したクエリでは、標準構文で記述された標準ビューを呼び出すことができ、その逆も可能です。新しい SQL コードでパイプ構文を使用しても、既存の SQL が廃止されたり使用できなくなったりすることはありません。

パフォーマンスや費用への影響がないパイプ構文は、変換プロキシなどの追加のレイヤを一切必要とせずに、BigQuery といった既存のプラットフォームで機能します。追加のレイヤではレイテンシや費用、信頼性のリスクが増し、デバッグや調整が困難になることがあります。

また、追加の費用は発生しません。クエリでパイプ構文を使用しても、SQL の宣言的なセマンティクスはそのままです。つまり SQL クエリオプティマイザーが、より効率的に実行できるようにクエリを再構成します。言い換えると、クエリを標準構文で記述してもパイプ構文で記述しても、通常、パフォーマンスはまったく同じです。

パイプ構文の用途

データの探索、ダッシュボードの作成、データパイプラインの構築、ログの分析などを行うとき、パイプ構文を使用すると、保守性の高い SQL クエリを明確かつ効率的に記述できます。パイプ構文はほとんどの標準 SQL 演算子をサポートしているため、記述するクエリの用途にかかわらず使用できます。以下に応用例をいくつかご紹介します。

アドホック分析とクエリのデバッグデータ探索を行うときは、通常、まずテーブルの行（FROM 句で開始）を見て何があるかを確認してから、フィルタ、集計、結合、並べ替えなどを追加します。パイプ構文では、FROM 句で開始してそこから構築できるため、こうしたデータ探索が非常に簡単になります。どのステップでも、それまでの結果を確認できます。さらに別のパイプ演算子を追加し、もう一度クエリを実行して新たな結果を確認することができます。

パイプ構文はクエリのデバッグにも役立ちます。パイプ構文のクエリには、パイプ記号までのすべてのクエリ接頭辞も有効なクエリだという優れた特性があります。そのため、そのクエリ接頭辞をハイライト表示して実行し、その時点までの中間結果を表示することができます。

データ エンジニアリングのライフサイクルデータ量が増加するにつれ、データの処理と変換はさらに困難になり、時間がかかるようになります。通常、データ量の多い環境では、データパイプラインの構築、適応、メンテナンスに多大なエンジニアリング作業が必要になります。パイプ構文では、クエリの線形構造と直感的な構文により、データエンジニアリングが効率化します。標準 SQL を使用する際につきものだった、あの深くネストされたクエリと CTE に別れを告げましょう。GoogleSQL に追加されたこの新機能により、データの解析、抽出、変換の方法が刷新され、データパイプラインの作成と維持が簡単になります。ユースケースの例を挙げた記事では、BigQuery と Cloud Logging の両方でパイプ構文を使用して、ログデータのワークロードを迅速化する方法を紹介しています。

SQL で LLM と自然言語を適用研究によると、SQL が複雑になって人間が読み書きしにくくなることがあるのと同じ理由から、大規模言語モデル（LLM）で SQL を理解し生成するのが困難になることがあります。一方、パイプ構文ではクエリを独立したステップに分割し、目的の論理データフローに密接に対応させます。LLM にとっては目的のデータフローを表現するパイプ構文を生成する方が簡単であり、人間が読みやすい簡潔なクエリが生成されます。また、生成されたクエリを人間が検証する作業もはるかに簡単になります。

パイプ構文により、何が起きているのかや何ができるのかを理解しやすくなるため、コードアシスタント機能や自動補完機能が向上するほか、クエリ全体に対するグローバルな編集ではなく、あるパイプ演算子に対するローカルな編集を提案できるようになります。AI 生成のコードの提案が洗練され、クエリに組み込む自然言語ベースの演算子が増えれば、ユーザーの生産性を一層向上させる絶好の機会が生まれます。

パイプ構文を今すぐ活用する

SQL はその優れた機能により、50 年にわたってデータ処理の共通言語として利用されてきました。多くのことを適切に処理する SQL は、クエリを関係演算子の宣言型の組み合わせとして表現することに非常に長けています。

だからといって、SQL に改善の余地がないというわけではありません。パイプ構文は SQL を未来へと導き、ユーザビリティに関する SQL の最大の課題を解決し、SQL の操作や拡張の新しい方法を実現します。これは SQL の置き換えでも、新しい言語の開発でもありません。パイプ構文を使用した SQL は依然として SQL ですが、優れた SQL です。ユーザーフレンドリーで、柔軟性があり、表現力に富んでいます。