Dépannage de Snowpipe

Ce chapitre décrit une approche méthodique pour dépanner des problèmes liés aux chargements de données avec Snowpipe.

Dans ce chapitre :

Les étapes permettant de résoudre les problèmes liés à Snowpipe diffèrent en fonction du flux de travail utilisé pour charger les fichiers de données.

Chargement automatique de données à l’aide de notifications d’événement de stockage dans le Cloud

Étape 1 : Vérification du statut du canal

Récupérez le statut actuel du canal. Les résultats sont affichés au format JSON. Pour plus d’informations, voir SYSTEM$PIPE_STATUS.

Vérifiez les valeurs suivantes :

lastReceivedMessageTimestamp

Spécifie l’horodatage du dernier message d’événement reçu de la file d’attente de messages. Notez que ce message peut ne pas s’appliquer au canal spécifique, par exemple si le chemin d’accès associé au message ne correspond pas au chemin indiqué dans la définition du canal. De plus, seuls les messages déclenchés par des objets de données créés sont consommés par les canaux d’intégration automatique.

Si l’horodatage est plus tôt que prévu, cela indique probablement un problème lié à la configuration du service (c’est-à-dire Amazon SQS ou Amazon SNS, ou Event Grid Azure) ou au service en soi. Si le champ est vide, vérifiez vos paramètres de configuration de service. Si le champ contient un horodatage mais qu’il est plus tôt que prévu, vérifiez si des paramètres ont été modifiés dans la configuration de votre service.

lastForwardedMessageTimestamp

Spécifie l’horodatage du dernier message d’événement « créer un objet » avec un chemin correspondant qui a été transféré au canal.

Si les messages d’événement sont reçus de la file de messages mais ne sont pas transférés vers le canal, il existe probablement une incompatibilité entre le chemin de stockage blob où les nouveaux fichiers de données sont créés et le chemin combiné spécifié dans les définitions de zone de préparation et de canal Snowflake. Vérifiez tous les chemins spécifiés dans les définitions de zone de préparation et de canal. Notez qu’un chemin spécifié dans la définition de canal est ajouté à tout chemin de la définition de zone de préparation.

Étape 2. Affichage de l’historique COPY de la table

Si les messages d’événement sont reçus et transférés, interrogez l’historique de l’activité de chargement de la table cible. Pour plus d’informations, voir COPY_HISTORY.

La colonne STATUS indique si un ensemble particulier de fichiers a été chargé, partiellement chargé ou non. La colonne FIRST_ERROR_MESSAGE fournit une raison lorsqu’une tentative est partiellement chargée ou échouée.

Notez que si un ensemble de fichiers pose plusieurs problèmes, la colonne FIRST_ERROR_MESSAGE indique seulement la première erreur rencontrée. Pour afficher toutes les erreurs dans les fichiers, exécutez une instruction COPY INTO <table> avec l’option de copie VALIDATION_MODE définie sur RETURN_ALL_ERRORS. L’option de copie VALIDATION_MODE commande une instruction COPY pour valider les données à charger et retourner les résultats en fonction de l’option de validation spécifiée. Aucune donnée n’est chargée lorsque cette option de copie est spécifiée. Dans l’instruction, faites référence à l’ensemble des fichiers que vous avez tenté de charger à l’aide de Snowpipe. Pour plus d’informations sur l’option de copie, voir COPY INTO <table>.

Si la sortie COPY_HISTORY n’inclut pas un ensemble de fichiers attendus, interrogez une période antérieure. Si les fichiers étaient des doublons d’anciens fichiers, l’historique de chargement aurait peut-être enregistré l’activité lors de la tentative de chargement des fichiers d’origine.

Étape 3 : Validation des fichiers de données

Si l’opération de chargement rencontre des erreurs dans les fichiers de données, la fonction de table COPY_HISTORY décrit la première erreur rencontrée dans chaque fichier. Pour valider les fichiers de données, interrogez la fonction VALIDATE_PIPE_LOAD.

Appeler des points de terminaison REST Snowpipe pour charger les données

Étape 1 : Vérification des problèmes d’authentification

Les points de terminaison REST de Snowpipe utilisent l’authentification par paire de clés avec un jeton Web JSON (JWT).

Les SDKs d’intégration Python/Java génèrent le JWT pour vous. Lorsque vous appelez directement l’API REST, vous devez la générer. Si aucun jeton JWT n’est fourni dans la requête, l’erreur 400 est renvoyée par le point de terminaison REST. Si un jeton non valide est fourni, une erreur similaire à celle qui suit est renvoyée :

snowflake.ingest.error.IngestResponseError: Http Error: 401, Vender Code: 390144, Message: JWT token is invalid.

Étape 2. Affichage de l’historique COPY de la table

Interrogez l’historique de l’activité de chargement d’une table, y compris toute tentative de chargement de données à l’aide de Snowpipe. Pour plus d’informations, voir COPY_HISTORY. La colonne STATUS indique si un ensemble particulier de fichiers a été chargé, partiellement chargé ou non. La colonne FIRST_ERROR_MESSAGE fournit une raison lorsqu’une tentative est partiellement chargée ou échouée.

Notez que si un ensemble de fichiers pose plusieurs problèmes, la colonne FIRST_ERROR_MESSAGE indique seulement la première erreur rencontrée. Pour afficher toutes les erreurs dans les fichiers, exécutez une instruction COPY INTO <table> avec l’option de copie VALIDATION_MODE définie sur RETURN_ALL_ERRORS. L’option de copie VALIDATION_MODE commande une instruction COPY pour valider les données à charger et retourner les résultats en fonction de l’option de validation spécifiée. Aucune donnée n’est chargée lorsque cette option de copie est spécifiée. Dans l’instruction, faites référence à l’ensemble des fichiers que vous avez tenté de charger à l’aide de Snowpipe. Pour plus d’informations sur l’option de copie, voir COPY INTO <table>.

Étape 3 : Vérification du statut du canal

Si la fonction de table COPY_HISTORY affiche zéro résultat pour la charge de données que vous étudiez, récupérez l’état actuel du canal. Les résultats sont affichés au format JSON. Pour plus d’informations, voir SYSTEM$PIPE_STATUS.

La clé executionState identifie l’état d’exécution du canal. Par exemple, PAUSED indique que le canal est actuellement en pause. Le propriétaire du canal pourrait reprendre l’exécution du canal à l’aide de ALTER PIPE.

Si la valeur executionState indique un problème lors du démarrage du canal, vérifiez la clé error pour plus d’informations.

Étape 4 : Validation des fichiers de données

Si l’opération de chargement rencontre des erreurs dans les fichiers de données, la fonction de table COPY_HISTORY décrit la première erreur rencontrée dans chaque fichier. Pour valider les fichiers de données, interrogez la fonction VALIDATE_PIPE_LOAD.

Autres problèmes

Ensemble de fichiers déchargés

Si la sortie de la fonction COPY_HISTORY indique qu’un sous-ensemble de fichiers n’a pas été chargé, vous pouvez essayer de « rafraîchir » le canal.

Cette situation peut survenir dans l’une ou l’autre des situations suivantes :

  • La zone de préparation externe était précédemment utilisée pour charger les données en lot à l’aide de la commande COPY INTO table.

  • REST API:

    • La fonctionnalité externe pilotée par événement est utilisée pour appeler les APIs REST, et un backlog de fichiers de données existait déjà dans la zone de préparation externe avant que les événements soient configurés.

  • Auto-intégration :

    • Un retard de traitement des fichiers de données existait déjà dans la zone de préparation externe avant la configuration des notifications d’événement.

    • Un échec de notification d’événement a empêché la mise en file d’attente d’un ensemble de fichiers.

Pour charger les fichiers de données dans votre zone de préparation externe à l’aide du canal configuré, exécutez une instruction ALTER PIPE … REFRESH.

Impossible de recharger les données modifiées, données modifiées chargées par inadvertance

Snowflake utilise des métadonnées de chargement de fichiers pour éviter de recharger les mêmes fichiers (et de dupliquer les données) dans une table. Snowpipe empêche le chargement de fichiers portant le même nom même s’ils ont été modifiés ultérieurement (c’est-à-dire qu’ils ont un eTag différent).

Les métadonnées de chargement de fichiers sont associées à l”objet canal plutôt qu’à la table. En conséquence :

  • Les fichiers en zone de préparation portant le même nom que les fichiers déjà chargés sont ignorés, même s’ils ont été modifiés, par exemple si de nouvelles lignes ont été ajoutées ou si des erreurs dans le fichier ont été corrigées.

  • Tronquer la table à l’aide de la commande TRUNCATE TABLE n’entraîne pas la suppression des métadonnées de chargement de fichier de Snowpipe.

Cependant, notez que les canaux ne conservent les métadonnées de l’historique de chargement que pendant 14 jours. Donc :

Fichiers modifiés et mis en zone de préparation dans les 14 jours

Snowpipe ignore les fichiers modifiés qui sont à nouveau mis en zone de préparation. Pour recharger les fichiers de données modifiés, il est actuellement nécessaire de recréer l’objet de canal en utilisant la syntaxe CREATE OR REPLACE PIPE.

L’exemple suivant recrée le canal mypipe en se basant sur l’exemple de l’étape 1 de Préparation du chargement des données à l’aide de l’API REST Snowpipe :

create or replace pipe mypipe as copy into mytable from @mystage;
Fichiers modifiés et mis en zone de préparation après 14 jours

Snowpipe charge à nouveau les données, ce qui peut entraîner des enregistrements en double dans la table cible.

De plus, des enregistrements en double peuvent être chargés dans la table cible si des instructions COPY INTO <table> sont exécutées, qui font référence aux mêmes compartiment/conteneur, chemin et table cible que dans les chargements Snowpipe actifs. Les historiques de chargement de la commande COPY et de Snowpipe sont stockés séparément dans Snowflake. Une fois que vous avez chargé des données mises en zone de préparation historiques, si vous devez charger des données manuellement à l’aide de la configuration de canal, exécutez une instruction ALTER PIPE … REFRESH. Reportez-vous à la section Ensemble de fichiers non chargé de cette rubrique pour plus d’informations.

Erreur : l’intégration {0} associée à la zone de préparation {1} est introuvable

Le chargement de données à partir d’une zone de préparation externe peut générer une erreur similaire à celle-ci :

003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.

Cette erreur peut se produire lorsque l’association entre la zone de préparation externe et l’intégration de stockage liée à la zone de préparation a été rompue. Cela se produit lorsque l’objet d’intégration de stockage a été recréé (avec CREATE OR REPLACE STORAGE INTEGRATION). Une zone de préparation est liée à une intégration de stockage à l’aide d’un ID caché plutôt que le nom de l’intégration de stockage. En coulisse, la syntaxe CREATE OR REPLACE détruit l’objet et le recrée avec un ID caché différent.

Si vous devez recréer une intégration de stockage après qu’elle a été liée à une ou plusieurs zones de préparation, vous devez rétablir l’association entre chaque zone de préparation et l’intégration de stockage en exécutant ALTER STAGE nom_zone_préparation SET STORAGE_INTEGRATION = nom_intégration_stockage, où :

  • nom_zone_préparation est le nom de la zone de préparation.

  • nom_intégration_stockage est le nom de l’intégration de stockage.