Cas d'utilisation de la reprise après sinistre: applications d'analyse de données limitées à la localité

Last reviewed 2022-01-07 UTC

Ce document fait partie d'une série qui traite de la reprise après sinistre (Disaster Recovery, DR) dans Google Cloud. Ce document explique comment appliquer les restrictions de localité du document, Concevoir une solution de reprise après sinistre pour des charges de travail limitées à la localité, aux applications d'analyse de données. Ce document explique en particulier comment les composants que vous utilisez dans une plate-forme d'analyse de données s'intègrent à une architecture de DR qui répond aux restrictions de localité auxquelles vos applications ou données peuvent être soumises.

Cette série comprend les parties suivantes :

Ce document est destiné aux architectes système et aux responsables informatiques. Il suppose que vous disposez des connaissances et compétences suivantes:

Exigences de localité pour une plate-forme d'analyse de données

Les plates-formes d'analyse de données sont généralement des applications complexes à plusieurs niveaux qui stockent les données au repos. Ces applications produisent des événements qui sont traités et stockés dans votre système d'analyse. L'application elle-même et les données stockées dans le système peuvent être soumises à des réglementations de localité. Ces réglementations varient non seulement d'un pays à l'autre, mais également dans les secteurs d'activité spécifiques. Par conséquent, vous devez bien comprendre vos exigences en termes de localité des données avant de commencer à concevoir votre architecture de DR.

Vous pouvez déterminer si votre plate-forme d'analyse de données présente des exigences en termes de localité en répondant aux deux questions suivantes:

  • Votre application doit-elle être déployée dans une région spécifique ?
  • Vos données au repos sont-elles limitées à une région spécifique ?

Si vous répondez "non" aux deux questions, votre plate-forme d'analyse de données ne comporte aucune exigence spécifique à la localité. Étant donné que votre plate-forme n'a pas d'exigences en termes de localité, suivez les instructions de reprise après sinistre pour les services et produits conformes décrits dans le guide de planification de reprise après sinistre.

Toutefois, si vous répondez "oui" à l'une des questions, votre application est limitée à la localité. Étant donné que votre plate-forme d'analyse est limitée à la localité, vous devez vous poser la question suivante : Pouvez-vous utiliser des techniques de chiffrement pour limiter exigences pour les données au repos ?

Si vous parvenez à utiliser les techniques de chiffrement, vous pouvez utiliser les services multirégionaux et birégionaux de Cloud External Key Manager et Cloud Key Management Service. Vous pouvez ensuite appliquer les techniques standards de haute disponibilité et de reprise après sinistre (HA/DR, High Availability and Disaster Recovery) décrites dans les scénarios de reprise après sinistre pour les données.

Si vous ne pouvez pas utiliser les techniques de chiffrement, vous devez utiliser des solutions personnalisées ou des offres partenaires pour la planification de la reprise après sinistre. Pour en savoir plus sur les techniques permettant de résoudre les restrictions de localité pour les scénarios de reprise après sinistre, consultez la page Concevoir une solution de reprise après sinistre pour des charges de travail limitées à la localité.

Composants d'une plate-forme d'analyse de données

Lorsque vous comprenez les exigences en termes de localité, l'étape suivante consiste à comprendre les composants utilisés par votre plate-forme d'analyse de données. Certains composants courants de la plate-forme d'analyse de données sont les bases de données, les lacs de données, les pipelines de traitement et les entrepôts de données, comme décrit dans la liste suivante:

  • Google Cloud dispose d'un ensemble de services de base de données adaptés à différents cas d'utilisation.
  • Les lacs de données, les entrepôts de données et les pipelines de traitement peuvent avoir des définitions légèrement différentes. Ce document utilise un ensemble de définitions faisant référence aux services Google Cloud :
    • Un lac de données est une plate-forme évolutive et sécurisée permettant d'ingérer et de stocker des données provenant de plusieurs systèmes. Un lac de données type peut utiliser Cloud Storage comme dépôt de stockage central.
    • Un pipeline de traitement est un processus de bout en bout qui prend les données ou les événements d'un ou de plusieurs systèmes, les transforme et les charge dans un autre système. Le pipeline peut suivre un processus ETL (extraction, transformation et chargement) ou un processus ELT (extraction, chargement et transformation). En règle générale, le système dans lequel les données traitées sont chargées est un entrepôt de données. Pub/Sub, Dataflow et Dataproc sont des composants couramment utilisés d'un pipeline de traitement.
    • Un entrepôt de données est un système d'entreprise utilisé pour le rapport et l'analyse de données, qui provient généralement d'une base de données opérationnelle. BigQuery est un système d'entreposage de données couramment utilisé exécuté sur Google Cloud.

En fonction des exigences de localité et des composants d'analyse de données que vous utilisez, la mise en œuvre réelle de reprise après sinistre varie. Les sections suivantes illustrent cette variante avec deux cas d'utilisation.

Cas d'utilisation par lots: tâche ETL périodique

Le premier cas d'utilisation décrit un processus par lots dans lequel une plate-forme de commerce collecte périodiquement les événements de vente sous forme de fichiers de divers magasins, puis les écrit dans un bucket Cloud Storage. Le schéma suivant illustre l'architecture d'analyse de données pour la tâche par lot de ce revendeur.

Diagramme d'architecture d'un cas d'utilisation par lot impliquant des données de point de vente.

L'architecture comprend les phases et composants suivants:

  • La phase d'ingestion consiste en les magasins envoyant leurs données de point de vente (point-of-sale, POS) à Cloud Storage. Ces données ingérées sont en attente de traitement.
  • La phase d'orchestration utilise Cloud Composer pour orchestrer le pipeline par lot de bout en bout.
  • La phase de traitement implique une tâche Apache Spark exécutée sur un cluster Dataproc. La tâche Apache Spark effectue un processus ETL sur les données ingérées. Ce processus ETL fournit des métriques commerciales.
  • La phase de lac de données prend les données traitées et stocke les informations dans les composants suivants :
    • Les données traitées sont généralement stockées dans des formats en colonnes Cloud Storage tels queParquet etORC car ces formats permettent un stockage efficace et un accès plus rapide aux charges de travail analytiques.
    • Les métadonnées sur les données de processus (telles que les bases de données, les tables, les colonnes et les partitions) sont stockées dans le service de métastore Hive fourni par Dataproc Metastore.

Dans les scénarios où les localités sont restreintes, il peut être difficile de fournir une capacité de traitement et d'orchestration redondante pour maintenir la disponibilité. Les données étant traitées par lots, les pipelines de traitement et d'orchestration peuvent être recréés, et les tâches par lot peuvent être redémarrées après la résolution d'un scénario de sinistre. Par conséquent, pour la reprise après sinistre, l'accent est mis sur la récupération des données réelles: les données POS ingérées, les données traitées stockées dans le lac de données et les métadonnées stockées dans le lac de données.

Ingestion dans Cloud Storage

Vous devez tout d'abord déterminer les exigences de localité du bucket Cloud Storage utilisé pour ingérer les données du système POS. Utilisez ces informations de localité lorsque vous envisagez les options suivantes:

  • Si les exigences de localité autorisent les données au repos à se trouver dans l'un des emplacements multirégionaux ou birégionaux, choisissez le type d'emplacement correspondant lorsque vous créez le bucket Cloud Storage. Le type d'emplacement que vous choisissez définit les régions Google Cloud utilisées pour répliquer vos données au repos. Si une panne se produit dans l'une des régions, les données résidant dans des buckets multirégionaux ou birégionaux restent accessibles.
  • Cloud Storage est également compatible avec les clés de chiffrement gérées par le client (CMEK) et les clés de chiffrement fournies par le client (CSEK). Certaines règles de localité permettent aux données au repos d'être stockées dans plusieurs emplacements lorsque vous utilisez des clés CMEK ou CSEK pour la gestion des clés. Si vos règles de localité autorisent l'utilisation de CMEK ou de CSEK, vous pouvez concevoir votre architecture de DR de sorte qu'elle utilise des régions Cloud Storage.
  • Vos exigences en termes de localité peuvent ne pas vous permettre d'utiliser ces types d'emplacement ou la gestion des clés de chiffrement. Lorsque vous ne pouvez pas utiliser les types d'emplacement ou la gestion des clés de chiffrement, vous pouvez utiliser la commande gsutil rsync pour synchroniser les données vers un autre emplacement, tel que des solutions de stockage sur site ou de stockage auprès d'un autre fournisseur cloud.

En cas de sinistre, les données de point de vente ingérées dans le bucket Cloud Storage peuvent contenir des données qui n'ont pas encore été traitées et importées dans le lac de données. Les données du point de vente peuvent également ne pas pouvoir être ingérées dans le bucket Cloud Storage. Dans ces cas, vous disposez des options de reprise après sinistre suivantes:

  • Laissez le système POS réessayer. Si le système n'est pas en mesure d'écrire les données du point de vente dans Cloud Storage, le processus d'ingestion des données échoue. Pour atténuer cette situation, vous pouvez mettre en œuvre un algorithme d'intervalle exponentiel entre les tentatives tronqué pour permettre au système POS de relancer l'opération d'ingestion de données. Étant donné que Cloud Storage offre une durabilité de onze neuf, l'ingestion des données et le pipeline de traitement suivant reprend avec une perte de données faible ou nulle après la réactivation du service Cloud Storage.

  • Créer des copies des données ingérées. Cloud Storage est compatible avec les types d'emplacements multirégionaux et birégionaux. Selon vos exigences en termes de localité des données, vous pouvez peut-être configurer un bucket Cloud Storage multirégional ou birégional pour augmenter la disponibilité des données. Vous pouvez également vous servir d'outils tels que gsutil pour synchroniser les données entre Cloud Storage et un autre emplacement.

Orchestration et traitement des données POS ingérées

Dans le schéma d'architecture du cas d'utilisation par lot, Cloud Composer effectue les étapes suivantes:

  • Vérifie que les nouveaux fichiers ont été importés dans le bucket d'ingestion Cloud Storage.
  • Démarre un cluster Dataproc éphémère.
  • Démarre une tâche Apache Spark pour traiter les données.
  • Supprime le cluster Dataproc à la fin de la tâche.

Cloud Composer utilise des fichiers de graphes orientés acycliques (DAG) qui définissent cette série d'étapes. Ces fichiers DAG sont stockés dans un bucket Cloud Storage qui n'est pas illustré dans le schéma de l'architecture. En ce qui concerne la localité birégionale et multirégionale, les considérations de reprise après sinistre pour le bucket de fichiers DAG sont les mêmes que celles décrites pour le bucket d'ingestion.

Les clusters Dataproc sont éphémères. Autrement dit, les clusters n'existent que pendant l'exécution de la phase de traitement. Cette nature éphémère signifie que vous n'avez rien à faire de manière explicite pour la reprise après sinistre en ce qui concerne les clusters Dataproc.

Stockage du lac de données avec Cloud Storage

Le bucket Cloud Storage que vous utilisez pour le lac de données a les mêmes considérations de localité que celles décrites pour le bucket d'ingestion : considérations birégionales et multirégionales, utilisation du chiffrement et utilisation de gsutil rsync.

Lors de la conception du plan de DR pour votre lac de données, tenez compte des aspects suivants:

  • Taille des données Le volume de données d'un lac de données peut être important. La restauration d'un grand volume de données prend du temps. Dans un scénario de DR, vous devez prendre en compte l'impact du volume du lac de données sur le temps nécessaire
    à la restauration des données à un point répondant aux critères suivants:

    Pour le cas d'utilisation actuel par lot, Cloud Storage est utilisé pour l'emplacement du lac de données et offre une durabilité de 11 neuf. Cependant, les attaques de rançongiciels sont en hausse. Pour vous assurer que vous êtes en mesure de vous remettre de ces attaques, il est prudent de suivre les bonnes pratiques décrites dans la section suivante :Comment Cloud Storage offre 11 neuf de durabilité.

  • Dépendance des données. Les données des lacs de données sont généralement consommées par d'autres composants d'un système d'analyse de données tel qu'un pipeline de traitement. Dans un scénario de DR, le pipeline de traitement et les données dont il dépend doivent partager le même RTO. Dans ce contexte, concentrez-vous sur la durée pendant laquelle le système peut être indisponible.

  • Âge des données. Les données de l'historique peuvent permettre un RPO plus élevé. Ce type de données peut avoir déjà été analysé ou traité par d'autres composants d'analyse de données et a peut-être été conservé dans un autre composant ayant ses propres stratégies de reprise après sinistre. Par exemple, les enregistrements de ventes exportés vers Cloud Storage sont importés quotidiennement dans BigQuery pour analyse. Avec des stratégies de reprise après sinistre appropriées pour BigQuery, les enregistrements de ventes historiques qui ont été importés dans BigQuery peuvent avoir des objectifs de récupération inférieurs à ceux qui n'ont pas été importés.

Stockage de métadonnées de lac de données avec Dataproc Metastore

Dataproc Metastore est un métastore Apache Hive entièrement géré, hautement disponible, autoréparation et sans serveur. Le métastore fournit des fonctionnalités d'abstraction et de découverte de données. Le métastore peut être sauvegardé et restauré en cas de sinistre. Le service Dataproc Metastore vous permet également d'exporter et d'importer des métadonnées. Vous pouvez ajouter une tâche pour exporter le métastore et conserver une sauvegarde externe avec votre tâche ETL.

Si vous rencontrez une erreur de correspondance des métadonnées, vous pouvez recréer le métastore à partir des données elles-mêmes à l'aide de la commande MSCK.

Cas d'utilisation par flux : modifier la capture de données à l'aide de l'ELT

Le deuxième cas d'utilisation décrit une plate-forme de commerce qui utilise la capture de données modifiées (CDC, Change Data Capture) pour mettre à jour les systèmes d'inventaire des backends et suivre les métriques de ventes en temps réel. Le schéma suivant illustre une architecture dans laquelle les événements d'une base de données transactionnelle, telle que Cloud SQL, sont traités, puis stockés dans un entrepôt de données.

Diagramme d'architecture d'un cas d'utilisation par flux impliquant la capture de données modifiées des données de commerce.

L'architecture comprend les phases et composants suivants:

  • La phase d'ingestion comprend les événements de modification entrants envoyés vers Pub/Sub. En tant que service de distribution de messages, Pub/Sub est utilisé pour ingérer et distribuer de manière fiable des données d'analyse de flux. Pub/Sub présente l'avantage supplémentaire d'être évolutif et sans serveur.
  • La phase de traitement implique d'utiliser Dataflow pour effectuer un processus ELT sur les événements ingérés.
  • Pendant la phase d'entrepôt de données, BigQuery stocke les événements traités. L'opération de fusion insère ou met à jour un enregistrement dans BigQuery. Cette opération permet aux informations stockées dans BigQuery de rester à jour avec la base de données transactionnelle.

Bien que cette architecture CDC ne repose pas sur Cloud Composer, certaines architectures CDC nécessitent l'orchestration par Cloud Composer de l'intégration du flux dans des charges de travail par lot. Dans ce cas, le workflow Cloud Composer met en œuvre des vérifications d'intégrité, des remplissages et des projections qui ne peuvent pas être effectués en temps réel en raison de contraintes de latence. Les techniques de reprise après sinistre pour Cloud Composer sont décrites dans le cas d'utilisation du traitement par lot décrit précédemment dans ce document.

Pour un pipeline de flux de données, vous devez tenir compte des éléments suivants lors de la planification de votre architecture de DR:

  • Dépendances du pipeline. Les pipelines de traitement exploitent un ou plusieurs systèmes (les sources). Les pipelines traitent, transforment et stockent ensuite ces entrées dans d'autres systèmes (les récepteurs). Il est important de concevoir l'architecture de reprise après sinistre pour atteindre votre RTO de bout en bout. Vous devez vous assurer que le RPO des sources et des récepteurs de données vous permet d'atteindre le RTO. En plus de concevoir votre architecture cloud pour répondre à vos exigences en termes de localité, vous devez également concevoir vos sources CDC d'origine pour permettre la réalisation de votre RTO de bout en bout.
  • Chiffrement et localité : Si le chiffrement vous permet de limiter les restrictions de localité, vous pouvez utiliser Cloud KMS pour atteindre les objectifs suivants :
    • Gérez vos propres clés de chiffrement.
    • Tirer parti de la fonctionnalité de chiffrement des services individuels.
    • Déployez les services dans des régions qui ne seraient autrement pas disponibles en raison de restrictions de localité.
  • Règles de localité sur les données en cours de transfert. Certaines règles de localité peuvent ne s'appliquer qu'aux données au repos, mais pas aux données en transit. Si vos règles de localité ne s'appliquent pas aux données en mouvement, concevez votre architecture de DR de façon à exploiter les ressources d'autres régions pour améliorer les objectifs de reprise. Vous pouvez compléter l'approche régionale en intégrant des techniques de chiffrement.

Ingestion dans Pub/Sub

Si vous n'avez pas de restrictions de localité, vous pouvez publier des messages sur le point de terminaison mondial Pub/Sub. Les points de terminaison mondiaux Pub/Sub sont visibles et accessibles depuis n'importe quel emplacement Google Cloud.

Si vos exigences en termes de localité autorisent l'utilisation du chiffrement, il est possible de configurer Pub/Sub pour obtenir un niveau de haute disponibilité similaire à celui des points de terminaison mondiaux. Bien que les messages Pub/Sub soient chiffrés par défaut avec des clés gérées par Google, vous pouvez configurer Pub/Sub pour utiliser CMEK à la place. En utilisant Pub/Sub avec CMEK, vous pouvez respecter les règles de localité sur le chiffrement tout en maintenant une haute disponibilité.

Certaines règles de localité exigent que les messages restent dans un emplacement spécifique même après le chiffrement. Si vos règles de localité sont soumises à cette restriction, vous pouvez spécifier la règle de stockage des messages d'un sujet Pub/Sub et la limiter à une région. Si vous utilisez cette approche de stockage des messages, les messages publiés dans un sujet ne sont jamais conservés en dehors de l'ensemble des régions Google Cloud que vous spécifiez. Si vos règles de localité autorisent plusieurs régions Google Cloud à être utilisées, vous pouvez augmenter la disponibilité du service en activant ces régions dans le sujet Pub/Sub. Sachez que la mise en œuvre d'une règle de stockage de messages pour restreindre les emplacements de ressources Pub/Sub entraîne des compromis en matière de disponibilité.

Un abonnement Pub/Sub vous permet de stocker des messages non confirmés pendant sept jours maximum sans aucune restriction sur le nombre de messages. Si votre contrat de niveau de service autorise les données retardées, vous pouvez mettre les données en mémoire tampon de votre abonnement Pub/Sub si les pipelines cessent de s'exécuter. Lorsque les pipelines sont à nouveau en cours d'exécution, vous pouvez traiter les événements sauvegardés. Cette conception présente l'avantage d'avoir un RPO faible. Pour en savoir plus sur les limites de ressources pour Pub/Sub, consultez la section Limites de ressources pour les quotas Pub/Sub.

Traitement d'événements avec Dataflow

Dataflow est un service géré permettant d'exécuter une grande variété de schémas de traitement des données. Le SDK Apache Beam est un modèle de programmation Open Source qui vous permet de développer des pipelines par lots et en flux continu. Vous créez des pipelines avec un programme Apache Beam, puis vous les exécutez sur le service Dataflow.

Lorsque vous concevez pour des restrictions de localité, vous devez prendre en compte l'emplacement de vos sources, récepteurs et fichiers temporaires. Si ces emplacements se trouvent en dehors de la région de votre tâche, vos données peuvent être envoyées d'une région à l'autre. Si vos règles de localité autorisent le traitement des données dans un emplacement différent, concevez votre architecture de DR de manière à déployer des nœuds de calcul dans d'autres régions Google Cloud afin de fournir une haute disponibilité.

Si vos restrictions de localité limitent le traitement à un seul emplacement, vous pouvez créer une tâche Dataflow limitée à une région ou une zone spécifique. Lorsque vous envoyez une tâche Dataflow, vous pouvez spécifier les paramètres de point de terminaison régional, région de nœud de calcul et zone de nœud de calcul. Ces paramètres contrôlent l'emplacement de déploiement des nœuds de calcul et l'emplacement de stockage des métadonnées de tâche.

Apache Beam fournit un framework qui permet d'exécuter des pipelines sur différents exécuteurs. Vous pouvez concevoir une architecture de reprise après sinistre pour tirer parti de cette fonctionnalité. Par exemple, vous pouvez concevoir une architecture de reprise après sinistre pour disposer d'un pipeline de sauvegarde qui s'exécute sur votre cluster Spark local sur site à l'aide d'Apache Spark Runner. Pour savoir si un exécuteur spécifique est capable d'effectuer une certaine opération de pipeline, consultez la section Matrice des fonctionnalités Beam.

Si le chiffrement vous permet de limiter les restrictions de localité, vous pouvez utiliser CMEK dans Dataflow pour chiffrer à la fois les artefacts d'état de pipeline et les sources et récepteurs protégés par des clés Cloud KMS. À l'aide du chiffrement, vous pouvez concevoir une architecture de reprise après sinistre qui utilise des régions qui ne seraient autrement pas disponibles en raison de restrictions de localité.

Entrepôt de données créé sur BigQuery

Les entrepôts de données sont compatibles avec l'analyse et la prise de décision. En plus de contenir une base de données analytique, les entrepôts de données contiennent plusieurs composants et procédures d'analyse.

Lors de la conception du plan de reprise après sinistre pour votre entrepôt de données, tenez compte des caractéristiques suivantes:

  • Taille Les entrepôts de données sont beaucoup plus volumineux que les systèmes de traitement de transactions en ligne (OLTP). Il n'est pas rare que les entrepôts de données aient des téraoctets ou pétaoctets de données. Vous devez déterminer le temps nécessaire à la restauration de ces données pour atteindre vos valeurs RPO et RTO. Lorsque vous planifiez votre stratégie de DR, vous devez également prendre en compte le coût associé à la récupération de téraoctets de données. Pour en savoir plus sur les techniques d'atténuation des risques liés à la reprise après sinistre pour BigQuery, consultez les informations BigQuery dans la section sur les mécanismes de sauvegarde et de récupération pour les services de base de données gérés sur Google Cloud.

  • Disponibilité : Lorsque vous créez un ensemble de données BigQuery, vous sélectionnez l'emplacement de stockage de vos données : régional ou multirégional. Un emplacement régional est un emplacement géographique spécifique, tel que l'Iowa (us-central1) ou Montréal (northamerica-northeast1). Un emplacement multirégional correspond à une vaste zone géographique, telle que les États-Unis ou l'Europe, et comporte au moins deux lieux géographiques.

    Lors de la conception de votre plan de DR pour respecter les restrictions de localité, le domaine de défaillance (c'est-à-dire si la défaillance se produit au niveau de la machine, de la zone ou de la région) aura un impact direct sur votre conformité de votre RTO. Pour en savoir plus sur ces domaines de défaillance et leur incidence sur la disponibilité, consultez la section Disponibilité et durabilité de BigQuery.

  • Nature des données. Les entrepôts de données contiennent des informations historiques, et la plupart des anciennes données sont souvent statiques. De nombreux entrepôts de données sont conçus pour être ajoutés uniquement. Si votre entrepôt de données est en mode append-only, vous pouvez atteindre votre RTO en restaurant uniquement les données ajoutées. Dans cette approche, vous sauvegardez uniquement ces données ajoutées. En cas de sinistre, vous pourrez restaurer les données ajoutées et mettre votre entrepôt de données à disposition, mais avec un sous-ensemble de données.

  • Modèle d'ajout et de mise à jour des données Les entrepôts de données sont généralement mis à jour à l'aide de modèles ETL ou ELT. Lorsque vous disposez de chemins de mise à jour contrôlés, vous pouvez reproduire les événements de mise à jour récents à partir de sources alternatives.

Vos exigences en termes de localité peuvent limiter l'utilisation d'une ou de plusieurs régions pour votre entrepôt de données. Bien que les ensembles de données BigQuery puissent être régionaux, le stockage multirégional est le moyen le plus simple et le plus économique d'assurer la disponibilité de vos données en cas de sinistre. Si le stockage multirégional n'est pas disponible dans votre région, mais que vous pouvez en utiliser une autre, utilisez le service de transfert de données BigQuery pour copier votre ensemble de données dans une autre région. Si vous pouvez utiliser le chiffrement pour réduire les exigences de localité, vous pouvez gérer vos propres clés de chiffrement avec Cloud KMS et BigQuery.

Si vous ne pouvez utiliser qu'une seule région, envisagez de sauvegarder les tables BigQuery. La solution la plus rentable pour sauvegarder des tables consiste à utiliser les exportations BigQuery. Utilisez Cloud Scheduler ou Cloud Composer pour programmer périodiquement une tâche d'exportation afin d'écrire dans Cloud Storage. Vous pouvez utiliser des formats tels que Avro avec la compression SNAPPY ou JSON avec la compression GZIP. Lorsque vous concevez vos stratégies d'exportation, tenez compte des limites applicables aux exportations.

Vous pouvez également stocker des sauvegardes BigQuery dans des formats en colonnes tels que Parquet et ORC. Ils offrent une compression élevée et permettent une interopérabilité avec de nombreux moteurs Open Source, tels que Hive et Presto, que vous pouvez avoir dans vos systèmes sur site. Le schéma suivant décrit le processus d'exportation de données BigQuery vers un format en colonnes pour le stockage dans un emplacement sur site.

Diagramme d'architecture montrant l'exportation de données BigQuery vers un espace de stockage en colonnes pour la reprise après sinistre.

Plus précisément, ce processus d'exportation de données BigQuery vers un emplacement de stockage sur site comprend les étapes suivantes:

  • Les données BigQuery sont envoyées à une tâche Apache Spark sur Dataproc. L'utilisation de la tâche Apache Spark autorise l'évolution du schéma.
  • Une fois que la tâche Dataproc a traité les fichiers BigQuery, ceux-ci sont écrits dans Cloud Storage, puis transférés vers un emplacement de reprise après sinistre sur site.
  • Cloud Interconnect vous permet de connecter votre réseau cloud privé virtuel à votre réseau sur site.
  • Le transfert vers l'emplacement de reprise après sinistre sur site peut se produire via la tâche Spark.

Si la conception de votre entrepôt est de type "append-only" et partitionnée par date, vous devez Créer une copie des partitions requises dans une nouvelle table avant d'exécuter une tâche d'exportation BigQuery dans la nouvelle table. Vous pouvez ensuite utiliser un outil tel que gsutil pour transférer les fichiers mis à jour vers votre emplacement de sauvegarde sur site ou dans un autre cloud. (Des frais de sortie peuvent s'appliquer lorsque vous transférez des données hors de Google Cloud.)

Par exemple, vous disposez d'un entrepôt de données de ventes composé d'une table orders de type "append-only", dans laquelle les nouvelles commandes sont ajoutées à la partition correspondant à la date actuelle. Toutefois, des conditions de retour peuvent permettre de renvoyer des articles dans un délai de sept jours. Par conséquent, les enregistrements de la table orders au cours des sept derniers jours peuvent être mis à jour. Vos stratégies d'exportation doivent prendre en compte les règles de retour. Dans cet exemple, toute tâche d'exportation permettant de sauvegarder la table orders doit également exporter les partitions représentant les commandes au cours des sept derniers jours afin d'éviter les mises à jour manquantes en raison de retours.

Étape suivante