Ce document décrit les principes et les techniques permettant de mettre en œuvre un workflow reproductible qui vous aidera à intégrer les modifications de données dans votre entrepôt de données basé sur BigQuery. Ces modifications peuvent inclure de nouveaux ensembles de données, de nouvelles sources de données, ou des mises à jour et des modifications apportées à des ensembles de données existants. Ce document décrit également une architecture de référence pour cette tâche.
Ce document s'adresse aux architectes de logiciels, aux architectes de données et aux ingénieurs de données qui utilisent BigQuery en tant qu'entrepôt de données. Dans ce document, nous partons du principe que vous maîtrisez les concepts de base de CI/CD ou de pratiques similaires de gestion du cycle de vie des applications.
Introduction
L'intégration continue et la livraison continue (CI/CD) sont devenues une technique essentielle dans le cycle de développement des logiciels. L'adoption des principes de CI/CD permet aux équipes de fournir de meilleurs logiciels avec moins de problèmes qu'en intégrant des fonctionnalités et en les déployant manuellement. La CI/CD peut également faire partie d'une stratégie de gestion des données lorsque vous modernisez votre entreposage de données.
Toutefois, lorsque vous travaillez avec un entrepôt de données comme BigQuery, il existe des différences dans la manière de mettre en œuvre la CI/CD par rapport à la mise en œuvre de CI/CD dans le code source. Ces différences sont en partie dues au fait que l'entreposage de données est un système intrinsèquement avec état permettant de gérer les données sous-jacentes.
Ce document fournit les informations suivantes :
- Des techniques de mise en œuvre d'une stratégie d'intégration continue (CI) dans BigQuery.
- Des conseils et des méthodes pour éviter les pièges.
- Des suggestions pour les fonctionnalités BigQuery qui facilitent la CI dans BigQuery.
Ce document se concentre sur la CI, car l'intégration présente plus de considérations spécifiques aux données pour une équipe d'entreposage de données que la livraison continue (CD).
Quand utiliser la CI pour un entrepôt de données BigQuery ?
Dans ce document, l'intégration des données est une tâche généralement effectuée par l'équipe d'entrepôt de données, qui inclut l'intégration de nouvelles données dans l'entrepôt de données. Cette tâche peut impliquer l'intégration d'une nouvelle source de données dans l'entrepôt de données, ou la modification de la structure d'une table déjà présente dans l'entrepôt de données.
L'intégration de nouvelles données dans l'entrepôt de données est une tâche semblable à l'intégration d'une nouvelle fonctionnalité dans un logiciel existant. Cela peut entraîner des bugs et affecter négativement l'expérience de l'utilisateur final. Lorsque vous intégrez des données dans BigQuery, il est possible que les utilisateurs en aval (par exemple, les applications, les tableaux de bord d'informatique décisionnelle et les utilisateurs individuels) rencontrent des problèmes en raison d'incohérences des schémas. Il se peut également que les consommateurs utilisent des données incorrectes qui ne reflètent pas les données de la source de données d'origine.
La CI pour l'entrepôt de données est utile lorsque vous souhaitez effectuer les opérations suivantes :
- Décrire les points clés de l'intégration continue pour un système d'entrepôt de données.
- Concevoir et mettre en œuvre une stratégie de CI pour votre environnement BigQuery.
- Découvrir comment utiliser les fonctionnalités BigQuery pour la mise en œuvre de la CI.
Ce guide ne décrit pas comment gérer la CI pour les produits autres que l'entrepôt de données, y compris les produits de données tels que Dataflow et Bigtable.
Exemple de scénario
L'entreprise Exemple est une grande entreprise de commerce de détail qui gère son entrepôt de données dans BigQuery. L'année prochaine, l'entreprise souhaite intégrer de nouvelles sources de données dans son entrepôt de données, sources qui proviennent d'entreprises récemment acquises par l'entreprise Exemple. Les nouvelles sources de données à intégrer ont des schémas différents. Cependant, l'entrepôt de données doit conserver son schéma existant, et assurer la cohérence forte et l'exhaustivité des données afin que les utilisateurs en aval ne soient pas affectés de manière négative.
Actuellement, l'équipe d'entrepôt de données de l'entreprise Exemple effectue l'intégration des données. L'intégration repose sur l'utilisation des sources de données existantes dans un schéma prédéfini. Ce workflow implique les anciens processus d'importation de données, les bases de données acquises et les services d'application.
Pour mettre à jour ses processus d'intégration de données afin de les adapter aux nouvelles sources de données, l'équipe d'entrepôt de données doit revoir leur approche d'intégration des données afin de répondre aux exigences mentionnées précédemment, telles que la cohérence forte des données. L'équipe doit mettre en œuvre les changements de manière isolée afin que les modifications de données puissent être testées et mesurées avant que les données ne soient mises à la disposition des utilisateurs en aval.
Une fois que l'équipe d'entrepôt de données a adopté le nouveau workflow, elle dispose d'un processus reproductible. Chaque développeur peut créer un environnement de développement isolé basé sur des données de production. Grâce à ces environnements isolés, les développeurs peuvent effectuer des modifications, les tester, les faire examiner et apporter les modifications requises à l'environnement de production. Si les modifications entraînent des bugs ou des problèmes imprévus, vous pouvez facilement effectuer un rollback.
Signification de l'intégration continue pour un entrepôt de données
L'intégration continue (CI) est un ensemble de pratiques qui permet aux équipes de développement de raccourcir les cycles de développement et de détecter les problèmes dans le code plus rapidement qu'avec des systèmes manuels. Le principal avantage de l'adoption d'une approche de CI est la capacité à développer rapidement, ce qui réduit les risques d'interférence entre les développeurs. Pour atteindre cet objectif, assurez-vous que le processus est reproductible, tout en permettant à chaque développeur de travailler de manière isolée par rapport aux autres développeurs.
Ces principes s'appliquent également lorsqu'une organisation doit intégrer des données dans un entrepôt de données, à quelques différences près. Dans le contexte du développement logiciel typique, la CI isole les modifications apportées au code source, qui est sans état. Dans le contexte de la CI dans les données, la CI intègre des données dans un système d'entrepôt de données. Cependant, les données sont avec état par définition. Cette différence a des conséquences sur l'application de la CI aux scénarios d'entrepôt de données, comme décrit dans ce document.
Autres scénarios non traités dans ce document
Bien que ce document se concentre sur l'isolation des modifications en matière de développement dans l'environnement de production, il ne couvre pas les aspects suivants de l'intégration des données :
- Tests des données : parvenez-vous à vérifier que les données dont vous disposez sont conformes aux exigences commerciales ? Les données sont-elles assez fiables pour servir de source fiable d'informations ? Pour augmenter le niveau de confiance dans les données que vous diffusez à partir de votre entrepôt de données, il est important de tester les données. Pour effectuer un test, vous pouvez exécuter un ensemble de requêtes pour vérifier que les données ne sont pas des valeurs manquantes ou qu'elles ne contiennent pas de "mauvaises" valeurs.
- Traçabilité des données : pouvez-vous voir n'importe quelle table dans son contexte ? Par exemple, pouvez-vous voir d'où proviennent les données et quels ensembles de données ont été précalculés afin de générer la table ? Dans les architectures modernes d'entrepôt de données, les données sont divisées en de nombreux systèmes utilisant différentes structures de données spécialisées. Celles-ci incluent les bases de données relationnelles, les bases de données NoSQL et les sources de données externes. Pour bien comprendre les données dont vous disposez, vous devez en effectuer le suivi. Vous devez également comprendre comment les données ont été générées et d'où elles proviennent.
Ces sujets n'entrent pas dans le cadre de ce guide. Toutefois, il sera bénéfique pour votre stratégie de données de prévoir ces sujets lors de la conception d'un workflow pour votre équipe.
Configuration typique de BigQuery en tant qu'entrepôt de données
Le schéma suivant illustre une conception d'entrepôt de données classique pour BigQuery. Il montre comment les données de sources externes sont ingérées dans l'entrepôt de données et comment les consommateurs utilisent les données de l'entrepôt de données.
Les données commencent dans les sources de données, où elles se trouvent dans des bases de données à faible latence ou transactionnelles classiques, telles que des bases de données OLTP SQL et des bases de données NoSQL. Un processus planifié copie les données dans une zone de préproduction.
Les données sont stockées temporairement dans la zone de préproduction. Si nécessaire, les données sont transformées pour s'adapter à un système analytique avant leur chargement dans les tables d'entrepôt de données (dans ce schéma, la zone de préproduction se trouve dans Google Cloud, mais ce n'est pas obligatoire). Les transformations peuvent inclure la dénormalisation, l'enrichissement de certains ensembles de données ou la gestion d'entrées mal formées (par exemple, des entrées avec des valeurs manquantes).
Depuis la zone de préproduction, les nouvelles données sont chargées dans les tables d'entrepôt de données. Les tables peuvent être organisées de différentes manières en fonction de la conception de l'entrepôt de données, et sont généralement appelées tables principales. Voici quelques exemples de paradigmes de conception de table : le paradigme schéma en étoile, le paradigme dénormalisé et les agrégations à plusieurs niveaux.
Quelle que soit leur conception, ces tables enregistrent des données au fil du temps. Les tables doivent respecter le schéma et sont supposées contenir la source fiable à des fins d'analyse. Ce rôle signifie que les données de ces tables doivent être complètes, cohérentes et conformes aux schémas prédéfinis.
Ces tables ne diffusent pas de données directement aux utilisateurs. Les données sont plutôt diffusées via une couche d'accès, conçue pour encapsuler la logique métier qui doit être appliquée aux données sous-jacentes. Voici des exemples de ce type de logique métier : le calcul d'une métrique pour chaque enregistrement, ou le filtrage et le regroupement des données.
Les utilisateurs des données peuvent se connecter aux données de la couche d'accès de l'entrepôt de données et les lire. Ces utilisateurs de données peuvent inclure des systèmes tels que les suivants :
- Tableaux de bord d'informatique décisionnelle
- Blocs-notes pour la science des données
- Systèmes opérationnels qui s'appuient sur des données calculées dans l'entrepôt de données
- Utilisateurs humains pour les requêtes ad hoc
Les utilisateurs de données s'appuient massivement sur l'entrepôt de données pour fournir des schémas cohérents et sur la logique métier que l'entrepôt de données encapsule. Ces schémas et cette logique métier peuvent être considérés comme des contrats de niveau de service de la plate-forme d'entrepôt de données. Toute modification de la logique métier, du schéma ou de l'exhaustivité des données peut avoir des conséquences importantes en aval. Compte tenu de la nature en constante évolution des plates-formes de données modernes, l'équipe d'entrepôt de données peut être requise pour effectuer ces modifications tout en respectant strictement les contrats de niveau de service. Pour que l'équipe puisse respecter ces contrats de niveau de service et tenir à jour l'entrepôt de données, elle a besoin d'un workflow permettant d'intégrer les données tout en minimisant les frictions potentiellement liées à ces modifications.
Éléments pour l'intégration continue dans un entrepôt de données
Comme pour toute autre équipe de développement ou informatique, l'équipe d'entrepôt de données doit maintenir les éléments essentiels à ses responsabilités. Ces éléments peuvent généralement être divisés en plusieurs catégories, décrites ci-dessous :
Codebase pour les pipelines de données : ces éléments sont généralement constitués de code source dans un langage de programmation de haut niveau, tel que Python ou Java. Pour ces types d'éléments, les processus CI/CD sont créés à l'aide d'outils tels que Git et Jenkins, ou de solutions Google Cloud telles que Cloud Source Repositories et Cloud Build.
Scripts SQL : ces éléments décrivent la structure et la logique métier encapsulée dans l'entrepôt de données. Dans cette catégorie, les éléments peuvent être divisés en plusieurs sous-catégories, décrites ci-dessous :
- Langage de définition de données (LDD) : ces éléments sont utilisés pour définir le schéma des tables et des vues.
- Langage de manipulation de données (LMD) : ces éléments sont utilisés pour manipuler les données dans une table. Les commandes LMD sont également utilisées pour créer des tables basées sur des tables existantes.
- Langage de contrôle de données (LCD) : ces éléments permettent de contrôler les autorisations et l'accès aux tables. Dans BigQuery, vous pouvez contrôler les accès à l'aide de SQL et de l'outil de ligne de commande
bq, ou à l'aide de l'API REST BigQuery. Toutefois, nous vous recommandons d'utiliser IAM.
Ces éléments, ainsi que d'autres, tels que les scripts Terraform utilisés pour créer des composants, sont gérés dans des dépôts de code. Des outils tels que Dataform peuvent vous aider à créer un pipeline CI/CD qui valide vos scripts SQL et vérifie les règles de validation prédéfinies sur les tables créées par des scripts LDD. Ces outils vous permettent d'appliquer des processus de compilation et de test pour SQL, qui ne dispose généralement pas d'un environnement de test naturel.
En plus des éléments associés aux outils et aux processus, les données constituent le principal élément d'une équipe d'entrepôt de données. Les données ne peuvent pas être suivies à l'aide de systèmes de suivi des ressources tels que Git, qui sont conçus pour suivre le code source. Ce document traite des problèmes associés au suivi des données.
Problèmes d'intégration des données
En raison de la complexité potentielle des relations de tables dans un entrepôt de données (par exemple, dans l'un des paradigmes de conception de table mentionnés précédemment), il est difficile de maintenir isolé l'état des données de production dans un environnement de test. Les pratiques standards de développement logiciel ne peuvent pas être appliquées au scénario d'intégration des données.
Le tableau suivant récapitule les différences entre les pratiques d'intégration du code et les pratiques d'intégration des données.
| Intégration du code | Intégration des données | |
|---|---|---|
| Développement local | Le code source est facile à cloner en raison de sa taille relativement petite. En règle générale, le code s'adapte à la plupart des machines des utilisateurs finaux (à l'exception des cas de monorepo, qui disposent d'autres solutions). | La plupart des tables d'un entrepôt de données ne peuvent pas tenir sur une machine de développement en raison de leur taille. |
| Tests centralisés | Plusieurs états du code source sont clonés dans un système central (un serveur CI) pour passer par des tests automatisés. Le fait de disposer de différents états du code vous permet de comparer les résultats d'une version stable à ceux d'une version de développement. | Il n'est pas simple de créer différents états des données dans un environnement isolé. Le transfert de données en dehors de l'entrepôt de données est une opération fastidieuse et chronophage. Il n'est pas pratique de la réaliser aussi souvent que les tests l'exigent. |
| Versions précédentes | Au cours du processus de publication de nouvelles versions du logiciel, vous pouvez suivre les versions antérieures. Si vous détectez un problème dans une nouvelle version, vous pouvez effectuer un rollback vers une version stable. | Effectuer des sauvegardes de tables dans l'entrepôt de données est une pratique standard au cas où vous auriez besoin d'effectuer un rollback. Cependant, vous devez vous assurer que le rollback appliqué à toutes les tables concernées permet de les restaurer telles qu'elles étaient à un même moment précis. De cette manière, les tables associées sont cohérentes entre elles. |
Intégrer des données dans des tables BigQuery
BigQuery offre deux fonctionnalités qui peuvent vous aider à concevoir un workflow d'intégration des données : les instantanés de table et les clones de table. Vous pouvez combiner ces fonctionnalités pour mettre en place un workflow vous permettant d'obtenir un environnement de développement économique. Les développeurs peuvent manipuler les données et leur structure indépendamment de l'environnement de production, et effectuer le rollback d'une modification si nécessaire.
Un instantané de table BigQuery est une représentation en lecture seule d'une table (appelée table de base) à un moment donné. De même, un clone de table BigQuery est une représentation en lecture/écriture d'une table à un moment donné. Dans les deux cas, les coûts de stockage sont réduits, car seules les différences par rapport à la table de base sont stockées. Les clones de table commencent à entraîner des frais lorsque la table de base change ou lorsque les clones de table changent. Les instantanés de table étant en lecture seule, ils n'engendrent des frais que lorsque la table de base change.
Pour plus d'informations sur les tarifs des instantanés de table et des clones de table, consultez les pages Présentation des instantanés de table et Présentation des clones de table.
Vous pouvez prendre des instantanés de table et des clones de table à l'aide de la fonctionnalité temporelle de BigQuery (qui permet de revenir jusqu'à sept jours en arrière). Cette fonctionnalité vous permet de capturer des instantanés et des clones de plusieurs tables à un même moment précis, ce qui rend votre environnement de travail et vos instantanés cohérents entre eux. Cette fonctionnalité peut être utile pour les tables fréquemment mises à jour.
Utiliser des clones et des instantanés de table pour permettre l'isolation
Pour illustrer le workflow d'intégration de la CI dans un entrepôt de données, imaginez le scénario suivant. Vous devez intégrer un nouvel ensemble de données dans l'entrepôt de données. La tâche peut consister à créer des tables d'entrepôt de données, à mettre à jour des tables existantes, à modifier la structure des tables, ou une combinaison de ces tâches. Le workflow peut ressembler à ceci :
- Vous identifiez les tables susceptibles d'être affectées par les modifications et les tables supplémentaires que vous souhaitez vérifier.
- Vous créez un ensemble de données BigQuery contenant les éléments nécessaires à cette modification. Cet ensemble de données permet d'isoler les modifications et de séparer cette tâche des autres tâches sur lesquelles d'autres membres de l'équipe travaillent. L'ensemble de données doit se trouver dans la même région que l'ensemble de données source. Toutefois, le projet peut être séparé du projet de production pour répondre aux exigences de sécurité et de facturation de votre organisation.
Pour chacune des tables, vous créez un clone et un instantané dans le nouvel ensemble de données, potentiellement pour un même moment précis. Cette approche offre les avantages suivants :
- Le clone de table peut servir de copie de travail dans laquelle vous pouvez effectuer des modifications librement sans affecter la table de production. Vous pouvez créer plusieurs clones de table de la même table de base afin de tester différents chemins d'intégration en même temps, avec une surcharge minimale.
- L'instantané peut servir de point de restauration et de référence, c'est-à-dire de point où on sait que les données fonctionnaient avant toute modification. Cet instantané vous permet d'effectuer un rollback au cas où un problème serait détecté plus tard dans le processus.
Vous utilisez les clones de table pour implémenter les modifications requises pour ces tables. Cette action génère une version mise à jour des clones de table, que vous pouvez tester dans un ensemble de données isolé.
À la fin de la phase de mise en œuvre, vous pouvez éventuellement présenter un ensemble de données qui peut être utilisé pour les tâches suivantes :
- Tests unitaires avec un outil de validation tel que Dataform. Les tests unitaires sont autonomes, ce qui signifie que l'élément est testé de manière isolée. Dans ce cas, l'élément est la table dans BigQuery. Les tests unitaires peuvent rechercher des valeurs nulles, vérifier que toutes les chaînes répondent aux exigences de longueur et s'assurer que certains agrégats produisent des résultats utiles. Les tests unitaires peuvent inclure tout test de confiance qui garantit que la table conserve les règles métier de l'organisation.
- Tests d'intégration avec les utilisateurs en aval.
- Examens par des pairs.
Ce workflow vous permet d'effectuer des tests avec des données de production, sans affecter les utilisateurs en aval.
Avant de fusionner les nouvelles données dans BigQuery, vous pouvez créer un autre instantané. Cet instantané est utile en tant qu'autre option de rollback si les données de la table de base ont changé.
Le processus de fusion des modifications dépend du processus que votre organisation souhaite adopter et des modifications qui sont requises. Par exemple, en cas de modification des scripts SQL, le nouvel ensemble de données peut être accompagné d'une demande d'extraction envoyée au codebase standard. Si la modification est limitée à une modification des données d'une table particulière, vous pouvez simplement copier les données à l'aide des méthodes standards de BigQuery.
Vous pouvez utiliser un script de procédures stockées pour encapsuler et automatiser les étapes de création d'un ensemble de données et de création des clones et des instantanés. L'automatisation de ces tâches réduit les risques d'erreur humaine. Pour obtenir un exemple de script permettant d'automatiser les processus, consultez le dépôt GitHub de l'utilitaire CLI d'intégration continue des données dans BigQuery.
Avantages de l'utilisation de clones et d'instantanés de table
Lorsque vous utilisez le workflow décrit dans la section précédente, vos développeurs peuvent travailler de façon isolée et en parallèle, sans interférer avec leurs collègues. Les développeurs peuvent tester les modifications et les examiner. Si un problème survient, ils peuvent effectuer un rollback. Étant donné que vous utilisez des instantanés de tables et non des tables complètes, vous pouvez réduire les coûts et le stockage par rapport à l'utilisation de tables complètes.
Cette section fournit des informations plus détaillées sur la manière dont les instantanés de table et les clones de table permettent aux développeurs d'obtenir ce workflow. Le schéma suivant illustre la relation entre les instantanés et les clones de table et les données de l'ensemble de données de production.
Dans le diagramme, l'ensemble de données de production contient toutes les tables qui sont utilisées en production. Chaque développeur peut créer un ensemble de données pour son propre environnement de développement. Le schéma montre deux ensembles de données de développement, nommés Dev Dataset 1 (Ensemble de données de développement 1) et Dev Dataset 2 (Ensemble de données de développement 2). En utilisant ces ensembles de données de développement, les développeurs peuvent travailler simultanément sur les mêmes tables sans interférer les uns avec les autres.
Une fois que les développeurs ont créé un ensemble de données, ils peuvent créer des clones et des instantanés des tables sur lesquelles ils travaillent. Les clones et les instantanés représentent les données à un moment précis. À ce stade, les développeurs sont libres de modifier les clones de la table, car les modifications ne sont pas visibles sur la table de base.
Les développeurs peuvent examiner les clones de table, les comparer à l'instantané et les tester pour vérifier leur compatibilité avec les utilisateurs en aval. D'autres développeurs peuvent travailler avec d'autres clones et instantanés, sans interférence, et sans créer trop de copies de la table de base, ce qui consomme beaucoup de ressources.
Les développeurs peuvent fusionner les modifications dans la table de base tout en conservant la sécurité de l'instantané comme option de rollback, si nécessaire. Ce processus peut également être répété pour différents environnements, tels que le développement, les tests et la production.
Alternatives aux clones et aux instantanés de table
Il existe des alternatives à l'utilisation des clones de table et des instantanés de table, qui vous permettent d'obtenir un résultat similaire. Ces autres méthodes sont généralement utilisées différemment des clones et des instantanés. Il est important de comprendre les différences entre ces méthodes et dans quelles circonstances vous pouvez préférer une méthode à l'autre.
Copier des tables entières dans un autre ensemble de données
Une autre méthode consiste à utiliser un autre ensemble de données et à copier les tables dans cet ensemble de données. Cette méthode est semblable à l'utilisation de clones et d'instantanés de table, mais vous copiez l'ensemble complet de tables. En fonction de la taille des données copiées, les coûts de stockage peuvent être élevés. Certaines organisations ont utilisé cette méthode avant que les clones de table ne soient disponibles dans BigQuery. Cependant, cette méthode ne présente aucun avantage par rapport à l'utilisation de clones et d'instantanés.
Exporter et importer des tables vers Cloud Storage
Une autre méthode consiste à déplacer les données via Cloud Storage. Cette méthode est également semblable à l'utilisation de clones de table et d'instantanés de table. Toutefois, elle inclut l'étape supplémentaire d'exporter les données vers un bucket Cloud Storage. L'un des avantages de cette méthode est qu'elle vous offre une sauvegarde supplémentaire de vos données. Vous pouvez choisir cette méthode si vous souhaitez une sauvegarde pour la reprise après sinistre ou les solutions hybrides.
Utiliser Analytics Hub
Analytics Hub vous permet de partager des ensembles de données en dehors et à l'intérieur de l'organisation de manière sécurisée. Il offre de nombreuses fonctionnalités qui vous permettent de publier des ensembles de données pour fournir aux abonnés un accès contrôlé et en lecture seule à ces ensembles de données. Cependant, même si vous pouvez utiliser Analytics Hub pour exposer les ensembles de données afin de mettre en œuvre des modifications, un développeur doit tout de même créer des clones de table pour travailler avec les tables.
Résumé des options d'intégration continue d'entrepôt de données
Le tableau suivant récapitule les différences, les avantages et les inconvénients potentiels des différentes options d'intégration continue d'entrepôt de données (Analytics Hub offre un ensemble de fonctionnalités différent. Il n'est donc pas mesurable à l'aide des paramètres listés dans le tableau).
| Coûts | Rollbacks | Risques | |
|---|---|---|---|
| Instantanés et clones de table | Minimal. Vous ne payez que pour la différence entre l'instantané ou le clone et la table de base. | L'instantané agit comme sauvegarde pour effectuer un rollback si nécessaire. | Vous contrôlez le niveau de risque. Les instantanés peuvent être pris à un moment donné pour toutes les tables, ce qui réduit les incohérences même en cas de rollback. |
| Copie de table | Coûts plus élevés que ceux de l'utilisation d'instantanés de tables et de clones de table. L'intégralité des données est en double. Pour effectuer des rollbacks, vous avez besoin de plusieurs copies de la même table. | Possible, mais nécessite deux copies de la table : une copie qui servira de sauvegarde, et une copie de travail qui peut être modifiée. | Le clonage est plus difficile à effectuer à un moment précis. Si un rollback est nécessaire, toutes les tables ne sont pas prises au même moment précis. |
| Exporter et importer | Coûts plus élevés que ceux de l'utilisation d'instantanés de tables et de clones de table. Les données sont dupliquées. Pour être compatible avec le rollback, vous avez besoin de plusieurs copies de la même table. | Les données exportées servent de sauvegarde. | Les données exportées ne constituent pas une exportation à un moment précis pour plusieurs tables. |
Étape suivante
- Pour en savoir plus sur les instantanés de table BigQuery, consultez la page Présentation des instantanés de table.
- Pour en savoir plus sur l'intégration continue pour le développement logiciel, consultez la page Technologies DevOps : Intégration continue.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.