Dépannage de Snowpipe¶

Notifications d’erreur¶

Configuration des notifications d’erreur pour Snowpipe Lorsque Snowpipe rencontre des erreurs pendant un chargement, la fonction envoie une notification à un service de messagerie dans le Cloud configuré, ce qui permet d’analyser vos fichiers de données. Pour plus d’informations, voir Notifications d’erreur Snowpipe.

Étapes de dépannage général¶

Effectuez les étapes suivantes pour identifier la cause de la plupart des problèmes empêchant le chargement automatique des fichiers.

Fichiers générés dans le stockage Microsoft Azure Data Lake Storage Gen2 non chargés¶

Actuellement, certains clients tiers n’appellent pas FlushWithClose dans l’API ADLS Gen 2 REST. Cette étape est nécessaire pour déclencher des événements qui notifient à Snowpipe de charger les fichiers. Essayez d’appeler l’API REST manuellement pour déclencher le chargement de ces fichiers par Snowpipe.

Pour plus d’informations sur la méthode Flush avec l’argument close voir https://docs.microsoft.com/en-us/dotnet/api/azure.storage.files.datalake.datalakefileclient.flush. Pour des informations de référence supplémentaires REST API concernant la charge du paramètre close voir https://docs.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/update.

Snowpipe arrête le chargement des fichiers après la suppression de l’abonnement à une rubrique Amazon SNS¶

La première fois qu’un utilisateur crée un objet canal qui fait référence à un sujet spécifique d’Amazon Simple Notification Service (SNS), Snowflake abonne une file d’attente d’Amazon Simple Queue Service (SQS) au sujet. Si un administrateur AWS supprime l’abonnement SQS au sujet SNS, tout canal qui fait référence au sujet ne reçoit plus de messages d’événements d’Amazon S3.

Pour résoudre le problème :

1. Attendez 72 heures à partir du moment où l’abonnement au sujet SNS a été supprimé.

   Après 72 heures, Amazon SNS efface l’abonnement supprimé. Pour plus d’informations, consultez la documentation Amazon SNS.

2. Recréez tous les canaux qui font référence au sujet (en utilisant CREATE OR REPLACE PIPE). Référence le même sujet SNS dans la définition du canal. Pour obtenir des instructions, voir Étape 3 : Création d’un canal avec l’intégration automatique activée.

Tous les canaux qui fonctionnaient avant la suppression de l’abonnement au sujet SNS devraient maintenant recommencer à recevoir des messages d’événements de S3.

Pour contourner le délai de 72 heures, vous pouvez créer un sujet SNS avec un nom différent. Recréez tous les canaux qui font référence au sujet en utilisant la commande CREATE OR REPLACE PIPE et spécifiez le nouveau nom du sujet.

Chargements depuis Google Cloud Storage retardés ou fichiers manquants¶

Lorsque le chargement automatique de données à partir de Google Cloud Storage (GCS) à l’aide de messages Pub/Sub est configuré, le message d’événement pour un seul fichier mis en zone de préparation pouvait être lu. Par ailleurs, les chargements de données à partir de GCS pourraient être retardés de quelques minutes à une journée ou plus. En général, l’un ou l’autre de ces problèmes est causé lorsqu’un administrateur GCS n’a pas accordé au compte de service Snowflake le rôle Monitoring Viewer.

Pour les instructions, consultez « Étape 2 : accorder un accès à Snowflake à l’abonnement Pub/Sub » dans Configuration de l’accès sécurisé au stockage Cloud.

Notifications d’erreur¶

La prise en charge des notifications d’erreur Snowpipe est disponible pour les comptes Snowflake hébergés sur Amazon Web Services (AWS). Les erreurs rencontrées lors d’un chargement de données déclenchent des notifications qui permettent l’analyse de vos fichiers de données. Pour plus d’informations, voir Notifications d’erreur Snowpipe.

Étapes de dépannage général¶

Effectuez les étapes suivantes pour identifier la cause de la plupart des problèmes empêchant le chargement des fichiers.

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

Ensemble de fichiers non chargés¶

Duplication de données dans les tables cibles¶

Comparez les instructions COPY INTO <table> dans les définitions de tous les canaux du compte en exécutant SHOW PIPES ou en interrogeant la vue PIPES dans Account Usage ou la vue PIPES dans Information Schema. Si plusieurs canaux font référence au même emplacement de stockage Cloud dans les instructions COPY INTO <table>, vérifiez que les chemins de répertoire ne se chevauchent pas. Sinon, plusieurs canaux pourraient charger le même ensemble de fichiers de données dans les tables cibles. Par exemple, cette situation peut se produire lorsque plusieurs définitions de canaux font référence au même emplacement de stockage avec différents niveaux de granularité, tels que <emplacement_stockage>/path1/ et <emplacement_stockage>/path1/path2/. Dans cet exemple, si les fichiers sont en zone de préparation dans <emplacement_stockage>/path1/path2/, les deux canaux chargeront une copie des fichiers.

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 au chargement de données à l’aide de l’API REST Snowpipe :

create or replace pipe mypipe as copy into mytable from @mystage;

Copy

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 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. Voir Ensemble des fichiers non chargés dans cette rubrique pour plus d’informations.

Chargement d’horaires insérés en utilisant un CURRENT_TIMESTAMP antérieur aux valeurs LOAD_TIME dans la vue COPY_HISTORY¶

Les concepteurs de tables peuvent ajouter une colonne d’horodatage qui insère l’horodatage actuel comme valeur par défaut lorsque des enregistrements sont chargés dans une table. L’objectif est de saisir l’heure à laquelle chaque enregistrement a été chargé dans la table ; toutefois, les horodatages sont antérieurs aux valeurs de la colonne LOAD_TIME renvoyées par la fonction COPY_HISTORY (Information Schema) ou la vue COPY_HISTORY (Account Usage). La raison en est que CURRENT_TIMESTAMP est évalué lorsque l’opération de chargement est compilée dans les services Cloud plutôt que lorsque l’enregistrement est inséré dans la table (c’est-à-dire lorsque la transaction pour l’opération de chargement est validée).

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

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 stage_name SET STORAGE_INTEGRATION = storage_integration_name, où :

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

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

Erreurs relatives à Snowpipe faisant référence à des régions gouvernementales¶

Vous pouvez obtenir une erreur lorsque Snowpipe fait référence à un compartiment dans une région gouvernementale alors que le compte se trouve dans une région commerciale. Notez que les régions gouvernementales des fournisseurs Cloud n’autorisent pas l’envoi de notifications d’événements vers ou depuis d’autres régions commerciales. Pour plus d’informations, voir AWS GovCloud (US) et Azure Government.