Gestion de Snowpipe

Ce chapitre décrit les tâches administratives associées à la gestion de Snowpipe.

Dans ce chapitre :

Suppression des fichiers en zone de préparation après le chargement des données par Snowpipe

Les objets canal ne prennent pas en charge l’option de copie PURGE. Snowpipe ne peut pas supprimer automatiquement les fichiers en zone de préparation lorsque les données sont chargées avec succès dans les tables.

Pour supprimer les fichiers en zone de préparation dont vous n’avez plus besoin, nous vous recommandons d’exécuter périodiquement la commande REMOVE.

Vous pouvez également configurer les fonctions de gestion du cycle de vie fournies par votre fournisseur de services de stockage Cloud.

Chargement de données historiques

Note

Les informations de cette section concernent les chargements de données automatisés à l’aide de notifications d’événement. Les appels vers l’API REST de Snowpipe peuvent charger des données historiques sans nécessiter d’étapes supplémentaires.

Une instruction ALTER PIPE … REFRESH copie un ensemble de fichiers de données mis en zone de préparation au cours des sept jours précédents dans la file d’attente d’intégration de Snowpipe pour un chargement dans la table cible. Si vous souhaitez charger des données à partir de fichiers mis en zone de préparation précédemment, nous vous recommandons les étapes suivantes :

  1. Chargez les données historiques dans la table cible en exécutant une instruction COPY INTO <table>.

  2. Configurez les chargements de données automatiques à l’aide de Snowpipe avec les notifications d’événement. Les fichiers qui viennent d’être créés déclencheront des notifications d’événements pour une intégration dans la table cible. Étant donné que les fichiers de données historiques ne déclenchent pas de notifications d’événements, ils ne sont pas chargés deux fois.

    Pour obtenir des instructions, voir :

    Amazon S3

    Automatisation de Snowpipe pour Amazon S3

    Google Cloud Storage

    Snowpipe automatisé pour Google Cloud Storage

    Microsoft Azure

    Automatisation de Snowpipe pour le stockage Microsoft Azure Blob

  3. Exécutez une instruction ALTER PIPE … REFRESH pour mettre en file d’attente tous les fichiers mis en zone de préparation entre les étapes 1 et 2. L’instruction vérifie l’historique de chargement de la table cible et du canal pour s’assurer que les mêmes fichiers ne sont pas chargés deux fois.

Recréation de canaux

La recréation d’un canal (à l’aide d’une instruction CREATE OR REPLACE PIPE) est nécessaire pour modifier la plupart des propriétés du canal.

Cette section décrit les considérations et les meilleures pratiques à suivre lors de la recréation de canaux.

Recréer des canaux pour des chargements de données automatisés

Lors de la recréation d’un canal qui automatise les chargements de données à l’aide de notifications d’événements, nous vous recommandons d’effectuer les étapes suivantes :

  1. Mettez en pause le canal (à l’aide de ALTER PIPE … SET PIPE_EXECUTION_PAUSED = true).

  2. Interrogez la fonction SYSTEM$PIPE_STATUS et vérifiez que l’état d’exécution du canal est PAUSED.

  3. Recréez le canal (en utilisant CREATE OR REPLACE PIPE).

  4. Mettez à nouveau le canal en pause.

  5. Passez en revue les étapes de configuration de votre service de messagerie Cloud pour vous assurer que les paramètres sont toujours exacts :

  6. Reprenez le canal (en utilisant ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false).

  7. Interrogez à nouveau la fonction SYSTEM$PIPE_STATUS et vérifiez que l’état d’exécution du canal est RUNNING.

Historique de chargement

L’historique de chargement des opérations Snowpipe est stocké dans les métadonnées de l’objet canal. Lorsqu’un canal est recréé, l’historique de chargement est détruit. En général, cette condition n’affecte les utilisateurs que s’ils exécutent ensuite une instruction ALTER PIPE … REFRESH sur le canal. Cela pourrait avoir pour effet le chargement de données en double à partir de fichiers en zone de préparation dans l’emplacement de stockage du canal si les données ont déjà été chargées avec succès et si les fichiers n’ont pas été supprimés par la suite.

Modification des paramètres Cloud de la zone de préparation référencée

Les paramètres Cloud d’une zone de préparation externe sont les suivants :

  • URL

  • STORAGE_INTEGRATION

  • ENCRYPTION

Une fois que Snowpipe a été configuré avec succès, si vous devez modifier l’un des paramètres Cloud de la zone de préparation référencée, nous vous recommandons d’effectuer les étapes suivantes :

  1. Mettez en pause le canal (à l’aide de ALTER PIPE … SET PIPE_EXECUTION_PAUSED = true). Attendez que tous les fichiers actuellement en file d’attente soient chargés dans la table cible.

  2. Modifiez les paramètres de zone de préparation si nécessaire (en utilisant ALTER STAGE).

  3. Reprenez le canal (avec ALTER PIPE ... SET PIPE_EXECUTION_PAUSED = false).

Étant donné que les canaux ne sont pas transactionnels, ces étapes garantissent que Snowpipe met les fichiers en file d’attente en utilisant les dernières valeurs de paramètre de zone de préparation.

Avertissement

La modification du paramètre URL d’une zone de préparation peut entraîner le blocage de tout canal dépendant qui utilise la messagerie cloud pour déclencher des chargements de données (c’est-à-dire où AUTO_INGEST = TRUE).

Transfert de propriété de canal

Effectuez les étapes suivantes pour transférer la propriété d’un canal :

  1. Définissez le paramètre PIPE_EXECUTION_PAUSED sur TRUE.

    Ce paramètre permet de suspendre ou de reprendre un canal. Ce paramètre est pris en charge aux niveaux suivants :

    • Compte

    • Schéma

    • Canal

    Au niveau du canal, le propriétaire de l’objet (ou un rôle parent dans une hiérarchie de rôles) peut définir le paramètre pour interrompre ou reprendre un canal spécifique.

    Un administrateur de compte (utilisateur avec le rôle ACCOUNTADMIN) peut définir ce paramètre au niveau du compte pour interrompre ou reprendre tous les canaux du compte. De même, un utilisateur avec le privilège MODIFY sur le schéma peut mettre en pause ou reprendre les canaux au niveau du schéma. Notez que ce contrôle de domaine plus large n’affecte que les canaux pour lesquels le paramètre n’a pas déjà été réglé à un niveau inférieur, par exemple, par le propriétaire au niveau objet.

  2. Transférer la propriété du canal en utilisant GRANT OWNERSHIP.

  3. Forcez la reprise du canal (avec SYSTEM$PIPE_FORCE_RESUME).

    Cette étape permet au nouveau propriétaire d’évaluer le statut du canal et de déterminer combien de fichiers de données sont en attente d’être chargés à l’aide de la commande SYSTEM$PIPE_STATUS. Nous vous recommandons de vérifier que seuls les fichiers approuvés pour le chargement dans la table cible sont mis en file d’attente.

Modification de l’instruction COPY dans une définition de canal

Effectuez les étapes suivantes pour modifier l’instruction COPY dans une définition de canal. Par exemple, lorsque des colonnes sont ajoutées à la table cible.

Pour exécuter les commandes de cette section, le rôle actuel de l’utilisateur doit disposer du privilège OWNERSHIP sur le canal.

  1. Mettez en pause le canal (à l’aide de ALTER PIPE … SET PIPE_EXECUTION_PAUSED=true).

  2. Interrogez la fonction SYSTEM$PIPE_STATUS et vérifiez que l’état d’exécution du canal est PAUSED et que le nombre de fichiers en attente est de 0.

  3. Recréez le canal pour modifier l’instruction COPY dans la définition. Choisissez l’une des options suivantes :

  4. Mettez à nouveau le canal en pause.

  5. Passez en revue les étapes de configuration de votre service de messagerie Cloud pour vous assurer que les paramètres sont toujours exacts :

  6. Reprenez le canal (en utilisant ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false).

  7. Interrogez à nouveau la fonction SYSTEM$PIPE_STATUS et vérifiez que l’état d’exécution du canal est RUNNING.

Note

Les métadonnées de chargement de fichiers sont associées à l” objet canal plutôt qu’à la table. La recréation du canal supprime l’historique des fichiers chargés. Assurez-vous que les fichiers déjà chargés par Snowpipe ne sont pas accidentellement soumis à nouveau au canal, puis chargés à nouveau dans la table cible. Pour afficher l’historique des requêtes d’une table, interrogez la fonction COPY_HISTORY.

Reprise d’un canal obsolète

Note

Cette section s’intéresse uniquement aux objets de canal qui exploitent la messagerie Cloud pour déclencher des chargements de données (c’est-à-dire où AUTO_INGEST = TRUE dans la définition du canal).

Lorsqu’un canal est mis en pause, les messages d’événements reçus pour ce canal entrent dans une période de conservation limitée. La période est de 14 jours par défaut. Si un canal est mis en pause pendant plus de 14 jours, il est considéré comme obsolète.

Pour reprendre un canal obsolète, un rôle qualifié doit appeler la fonction SYSTEM$PIPE_FORCE_RESUME et saisir l’argument STALENESS_CHECK_OVERRIDE. Cet argument indique que l’on comprend que le rôle reprend un canal obsolète.

Par exemple, reprendre le canal stalepipe1 obsolète dans la base de données et le schéma mydb.myschema :

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1','staleness_check_override');
Copy

Pendant que le canal obsolète était en pause, si la propriété du canal a été transférée à un autre rôle, la reprise du canal nécessite l’argument OWNERSHIP_TRANSFER_CHECK_OVERRIDE supplémentaire. Par exemple, reprendre le canal stalepipe2 obsolète dans la base de données et le schéma mydb.myschema, qui a été transféré à un nouveau rôle :

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1','staleness_check_override, ownership_transfer_check_override');
Copy

Lorsqu’une notification d’événement reçue pendant qu’un canal est en pause atteint la fin de la période de conservation limitée, Snowflake planifie sa suppression des métadonnées internes. Si le canal est repris ultérieurement, Snowpipe traite ces anciennes notifications au mieux. Snowflake ne peut pas garantir qu’elles sont traitées.

Par exemple, si un canal est repris 15 jours après avoir été mis en pause, Snowpipe ignore généralement toute notification d’événement reçue le premier jour où le canal a été mis en pause (c’est-à-dire qui date maintenant de plus de 14 jours). Si le canal est repris 16 jours après avoir été mis en pause, Snowpipe ignore généralement les notifications d’événements qui ont été reçues le premier et le deuxième jour après la mise en pause du canal. Et ainsi de suite.

Langage: Français