Automatisation évolutive des sauvegardes BigQuery

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette architecture fournit un framework et un déploiement de référence pour vous aider à développer votre stratégie de sauvegarde BigQuery. Ce framework recommandé et son automatisation peuvent aider votre organisation à effectuer les opérations suivantes:

• Respectez les objectifs de reprise après sinistre de votre organisation.
• récupérer des données qui ont été perdues en raison d'erreurs humaines ;
• Respectez les réglementations.
• Améliorez votre efficacité opérationnelle.

Le champ d'application des données BigQuery peut inclure (ou exclure) des dossiers, des projets, des ensembles de données et des tables. Cette architecture recommandée vous montre comment automatiser les opérations de sauvegarde récurrentes à grande échelle. Vous pouvez utiliser deux méthodes de sauvegarde pour chaque table : les instantanés BigQuery et les exportations BigQuery vers Cloud Storage.

Ce document est destiné aux architectes cloud, aux ingénieurs et aux responsables de la gouvernance des données qui souhaitent définir et automatiser des règles de données dans leur organisation.

Architecture

Le schéma suivant illustre l'architecture de sauvegarde automatisée:

Le workflow illustré dans le schéma précédent comprend les phases suivantes:

1. Cloud Scheduler déclenche une exécution sur le service de coordinateur via un message Pub/Sub, qui contient le champ d'application des données BigQuery incluses et exclues. Les exécutions sont planifiées à l'aide d'une expression Cron.
2. Le service de répartiteur, basé sur Cloud Run, utilise l'API BigQuery pour répertorier les tables comprises dans le champ d'application de BigQuery.
3. Le service de répartiteur envoie une requête pour chaque table au service de configuration via un message Pub/Sub.

4. Le service de configuration Cloud Run calcule la règle de sauvegarde de la table à partir de l'une des options définies suivantes:

   1. La stratégie au niveau de la table, définie par les propriétaires des données.
   2. La règle de remplacement, définie par le responsable de la gouvernance des données, pour les tables sans règles définies.

   Pour en savoir plus sur les règles de sauvegarde, consultez Règles de sauvegarde.

5. Le service de configuration envoie une requête pour chaque table au service suivant, en fonction de la règle de sauvegarde calculée.

6. Selon la méthode de sauvegarde, l'un des services Cloud Run personnalisés suivants envoie une requête à l'API BigQuery et exécute le processus de sauvegarde:

   1. Le service pour les instantanés BigQuery sauvegarde la table en tant qu'instantané.
   2. Le service d'exportation de données sauvegarde la table en tant qu'exportation de données vers Cloud Storage.

7. Lorsque la méthode de sauvegarde est une exportation de données de table, un récepteur de journaux Cloud Logging écoute les événements d'achèvement des tâches d'exportation afin de permettre l'exécution asynchrone de l'étape suivante.

8. Une fois que les services de sauvegarde ont terminé leurs opérations, Pub/Sub déclenche le service d'ajout de tags.

9. Pour chaque table, le service d'ajout de tags enregistre les résultats des services de sauvegarde et met à jour l'état de la sauvegarde dans la couche de métadonnées Cloud Storage.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants:

• BigQuery : entrepôt de données d'entreprise qui vous aide à gérer et analyser vos données grâce à des fonctionnalités intégrées telles que l'analyse géospatiale du machine learning et l'informatique décisionnelle.
• Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
• Pub/Sub : service de messagerie asynchrone et évolutif qui dissocie les services qui produisent des messages des services qui traitent ces messages.
• Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
• Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis l'intérieur et l'extérieur de Google Cloud, et sont répliquées sur les différents emplacements à des fins de redondance.
• Cloud Scheduler: planificateur de tâches Cron entièrement géré, pensé pour les entreprises, qui vous permet de configurer des unités de travail planifiées à exécuter à des heures définies ou à intervalles réguliers.
• Datastore: base de données NoSQL hautement évolutive pour vos applications Web et mobiles.

Cas d'utilisation

Cette section fournit des exemples de cas d'utilisation pour lesquels vous pouvez exploiter cette architecture.

Automatisation des sauvegardes

Par exemple, votre entreprise peut opérer dans un secteur réglementé et utiliser BigQuery comme entrepôt de données principal. Même si votre entreprise suit les bonnes pratiques en matière de développement logiciel, de revue de code et d'ingénierie des versions, il existe toujours un risque de perte ou de corruption de données due à des erreurs humaines. Dans un secteur réglementé, vous devez réduire ce risque autant que possible.

Voici quelques exemples de ces erreurs humaines:

• Des tables sont supprimées par erreur.
• Corruption des données en raison d'une erreur de logique de pipeline de données.

Ces types d'erreurs humaines peuvent généralement être résolus à l'aide de la fonctionnalité de fonctionnalité temporelle, qui vous permet de récupérer des données remontant jusqu'à sept jours. En outre, BigQuery propose également une période de sécurité au cours de laquelle les données supprimées sont conservées dans un stockage de sécurité pendant sept jours supplémentaires après la fenêtre de fonctionnalité temporelle. Ces données sont disponibles pour la récupération d'urgence via Cloud Customer Care. Toutefois, si votre entreprise ne détecte pas et ne corrige pas de telles erreurs dans ce laps de temps combiné, les données supprimées ne pourront plus être récupérées à partir de leur dernier état stable.

Pour limiter ce problème, nous vous recommandons d'exécuter des sauvegardes régulières pour toutes les tables BigQuery qui ne peuvent pas être reconstruites à partir des données sources (par exemple, les enregistrements historiques ou les KPI avec une logique métier en constante évolution).

Votre entreprise peut utiliser des scripts de base pour sauvegarder des dizaines de tableaux. Toutefois, si vous devez sauvegarder régulièrement des centaines ou des milliers de tables au sein de votre organisation, vous avez besoin d'une solution d'automatisation évolutive capable d'effectuer les opérations suivantes:

• Gérez différentes Google Cloud limites d'API.
• Fournir un framework standardisé pour définir des règles de sauvegarde
• Offrez des fonctionnalités de transparence et de surveillance pour les opérations de sauvegarde.

Règles de sauvegarde

Votre entreprise peut également exiger que les règles de sauvegarde soient définies par les groupes de personnes suivants:

• Les propriétaires de données, qui connaissent le mieux les tables et peuvent définir les règles de sauvegarde au niveau des tables appropriées.
• L'équipe de gouvernance des données, qui veille à la mise en place d'une règle de remplacement pour couvrir toutes les tables sans règle au niveau des tables. La règle de remplacement garantit que certains ensembles de données, projets et dossiers sont sauvegardés conformément aux réglementations de votre entreprise concernant la conservation des données.

Dans le déploiement de cette architecture de référence, il existe deux façons de définir les règles de sauvegarde pour les tables. Vous pouvez les utiliser ensemble:

• Configuration du propriétaire des données (décentralisée): règle de sauvegarde au niveau de la table, qui est associée manuellement à une table.

  • Le propriétaire des données définit un fichier JSON au niveau de la table, stocké dans un bucket commun.
  • Les stratégies manuelles prévalent sur les stratégies de remplacement lorsque la solution détermine la règle de sauvegarde d'une table.
  • Pour en savoir plus sur le déploiement, consultez Définir des règles de sauvegarde au niveau des tables.

• Configuration par défaut de l'organisation (centralisée): règle de remplacement, qui ne s'applique qu'aux tables qui ne possèdent pas de règles associées manuellement.

  • Dans le cadre de la solution, une équipe de gouvernance des données définit un fichier JSON central dans Terraform.
  • La règle de remplacement propose des stratégies de sauvegarde par défaut au niveau du dossier, du projet, de l'ensemble de données et de la table.
  • Pour en savoir plus sur le déploiement, consultez Définir des règles de sauvegarde de remplacement.

Sauvegarde ou réplication

Un processus de sauvegarde crée une copie des données de la table à un certain moment, afin qu'elle puisse être restaurée en cas de perte ou de corruption des données. Les sauvegardes peuvent être exécutées une seule fois ou de manière récurrente (via une requête ou un workflow programmés). Dans BigQuery, les sauvegardes à un moment précis peuvent être effectuées à l'aide d'instantanés. Vous pouvez utiliser des instantanés pour conserver des copies des données au-delà de la période de glissement dans le temps de sept jours dans le même emplacement de stockage que les données sources. Les instantanés BigQuery sont particulièrement utiles pour récupérer des données après des erreurs humaines entraînant une perte ou une corruption de données, plutôt que pour la récupération après des défaillances régionales. BigQuery propose un objectif de niveau de service (SLO) allant de 99,9% à 99,99%, selon l'édition.

En revanche, la réplication est le processus continu consistant à copier les modifications apportées à une base de données vers une base de données secondaire (ou dupliquée) située dans un autre emplacement. Dans BigQuery, la réplication interrégionale peut contribuer à assurer la géoredondance en créant des copies en lecture seule des données dans des Google Cloud régions secondaires, différentes de la région des données sources. Toutefois, la réplication interrégionale BigQuery n'est pas destinée à être utilisée comme plan de reprise après sinistre pour les scénarios de panne globaux. Pour assurer votre résilience face aux sinistres régionaux, envisagez d'utiliser la reprise après sinistre gérée de BigQuery.

La réplication interrégionale BigQuery fournit une copie synchronisée en lecture seule des données dans une région proche des consommateurs de données. Ces copies de données activent les jointures colocalisées et évitent le trafic et les coûts interrégionaux. Toutefois, en cas de corruption de données due à une erreur humaine, la réplication seule ne peut pas faciliter la récupération, car les données corrompues sont automatiquement copiées sur l'instance dupliquée. Dans ce cas, les sauvegardes à un moment précis (instantanés) constituent un meilleur choix.

Le tableau suivant présente un récapitulatif des méthodes de sauvegarde et de la réplication:

Méthode	Fréquence	Emplacement de stockage	Cas d'utilisation	Coûts
Sauvegarde (Instantanés ou exportation Cloud Storage)	Ponctuel ou récurrent	Identiques aux données de la table source	Restaurer les données d'origine, au-delà de la période de fonctionnalité	Les instantanés entraînent des frais de stockage pour les modifications de données apportées à l'instantané uniquement Des frais de stockage standards peuvent s'appliquer aux exportations. Voir Optimisation des coûts
Réplication interrégionale	En continu	Fonctions	Créer une instance répliquée dans une autre région Migrations uniques entre régions	Des frais de stockage des données dans l'instance dupliquée Des frais de réplication de données s'appliquent

Considérations de conception

Cette section fournit des conseils à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie qui répond à vos exigences spécifiques en termes de sécurité, de fiabilité, d'optimisation des coûts, d'efficacité opérationnelle et de performances.

Sécurité, confidentialité et conformité

Le déploiement intègre les mesures de sécurité suivantes dans sa conception et sa mise en œuvre:

• Le paramètre d'entrée réseau pour Cloud Run n'accepte que le trafic interne afin de restreindre l'accès depuis Internet. De plus, seuls les utilisateurs authentifiés et les comptes de service peuvent appeler les services.
• Chaque service Cloud Run et abonnement Pub/Sub utilise un compte de service distinct, qui ne dispose que des autorisations requises. Cela réduit les risques associés à l'utilisation d'un seul compte de service pour le système et respecte le principe du moindre privilège.

Pour des raisons de confidentialité, la solution ne collecte ni ne traite aucune information permettant d'identifier personnellement l'utilisateur. Toutefois, si les tables sources ont exposé des informations permettant d'identifier personnellement l'utilisateur, les sauvegardes effectuées sur ces tables incluent également ces données exposées. Le propriétaire des données sources est responsable de la protection des informations permettant d'identifier personnellement l'utilisateur dans les tables sources (par exemple, en appliquant la sécurité au niveau des colonnes, le masquage des données ou le masquage). Les sauvegardes ne sont sécurisées que lorsque les données sources sont sécurisées. Une autre approche consiste à s'assurer que les projets, ensembles de données ou buckets contenant des données de sauvegarde avec informations personnelles exposées disposent des stratégies IAM (Identity and Access Management) requises qui limitent l'accès aux seuls utilisateurs autorisés.

En tant que solution à usage général, le déploiement de référence ne répond pas nécessairement aux exigences spécifiques d'un secteur particulier.

Fiabilité

Cette section décrit les fonctionnalités et les considérations de conception en matière de fiabilité.

Atténuation des défaillances avec précision

Si vous souhaitez sauvegarder des milliers de tables, vous risquez d'atteindre les limites de l'API pour les produits Google Cloud sous-jacents (par exemple, les limites des opérations d'instantanés et d'exportation pour chaque projet). Toutefois, si la sauvegarde d'une table échoue en raison d'une mauvaise configuration ou d'autres problèmes temporaires, cela ne devrait pas affecter l'exécution globale ni la possibilité de sauvegarder les autres tables.

Pour limiter les défaillances potentielles, le déploiement de référence dissocie les étapes de traitement en utilisant des services Cloud Run précis et en les connectant via Pub/Sub. Si une requête de sauvegarde de table échoue à la dernière étape du service d'ajout de tags, Pub/Sub ne relance que cette étape, sans relancer l'ensemble du processus.

La répartition du flux en plusieurs services Cloud Run, au lieu de plusieurs points de terminaison hébergés dans un seul service Cloud Run, permet de fournir un contrôle précis de chaque configuration de service. Le niveau de configuration dépend des fonctionnalités du service et des API avec lesquelles il communique. Par exemple, le service de répartiteur s'exécute une fois par exécution, mais il faut beaucoup de temps pour répertorier toutes les tables comprises dans le champ d'application de la sauvegarde BigQuery. Par conséquent, le service de répartiteur nécessite un délai d'expiration et des paramètres de mémoire plus élevés. Cependant, le service Cloud Run pour les instantanés BigQuery s'exécute une seule fois par table en une seule exécution et se termine en moins de temps que le service de coordinateur. Par conséquent, le service Cloud Run requiert un ensemble différent de configurations au niveau du service.

Cohérence des données

La cohérence des données entre les tables et les vues est essentielle pour maintenir une stratégie de sauvegarde fiable. Les données étant mises à jour et modifiées en continu, les sauvegardes effectuées à des moments différents peuvent capturer différents états de votre ensemble de données. Ces sauvegardes dans différents états peuvent entraîner des incohérences lors de la restauration des données, en particulier pour les tables appartenant au même ensemble de données fonctionnel. Par exemple, la restauration d'une table des ventes à un moment différent de sa table d'inventaire correspondante peut créer une incohérence au niveau du stock disponible. De même, les vues de base de données qui agrègent les données de plusieurs tables peuvent être particulièrement sensibles aux incohérences. La restauration de ces vues sans s'assurer que les tables sous-jacentes sont dans un état cohérent peut entraîner des résultats inexacts ou trompeurs. Par conséquent, lorsque vous concevez vos règles et fréquences de sauvegarde BigQuery, vous devez impérativement prendre en compte cette cohérence et vous assurer que vos données restaurées reflètent avec précision l'état réel de votre ensemble de données à un moment donné.

Par exemple, dans le déploiement de cette architecture de référence, la cohérence des données est contrôlée via les deux configurations suivantes dans les règles de sauvegarde. Ces configurations calculent la durée exacte des instantanés de table via la fonctionnalité temporelle, sans nécessairement sauvegarder toutes les tables en même temps.

• backup_cron: contrôle la fréquence de sauvegarde d'une table. L'horodatage de début d'une exécution sert de point de référence pour le calcul du déplacement dans le temps pour toutes les tables sauvegardées dans cette exécution.
• backup_time_travel_offset_days: contrôle le nombre de jours passés à soustraire du point de référence (heure de début de l'exécution) pour calculer la version exacte de la table dans le temps.

Restauration automatique des sauvegardes

Bien que cette architecture de référence se concentre sur l'automatisation des sauvegardes à grande échelle, vous pouvez également envisager de restaurer ces sauvegardes de manière automatisée. Cette automatisation supplémentaire peut offrir des avantages semblables à ceux de l'automatisation des sauvegardes, y compris une efficacité et une vitesse de récupération améliorées, avec moins de temps d'arrêt. Étant donné que la solution assure le suivi de tous les paramètres et résultats de sauvegarde via le service d'ajout de tags, vous pouvez développer une architecture similaire pour appliquer les opérations de restauration à grande échelle.

Par exemple, vous pouvez créer une solution basée sur un déclencheur à la demande qui envoie un champ d'application de données BigQuery à un service de coordinateur, qui envoie une requête par table à un service de configuration. Le service de configuration peut récupérer l'historique de sauvegarde souhaité pour une table particulière. Le service de configuration peut ensuite le transmettre à un service de restauration d'instantanés BigQuery ou au service de restauration Cloud Storage pour appliquer l'opération de restauration en conséquence. Enfin, un service d'ajout de tags peut stocker les résultats de ces opérations dans un magasin d'état. Ainsi, le framework de restauration automatisé peut bénéficier des mêmes objectifs de conception que le framework de sauvegarde décrits dans ce document.

Optimisation des coûts

Le framework de cette architecture fournit des règles de sauvegarde qui définissent les paramètres suivants pour optimiser les coûts globaux:

• Méthode de sauvegarde: le framework propose les deux méthodes de sauvegarde suivantes :
  • Les instantanés BigQuery, qui entraînent des coûts de stockage en fonction des données mises à jour et supprimées par rapport à la table de base. Par conséquent, les instantanés sont plus rentables pour les tables de type "append-only" ou celles dont les mises à jour sont limitées.
  • Exportations de BigQuery vers Cloud Storage, qui entraînent des frais de stockage standards. Toutefois, pour les grandes tables qui suivent une approche de troncation et de chargement, il est plus rentable de les sauvegarder sous forme d'exportations dans des classes de stockage moins coûteuses.
• Expiration de l'instantané: la valeur TTL (Time To Live) est définie pour un seul instantané de table afin d'éviter que des frais de stockage ne soient facturés indéfiniment pour l'instantané. Les coûts de stockage peuvent augmenter si les tables n'ont pas d'expiration.

Efficacité opérationnelle

Cette section décrit les fonctionnalités et les considérations relatives à l'efficacité opérationnelle.

Règles de sauvegarde précises et évolutives

L'un des objectifs de ce framework est l'efficacité opérationnelle en augmentant les résultats de l'entreprise tout en maintenant une contribution de l'entreprise relativement faible et gérable. Par exemple, le résultat correspond à un nombre élevé de tables sauvegardées régulièrement, tandis que l'entrée est un petit nombre de configurations et de règles de sauvegarde gérées.

En plus d'autoriser les règles de sauvegarde au niveau de la table, le framework autorise également des règles au niveau de l'ensemble de données, du projet, du dossier et au niveau global. Cela signifie qu'avec quelques configurations à des niveaux supérieurs (par exemple, au niveau du dossier ou du projet), des centaines ou des milliers de tables peuvent être sauvegardées régulièrement et à grande échelle.

Observabilité

Avec un framework d'automatisation, il est essentiel que vous compreniez les états des processus. Par exemple, vous devriez pouvoir trouver les informations concernant les requêtes courantes suivantes:

• Règle de sauvegarde utilisée par le système pour chaque table.
• Historique des sauvegardes et emplacements de sauvegarde de chaque table.
• État général d'une seule exécution (nombre de tables traitées et de tables ayant échoué).
• Erreurs fatales qui se sont produites lors d'une seule exécution, et composants ou étapes du processus au cours desquels elles se sont produites.

Pour fournir ces informations, le déploiement écrit des journaux structurés dans Cloud Logging à chaque étape d'exécution utilisant un service Cloud Run. Les journaux incluent les entrées, les sorties et les erreurs, ainsi que d'autres points de contrôle de la progression. Un récepteur de journaux achemine ces journaux vers une table BigQuery. Vous pouvez exécuter un certain nombre de requêtes pour surveiller les exécutions et obtenir des rapports pour les cas d'utilisation courants de l'observabilité. Pour en savoir plus sur les journaux et les requêtes dans BigQuery, consultez la page Afficher les journaux acheminés vers BigQuery.

Optimisation des performances

Pour gérer des milliers de tables à chaque exécution, la solution traite les requêtes de sauvegarde en parallèle. Le service de répartiteur répertorie toutes les tables incluses dans le champ d'application de sauvegarde BigQuery et génère une requête de sauvegarde par table à chaque exécution. Cela permet à l'application de traiter des milliers de requêtes et de tables en parallèle, et non de manière séquentielle.

Certaines de ces requêtes peuvent initialement échouer pour des raisons temporaires, par exemple lorsque les limites des API Google Cloud sous-jacentes sont atteintes ou en cas de problèmes réseau. Jusqu'à ce que les requêtes soient terminées, Pub/Sub les relance automatiquement avec la stratégie d'intervalle exponentiel entre les tentatives. En cas d'erreurs fatales telles que des destinations de sauvegarde non valides ou des autorisations manquantes, elles sont consignées et l'exécution de cette requête de table spécifique est interrompue sans affecter l'exécution globale.

Limites

Les quotas et limites suivants s'appliquent à cette architecture.

Pour les instantanés de table, les conditions suivantes s'appliquent pour chaque projet d'opération de sauvegarde que vous spécifiez:

• Un projet peut exécuter jusqu'à 100 tâches simultanées d'instantanés de table.
• Un projet peut exécuter jusqu'à 50 000 tâches d'instantanés de table par jour.
• Un projet peut exécuter jusqu'à 50 tâches d'instantané de table par table et par jour.

Pour en savoir plus, consultez la section Instantanés de table.

Pour les tâches d'exportation (exportations vers Cloud Storage), les conditions suivantes s'appliquent:

• Vous pouvez exporter gratuitement jusqu'à 50 Tio de données par jour à partir d'un projet à l'aide du pool d'emplacements partagés.
• Un projet peut exécuter jusqu'à 100 000 exportations par jour. Pour étendre cette limite, créez une réservation d'emplacement.

Pour en savoir plus sur l'extension de ces limites, consultez la page Tâches d'exportation.

Concernant les limites de simultanéité, cette architecture utilise Pub/Sub pour relancer automatiquement les requêtes qui échouent en raison de ces limites, jusqu'à ce qu'elles soient traitées par l'API. Toutefois, en ce qui concerne les autres limites concernant le nombre d'opérations par projet et par jour, celles-ci peuvent être atténuées par une demande d'augmentation de quota, ou en répartissant les opérations de sauvegarde (instantanés ou exportations) sur plusieurs projets. Pour répartir les opérations sur plusieurs projets, configurez les règles de sauvegarde comme décrit dans les sections de déploiement suivantes:

• Définir des règles de sauvegarde de remplacement
• Configurer d'autres projets d'opération de sauvegarde
• Définir des règles de sauvegarde au niveau des tables

Déploiement

Pour déployer cette architecture, consultez la section Déployer l'automatisation des sauvegardes BigQuery évolutives.

Étape suivante

• Apprenez-en davantage sur BigQuery :
  • Instantanés de la table BigQuery
  • Exportations de la table BigQuery vers Cloud Storage
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.

Contributeurs

Auteur: Karim Wadie | Ingénieur stratégique Cloud

Autres contributeurs :

• Chris DeForeest | Ingénieur en fiabilité des sites
• Eyal Ben Ivri | Architecte de solutions cloud
• Jason Davenport | Developer Advocate
• Jaliya Ekanayake | Responsable de l'ingénierie
• Muhammad Zain | Ingénieur stratégique cloud