Introduction aux UDFs Java

Cette rubrique présente les UDFs Java et fournit des informations pour vous aider à décider quand utiliser une UDF Java.

Dans ce chapitre :

Qu’est-ce qu’une UDF Java ?

Une UDF (fonction définie par l’utilisateur) est une fonction écrite par l’utilisateur qui peut être appelée à partir de Snowflake de la même manière qu’une fonction intégrée peut être appelée.

Snowflake prend en charge les UDFs écrites en plusieurs langues, y compris Java.

Les UDFs Java sont des fonctions scalaires ; pour chaque ligne passée à l’UDF, l’UDF renvoie une valeur.

Les UDFs acceptent aucun ou plusieurs paramètres.

Lorsqu’un utilisateur appelle une UDF, il transmet le nom de l’UDF et les paramètres de l’UDF à Snowflake. Si l’UDF est une UDF Java, Snowflake appelle le code Java approprié (appelé méthode de gestion) dans un fichier JAR. La méthode de gestion renvoie ensuite la sortie à Snowflake, qui la renvoie au client. Vous trouverez ci-dessous une illustration simplifiée du flux de données :

UDF Data Flow

Les UDFs Java peuvent contenir à la fois du nouveau code et des appels vers des bibliothèques existantes, ce qui vous offre à la fois flexibilité et réutilisation du code. Par exemple, si vous disposez déjà d’un code d’analyse de données en Java, vous pouvez probablement l’intégrer dans une UDF Java.

Snowflake prend actuellement en charge l’écriture d’UDFs en Java versions 8.x, 9.x, 10.x, et 11.x.

Décider de l’opportunité d’utiliser une UDF Java

Cette section décrit les avantages et les limites des UDFs Java.

Pour des informations sur les autres langages potentiels dans lesquels écrire des UDFs, et pour des comparaisons entre ces langages : voir Aperçu des UDFs.

Pour des informations sur les autres moyens d’étendre Snowflake, voir :

Avantages des UDFs Java

Les UDFs Java sont particulièrement appropriées lorsqu’un ou plusieurs des éléments suivants sont vrais :

  • Vous disposez déjà d’un code Java (source ou compilé) que vous pouvez utiliser.

  • Votre code utilise (ou pourrait utiliser) des fonctions qui existent déjà dans les bibliothèques Java standard.

  • Vous connaissez Java aussi bien ou mieux que les autres langages qui prennent en charge des UDFs.

Limitations sur les UDFs Java

Limitations générales

  • Bien que votre méthode Java puisse utiliser les classes et les méthodes des bibliothèques Java standard, les contraintes de sécurité de Snowflake désactivent certaines capacités, comme l’écriture dans des fichiers. Pour plus de détails, voir la section intitulée Respecter les bonnes pratiques de sécurité.

  • Les UDFs Java ne sont pas partageables. Les objets de la base de données qui utilisent des UDFs Java ne sont pas non plus partageables. Par exemple, vous ne pouvez pas :

    • Partager directement une UDF Java.

    • Partager une vue qui appelle une UDF Java.

    • Partager une fonction qui appelle une UDF Java.

    • Partager une table avec une politique de masquage ou d’accès aux lignes qui appelle une UDF Java.

  • Si vous essayez de créer une UDF Java en utilisant l’option SECURE (CREATE SECURE FUNCTION...), Snowflake renvoie une erreur. L’option SECURE n’est pas encore prise en charge pour les UDFs Java.

  • Accorder le privilège USAGE sur une UDF Java peut permettre au destinataire de voir le contenu des fichiers importés par cette UDF. Si vous accordez le privilège USAGE sur une UDF Java à un rôle, et si ce rôle exécute une instruction qui appelle cette UDF Java, alors toute UDF Java dans la même instruction pourrait lire le contenu de tout fichier importé par l’UDF Java à laquelle vous avez accordé le privilège USAGE.

  • La création ou l’actualisation d’une base de données secondaire est bloquée s’il existe une UDF Java dans la base de données principale. (Cette limitation pourrait être supprimée dans les futures versions).

Limites du clonage

Une UDF Java peut être clonée lorsque la base de données ou le schéma contenant l’UDF Java est cloné(e). Pour être clonée, l’UDF Java doit remplir la ou les conditions suivantes :

  • Si l’UDF Java fait référence à une zone de préparation (par exemple, la zone de préparation qui contient le fichier JAR de l’UDF), cette zone de préparation doit être extérieure au schéma (ou à la base de données) en cours de clonage.

    Vous pouvez conserver une UDF Java et une zone de préparation référencée (ou plusieurs) dans des schémas distincts (et/ou des bases de données distinctes) de l’une des manières suivantes :

    • Chaque fois que l’UDF Java fait référence à une zone de préparation, utilisez un nom de zone de préparation qualifié (par exemple, « mon_db.mon_schéma.ma_zone_préparation() ») différent du schéma ou de la base de données de l’UDF Java. Si l’opération de clonage clone une base de données, la référence de la zone de préparation doit inclure la base de données et le schéma. Si l’opération de clonage clone un schéma, la référence de la zone de préparation doit inclure le schéma (et éventuellement la base de données).

    • Créez la zone de préparation référencée en utilisant un nom de zone de préparation non qualifié (qui utilise implicitement la base de données et le schéma actifs de la session actuelle), et créez l’UDF Java en utilisant un nom qualifié qui ne correspond pas à la base de données et au schéma actuels de la session.

    • Utilisez la zone de préparation de l’utilisateur comme zone de préparation référencée (la zone de préparation de l’utilisateur est distincte de la zone de préparation de la base de données ou de la zone de préparation du schéma).

Si une ou plusieurs UDFs Java du schéma ou de la base de données ne remplissent pas les conditions requises, le schéma ou la base de données peut toujours être cloné(e), mais les UDFs Java non conformes sont omises du clone sans message d’erreur ou d’avertissement.

Chaque UDF Java clonée a la même définition que l’originale. Cette définition inclut toute référence aux zones de préparation. Les références de zones de préparation dans l’UDF Java doivent être entièrement qualifiées, et sont donc absolues, et non relatives au schéma ou à la base de données clonée. Parce que l’originale et le clone pointent tous deux vers la ou les mêmes zones de préparation et le ou les mêmes fichiers :

  • La destruction de la zone de préparation ou la suppression des fichiers requis de la zone de préparation désactive les UDF originales et clonées.

  • La modification de la zone de préparation ou des fichiers de la zone de préparation (par exemple, le remplacement du fichier JAR par un fichier JAR plus récent) affecte à la fois les UDF originales et clonées.