Clonage avec BigQuery et Snowflake

Aujourd'hui, j'écris mon premier blog dans l'espoir d'en publier d'autres à l'avenir. Je me considère comme un passionné de données qui aime analyser et comprendre les données afin d'écrire mes solutions car, en fin de compte, ce sont les données qui sont essentielles pour toute application. Sans plus tarder, passons au sujet d'aujourd'hui : le clonage sur les deux systèmes d'entrepôt de données :

1. Snowflake
2. BigQuery

J'ai regardé de nombreux films et je me souviens dans Marvel Heroes lorsque Loki se clone de plusieurs manières à en même temps! Un tel clonage n'est peut-être pas possible dans le monde réel, mais il est possible dans le monde de la technologie. Par exemple, cloner le code sur une machine locale (le clone git est un exemple principal).

Maintenant, qu'en est-il des bases de données (DB) ? Pourquoi ne pas les cloner ? Eh bien, nous avions l'habitude de le faire, mais c'était vraiment une copie de la base de données qui consommait de l'espace. Vous vous demandez peut-être pourquoi devons-nous cloner une base de données sans consommer d'espace ? Eh bien, il y a beaucoup de réponses. Avant d'approfondir cela, arrêtons-nous un instant sur les raisons pour lesquelles nous faisons du clonage (alias Copie). La raison principale du clonage est de résoudre les problèmes de production ; lorsque nous déplaçons notre application en direct et que nous disons «  Oups, Je n'ai jamais rencontré ce type de données ou envisagé ces données », « J'aurais aimé avoir de telles données dans mon environnement de développement/test pour pouvoir couvrir ce scénario » ou « Nous n'avons pas un tel volume de données dans mon environnement de développement/test et je n'ai pas pu déterrer ces problèmes ! »

Le clonage aide également, pour n'en nommer que quelques-uns :

1. Amélioration de l'application et de la structure de données sous-jacente en utilisant une copie de production des données. et Tester les environnements et effectuer nos tests) les bases de données monolithiques comme Oracle, DB2 et SQL Server on-Prem. Nous avions l'habitude d'appeler cela du clonage, mais si vous observez, nous ne les clonons pas réellement, mais plutôt les copions. La copie présente de multiples inconvénients, notamment :
   1. Duplication des données
   2. Effort manuel (ou un outil supplémentaire pour effectuer une activité)
   3. Jours pour répliquer (si le volume est élevé)
   4. Les données ne sont pas synchronisées avec la production[19659003]Stockage supplémentaire

   J'ai personnellement traité la copie de bases de données extra-larges, ce qui prenait entre 2 et 4 jours, sans compter le temps de configuration post-copie (analyse, etc.).

   Je souhaitais nous avions une commande simple à utiliser qui clonerait la base de données sans occuper d'espace et effectuerait mon travail en quelques commandes sans dépendre de mes DBA. Voilacela s'est avéré être vrai lorsque j'ai commencé à passer ma certification Snowflake Pro Core et à étudier et à jouer avec Snowflake.

   Permettez-moi de prendre du recul et de parler de Snowflake. 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. Il a 3 couches d'architecture :

   1. Cloud Services : Le coordinateur et la collection de Services.
   2. Query Processing : Cerveau du système, où l'exécution des requêtes est effectuée à l'aide de « virtual entrepôts".
   3. Stockage de la base de données : qui stocke physiquement les données en mode Colonne.

   

   • Observez les métadonnées de cette table :

   

    [19659038]ID : ID unique pour cette table

2. CLONE_GROUP_ID : à partir de quel ID de l'objet est cloné (donc c'est le même que l'ID)
3. Maintenant, je vais créer un clone de Transactions appelé "Transactions_Clone". Maintenant, la table affichera le même volume d'enregistrements :



• Nous pourrions nous demander s'il a « copié » l'intégralité de la table « Transactions » et l'a répliqué, mais ce n'est pas le cas. Alors, comment savons-nous qu'il n'a pas copié? Voir les métadonnées du tableau ci-dessous :



• Observez ce qui suit
  • ID : La nouvelle table a son propre ID unique
  • CLONE_GROUP_ID : Il pointe vers l'ID de la table "Transactions". N'est-ce pas intelligent !
• Donc, techniquement, lorsque j'interroge TRANSACTIONS_CLONE Cela fait simplement référence à l'emplacement des données de "TRANSACTIONS"
• Lorsque nous ajoutons des données au maître, vous ne voir cela dans TRANSACTIONS_CLONE ! (ce qui était attendu)
• Maintenant, disons, je supprime les données de TRANSACTIONS_CLONE (60 d'entre elles), je ne verrai pas ces 60, mais les autres données seront toujours référencées à partir de sa source d'origine "TRANSACTIONS"



• Et mes octets actifs sont toujours à 0



• Maintenant, j'ai chargé environ 100K enregistrements et jette un œil au nombre de enregistrements !, il prend les nouvelles données de l'emplacement récemment ajouté et le reste de la source.



Si un utilisateur modifie la table ou l'objet, tout ce que Snowflake fait, c'est qu'il aura les données supplémentaires (ou les données supprimées) des nouveaux pointeurs/références. Cela implique des coûts de stockage pour les données ajoutées uniquement. Lorsque vous supprimez les données, les données d'origine ne sont pas modifiées, mais sa couche de service Cloud contient les informations nécessaires sur ce qui a été supprimé et ajouté, ce qui en fait une « vraie » copie Zero.

De même, si vous apportez des modifications structurelles, Snowflake gère les changements dans sa couche de services Cloud et apporte les données nécessaires en conséquence.

Cela donne une réelle puissance de clonage sans consommer d'espace et vous pouvez répliquer la table en quelques minutes, voire quelques secondes. Accélérez également votre développement et vos tests avec une bien meilleure efficacité.

BigQuery est l'une des bases de données les plus populaires, ou nous devrions appeler Cloud Data Warehouse, qui offre des fonctionnalités riches pour le stockage des données et des performances et une évolutivité extrêmes des données. Il s'agit d'une base de données entièrement gérée, vous n'avez donc pas à vous soucier du stockage ou des moteurs de calcul à utiliser. Contrairement à Snowflake, il faut choisir un entrepôt virtuel (alias moteur de calcul) pour exécuter votre requête, et si la requête ne se porte pas mieux, vous pouvez choisir un entrepôt configuré plus haut pour permettre à la requête de mieux s'exécuter.

Dans BigQuery, vous n'avez pas à vous en soucier et concentrez-vous simplement sur l'écriture de la requête et son exécution. Vous ne serez facturé que pour les données que vous récupérez.

BigQuery est similaire à Snowflake, mais jusqu'à présent, il n'avait pas la possibilité de cloner la base de données. Lors de Google Next '21, il a été annoncé que vous pourrez bientôt :

1. Prendre un instantané
2. Cloner la base de données





À 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 AML.

En savoir plus sur cet auteur