Flocon de neige de voyage dans le temps contre BigQuery

Bonjour les amis, je suis de retour avec un autre sujet intéressant appelé "le voyage dans le temps". Je pense que beaucoup d'entre vous aimeraient pouvoir remonter le temps et réparer quelque chose. L'idée du voyage dans le temps a été rendue possible dans le monde fictif des films et des livres, y compris Aditya 369 (sorti pendant mon adolescence), les films Marvel récents et Tenet. Bien que nous sachions qu'il est impossible de voyager dans le temps dans le monde réel, cela est possible dans le monde de la technologie (avec des bases de données, par exemple). voulait revenir à l'état pré-étatique? Dans une certaine mesure, vous le pouvez avec Time Travel. Plus précisément, vous pouvez remonter dans le temps et « restaurer » comme par magie l'état précédent.

J'utilise Oracle depuis plus de deux décennies et nous nous entraînons souvent à faire une « sauvegarde » de la table avant d'effectuer tout type d'opération. . Si tout se passe bien, nous le jetons ou le laissons à des fins de suivi. Avec les principales bases de données comme Oracle, si nous n'avions pas fait cette "sauvegarde", vous deviez contacter un administrateur de base de données (DBA) pour trouver un moyen de la restaurer à partir de journaux ou de bandes (bien sûr, vous pouviez restaurer la table supprimée de la corbeille). La création d'une « sauvegarde » n'est cependant pas une solution parfaite, car elle s'accompagne d'un coût élevé d'utilisation du disque et peut prendre du temps.

Les nouvelles technologies et bases de données sont conçues en gardant à l'esprit la flexibilité et la simplicité. En plus du faible coût de stockage des données et de l'omniprésence du cloud, l'innovation n'a pas de limites.

Les avantages de la technologie capable de voyager dans le temps incluent :

1. Vous pouvez effectuer en toute confiance les activités que vous souhaitez faire et comparer les avec des versions historiques (sans encourir de coûts)
2. Cela fait gagner du temps
3. Cela réduit les coûts de disque ou de stockage

Revenons donc aux outils Data Warehouse sur lesquels j'ai récemment écrit qui ont voyage dans le temps intégré. Ceux-ci n'ont besoin d'aucune assistance d'équipe externe et peuvent être effectués par un développeur/testeur régulier avec quelques ensembles de commandes. Ils ne sont autres que :

1. Snowflake
2. BigQuery

La fonctionnalité de voyage dans le temps est possible grâce à la méthodologie « de sécurité intégrée » qui est entièrement gérée en coulisses par ces fournisseurs. J'explorerai la mesure de sécurité intégrée plus en détail dans des blogs ultérieurs.

Veuillez noter que la sécurité intégrée consomme de l'espace de stockage, mais elle est beaucoup moins chère que les méthodes traditionnelles. Vous n'avez pas besoin d'une équipe externe pour y ajouter de l'espace disque car ces technologies utilisent le stockage Cloud, ce qui est peu coûteux.

Passons maintenant aux détails de chaque entrepôt de données et comparons-les également les uns à côté des autres.[19659015]Snowflake est un outil multi-cloud Data Lake/Warehouse qui est entièrement construit sur le cloud, pour le cloud, et son architecture est définie sur une architecture de base de données à disque partagé et sans partage. Nous avons examiné sa couche d'architecture dans mon blog précédent.

Le voyage dans le temps avec Snowflake est appelé « cycle de vie continu de la protection des données » et vous pouvez conserver les données pendant une certaine période. À l'aide de cette fonctionnalité, vous pouvez effectuer certaines actions dans la fenêtre de temps, notamment :

• Interroger des données qui ont depuis été mises à jour ou supprimées
• Créer des clones de tables, de schémas et de bases de données entiers à ou avant des points spécifiques du pas[19659007]Restaurer les tables, schémas et bases de données qui ont été supprimés

Une fois la fenêtre de temps écoulée, les données sont déplacées vers la zone de « sécurité intégrée » de Snowflake.

La beauté de cela vient des instructions SQL où vous pouvez restaurer :[19659006]À un certain moment (en utilisant soit l'horodatage)

Snowflake propose différentes saveurs de voyage dans le temps et elles diffèrent d'une version à l'autre. La version standard vous offre 24 heures de voyage dans le temps (comme un film bien connu 24 de Surya). Les versions au-dessus de la plage standard entre 0 à 90 jours ! Mais par défaut, il est défini sur 1 jour pour tous les niveaux de compte.

Maintenant, passons aux détails techniques de ce voyage dans le temps.

Tout d'abord, vérifions la rétention définie au niveau de notre compte, elle est définie sur 1 par défaut. . (Veuillez noter que j'ai un compte d'entreprise Snowflake gratuit de 30 jourst)

J'ai créé certaines tables alors que cette rétention est une, toutes ces tables J'ai juste 1 jour.

Maintenant, j'augmente la rétention de 90 jours au niveau du compte :

As dès que je passe à 90, j'ai toutes mes tables augmentées à 90 jours !

Maintenant, permettez-moi de lancer un scénario. Veuillez noter que j'utilise la nomenclature bancaire et AML pour les tables et les conventions.

1. Notre table des transactions contient des données de différents types de transactions et la devise d'origine et la devise de base.
2. Nous avons trouvé un problème que toutes les transactions par virement bancaire (CWTF) ont la devise d'origine et la devise de base en USD.
3. Cela doit être corrigé uniquement pour les types CWTF.

Voyons la diffusion des données :

Nous devons donc touchez uniquement l'élément de ligne 3 et mettez à jour CURRENCY_ORIGINATING de USD pour dire EUR (environ 50 000 enregistrements).

Idéalement, ce que nous faisons est :

1. Reprenez les transactions et nommez-les Transactions_20211124 (la date à laquelle nous créons)[19659007]Mettre à jour la table des transactions
2. Enfin, supprimez la table des transactions temporaire (ou laissez-la à des fins de suivi). La suppression ne coûtera rien, mais si nécessaire à des fins d'audit, elle consommera de l'espace. Vous êtes condamné et ne pouvez même pas remonter le temps pour le réparer ! Examinons donc un scénario dans lequel j'ai exécuté une déclaration incorrecte dans laquelle j'ai mis à jour les deux devises en EUR ! ]

   Et maintenant ? Eh bien, je ne devrais pas être si inquiet, car je peux toujours remonter le temps et restaurer la table. Cela ressemblerait à :

   1. Trouvez l'ID SQL dans l'historique, pour moi son "01a0812f-0000-5c7b-0000-00010fca53ad" et voyez les données

   

   Je peux toujours voir les anciennes données, donc tout ce que j'ai à faire est de prendre ces données et de les réinsérer dans la table actuelle (même si cela semble simple, en production, nous devons être prudents !) (Si c'est un système OLTP où les données affluent en permanence, nous devons appliquer différentes méthodes). Pour l'instant, j'écrase simplement ma table d'origine.

   

   Nous voyons que les données ont été restaurées. Maintenant, je vais exécuter la mise à jour correcte.

   

   La mise à jour correcte a mis à jour 50 000 enregistrements.

   

   Les données finales :

   

   Maintenant, vous avez vu la puissance du voyage dans le temps et comment nous pouvons l'utiliser en cas de besoin.

   Voyons comment nous pouvons y parvenir dans BigQuery et quelles sont ses caractéristiques

   BigQuery est une base de données cloud de Google et prend également en charge les voyages dans le temps. Il n'a pas plusieurs « saveurs » comme le fait Snowflake, mais il prend en charge 7 jours de voyage dans le temps. Cette fonctionnalité prend en charge les éléments suivants :

   1. Données de requête qui ont été mises à jour/supprimées
   2. Restaurer une table qui est supprimée (aka Abandonnée)
   3. Restaurer une table qui a expiré

   Si nous voulons accéder aux données au-delà de 7 jours, nous pouvons prendre des instantanés réguliers de la base de données (par exemple, Oracle). Nous pourrons parler d'instantanés dans des blogs ultérieurs, mais pour l'instant, restons-en au voyage dans le temps.

   Contrairement à Snowflake, dans BigQuery, nous ne pouvons utiliser un point dans le temps qu'à l'aide d'un horodatage.

   J'ai un tableau similaire dans mon BigQuery. mais son volume est inférieur. !

   

   

   Maintenant, nous avons mis à jour les données de manière incorrecte. Utilisons la méthodologie BigQuery Timestamp et remontons le temps pour récupérer les données avant leur mise à jour, les afficher et les restaurer (j'ai exécuté la mise à jour à 11h50 HNE, je dois donc revenir avant).

   

   

   Restaurons maintenant ces données dans la table maître. Notez que BigQuery n'a aucun moyen d'insérer un écrasementvous pouvez donc soit utiliser la fusion (si vous connaissez les clés, soit tronquer et insérer). J'ai adopté l'approche la plus tardive pour mon POC car je n'ai pas de clé sur laquelle je pourrais simplement mettre à jour. Veuillez éviter de tronquer et d'insérer dans n'importe quel environnement de production. données et exécuter les validations, et nous devrions voir seulement 33 360 enregistrements mis à jour avec EUR.

   

   Voici, nous avons mis à jour les données correctement !

   

   Nous pouvons maintenant voir comment utiliser l'horodatage ou une autre option permettant de revenir en arrière par intervalles (généralement par heure) pour récupérer les données. N'oubliez pas que BigQuery ne conserve que les données des 7 derniers jours. Après la période de 7 jours, vous perdrez les données.

   Quelques observations supplémentaires :

   1. Vous ne pouvez remonter dans le temps que par intervalles d'heures, donc si vous avez donné une heure au-delà des heures où les données n'existent pas, vous verrez une erreur :
   2. C'est un peu délicat lorsque vous utilisez « FOR SYSTEM_TIME AS OF TIMESTAMP ", même si vous pouvez obtenir l'horodatage à partir de l'historique de vos tâches, car vous devez fournir votre fuseau horaire car BigQuery s'exécute à tout moment en utilisant UTC. Pour moi, j'ai dû donner l'heure sous la forme :"TIMESTAMP('2021-11-26 11:50:37-05:00')", où -5:00 est l'heure EST, donc vous devrait fournir votre propre fuseau horaire afin que BigQuery puisse extraire les données avec précision.

   Nous avons vu comment nous pouvions récupérer en toute sécurité les données de l'historique avec quelques ensembles de commandes sans compter sur les DBA ou tout autre mécanisme. Maintenant, je voudrais mettre en garde quelques points :

   1. Le voyage dans le temps est un mécanisme sympa mais il doit être utilisé avec une extrême prudence.
   2. Vous devez examiner la rétention au niveau du compte et au niveau de la table pour vous assurer que vous êtes dans les limites de votre restauration.
   3. Vous ne pouvez pas simplement écraser les données de l'historique vers l'actuelle car cela peut entraîner un écrasement des données qui ont été insérées entre la suppression et maintenant, alors faites très attention ici.

   Même si je a mentionné la "sauvegarde" traditionnelle comme longue et coûteuse, vous pouvez y aller si vous devez vous préparer à un audit, rappelez-vous que Time Travel et Fail Safe ont une durée de vie maximale de 97 jours (Fail Safe est de 7 jours et ceci est hors de votre contrôle) et Time Travel est de 90 jours (maximum) pour les comptes Snowflake Enterprise et plus !

   J'ai constaté que dans BigQuery, l'utilisation du Time Travel est peu compliquée, surtout si vous ne fournissez pas l'heure appropriée. format.

   J'ai trouvé Snowflake comme gagnant clair en raison de sa facilité d'utilisation et le laps de temps que vous pouvez voyager dans le temps (90 jours contre 7). beaucoup de documentation sur la mise en œuvre. En attendant, déconnectez-vous !

   

   À propos de l'auteur <!– :   kvaddadi, Sr Technical Architect–>

   Krishna Vaddadi est architecte technique senior. Un architecte expérimenté et motivé en base de données, plateforme et cloud ; Krishna est spécialisé dans le Big Data et les plateformes cloud. C'est un passionné de données et une PME expérimentée dans le domaine de la LBA.

   En savoir plus sur cet auteur