Java UDFs の紹介

このトピックでは、Java UDFs を紹介し、Java UDF をいつ使用するかを決定するのに役立つ情報を提供します。

このトピックの内容:

Java UDF とは

UDF (ユーザー定義関数)は、組み込み関数を呼び出すのと同じ方法でSnowflakeから呼び出すことができるユーザー作成関数です。

Snowflakeは、Javaなど、複数の言語で記述された UDFs をサポートしています。

Java UDFs はスカラー関数です。UDF に渡される行ごとに、 UDF は値を返します。

UDFs は0以上のパラメーターを受け入れます。

ユーザーが UDF を呼び出すと、ユーザーは UDF の名前と UDF のパラメーターをSnowflakeに渡します。UDF がJava UDF の場合、Snowflakeは JAR ファイル内の適切なJavaコード(呼称 ハンドラーメソッド)を呼び出します。次に、ハンドラーメソッドは出力をSnowflakeに返し、Snowflakeはそれをクライアントに返します。以下は、データフローの簡略図です。

UDF Data Flow

Java UDFs には、新しいコードと既存ライブラリへの呼び出しの両方を含めることができるため柔軟性があり、コードの再利用も可能です。たとえば、Javaでデータ分析コードをすでに持っている場合は、大抵Java UDF に組み込むことができます。

Snowflakeは現在、Javaバージョン8.x、9.x、10.x、および11.xによる UDFs の記述をサポートしています。

Java UDF をいつ使用するかの決定

このセクションでは、Java UDFs の利点と制限について説明します。

UDFs を書き込む他の潜在的な言語の情報、およびそれらの言語間の比較については、 UDFsの概要 をご参照ください。

Snowflakeを拡張する他の方法については、以下をご参照ください。

Java UDFs の利点

Java UDFs は、次の1つ以上が当てはまる場合に特に適しています。

  • 使用できるJavaコード(ソースまたはコンパイル済み)がすでにある。

  • コードは、標準のJavaライブラリにすでに存在する関数を使用する(または使用する可能性がある)。

  • UDFs をサポートする他の言語と同程度、あるいはそれ以上、Javaに対する知識がある。

Java UDFs の制限

一般的な制限

  • Javaメソッドは標準のJavaライブラリのクラスとメソッドを使用できますが、Snowflakeのセキュリティ制約により、ファイルへの書き込みなど、一部の機能が無効になります。詳細については、 優れたセキュリティプラクティスに準拠 というタイトルのセクションをご参照ください。

  • Java UDFs は共有できません。Java UDFs を使用するデータベースオブジェクトも共有できません。たとえば、次は実行できません。

    • Java UDF を直接共有する。

    • Java UDF を呼び出すビューを共有する。

    • Java UDF を呼び出す関数を共有する。

    • Java UDF を呼び出すマスキングまたは行アクセスポリシーを使用してテーブルを共有する。

  • SECURE オプション(CREATE SECURE FUNCTION...)を使用してJava UDF を作成しようとすると、Snowflakeはエラーを返します。SECURE オプションは、Java UDFs ではまだサポートされていません。

  • Java UDF で USAGE 権限を付与すると、受信者はその UDF によってインポートされたファイルの内容を表示できる場合があります。Java UDF に対する USAGE 権限をロールに付与し、そのロールがそのJava UDF を呼び出すステートメントを実行する場合、同じステートメント内の任意のJava UDF は、USAGE 権限を付与されたJava UDF によってインポートされた任意のファイルの内容を読み取ることができます。

  • プライマリデータベースにJava UDF が存在する場合、セカンダリデータベースの作成または更新はブロックされます。(この制限は、将来のバージョンで削除される可能性があります。)

クローニングの制限

Java UDF は、Java UDF を含むデータベースまたはスキーマがクローンされるときに、クローンできます。クローンを作成するには、Java UDF が次の条件を満たす必要があります。

  • Java UDF がステージ(例: UDF の JAR ファイルを含むステージ)を参照する場合、そのステージは、クローンされるスキーマ(またはデータベース)の 外部 である必要があります。

    次の方法で、Java UDF と参照ステージを別々のスキーマ(および/または別々のデータベース)に保持できます。

    • Java UDF がステージを参照する場合は常に、Java UDF のスキーマまたはデータベースとは異なる修飾ステージ名(例: 「my_db.my_schema.my_stage()」)を使用します。クローン作成操作でデータベースのクローンを作成する場合、ステージ参照にはデータベースとスキーマを含める必要があります。クローン作成操作でスキーマのクローンを作成する場合、ステージ参照にはスキーマ(およびオプションでデータベース)を含める必要があります。

    • 非修飾ステージ名(現在のセッションのアクティブなデータベースとスキーマを暗黙的に使用する)を使用して参照されるステージを作成し、セッションの現在のデータベースとスキーマと一致しない修飾名を使用してJava UDF を作成します。

    • ユーザーのステージを参照されるステージとして使用します(ユーザーのステージは、データベースのステージまたはスキーマのステージとは別のものです)。

スキーマまたはデータベース内の1つ以上のJava UDFs が必要な条件を満たしていない場合でも、スキーマまたはデータベースのクローンを作成できますが、非準拠のJava UDFs は、エラーまたは警告メッセージなしでクローンから省略されます。

クローンされた各Java UDF は、元のJavaと同じ定義を持っています。その定義には、ステージへの参照が含まれます。Java UDF のステージ参照は完全修飾されている必要があるため、クローンを作成するスキーマやデータベースに関連するものではなく、絶対的なものです。オリジナルとクローンの両方が同じステージとファイルをポイントしているため、

  • ステージをドロップするか、ステージから必要なファイルを削除すると、元とクローンされた UDF の両方が無効になります。

  • ステージまたはステージ上のファイルを変更すると(例: JAR ファイルを新しい JAR ファイルに置き換える)、元とクローンされた UDF の両方に影響します。