によって Serge Rielau 、 アリソン・ワン による投稿
Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.
ユーザー定義関数（UDF）は、ユーザーがApache Spark™ SQLのネイティブ機能を拡張するための手段です。Databricks上のSQLでは、1.3.0以降、Scala、Java、Python、Rプログラミング言語で記述された外部ユーザー定義関数をサポートしています。外部UDFは非常に強力ですが、いくつかの注意点があります。
上記の問題に対処するため、新しい形式のUDFであるSQL UDFを発表できることを嬉しく思います。DBR 9.1 LTSで利用可能なSQL UDFは、SQLの表現力で完全に定義されており、SQLコンパイラからは完全に透過的です。
Databricks Lakehouse Platformの内部動作を理解するには、データウェアハウスをデータレイクハウスにもたらす理由 ebookをご覧ください。
SQL UDFは、Databricks上のSQLに対するシンプルかつ強力な拡張機能です。関数として、クエリ構築を簡素化する抽象化レイヤーを提供し、SQLクエリをより読みやすく、モジュール化します。非SQL言語で記述されたUDFとは異なり、SQL UDFはSQLユーザーにとって作成が容易です。SQL関数の本体はクエリオプティマイザから透過的であるため、外部UDFよりもパフォーマンスが高くなります。SQL UDFは、一時的または永続的な関数として作成でき、複数のクエリ、セッション、ユーザー間で再利用でき、アクセス制御言語（ACL）を介してアクセス制御できます。このブログでは、例とともにSQL UDFの主要なユースケースをいくつかご紹介します 。
想像できる最も単純な関数、つまり定数から始めましょう。リテラルをコードで使用すると可読性が損なわれ、定数が実際には一定でなくなる可能性があるため、使用しない方が良いことは誰もが知っています。したがって、一度だけ変更できるようにしたいのです。
外部UDFに慣れている場合は、際立った違いがいくつかあることがわかります。
これらの違い以外にも、外部UDFと同じ点がたくさんあります。
関数を使用してみましょう。
驚くことではありませんが、これは機能します。しかし、内部では何が起こっているのでしょうか？
これは素晴らしいです！SQLコンパイラは、関数呼び出しを定数自体に置き換えました。
こ れは、少なくともこのSQL UDFはパフォーマンスにコストがかからないことを意味します。
次に、別の一般的な使用パターンを見てみましょう。
組み込み関数の名前付けが気に入らないと想像してください。別の製品から多くのクエリを移行していて、その製品には異なる関数名と動作があるのかもしれません。あるいは、単に長い式をSQLクエリで何度もコピー＆ペーストするのが我慢できないのかもしれません。そこで、それを修正したいのです。
SQL UDFを使用すると、好きな名前で新しい関数を簡単に作成できます。
ここで使用された新しい構文を見てみましょう。
それ は機能するだけでなく…
…うまく機能します。
物理計画には、lpad、hex、least、greatest関数の直接的な適用が表示されていることがわかります。これは、関数のシリーズを直接呼び出した場合と同じ計画です。
SQL関数をSQL関数から構成することもできます。
SQL UDFのもう1つの一般的な使用法は、ルックアップをコード化することです。単純なルックアップは、RGBカラーコードを英語のカラー名にデコードすることかもしれません。
わかりました。しかし、この世界には2色以上の色があります。そして、この翻訳を両方向で行いたいので、これらは実際にはルックアップテーブルに入れるべきです。
ここには複数の新しい概念が適用されています。
物理計画はどのようになりますか？クエリを実行する外部UDFを使用すると、ネストされたループ結合が発生する可能性があり、貴重なリソースを浪費する最悪の方法であることが簡単にわかります。
この場合、Catalystはネストループ結合ではなくブロードキャストハッシュ結合を選択しました。これは、SQL UDFの内容を理解しているため可能です。
これまでの例ではすべて、単一の値を返すスカラー値関数が使用されていました。その結果は、構造体、配列、マップの複雑な組み合わせであっても、あらゆる型になり得ます。さらに、テーブル値関数という別の種類のUDFについても説明します。
ビューに引数があったらどうなるでしょうか？ユーザー提供の値に依存する複雑な述語をカプセル化できます。SQLテーブルUDFはまさにそれです。名前は違えどビューと同じですが、パラメータが付いています。
上記の色のマッピングが一意ではないと仮定しましょう。少なくとも、色の名前が言語によって異なることを断言できます。
したがって、`from_rgb`関数は、配列またはリレーションを返すように変更する必要があります。
ご覧のとおり、スカラー関数との唯一の違いは、より複雑なRETURNS句です。ビューとは異なり、SQL UDFは返されるリレーションのシグネチャの宣言を義務付けています。
ユーザー定義テーブル関数はDBRの新機能です。呼び出し方法を見てみましょう。
最も簡単な形式では、テーブル関数はビューが参照されるのと同じ方法で、同じ場所で呼び出されます。唯一の違いは、関数の引数を含む必須の括弧です。この関数はリテラル引数で呼び出されますが、引数は式、さらにはスカラーサブクエリでもかまいません。
しかし、最も強力なのは、SQLテーブルUDFを結合、特に相関クロス結合で使用することです。
ここでは、引数がFROM句の前の（ラテラルな）リレーションを参照（相関）しています。新しいLATERALキーワードにより、Catalystはこれらの列を解決できます。また、結果シグネチャで定義されたとおりに列に名前を付け、オプションで関数名で修飾することにより、テーブル関数の結果を参照できることにも注意してください。
当然のことながら、SQL UDFは、既存 のGRANT、REVOKE、SHOW、DESCRIBE、およびDROPステートメントによって完全にサポートされています。
詳細に指摘する価値のあるステートメントはDESCRIBEです。
基本的なdescribeは期待どおりの結果を返しますが、拡張されたDESCRIBEはさらに多くの詳細を追加します。
ここで説明したことは、SQL UDFの初期機能です。検討中の将来の拡張機能には、以下が含まれます。
SQL UDFはSQLの使いやすさにおいて大きな前進であり、このブログで概説されているようにさまざまな方法で使用できます。Databricks SQLでの利用や、データエンジニアリングジョブでのPhotonの使用など、さらにクリエイティブな方法をぜひお考えください。こちらのノートブックを試して、詳細についてはドキュメントをご覧ください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。