Résilience multi-emplacements pour les pipelines de données¶

Exigences¶

• Version : Snowflake Business Critical Edition (ou une version supérieure).

• Méthodes d’ingestion prises en charge : cette fonctionnalité prend exclusivement en charge le chargement de données basé sur des fichiers via Snowpipe (intégration automatique) et COPY INTO <table>. Elle ne prend pas en charge Openflow ou Snowpipe Streaming.

• Structures de chemins identiques : pour permettre à vos pipelines de localiser de nouveaux fichiers après le basculement, vous devez les écrire dans l’emplacement de stockage secondaire en utilisant exactement la même hiérarchie, la même structure de dossier et le même chemin relatif que votre emplacement principal.

Considérations¶

• Facturation : cette fonctionnalité entraîne des frais de réplication standard (transfert de données et ressources de calcul), facturés sur votre compte cible.

• Temps d’arrêt lié à la modification de la zone de préparation : modifier la propriété RELATIVE_URL sur une zone de préparation existante invalidera les objets dépendants et arrêtera l’ingestion. Nous vous recommandons de créer de nouvelles zones de préparation lors de la configuration afin d’éviter tout temps d’arrêt.

• Intégration de notifications à plusieurs files d’attente (MQNI) : l’utilisation de la même file d’attente active dans les comptes source et cible n’est pas prise en charge. Cela pourrait entraîner une perte de notifications. Snowflake ne vérifie pas si la même file d’attente est utilisée entre plusieurs comptes.

• Table de répertoire : la création d’une table de répertoire sur une zone de préparation à l’aide de la MLSI n’est actuellement pas prise en charge.

Comportement de réplication¶

• Réplication asynchrone : Snowflake réplique vos tables et l’historique de chargement de votre pipeline dans le même instantané. Étant donné qu’elles sont synchronisées, une panne n’entraînera pas de données en double. Si votre base de données secondaire a quatre heures de retard, les données de la table ont également quatre heures de retard, et le traitement des notifications mises en file d’attente correspondant à ces quatre heures met simplement la table à jour.

• Prévention de la perte de données en double écriture : votre objectif de point de récupération (RPO) est dicté par votre intervalle d’actualisation de réplication. Pour éviter toute perte de données lors d’un basculement, la période de conservation des messages de votre file d’attente de messages dans le Cloud secondaire doit être plus longue que votre intervalle de réplication. Si votre file d’attente supprime des messages avant que votre réplication planifiée ne soit rattrapée, ces fichiers ne seront pas ingérés lors du basculement.

• Risque de perte de données en écriture unique : si vous utilisez le routage en écriture unique, tous les fichiers traités sur l’emplacement principal après votre dernière réplication réussie sont totalement inconnus de l’emplacement secondaire. Lors du basculement, ces données seront temporairement absentes de votre compte cible.

1. Double-écritures - Recommandé¶

Votre application de production écrit simultanément des fichiers dans vos compartiments de stockage Cloud principal et secondaire. La file d’attente de messages secondaire accumule les notifications, mais Snowflake ne les traite pas, car la base de données secondaire est en lecture seule.

• Ce qui se passe lors du basculement : la base de données secondaire devient accessible en écriture. Snowpipe lit la file d’attente secondaire et utilise l’historique de chargement répliqué pour dédupliquer les fichiers. Si une panne empêche un fichier de se terminer dans l’emplacement principal, le pipeline secondaire lit la notification dans la file d’attente secondaire, voit le fichier absent de l’historique de chargement et l’ingère.

• Ce qui se passe lors de la restauration : lorsque l’emplacement principal est récupéré, que vous actualisez le groupe de basculement et que vous effectuez la restauration, Snowpipe démarre automatiquement l’ingestion de nouveaux fichiers, car l’historique de chargement a été synchronisé à partir du compte secondaire lors de la préparation de la restauration.

• Résultat : aucune donnée manquante, aucun doublon. Snowflake gère automatiquement le rapprochement dans les deux directions.

• Action nécessaire : aucune, au-delà de la synchronisation de réplication standard de pré-restauration (ALTER FAILOVER GROUP … REFRESH) pour s’assurer que le compte principal dispose de l’historique de chargement le plus récent.

2. Routage à écriture unique¶

Votre production écrit uniquement dans le stockage Cloud principal. En cas de panne, vous redirigez la production pour commencer à écrire de nouveaux fichiers dans le stockage Cloud secondaire.

• Ce qui se passe lors du basculement : le compte secondaire commence immédiatement à traiter les nouveaux fichiers acheminés vers le compartiment secondaire. Cependant, tous les fichiers en cours bloqués dans l’emplacement principal affecté sont temporairement abandonnés.

• Ce qui se passe lors de la restauration : lorsque l’emplacement principal est récupéré et que vous revenez à votre compte Snowflake principal, Snowpipe traite automatiquement toutes les notifications de fichiers qui ont atteint la file d’attente avant la panne.

• Résultat : aucun doublon. Cependant, tous les fichiers pour lesquels la génération des notifications Cloud a complètement échoué en raison de la panne (ou lorsque la panne a dépassé la politique de conservation des messages de votre file d’attente) nécessitent une intervention manuelle.

• Action nécessaire : après la restauration, comparez votre compartiment de stockage principal par rapport à la vue COPY_HISTORY dans Snowflake pour identifier les fichiers manquants. Exécutez ALTER PIPE … REFRESH ou une commande COPY INTO manuelle pour charger ces fichiers échoués spécifiques.

Étape 1 : Créer une intégration de stockage multi-emplacements (MLSI)¶

Pour configurer une intégration de stockage multi-emplacements, vous suivez les étapes standard de configuration d’une intégration de stockage avec quelques différences notées dans cette section.

Dans votre compte source, créez la MLSI en fournissant des valeurs pour chaque emplacement dans la liste STORAGE_LOCATIONS. Vous pouvez mélanger et faire correspondre les fournisseurs Cloud pour les configurations inter-Cloud.

CREATE STORAGE INTEGRATION my_mlsi
  TYPE = EXTERNAL_STAGE
  STORAGE_LOCATIONS =
  (
    (
      NAME = 'my-s3-us-west-1'
      STORAGE_PROVIDER = 'S3'
      STORAGE_BASE_URL = 's3://myBucketWest'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::12345:role/myrole'
      STORAGE_AWS_EXTERNAL_ID = 'mlsi-external-id'
      ENCRYPTION = ( TYPE = 'AWS_SSE_S3' )
    ),
    (
      NAME = 'my-s3-us-east-1'
      STORAGE_PROVIDER = 'S3'
      STORAGE_BASE_URL = 's3://myBucketEast'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::67890:role/myrole'
      STORAGE_AWS_EXTERNAL_ID = 'mlsi-external-id'
      ENCRYPTION = ( TYPE = 'AWS_SSE_S3' )
    )
  )
  ENABLED = TRUE
  STORAGE_ALLOWED_LOCATIONS = ('*')
  ACTIVE = 'my-s3-us-west-1';

Où :

• STORAGE_LOCATIONS : spécifie une liste d’un ou plusieurs emplacements de stockage (compartiment S3, compartiment GCS ou conteneur Azure) pour l’intégration de stockage. Pour voir les paramètres de chaque fournisseur Cloud, consultez les paramètres des fournisseurs Cloud (cloudProviderParams) sur la page de référence CREATE STORAGE INTEGRATION.

• NAME : chaîne qui spécifie l’identificateur (nom) pour l’emplacement de stockage.

• ENCRYPTION : spécifie le chiffrement pour l’emplacement de stockage. Vous devez spécifier le chiffrement pour l’emplacement de stockage au niveau de l’intégration de stockage plutôt qu’au niveau de la zone de préparation. Nécessaire uniquement pour le chargement à partir de fichiers chiffrés ; non requis si l’emplacement de stockage et les fichiers ne sont pas chiffrés. Pour afficher les options de chiffrement pour chaque fournisseur Cloud, consultez ENCRYPTION sur la page de référence CREATE STAGE.

• ACTIVE : spécifie le nom de l’emplacement de stockage à définir comme emplacement actif pour l’intégration de stockage dans le compte actuel.

  Pour l’emplacement de stockage actif dans votre compte source, vous devez configurer un contrôle d’accès et accorder à Snowflake l’autorisation d’accéder à votre stockage. Utilisez les instructions dans les rubriques suivantes :

  • Configuration d’une intégration de stockage Snowflake pour accéder à Amazon S3

  • Configuration d’une intégration pour Google Cloud Storage

  • Configuration d’un conteneur Azure pour le chargement de données

Étape 2 : Associer l’MLSI à une zone de préparation externe¶

Nous vous recommandons fortement de créer une nouvelle zone de préparation plutôt que de modifier une zone existante.

Utilisez la commande CREATE STAGE pour associer l’intégration de stockage multi-emplacements que vous avez créée à une ou plusieurs zones de préparation externes :

CREATE STAGE my_ext_stage
  RELATIVE_URL = '/my_folder/my_sub_folder/'
  STORAGE_INTEGRATION = 'my_mlsi';

Où :

• RELATIVE_URL : le chemin relatif vers votre emplacement de zone de préparation externe à partir de l’emplacement de stockage défini dans votre intégration de stockage. Pour permettre à vos pipelines de localiser de nouveaux fichiers après le basculement, vous devez les écrire dans l’emplacement de stockage secondaire en utilisant la même hiérarchie, la même structure de dossier et le même chemin relatif que votre emplacement principal.

• STORAGE_INTEGRATION : le nom de votre intégration de stockage multi-emplacements.

Par exemple :

ALTER STAGE my_ext_stage SET
  RELATIVE_URL = '/my_folder/my_sub_folder/'
  STORAGE_INTEGRATION = 'my_mlsi';

Étape 3 : Configurer une intégration de notifications à plusieurs files d’attente (MQNI)¶

Si vous utilisez un chargement de données automatisé via la messagerie Cloud et que vous avez configuré une intégration de stockage multi-emplacements pour votre zone de préparation externe, vous devez également utiliser une intégration de notifications à plusieurs files d’attente pour un basculement fluide de vos pipelines Snowpipe.

Pour chaque file d’attente que vous définissez pour l’intégration de notifications, vous devez préparer votre service de messagerie en utilisant les étapes des rubriques suivantes :

• Configuration d’Amazon SNS pour automatiser Snowpipe à l’aide de notifications SQS. Créer une rubrique SNS pour chaque région AWS dans laquelle votre MLSI possède des emplacements de stockage.

• Configuration de l’automatisation à l’aide de GCS Pub/Sub

• Configuration de l’automatisation avec Azure Event Grid

CREATE NOTIFICATION INTEGRATION my_mqni
  ENABLED = TRUE
  TYPE = MULTI_QUEUE
  DIRECTION = INBOUND
  QUEUES = (
    (
      NAME = 'my-us-west-1'
      NOTIFICATION_PROVIDER = AWS_SNS
      AWS_SNS_TOPIC_ARN = 'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-west'
    ),
    (
      NAME = 'my-us-east-1'
      NOTIFICATION_PROVIDER = AWS_SNS
      AWS_SNS_TOPIC_ARN = 'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-east'
    )
  )
  ACTIVE = 'my-us-west-1';

CREATE PIPE my_pipe
  AUTO_INGEST = TRUE
  INTEGRATION = my_mqni
  AS COPY INTO my_table FROM @my_ext_stage/my_pipe/;

SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  '<new_mqni_name>',
  '<original_sns_topic_arn_or_int_name>',
  '<new_sns_topic_arn_or_int_name>'
)

SELECT SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  'my_mqni',
  'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-west',
  'arn:aws:sns:us-east-1:67890:my-snowpipe-mlsi-east'
);

SELECT SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  'my_azure_mqni',
  'my_azure_ni_1',
  'my_azure_ni_2'
);

Étape 4 : Répliquer votre MLSI et votre MQNI sur un compte cible¶

1. To replicate your multi-location storage integration and multi-queue notification integration, alter your existing replication or failover group to include STORAGE INTEGRATIONS and NOTIFICATION INTEGRATIONS in the ALLOWED_INTEGRATION_TYPES list.

Par exemple, utilisez la commande ALTER FAILOVER GROUP :

ALTER FAILOVER GROUP my_fg SET
  OBJECT_TYPES = DATABASES, ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS,
    NOTIFICATION INTEGRATIONS;

2. Ensuite, dans votre compte cible, effectuez une opération d’actualisation :

ALTER FAILOVER GROUP my_fg REFRESH;

Étape 5 : Configurer les états actifs dans le compte cible¶

Après avoir effectué une opération d’actualisation, pour garantir un basculement fluide lors d’une panne réelle, configurez l’emplacement de stockage actif et la file d’attente (si vous utilisez une intégration de notifications) dans votre compte cible.

Dans votre compte cible :

1. Pour l’emplacement de stockage que vous souhaitez définir comme emplacement actif dans votre compte cible, suivez les instructions des rubriques suivantes pour accorder à Snowflake l’accès à votre stockage :

   • Option 1 : Configurer une intégration de stockage Snowflake pour accéder à Amazon S3

   • Configuration d’une intégration pour Google Cloud Storage

   • Configuration d’un conteneur Azure pour le chargement de données

2. Activez le stockage secondaire : Définissez la MLSI pour utiliser votre emplacement de stockage de sauvegarde secondaire dans le compte cible.

   CopyExpand

   ALTER STORAGE INTEGRATION my_mlsi SET ACTIVE = 'my-s3-us-east-1';
   

   Show lessSee more

   Scroll to top

3. Si vous utilisez une intégration de notifications à plusieurs files d’attente, accordez à Snowflake l’autorisation d’accès à votre service de messagerie pour la file d’attente que vous souhaitez définir comme active dans votre compte cible. Suivez les instructions relatives à votre fournisseur Cloud :

   • Pour AWS, consultez S’abonner à la file d’attente SQS de Snowflake dans la rubrique SNS sous Conditions préalables : Créer un sujet et un abonnement Amazon SNS.

   • Pour Google Cloud, consultez Accorder un accès à Snowflake à l’abonnement Pub/Sub sous Configuration de l’automatisation à l’aide de Pub/Sub GCS.

   • Pour Azure, consultez Accorder un accès à Snowflake à la file d’attente de stockage sous Configuration de l’automatisation avec Azure Event Grid.

4. Activer la file d’attente secondaire (si vous utilisez la MQNI) : Définissez la file d’attente active sur votre emplacement secondaire dans le compte cible.

   CopyExpand

   ALTER INTEGRATION my_mqni
     SET ACTIVE = 'MY_MQNI-queue2';
   

   Show lessSee more

   Scroll to top

1. Vérifier les états d’intégration actifs¶

Confirmez que vos intégrations pointent vers le bon stockage et les bonnes files d’attente en vérifiant leurs propriétés. Cherchez la propriété ACTIVE dans la sortie :

-- Check the active storage location
DESCRIBE STORAGE INTEGRATION my_mlsi;

-- Check the active message queue
DESCRIBE INTEGRATION my_mqni;

2. Vérifier l’état du canal (Snowpipe uniquement)¶

Utilisez la fonction SYSTEM$PIPE_STATUS pour vous assurer que votre canal fonctionne et pour vérifier s’il met activement en file d’attente de nouveaux fichiers à partir de votre emplacement secondaire.

SELECT SYSTEM$PIPE_STATUS('my_pipe');

Recherchez « executionState » : « RUNNING » et vérifiez « pendingFileCount » pour confirmer qu’il reconnaît activement les nouveaux fichiers déposés dans votre compartiment secondaire.

3. Valider l’ingestion réussie (historique de chargement)¶

Pour garantir un chargement des données sans erreurs ni doublons, interrogez la vue COPY_HISTORY. Celle-ci montre exactement quels fichiers ont été ingérés, leur chemin source, et quand ils ont été chargés.

SELECT file_name, status, row_count, last_load_time
FROM TABLE(information_schema.copy_history(
  table_name => 'my_table',
  start_time => DATEADD(hours, -1, CURRENT_TIMESTAMP())
));

Vérifiez que les chemins file_name reflètent votre emplacement de stockage actif et que l’état indique LOADED.