SQL革命！新パイプ構文登場

SQLは何十年もの間、構造化データ分析の共通言語として使われてきました。Databricksでは、ANSI SQLとその拡張機能をサポートするために多くの取り組みを行ってきました。本日、私たちは「SQLパイプ構文」の導入を発表できることを嬉しく思います。これは、SQLを劇的に書きやすく、理解しやすくするための、近年で最大の拡張機能です。しかも、完全な後方互換性を保ちながら実現しています。

これらのステップのSQLクエリは次のようになります：

ステップを順番に書くのではなく（1、2、3）、逆の順番で書く必要があります（3、2、1）。これは混乱を招き、クエリにロジックやステップを追加するたびに問題が複雑化します。

DataFrameが人気の理由

対照的に、DataFrameを考えてみましょう。Apache Sparkが当初データサイエンティストの間で人気を博した大きな理由は、ScalaやPythonのDataFrame APIの強力な機能にあります。プログラムでは、ソーステーブルから始めて、独立した操作を次々と連鎖させることができ、複雑なデータ変換を明確で直感的な順序で構築しやすくなります。

この設計は読みやすさを促進し、デバッグを簡素化しながら柔軟性を維持します。これがDatabricksがデータ管理分野で大きな成長を遂げた主な理由の一つであり、この勢いは今日も続いています。

同じロジックをPySparkのDataFrameで表現すると次のようになります：

このアプローチはアイデアの柔軟な反復を可能にします。元データがファイルに存在することはわかっているので、そのデータをリレーションとして表現するDataFrameを作成することからすぐに始められます。少し考えた後、文字列列で行をフィルタリングしたいと気づきます。そこで、前のDataFrameの最後に.filterステップを追加できます。また、最後に射影計算を行いたい場合は、その処理を一連の操作の最後に追加するだけです。

多くのユーザーは、SQLもこのような現代的なデータ言語と同様に動作することを望んでいました。しかし、これまではそれが不可能で、ユーザーはどちらかの考え方を選ばなければなりませんでした。

新しいSQLパイプ構文の登場！

現在では、両方の良いところを取り入れることが可能になりました！パイプ構文によって、SQLの記述が容易になり、後から読んだり拡張したりすることも簡単になります。また、私たちが考えた順序でそのままステップを使用できるようになり、混乱から解放されます。

 

VLDB 2024カンファレンスにおいて、Googleはこれを新しい標準として提案する産業論文を発表しました。クエリ処理エンジニアたちはこの機能を実装し、Apache Spark 4.0（ドキュメント）およびDatabricks Runtime 16.2（ドキュメント）以降でデフォルトで有効にしています。この機能は従来のSQL構文と下位互換性があります。ユーザーはこの構文を使って完全なクエリを書くことも、特定のサブクエリだけに使うことも、あるいは任意の有用な組み合わせで使うこともできます。

この産業論文では、最初の例としてTPC-Hベンチマークのクエリ13を取り上げています：

パイプ構文を使用して同じロジックを表現すると、任意の順序で始めから終わりまでの一連の演算子を適用します。

集約はどのように動作するのでしょうか？

従来のSQLでは、列や式の値に基づいて行をグループにまとめる場合、作成中のSQLクエリの最後にGROUP BY句を追加します。実行する集約は、クエリの最初にあるSELECTリストの最上部にずっと残っており、すべての式は次のいずれかでなければならなくなります。

• グループ化キーの場合、GROUP BY句は、その表現（またはエイリアス参照または序数）のコピーを含まなければなりません。
• 集約関数のようなSUM、COUNT、MIN、またはMAXは、入力テーブルの列に基づく式を受け入れることができます。例えば、SUM(A + B)。結果に対して投影を計算することもできます、例えばSUM(A) + 1のような。

これらのカテゴリのいずれにも該当しないSELECT項目は、「式XがSELECTリストに現れましたが、グループ化または集約されていません」というエラーを引き起こします。

WHERE句のルールも変わります。

• GROUP BY句の前に現れると、指定された基準に従って行をフィルタリングし、それらを集約します。
• それ以外の場合、クエリは無効であり、私たちは奇妙なエラーを得ます。ユーザーは代わりに同じフィルタリング条件を持つHAVING句を書く必要があり、それはGROUP BY句の後にのみ現れるべきで、その前には現れません。
• QUALIFY句も、コンテキストに応じてフィルタリングを行うための別の構文を理解し使用する必要がある別の例として機能します。

パイプ構文は、各集計操作（グループ化を含む）を専用のステップに分離することでこの問題を解決し、いつでも適用できるようにします。このステップ内には集計関数を含む式のみが現れることができ、集計関数は|> SELECT ステップ内には現れることができません。SQLの作成者がこれらの不変条件を忘れた場合、結果のエラーメッセージは非常に明確で理解しやすくなっています。

また、グループ化式を1つのGROUP BY句に記述するだけでよいので、グループ化式を繰り返す必要もなくなりました。

前の例に集計を追加した例を見てみましょう。これはL、Mという2つの列を持つ結果テーブルを返します：

サブクエリを使いこなす

通常のSQLでは、句が特定の順序で現れ、繰り返しがないことが一般的に求められます。SQLクエリの結果に対してさらに操作を適用したい場合、元のクエリを括弧で囲み、それを外側のクエリのFROM句で使用するテーブルサブクエリを使用するという方法があります。この記事の冒頭のクエリはその簡単な例を示しています。

このネスト（入れ子）構造は任意の回数発生する可能性があります。例えば、TPC-DSクエリ23は次のようになります：

これは括弧とインデントのレベルが増えるにつれて、混乱を招き読みにくくなっています！

一方、SQLパイプ構文ではテーブルサブクエリが全く必要ありません。パイプ演算子は任意の順序で配置できるため、いつでも新しい演算子を末尾に追加するだけで、すべてのステップが同じように機能します。

後方互換性で簡単に始められる

パイプ構文は、SQLの書き方、読み方、拡張方法を再構築します。従来のSQLの考え方からこの新しいパラダイムに切り替えるのは難しいように思えるかもしれません。さらに、以前に書かれた大量のSQLクエリを維持し、後で拡張する責任がある場合もあるでしょう。2つのSQL構文でどのように対応すればよいのでしょうか？

幸いなことに、この新しいSQL構文では問題ありません。これは従来のSQLと完全に相互運用可能で、どのクエリ（またはテーブルサブクエリ）も両方の構文を使用して記述できます。必要に応じて、SQLパイプ構文を使って新しいクエリを書き始め、以前のクエリをそのまま維持することができます。さらに、以前のクエリのテーブルサブクエリだけを新しい構文に置き換え、他の部分はそのままにすることも可能です。例えば、この記事の冒頭で紹介したTPC-H Q13の一部だけを更新する例を見てみましょう：

SQLパイプ演算子は任意の有効なクエリに続くことができるので、既存の通常のSQLクエリにそれらを追加し始めることも可能です。例をいくつかご紹介します。

今すぐ試してみよう！

SQLパイプ構文はDatabricks Runtimeバージョン16.2以降で試すことができます。または、Apache Spark 4.0をダウンロードして、オープンソースの世界で試してみましょう。この構文はSQLのPipe Syntaxに関する産業論文に準拠しているため、Google BigQueryやオープンソースのZetaSQLプロジェクトとも互換性があります。

この構文はコミュニティでも話題を集め始め、他の場所でも採用され始めており、現在そして将来的な移植性がさらに向上しています。

ぜひ試してみて、初心者から経験豊富なユーザーまでSQLクエリをより簡単に書けるようになるメリットを体験してください。複雑なサブクエリの代わりに明確で組み合わせ可能な演算子を使用することで、将来的な可読性と拡張性も向上します。