Migrer des entrepôts de données vers BigQuery : Présentation du transfert de schéma et de données

Ce document fait partie d'une série qui vous aide à passer d'un entrepôt de données sur site à BigQuery sur Google Cloud. Cette partie aborde les concepts et les tâches associés au transfert du schéma et des données depuis un entrepôt de données existant vers BigQuery.

Les documents de la série sont constitués des articles suivants :

Présentation

La migration de votre entrepôt de données vers le cloud est un processus complexe qui demande de la planification, des ressources et du temps. Pour ne pas vous laisser submerger par cette complexité, vous devez adopter une approche itérative et par étapes de la migration de l'entrepôt de données. Cet article explore la première étape de la phase d'exécution de la migration, qui est le déplacement de votre schéma et de vos données. Il explique également comment les itérations supplémentaires de cette étape peuvent améliorer le résultat.

Pour obtenir une présentation des différentes phases de migration, consultez l'article d'introduction et de présentation de cette série.

Processus de migration du schéma et des données

Au début de votre parcours de migration, vous disposez de systèmes en amont qui alimentent votre ancien entrepôt de données, et de systèmes en aval qui utilisent ces données dans les rapports, dans les tableaux de bord et en tant que flux pour les autres processus.

Ce flux général de données soutient de nombreux cas d'utilisation analytiques, comme le montre le schéma suivant :

État de départ avant la migration

La finalité de votre parcours est l'exécution du plus grand nombre de cas d'utilisation possible sur BigQuery. À ce moment-là, vous pouvez minimiser l'utilisation de votre ancien entrepôt de données, jusqu'à le supprimer. C'est vous qui déterminez les cas d'utilisation à migrer et à quel moment, en établissant la priorité qui leur correspond au cours de la phase de préparation et de détection de la migration.

Migrer les données et le schéma sur site vers BigQuery

Au cours de la phase d'évaluation et de planification de la migration, vous identifiez les cas d'utilisation que vous souhaitez migrer. Ensuite, vous lancez les itérations de migration au cours de la phase d'exécution. Pour gérer vos itérations tout en exécutant votre environnement d'analyse avec des interruptions minimales, suivez ce processus de haut niveau :

  1. Transférez les tables, et configurez et testez les processus en aval.

    • Transférez le groupe de tables associé à chaque cas d'utilisation vers BigQuery sans apporter de modification, à l'aide du service de transfert de données BigQuery ou d'un autre outil ETL. Pour plus d'informations sur les outils, consultez la section relative au transfert initial des données.
    • Configurez les versions de test de vos processus en aval pour lecture à partir des tables BigQuery.

    Cette première étape divise le flux de données. Le schéma suivant illustre le flux qui en résulte. Certains systèmes en aval lisent désormais les données à partir de BigQuery, comme indiqué dans les flux avec le libellé B. Les autres systèmes continuent de lire les données à partir de l'ancien entrepôt, comme indiqué dans les flux avec le libellé A.

    Les processus en amont alimentent l'ancien entrepôt. Certains d'entre eux vont aux processus en aval, mais d'autres à BigQuery au moyen du service de transfert de données BigQuery, puis de différents processus en aval.

  2. Configurez des processus en amont de test pour écriture des données sur les tables BigQuery à la place (ou en plus) de l'ancienne base de données.

    Après les tests, configurez vos processus en amont et en aval de production pour écriture et lecture sur les tables BigQuery. Ces processus peuvent se connecter à BigQuery à l'aide de l'API BigQuery et incorporer de nouveaux produits cloud tels que Google Data Studio et Dataflow.

    À ce stade, trois flux de données sont en place :

    1. Ancien. Les données et les processus ne changent pas et restent centrés sur votre ancien entrepôt de données.
    2. Déchargé. Les processus en amont alimentent votre ancien entrepôt de données, les données sont déchargées vers BigQuery, puis elles alimentent les processus en aval.
    3. Entièrement migré. Les processus en amont et en aval ne s'appuient plus sur l'ancien entrepôt de données pour l'écriture ou la lecture.

      Le schéma suivant présente un système avec ces trois flux :

      Flux de charges de travail sur plusieurs chemins
  3. Sélectionnez des cas d'utilisation supplémentaires pour la migration, puis revenez à l'étape 1 pour démarrer une nouvelle itération d'exécution. Poursuivez les itérations sur ces étapes jusqu'à ce que tous vos cas d'utilisation soient entièrement migrés vers BigQuery. Lorsque vous sélectionnez vos cas d'utilisation, vous pouvez reprendre ceux qui sont restés à l'état déchargé pour les migrer entièrement. Pour les cas d'utilisation entièrement migrés, envisagez la poursuite du processus d'évolution en suivant les instructions présentes dans la section sur l'évolution de votre schéma dans BigQuery.

    Dernière étape pour les cas d'utilisation migrés

Évolution de votre schéma dans BigQuery

La migration de l'entrepôt de données représente une opportunité unique de faire évoluer votre schéma une fois qu'il est passé sur BigQuery. Dans cette section, vous obtiendrez des conseils pour faire évoluer votre schéma en suivant une série d'étapes. En appliquant ces instructions, vous pouvez maintenir l'exécution de votre environnement d'entrepôt de données pendant les modifications du schéma avec des interruptions minimales sur les processus en amont et en aval.

Les étapes de cette section se concentrent sur la transformation du schéma pour un seul cas d'utilisation.

En fonction de l'avancement que vous souhaitez appliquer à l'évolution, vous pouvez vous arrêter à une étape intermédiaire ou continuer jusqu'à l'évolution complète de votre système.

  1. Transférez un cas d'utilisation tel quel vers BigQuery. Suivez les étapes décrites dans la section précédente pour un cas d'utilisation donné.

    Avant de passer aux étapes suivantes, assurez-vous que les processus en amont et en aval de votre cas d'utilisation s'appuient déjà sur BigQuery pour l'écriture et la lecture. Il est toutefois possible de partir d'un état intermédiaire où seul le processus en aval lit les données à partir de BigQuery. Dans ce scénario, n'appliquez que les instructions relatives à la partie en aval. Le schéma suivant illustre un cas d'utilisation dans lequel les processus en amont et en aval écrivent et lisent les données sur des tables dans BigQuery.

    Les processus en amont alimentent les tables BigQuery et, de là, les processus en aval.

  2. Mettez en place de légères optimisations.

    1. Recréez vos tables en appliquant le partitionnement et le clustering. Pour cette tâche, vous pouvez avoir recours à la création d'une table à partir d'un résultat de requête. Pour plus de détails, consultez la discussion et les exemples pour les tables partitionnées, et la discussion et les exemples pour les tables en cluster.
    2. Redirigez vos processus en amont et en aval vers les nouvelles tables.
  3. Créez des vues de façade.

    Si vous souhaitez faire évoluer votre schéma au-delà des optimisations légères, créez des vues de façade pour vos tables. Le modèle de façade est une méthode de conception qui masque le code (ou les structures) sous-jacent afin d'en cacher la complexité. Dans ce cas, les vues de façade masquent les tables sous-jacentes afin de cacher la complexité causée par les modifications de tables issues des processus en aval.

    Les vues peuvent décrire un nouveau schéma, libéré des contraintes techniques et modélisé avec de nouveaux scénarios d'ingestion et de consommation en tête.

    Dans les faits, les tables et la définition de requête de vue en elle-même peuvent changer. Les vues permettent toutefois de faire abstraction de ces changements, qui deviennent des détails d'implémentation interne de votre entrepôt de données. Elles renvoient ainsi toujours les mêmes résultats. Cette couche d'abstraction constituée de vues de façade isole vos systèmes en amont et en aval des changements aussi longtemps que nécessaire, et ne met les modifications en lumière qu'aux moments opportuns.

  4. Transformez les processus en aval.

    Vous pouvez transformer certains de vos processus en aval afin qu'ils lisent les données à partir des vues en façade plutôt qu'à partir des tables. Ces processus profiteront d'emblée du schéma évolué. Ces processus savent qu'en arrière-plan, les vues de façade obtiennent toujours leurs données de l'ancien schéma BigQuery, comme le montre le schéma suivant :

    Les processus en amont alimentent les tables BigQuery. Certains alimentent les processus en aval. D'autres alimentent les vues de façades, qui alimentent les processus évolués en aval.

    Nous avons commencé par décrire la transformation des processus en aval. Votre entreprise en retire de la valeur plus rapidement, sous la forme de tableaux de bord ou de rapports migrés, si vous aviez transformé des processus en amont qui ne sont pas visibles pour les acteurs non techniciens. Il est néanmoins possible de démarrer la transformation avec vos processus en amont. La priorité donnée à ces tâches dépend entièrement de vos besoins.

  5. Transformez les processus en amont.

    Vous pouvez transformer certains de vos processus en amont afin qu'ils écrivent les données dans le nouveau schéma. Les vues étant en lecture seule, vous créez les tables sur la base du nouveau schéma, puis modifiez la définition de requête des vues de façade. Certaines vues vont continuer à interroger l'ancien schéma, tandis que d'autres vont interroger les nouvelles tables ou effectuer une opération SQL UNION sur les deux, comme le montre le schéma suivant :

    Les processus en amont alimentent les tables BigQuery, mais ils ne sont plus intégrés dans les processus en aval. Au lieu de cela, les tables BigQuery alimentent les vues de façade, qui à leur tour alimentent les processus évolués en aval.

    À ce stade, vous tirez parti des champs imbriqués et répétés lorsque vous créez les tables. Vous pouvez ainsi dénormaliser davantage votre modèle et profiter directement de la représentation des données en colonnes sous-jacente de BigQuery.

    L'un des avantages des vues de façade réside dans le fait que vos processus en aval peuvent poursuivre leur transformation indépendamment de ces modifications de schéma sous-jacentes et des changements apportés aux processus en amont.

  6. Faites évoluer entièrement votre cas d'utilisation.

    Enfin, vous pouvez transformer les processus en amont et en aval restants. Une fois que tous ces processus ont évolué afin d'écrire les données dans les nouvelles tables et de les lire à partir des nouvelles vues de façade, vous modifiez les définitions de requête des vues de façade afin qu'elles ne lisent plus les données à partir de l'ancien schéma. Vous pouvez alors supprimer les tables de l'ancien modèle du flux de données. Le schéma suivant montre la situation dans laquelle les anciennes tables ne sont plus utilisées.

    Les processus initiaux en amont ne sont plus utilisés. Il ne reste que les processus évolués en amont, qui alimentent les tables évoluées, qui alimentent les vues de façade, qui alimentent tous les processus en aval.

    Si les vues de façade n'agrègent pas les champs ou les colonnes de filtre, vous pouvez configurer vos processus en aval afin qu'ils lisent les données à partir des tables évoluées, puis supprimer les vues de façade afin de réduire la complexité, comme le montre le schéma suivant :

    Dans la configuration finale, les tables BigQuery et les tables évoluées sont intégrées aux vues de façade, qui constituent l'unique source des processus en aval.

Transférer vos données

Cette section traite des aspects pratiques de la migration de vos données depuis un ancien entrepôt de données vers BigQuery.

Transfert de données initial

Plusieurs approches sont adoptables pour le transfert initial des données.

Utiliser le service de transfert de données BigQuery

Le service de transfert de données BigQuery est un produit entièrement géré soutenu par un contrat de niveau de service pour la disponibilité et la diffusion des données. Pour transférer vos données à l'aide du service, procédez comme suit :

  1. Du côté de Google Cloud, vous créez un projet, activez les API requises, puis configurez des autorisations et un ensemble de données de destination.
  2. Dans BigQuery, vous configurez un transfert à l'aide du service de transfert de données BigQuery, en spécifiant l'ensemble de données de destination et d'autres paramètres, puis vous récupérez un nom de ressource qui sert d'identifiant du transfert.
  3. Sur site, vous installez l'agent de migration BigQuery. Vous l'initialisez ensuite à l'aide du nom de la ressource pour que l'agent pointe vers le transfert du service de transfert de données BigQuery que vous venez de configurer.
  4. Vous exécutez l'agent sur site. L'agent communique automatiquement via JDBC avec votre entrepôt de données, extrait le schéma et les données, et les transmet au service de transfert de données BigQuery, qui les écrit ensuite dans l'ensemble de données BigQuery approprié.

Le schéma suivant présente un aperçu du transfert à l'aide du service de transfert de données BigQuery :

L'ancien entrepôt utilise l'agent de migration BigQuery sur site et le service de transfert de données BigQuery du côté Google Cloud pour transférer les données vers BigQuery.

Le service de transfert de données BigQuery peut non seulement extraire, transférer et charger des données, mais il prend également en charge la création des tables nécessaires dans l'ensemble de données de destination BigQuery en mettant en miroir le schéma de la source. Il s'agit d'une fonctionnalité pratique pour un transfert rapide et entièrement automatisé lors des itérations de migration initiales.

Pour obtenir un tutoriel pas à pas sur l'exécution d'un transfert de données à l'aide du service BigQuery, reportez-vous au guide de démarrage rapide sur le transfert de schéma et de données.

Utiliser d'autres outils ETL

Si vous ne pouvez ou ne souhaitez pas installer l'agent de migration sur site, Google Cloud propose plusieurs alternatives pour le transfert de vos données vers BigQuery. Le procédé est le suivant :

  1. Vous extrayez les données de votre source vers un stockage sur site intermédiaire.
  2. Vous utilisez l'outil de votre choix pour transférer les données vers un bucket Cloud Storage de préproduction.
  3. Vous utilisez un outil Google Cloud natif pour charger des données du bucket vers BigQuery.

Le schéma suivant illustre ce flux :

L'entrepôt préexistant copie les données dans un espace de stockage temporaire sur site. Un outil de transfert de données copie les données dans un bucket Cloud Storage. Un outil de transformation de données communique entre le bucket et BigQuery.

En fonction de votre format d'extraction de données et selon que vous souhaitez réduire ou enrichir les données avant de les charger dans BigQuery, une étape de transformation des données peut être nécessaire dans le pipeline. L'étape de transformation peut être exécutée sur site ou sur Google Cloud :

  • Si l'étape de transformation est exécutée sur site, réfléchissez aux limitations potentielles de débit dues aux outils et à la capacité de calcul disponible. De plus, si le processus de transformation enrichit les données, pensez au temps de transfert ou à la bande passante réseau supplémentaire nécessaire.
  • Si l'étape de transformation est exécutée sur Google Cloud, vous pouvez vous appuyer sur un outil géré tel que Dataflow, ou utiliser vos propres outils sur Compute Engine ou Google Kubernetes Engine (GKE). Cependant, si la transformation nécessite l'accès aux ressources sur site, vous devez établir une connectivité hybride afin que ces ressources soient accessibles à partir du VPC Google Cloud.

Dans les sections suivantes, nous partons du principe que les transformations sont effectuées dans Google Cloud.

Extraire les données sources

Votre source comprend probablement un outil pour exporter les données dans un format indépendant du fournisseur, tel que CSV ou Apache AVRO. Si vous choisissez CSV ou un format de données simple et délimité semblable, vous devez également extraire et transférer les définitions de schéma de table. Pour réduire la complexité des transferts, nous vous recommandons d'utiliser AVRO ou des systèmes de sérialisation similaires, dans lesquels le schéma est déjà intégré aux données. Par exemple, dans le cas de Teradata, vous pouvez définir un script d'exportation Parallel Transporter (TPT) afin d'extraire les fichiers Avro ou CSV à partir des tables Teradata.

Dans le cadre de ce processus, vous copiez les fichiers extraits depuis votre source vers un stockage de préproduction dans votre environnement sur site.

Transférer les données

Une fois les données extraites, vous les transférez vers un bucket temporaire dans Cloud Storage. Selon la quantité de données transférées et la bande passante réseau disponible, vous avez le choix parmi les options de transfert suivantes :

  • Si les données extraites résident chez un autre fournisseur cloud, utilisez le service de transfert de stockage.
  • Si les données résident dans un environnement sur site ou dans une installation hébergée en colocation avec une bonne bande passante réseau, utilisez l'outil gsutil. L'outil gsutil accepte les importations parallèles multithreads, il reprend les opérations d'importation en cas d'erreur et chiffre le trafic en transit à des fins de sécurité.

    • Si vous ne pouvez pas utiliser gsutil, vous pouvez essayer un outil tiers proposé par un partenaire de Google.
    • Si votre bande passante réseau est limitée, vous pouvez avoir recours à des techniques de compression pour limiter la taille des données, ou modifier votre connexion actuelle à Google Cloud pour augmenter la bande passante.
  • Si vous ne parvenez pas à obtenir une bande passante réseau suffisante, vous pouvez effectuer un transfert hors connexion à l'aide de Transfer Appliance.

Lorsque vous créez le bucket Cloud Storage et que vous transférez les données via le réseau, minimisez la latence du réseau en choisissant l'emplacement le plus proche de votre centre de données. Si possible, choisissez un emplacement de bucket qui est celui de l'ensemble de données BigQuery.

Pour obtenir des informations détaillées sur les bonnes pratiques lors du déplacement de données vers Cloud Storage, avec une estimation des coûts, consultez la page Stratégies pour transférer des ensembles de données volumineux.

Charger les données dans BigQuery

Vos données se trouvent désormais dans un bucket Cloud Storage, plus près de leur destination. Différentes options permettent d'importer les données dans BigQuery, en fonction du degré de transformation dont elles ont encore besoin. Ces options se répartissent sur deux cas généraux :

  • Premier cas : les données sont prêtes à être ingérées à partir de Cloud Storage.

    Cette situation est fréquente lorsque les données peuvent être extraites de votre source et ne nécessitent pas d'autres transformations. Elle l'est également après des processus ETL complexes, où la transformation a déjà eu lieu avant le transfert des données vers le cloud.

    Dans ces deux scénarios, les bonnes pratiques recommandent la génération des données dans un format autodescriptif comme AVRO, ORC ou Parquet. Dans ce cas, BigQuery accepte directement l'ingestion de vos données. Si vous n'avez pas la possibilité de générer les données dans l'un de ces formats, vous pouvez appliquer un format qui n'est pas autodescriptif, tel que CSV ou JSON. Vous devez alors fournir une définition de schéma ou avoir recours à la détection automatique de schéma BigQuery.

    Pour plus d'informations sur les chargements ponctuels, consultez la section Présentation du chargement de données depuis Cloud Storage dans la documentation BigQuery. Pour plus d'informations sur les chargements planifiés à intervalles réguliers, consultez la section Présentation des transferts Cloud Storage dans la documentation du service de transfert de données BigQuery.

  • Second cas : les données doivent encore être transformées avant leur chargement dans BigQuery. Google et ses partenaires proposent différents outils ETL, tels que les suivants :

    • Cloud Data Fusion. Cet outil établit de manière graphique des pipelines de données ETL/ELT entièrement gérés à l'aide d'une bibliothèque Open Source de transformations et de connecteurs préconfigurés.
    • Dataflow. Cet outil définit et exécute des transformations de données complexes et des graphiques d'enrichissement à l'aide du modèle Apache Beam. Dataflow travaille sans serveur et est entièrement géré par Google, ce qui vous donne accès à une capacité de traitement quasiment illimitée.
    • Dataproc. Cet outil exécute un cluster Apache Spark et Apache Hadoop sur un service cloud entièrement géré.
    • Outils tiers. Contactez l'un de nos partenaires. Il vous proposera des solutions efficaces si vous souhaitez externaliser la création d'un pipeline de données.

Le schéma suivant présente le processus décrit dans cette section. L'outil de transfert de données est gsutil. Une étape de transformation exploite Dataflow et écrit directement les données dans BigQuery, éventuellement à l'aide du connecteur d'E/S Google BigQuery intégré à Apache Beam.

L'entrepôt préexistant copie les données dans un espace de stockage temporaire sur site. L'outil gsutil copie les données dans un bucket Cloud Storage. Dataflow effectue la lecture à partir du bucket de préproduction et déplace les données vers BigQuery.

Après avoir chargé une première salve de données dans BigQuery, vous pouvez commencer à profiter des puissantes fonctionnalités de BigQuery.

Cependant, comme lors du transfert de votre schéma, l'importation de vos données fait partie d'un processus itératif. Les itérations ultérieures peuvent commencer par étendre la portée des données transférées vers BigQuery. Elles peuvent ensuite réacheminer vos flux de données en amont afin que vous n'ayez plus à conserver votre ancien datastore. Ces sujets sont abordés dans la section suivante.

Augmenter l'étendue

Cette section vous indique comment procéder après le transfert initial des données afin d'optimiser votre utilisation de BigQuery.

Une portion de vos données réside maintenant dans BigQuery. Vous êtes passé par les étapes de traduction et d'optimisation de vos requêtes. Vous avez également modifié vos cas d'utilisation en aval afin de générer des rapports et analyses avec les données provenant de BigQuery. Vous vous préparez à présent à augmenter l'étendue des données utilisées dans BigQuery, et à réduire ainsi la dépendance à votre ancien entrepôt de données.

La méthode que vous choisissez pour les itérations ultérieures dépend de l'importance de la mise à jour à la seconde près des données pour votre cas d'utilisation. Si vos analystes de données peuvent travailler avec des données incorporées à l'entrepôt à intervalles réguliers, une option avec planification est à privilégier. Vous pouvez créer des transferts planifiés, à la manière du transfert initial. Vous utilisez le service de transfert de données BigQuery, d'autres outils ETL tels que le service de transfert de stockage de Google ou des implémentations tierces.

Si vous utilisez le service de transfert de données BigQuery, vous devez d'abord déterminer les tables à déplacer. Ensuite, vous créez un modèle de nom de table à inclure dans ces tables. Enfin, vous définissez une échéance récurrente d'exécution du transfert. Pour plus d'informations, consultez la section Configurer une tâche de transfert dans la documentation BigQuery.

En revanche, si votre cas d'utilisation nécessite un accès quasi-instantané aux nouvelles données, vous avez besoin d'une approche de streaming. Deux possibilités s'offrent à vous :

À court terme, l'augmentation de l'étendue de vos données BigQuery et de leur utilisation pour les processus en aval doit se concentrer sur la satisfaction des besoins de vos cas d'utilisation prioritaires. L'objectif à moyen terme est l'abandon de votre ancienne source de données. Par conséquent, utilisez judicieusement les itérations initiales. N'engagez pas de nombreuses ressources dans la perfectionnement des pipelines d'ingestion depuis votre ancien entrepôt de données vers BigQuery : au bout du compte, vous devrez adapter ces pipelines afin qu'ils n'utilisent plus cette source de données.

Transférer votre schéma

Le schéma de l'entrepôt de données définit la structure de vos données et les relations entre les différentes entités de données. Ce schéma est au cœur de la conception de vos données. Il influence de nombreux processus, en amont comme en aval.

Devez-vous planifier la transformation de votre schéma lors du passage au cloud, ou doit-il rester identique ? Les deux options sont possibles dans BigQuery. Si vous souhaitez conserver tel quel un schéma qui a fait ses preuves, nous vous proposons un processus simple et rapide. Nous vous recommandons néanmoins quelques légères optimisations afin que le schéma vous offre des avantages notables en matière de coûts et de performances.

En revanche, si vous décidez de modifier votre schéma afin de profiter pleinement des fonctionnalités de BigQuery, le schéma mis à jour vous offre des opportunités d'optimisation supplémentaires. Nous vous fournissons des instructions afin de réaliser cette transformation en toute fluidité.

Transfert initial du schéma

Comme indiqué dans la présentation du processus de migration, nous vous recommandons de réaliser cette migration par itérations d'étapes. Nous préconisons le transfert du schéma sans y apporter de modification lors des itérations initiales de la migration. Cette méthode présente des avantages :

  • Les pipelines de données qui alimentent votre entrepôt n'ont pas à être adaptés à un nouveau schéma.
  • Vous vous évitez l'ajout d'un nouveau schéma à la liste des supports de formation pour votre personnel.
  • Vous vous appuyez sur des outils automatisés pour effectuer le transfert du schéma et des données.

Par ailleurs, les démonstrations de faisabilité et autre activités d'exploration des données impliquant des fonctions cloud peuvent se poursuivre sans difficulté, même lorsque la migration a lieu en parallèle.

Le service de transfert de données BigQuery est idéal pour automatiser la migration du schéma et des données. Le service de transfert de données BigQuery peut lire des données depuis Teradata, Amazon S3, Google Ads, YouTube et d'autres sources, et les transférer vers BigQuery avec un minimum d'efforts de votre part.

Si vous ne pouvez pas utiliser le service de transfert de données BigQuery, vous pouvez exporter les données dans un format autodescriptif indépendant du fournisseur, tel qu'Apache Avro, puis les importer dans Cloud Storage. BigQuery peut alors importer le schéma et créer les tables requises. Pour plus d'informations sur cette approche, consultez la section Transfert de données initial de cet article.

Optimisations légères

En migrant vos tables telles quelles vers BigQuery, vous pouvez déjà profiter de ses fonctionnalités uniques. Par exemple, vous n'avez pas besoin de recréer les index, de rebrasser les blocs de données (nettoyage), ou de subir un temps d'arrêt ou une dégradation des performances à cause des mises à niveau.

Le maintien d'un modèle d'entrepôt de données intact au-delà des itérations initiales de la migration possède néanmoins des inconvénients :

  • Les problèmes existants et les contraintes techniques associées aux schémas perdurent.
  • Les optimisations de requêtes sont limitées, et peuvent avoir besoin d'être remaniées si le schéma est mis à jour ultérieurement.
  • Vous n'exploitez pas pleinement les autres fonctionnalités de BigQuery, telles que les champs imbriqués et répétés, le partitionnement et le clustering.

Cette section présente deux optimisations possibles pour votre schéma. Elles sont appelées "légères" car elles ne nécessitent aucune modification de la structure de vos tables. Elles doivent toutefois être appliquées à la création des tables.

Partitionnement

BigQuery vous permet de diviser vos données en segments, appelés partitions, qui facilitent la gestion et l'interrogation des données et améliorent l'efficacité de ces opérations. Vous pouvez partitionner vos tables sur la base d'une colonne TIMESTAMP ou DATE. Sinon, BigQuery peut ajouter des pseudo-colonnes afin de partitionner automatiquement vos données lors de l'ingestion. Les requêtes qui impliquent des partitions réduites peuvent être plus performantes, car elles n'analysent qu'un sous-ensemble des données, et peuvent diminuer les coûts en minimisant le nombre d'octets lus.

Le partitionnement n'a pas d'impact sur la structure existante de vos tables. Par conséquent, vous devriez envisager de créer des tables partitionnées même si votre schéma n'est pas modifié. Pour plus d’informations sur les optimisations de requêtes à l'aide du partitionnement, reportez-vous à l'article relatif à l'optimisation des performances de cette série.

Filtrage par cluster

Dans BigQuery, aucun index n'est utilisé pour interroger vos données. Les performances de requête produites par BigQuery sont dues au modèle sous-jacent, aux techniques de stockage et de requête, et à l'architecture massivement parallèle de BigQuery. Lorsque vous exécutez une requête, plus la quantité de données traitées est élevée, plus le nombre de machines ajoutées pour analyser les données et agréger les résultats simultanément est important. Cette technique s'adapte bien à d'immenses ensembles de données, contrairement à la reconstruction d'index.

Vous pouvez toutefois optimiser encore davantage les requêtes grâce à des techniques telles que le clustering. Avec le clustering, BigQuery trie automatiquement vos données en fonction des valeurs de quelques colonnes que vous spécifiez et les rapproche dans des blocs de taille optimale. Les performances des requêtes sont meilleures avec le clustering que sans. Grâce au clustering, BigQuery peut mieux estimer le coût d'exécution de la requête. Avec des colonnes en cluster, les requêtes éliminent également les analyses de données inutiles, et peuvent calculer les agrégations plus rapidement, car les blocs regroupent les enregistrements aux valeurs similaires.

Examinez vos requêtes à la recherche des colonnes fréquemment utilisées pour le filtrage, et créez vos tables en appliquant le clustering sur ces colonnes. Le clustering requiert des tables partitionnées, et il est lui aussi défini au moment de la création des tables. Pour plus d’informations sur les optimisations de requêtes à l'aide du clustering, reportez-vous à l'article relatif à l'optimisation des performances.

Par exemple, dans Teradata, Database Query Logging vous permet d'analyser l'utilisation que font les requêtes des bases de données, des tables, des colonnes, des index, des vues, etc. Les données sont journalisées dans la table DBQLObjTbl.

Dénormalisation

La migration des données est un processus itératif, comme indiqué dans l'introduction et la présentation. Ainsi, une fois que vous avez migré votre schéma initial vers le cloud, effectué de légères optimisations et testé quelques cas d'utilisation clés, il est peut-être temps d'explorer des fonctions supplémentaires qui bénéficient de la conception sous-jacente de BigQuery. Les champs imbriqués et répétés en font partie.

Les schémas d'entrepôt de données utilisent traditionnellement les modèles suivants :

  • Schéma en étoile. Il s'agit d'un modèle dénormalisé, ou une table de faits collecte des métriques telles que le montant d'une commande, la remise et la quantité, ainsi qu'un groupe de clés. Ces clés appartiennent aux tables de dimension (par exemple, client, fournisseur, région, etc.). Graphiquement, le modèle ressemble à une étoile, avec la table de faits au centre entourée de tables de dimension.
  • Schéma en flocon de neige. Il est semblable au schéma en étoile, mais ses tables de dimension sont normalisées, ce qui lui donne l'apparence d'un flocon de neige unique.

BigQuery accepte les schémas en étoile et en flocon de neige, mais sa représentation de schéma native n'est aucune des deux. Il utilise à la place des champs imbriqués et répétés pour une représentation plus naturelle des données. Pour plus d'informations, consultez l'exemple de schéma dans la documentation BigQuery.

La modification de votre schéma afin d'utiliser des champs imbriqués et répétés est un excellent choix d'évolution. Vous réduisez ainsi le nombre de jointures requises pour vos requêtes, et alignez votre schéma avec la représentation interne des données BigQuery. En interne, BigQuery organise les données selon le modèle Dremel et les stocke en colonnes dans un format appelé Capacitor.

Pour déterminer la meilleure approche de dénormalisation pour votre cas, tenez compte des bonnes pratiques de dénormalisation dans BigQuery, ainsi que des techniques de gestion des modifications de schéma.

Étapes suivantes