Dépannage des fonctions externes

Cette rubrique décrit comment dépanner une fonction externe.

Notez que pour certaines plates-formes Cloud, les instructions de création d’une fonction externe sur cette plate-forme Cloud peuvent contenir des informations de dépannage supplémentaires.

Dans ce chapitre :

Dépannage général

Assurez-vous que les arguments de la fonction externe correspondent aux arguments du service distant

Si vous écrivez votre propre service distant et si vous modifiez le nombre, les types de données ou l’ordre des arguments dans le service distant, n’oubliez pas d’apporter les modifications correspondantes à la fonction externe. Actuellement, la commande ALTER EXTERNAL FUNCTION n’a pas d’option pour modifier les paramètres, vous devez donc supprimer et recréer la fonction externe pour modifier les arguments.

Performance

Les conseils suivants peuvent vous aider à déboguer les problèmes de performances :

Consultez également la section de dépannage sur l”évolutivité.

Évolutivité

Les conseils suivants peuvent vous aider à déboguer les problèmes d’évolutivité :

  • Utilisez la page Profil de requête pour connaître la latence moyenne par requête.

  • Utilisez la page Profil de requête pour voir combien de fois les requêtes ont été retentées en raison d’erreurs transitoires, y compris celles listées dans la section intitulée Ne supposez pas que le service distant a validé chaque ligne exactement une fois.

  • Surveillez l’utilisation des ressources de votre service distant pour voir comment il s’adapte à la charge et assurez-vous que le service distant dispose d’une capacité suffisante pour répondre aux pics de charge.

  • Utilisez la journalisation dans Amazon API Gateway ou dans le service distant pour obtenir des détails par requête.

  • Contrôlez la simultanéité avec laquelle Snowflake envoie des requêtes à son service distant. Pour plus de détails, voir simultanéité.

  • Renvoie le code de réponse HTTP 429 du service distant lorsqu’il est surchargé. Renvoyez-le le plus tôt possible, plutôt que d’attendre que la latence augmente.

  • Tenez compte du délai d’expiration du service proxy. Par exemple, à compter de juillet 2020, le délai d’expiration pour Amazon API Gateway est de 30 secondes. Les délais d’expiration peuvent être causés par divers facteurs, notamment la surcharge du service distant.

Snowflake tente de réessayer les erreurs/délais d’expiration dans un délai raisonnable, mais si le service continue d’être surchargé et que les tentatives échouent, la requête est finalement abandonnée.

Voir également la section de dépannage sur Performance.

Symptômes spécifiques

Symptômes indépendants de la plate-forme

Symptôme : lorsque vous essayez d’appeler la fonction externe, vous obtenez le message « Erreur d’analyse JSON : réponse non valide »

Cause(s) possible(s)

La cause la plus probable est que le JSON renvoyé par le service distant (par exemple fonction AWS Lambda) n’est pas construit correctement.

Solution(s) possible(s)

Assurez-vous de renvoyer un tableau de tableaux, avec un tableau interne renvoyé pour chaque ligne d’entrée reçue. Consultez la description du format de sortie sur Format de données reçu par Snowflake.

Symptôme : un message d’erreur indiquant que la valeur renvoyée n’est pas au format JSON

Cause(s) possible(s)

Une cause possible de ceci est que votre valeur de retour inclut des guillemets doubles à l’intérieur de la valeur.

Solution(s) possible(s)

Bien que les chaînes JSON soient délimitées par des guillemets doubles, la chaîne elle-même ne doit pas commencer et se terminer par un guillemet dans la plupart des cas. Si les guillemets doubles intégrés sont incorrects, supprimez-les.

Symptôme : un message d’erreur indiquant que la fonction reçoit le mauvais nombre de lignes

Cause(s) possible(s)

Le service distant a probablement tenté de renvoyer plus ou moins de lignes qu’il en a reçues. (N’oubliez pas, même si la fonction est nominalement scalaire, elle peut recevoir plusieurs lignes dans le champ « body » du paramètre « event » et doit renvoyer exactement autant de lignes qu’elle a reçues.)

Solution(s) possible(s)

Assurez-vous que le service distant renvoie une ligne pour chaque ligne qu’il reçoit.

AWS

Symptôme : lorsque vous appelez votre fonction à partir de SQL, vous obtenez un message indiquant que les numéros de ligne ne sont pas en ordre

Cause(s) possible(s)

N’oubliez pas que les numéros de ligne que vous renvoyez doivent être des entiers ascendants monotones à partir de 0. Les numéros de ligne d’entrée doivent également suivre cette règle, et chaque sortie doit correspondre à la ligne d’entrée correspondante ; par exemple, la sortie dans la ligne de sortie 0 doit correspondre à l’entrée dans la ligne d’entrée 0.

Solution(s) possible(s)
  1. Assurez-vous que les numéros de ligne que vous renvoyez sont identiques à ceux que vous avez reçus et que chaque valeur de sortie utilise le numéro de ligne de l’entrée correspondante. Cela devrait fonctionner. Si ce n’est pas le cas, il est possible que les numéros de ligne en entrée ne soient pas corrects ou que vous n’ayez pas renvoyé les lignes dans le bon ordre. Passez donc à l’étape 2 ci-dessous.

  2. Assurez-vous que les numéros de ligne de sortie commencent par 0, augmentent de 1 et sont en ordre.

Symptôme : une Amazon API Gateway renvoie une erreur 502 lorsque le point de terminaison utilise l’intégration du proxy Lambda

Cause(s) possible(s)

La fonction Lambda peut avoir :

  • Expiré.

  • Renvoyé une exception.

  • Echoué d’une autre manière.

Solution(s) possible(s)

Si les journaux Lambda ou API Gateway sont à votre disposition, examinez-les.

Si le code source de la fonction Lambda est à votre disposition, analysez et déboguez le code dans la fonction Lambda. Dans certains cas, vous pourrez peut-être exécuter une copie de ce code dans un contexte plus simple (en dehors de AWS) pour faciliter le débogage.

Vérifiez que les données envoyées à la fonction Lambda sont au format attendu par la fonction Lambda. Vous voudrez peut-être essayer d’envoyer un ensemble de données plus petit et plus simple pour voir si cela réussit.

Vérifiez que vous n’envoyez pas trop de données à la fois.

Dans certains cas, l’augmentation du délai d’attente peut résoudre le problème, en particulier si la fonction Lambda nécessite beaucoup de ressources CPU, ou si la fonction Lambda elle-même appelle d’autres services distants et nécessite donc plus de temps.

Fonction EXTERNAL_FUNCTIONS_HISTORY

Symptôme : EXTERNAL_FUNCTIONS_HISTORY renvoie « … identificateur non valide… »

Cause possible

Vous n’avez peut-être pas mis la signature de fonction entre guillemets simples. Par exemple, ce qui suit est faux car les guillemets ne sont pas inclus :

select *
  from table(information_schema.external_functions_history(
    function_signature => mydb.public.myfunction(integer, varchar)));
Solution possible

Corrigez cela en ajoutant des guillemets autour de la signature de la fonction :

select *
  from table(information_schema.external_functions_history(
    function_signature => 'mydb.public.myfunction(integer, varchar)'));

Symptôme : EXTERNAL_FUNCTIONS_HISTORY renvoie une seule ligne de sortie et de nombreuses colonnes sont NULL

Cause possible

Vous n’avez probablement pas inclus de signature de fonction. Si vous ne spécifiez pas de signature de fonction, alors EXTERNAL_FUNCTION_HISTORY() renvoie les valeurs agrégées pour les colonnes telles que INVOCATIONS, SENT ROWS, etc., et renvoie NULL pour les colonnes telles que le nom de la fonction, les listes d’arguments, etc.

Solution possible

Si vous aviez l’intention d’obtenir des informations pour une fonction, incluez une signature de fonction.

Si vous aviez l’intention d’obtenir des informations pour toutes les fonctions, les valeurs NULL de certaines colonnes sont correctes et vous n’avez pas besoin de corriger la requête.