Introduction aux UDFs Python¶
Cette rubrique présente les UDFs Python et fournit des informations pour vous aider à décider quand utiliser une UDF Python.
Dans ce chapitre :
Qu’est-ce qu’une UDF Python ?¶
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 Python.
Les UDFs Python 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 Python, Snowflake appelle le code Python approprié (appelé fonction de gestionnaire). La fonction de gestionnaire renvoie ensuite la sortie à Snowflake, qui la renvoie au client.
Les UDFs Python peuvent contenir à la fois du nouveau code et des appels vers des paquets existants, 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 Python, vous pouvez probablement l’intégrer dans une UDF Python.
Snowflake prend actuellement en charge l’écriture d’UDFs dans la version 3.8 de Python.
Grâce à un partenariat avec Anaconda, les paquets Python de tiers sont fournis par Snowflake. Pour en savoir plus, voir Utilisation de paquets tiers.
Note
Il existe une API par lots UDF Python, qui permet de définir des fonctions Python recevant des lots de lignes d’entrée sous forme de DataFrames Pandas et renvoyant des lots de résultats sous forme de tableaux Pandas ou de Series. Pour plus d’informations, voir API par lots UDF Python.
Décider de l’opportunité d’utiliser une UDF Python¶
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 Python¶
Les UDFs Python sont particulièrement appropriées lorsqu’un ou plusieurs des éléments suivants sont vrais :
Vous disposez déjà d’un code Python (source ou compilé) que vous pouvez utiliser.
Votre code utilise (ou pourrait utiliser) des fonctions qui existent déjà dans les paquets Python standard.
Vous connaissez Python aussi bien ou mieux que les autres langages qui prennent en charge des UDFs.
Vous voulez profiter de l’écosystème tiers riche de Python.
Limites des UDFs Python¶
Limitations générales¶
Bien que votre fonction Python puisse utiliser les modules et les fonctions des paquets Python standard, les contraintes de sécurité de Snowflake désactivent certaines capacités, comme l’accès au réseau et l’écriture dans les fichiers. Pour plus de détails, voir la section intitulée Respecter les bonnes pratiques de sécurité.
Toutes les UDFs et tous les modules introduits par le biais de zone de préparation doivent être indépendants de la plate-forme et ne doivent pas contenir d’extensions natives.
Évitez le code qui suppose une architecture CPU spécifique (par exemple, x86).
Évitez le code qui suppose un système d’exploitation spécifique.
Les UDFs Python ne sont pas partageables. Les objets de la base de données qui utilisent des UDFs Python ne sont pas non plus partageables. Par exemple, vous ne pouvez pas :
Partager directement une UDF Python.
Partager une vue qui appelle une UDF Python.
Partager une fonction qui appelle une UDF Python.
Partager une table avec une politique de masquage ou d’accès aux lignes qui appelle une UDF Python.
Accorder le privilège USAGE sur une UDF Python 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 Python à un rôle, et si ce rôle exécute une instruction qui appelle cette UDF Python, alors toute UDF Python dans la même instruction pourrait lire le contenu de tout fichier importé par l’UDF Python à laquelle vous avez accordé le privilège USAGE.
La réplication de la base de données est prise en charge pour les UDFs Python en ligne. Cependant, la réplication est bloquée si une UDF Python a une dépendance sur un fichier dans une zone de préparation (c’est-à-dire une fonction créée à l’aide de la clause IMPORTS). Cette limitation pourrait être supprimée dans les futures versions.
Snowflake utilise le module Python
zipimport
pour importer du code Python depuis des zones de préparation. Par conséquent, toute limitationzipimport
sera également présente avec des UDFs. Pour en savoir plus surzipimport
, consultez la référence zipimport.
Limites du clonage¶
Une UDF Python peut être clonée lorsque la base de données ou le schéma contenant l’UDF Python est cloné(e). Pour être clonée, l’UDF Python doit remplir la ou les conditions suivantes :
Si l’UDF Python fait référence à une zone de préparation, cette zone de préparation doit être extérieur au schéma (ou à la base de données) en cours de clonage.
Vous pouvez conserver une UDF Python et sa 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 Python 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 Python. 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 Python 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 Python 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 Python non conformes sont omises du clone sans message d’erreur ou d’avertissement.
Chaque UDF Python 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 Python 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 affecte à la fois les UDF originales et clonées.