Meilleures pratiques en matière d’accès au réseau externe¶

Suivre les meilleures pratiques applicables des fonctions externes¶

Suivez les meilleures pratiques décrites pour les fonctions externes, y compris les suivantes :

• Utiliser une API de lot d’un service à distance si disponible

• Ne supposez pas que le service distant a validé chaque ligne exactement une fois

Notez que, contrairement aux fonctions externes, vous êtes responsable, dans le code de votre gestionnaire, de l’exécution des tentatives, de l’envoi de requêtes par lots à partir d’UDFs vectorisées et de la gestion des exceptions.

Traiter une ligne à la fois lors de l’utilisation de l’accès externe dans une UDF ou une UDTFvectorisée¶

Lorsque votre code de gestionnaire d’UDF ou d’UDTF vectorisée fait des requêtes auprès d’un réseau externe, vous devez traiter chaque ligne indépendamment afin d’éviter des résultats non déterministes.

Pour réduire les frais de mise en réseau, Snowflake regroupe généralement les lignes à envoyer aux services distants. Le nombre de lots et la taille de chaque lot peuvent varier.

En outre, l’ordre des lots peut varier et l’ordre des lignes d’un lot peut varier. Même si la requête contient une clause ORDER BY, ORDER BY est généralement appliqué après la requête de l’emplacement réseau externe.

Etant donné que la taille du lot et l’ordre des lignes ne sont pas garantis, l’écriture d’un code de gestionnaire qui renvoie une valeur pour une ligne qui dépend de toute autre ligne de ce lot ou des lots précédents peut produire des résultats non déterministes.

Snowflake recommande fortement que votre traitement de code traite chaque ligne indépendamment.

La valeur de retour pour chaque ligne d’entrée doit dépendre uniquement de cette ligne d’entrée, pas des autres lignes d’entrée. (Actuellement, les gestionnaires qui effectuent un accès au réseau externe ne prennent pas en charge les fonctions de fenêtrage, par exemple).

Notez également que la taille des lots n’étant pas garantie, le comptage des lots n’est pas significatif.

Réutiliser la connexion TCP si possible¶

Snowflake limite le nombre total de connexions qui peuvent être établies à partir d’une UDF. Lorsque cette limite est atteinte, le message d’erreur suivant peut apparaître :

Cannot assign requested address

Pour éviter les problèmes d’épuisement des ressources, vous devez essayer de réutiliser les connexions autant que possible. Vous pouvez y parvenir en créant le client ou la session TCP une fois pendant l’initialisation de l’UDF, puis en l’utilisant dans le gestionnaire d’UDF pour le reste de la requête. Par exemple, pour un code écrit en Python, vous pouvez réutiliser l’objet Session (disponible dans la bibliothèque Python requests) pour plusieurs appels HTTP.

Pour plus d’informations et un exemple, voir Utilisation de l’intégration de l’accès externe dans une fonction ou une procédure.

S’attendre à des erreurs transitoires dans le code et les gérer¶

Lorsque vous avez une requête longuement exécutée qui appelle le service distant plusieurs fois, il est possible que l’un des appels échoue avec une erreur transitoire. Pour éviter les échecs de requête, votre code doit exécuter des tentatives et gérer les échecs en partant du principe que des échecs peuvent se produire.