Cette page a été traduite par l'API Cloud Translation.

Présentation du transfert de schéma et de données

Ce document 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.

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. L'exécution de plusieurs itérations de migration de schéma et de données peut améliorer le résultat.

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 entrepôt de données existant, 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 entrepôt de données existant, 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écouverte de la migration.

Transférer le schéma et les données vers BigQuery

Au cours de la phase 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 :

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 transfert de données initial.
- 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'entrepôt existant, comme indiqué dans les flux avec le libellé A.
Configurez des processus en amont de test pour l'écriture des données sur les tables BigQuery à la place (ou en plus) de l'entrepôt de données existant.

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 Looker Studio et Dataflow.

À ce stade, trois flux de données sont en place :
1. Existant. Les données et les processus ne changent pas et restent centrés sur votre entrepôt de données existant.
2. Déchargé. Les processus en amont alimentent votre entrepôt de données existant, 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'entrepôt de données existant pour l'écriture ou la lecture.
  Le schéma suivant présente un système avec ces trois flux :
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 décrites dans la section Faire évoluer votre schéma dans BigQuery.

Faire évoluer votre schéma dans BigQuery

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.

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.

Transférez un cas d'utilisation tel quel vers BigQuery.

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.
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.
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.
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 du schéma BigQuery source, comme le montre le schéma suivant :

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.
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 le schéma source, 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 :

À ce stade, vous pouvez tirer 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.
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 du schéma source. Vous pouvez alors supprimer les tables du modèle source du flux de données. Le schéma suivant montre la situation dans laquelle les tables source ne sont plus utilisées.

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 :

Effectuer un transfert initial de votre schéma et de vos données

Cette section traite des aspects pratiques de la migration de schéma et de données depuis un entrepôt de données existant vers BigQuery.

Nous vous recommandons de transférer le schéma sans y apporter de modifications lors des itérations initiales de la migration. Vous bénéficiez ainsi des avantages suivants :

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.

Choisir une méthode de transfert

Plusieurs approches sont adoptables pour le transfert initial.

Pour les entrepôts de données Amazon Redshift et Teradata, vous pouvez utiliser le Service de transfert de données BigQuery pour charger le schéma et les données directement depuis votre système existant dans BigQuery. Cloud Storage est toujours utilisé pour organiser les données lors du processus de migration.
Pour tout entrepôt de données, vous pouvez extraire des fichiers contenant votre schéma et vos données, les importer dans Cloud Storage, puis utiliser l'une des options suivantes pour charger le schéma et les données de ces fichiers dans BigQuery :

Pour plus d'informations sur le choix d'une méthode de transfert de données, consultez la section Choisir une méthode d'ingestion de données.

Envisager de transformer les données

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 peut être nécessaire. Vous pouvez transformer les données dans l'environnement existant ou sur Google Cloud:

Si vous transformez les données dans l'environnement actuel, réfléchissez à la façon dont la capacité de calcul et les outils disponibles peuvent limiter le débit. De plus, si vous optimisez les données pendant le processus de transformation, déterminez si vous avez besoin de temps de transfert ou de bande passante réseau supplémentaire.
Si vous transformez les données sur Google Cloud, consultez la section Charger des données à l'aide d'un outil ETL pour plus d'informations sur vos options.

Extraire le schéma existant et les données dans des fichiers

Votre plate-forme existante fournit probablement un outil pour exporter les données dans un format indépendant du fournisseur, tel qu'Apache AVRO ou CSV. Pour réduire la complexité des transferts, nous vous recommandons d'utiliser AVRO, ORC ou Parquet, où les informations de schéma sont intégrées aux données. Si vous choisissez CSV ou un format de données simple et délimité semblable, vous devez spécifier le schéma séparément. La procédure à suivre dépend de la méthode de transfert de données sélectionnée. Par exemple, pour l'importation par lots, vous pouvez spécifier un schéma au moment du chargement ou autoriser la détection automatique du schéma en fonction du contenu du fichier CSV.

Lorsque vous extrayez ces fichiers de votre plate-forme existante, copiez-les dans un espace de stockage de préproduction dans votre environnement existant.

Importer les fichiers dans Cloud Storage

Si vous n'utilisez pas le Service de transfert de données BigQuery pour charger des données directement à partir d'un entrepôt de données Amazon Redshift ou Teradata existant, vous devez importer les fichiers extraits dans un bucket 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 Google Cloud CLI. L'outil gcloud CLI accepte les importations parallèles multithreads, il reprend les opérations après les erreurs et chiffre le trafic en transit à des fins de sécurité.
- Si vous ne pouvez pas utiliser gcloud CLI, 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 le schéma et les données dans BigQuery

Chargez le schéma et les données dans BigQuery à l'aide de l'une des options décrites dans la section Choisir une méthode de transfert.

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.

Charger des données à l'aide d'un outil ETL

Si vos données nécessitent une transformation supplémentaire lors de leur chargement dans BigQuery, utilisez l'une des options suivantes :

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 gcloud CLI. Une étape de transformation exploite Dataflow et écrit directement dans BigQuery, éventuellement à l'aide du Connecteur d'E/S Google BigQuery intégré d'Apache Beam.

L'entrepôt de données existant copie les données dans un espace de stockage temporaire sur site. gcloud CLI 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. Vous pouvez ensuite réacheminer vos flux de données en amont vers BigQuery afin d'éviter de devoir maintenir l'exécution de votre entrepôt de données existant. Ces sujets sont abordés dans la section suivante.

Valider les données

Maintenant que vos données sont dans BigQuery, vous pouvez vérifier que leur transfert a réussi à l'aide de l'outil de validation des données (DVT, Data Validation Tool). DVT est un outil de CLI Python Open Source qui vous permet de comparer des données en provenance de différentes sources avec votre cible dans BigQuery. Vous pouvez spécifier les agrégations que vous souhaitez exécuter (par exemple, décompte, somme, moyenne) et les colonnes auxquelles elles doivent s'appliquer. Pour en savoir plus, consultez la page Automatiser la validation des données avec DVT.

Itérer le transfert initial

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 vous préparez à présent à augmenter l'étendue des données utilisées dans BigQuery, et à réduire ainsi la dépendance à votre entrepôt de données existant.

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.

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 :

Configurez un pipeline de chargement avec les produits Google Cloud. Google fournit un ensemble de modèles Dataflow de streaming pour vous faciliter la tâche.
Utilisez la solution de l'un de nos partenaires.

À 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 entrepôt de données existant. Utilisez les itérations initiales avec discernement et évitez de consacrer beaucoup de ressources à la perfectionnement des pipelines d'ingestion de votre entrepôt de données existant dans BigQuery. À terme, vous devrez adapter ces pipelines afin de ne pas utiliser l'entrepôt de données existant.

Optimiser le schéma

Migrer vos tables telles quelles vers BigQuery vous permet de 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.

Lorsque vous effectuez un transfert final, nous vous recommandons d'améliorer les performances du système en appliquant le partitionnement et le clustering aux tables que vous créez dans votre schéma.

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é.

Clustering

Dans BigQuery, aucun index n'est utilisé pour interroger vos données. Les performances de BigQuery sont optimisées par son modèle sous-jacent, ses techniques de stockage et de requête, ainsi que son architecture massivement parallèle. 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. Pour en savoir plus sur le clustering, consultez la page Présentation des tables en cluster.

Dénormalisation

La migration des données est un processus itératif. 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, envisagez d'utiliser des champs imbriqués et répétés dans BigQuery, ainsi que les techniques de gestion des modifications de schéma.

Étape suivante

Découvrez les étapes suivantes de la migration d'entrepôts de données :

Vous pouvez également en savoir plus sur le passage de technologies d'entrepôt de données spécifiques à BigQuery :