Évaluation de la migration

L'évaluation de la migration BigQuery vous permet de planifier et d'examiner la migration de votre entrepôt de données existant vers BigQuery. Vous pouvez exécuter l'évaluation de la migration BigQuery pour générer un rapport afin d'évaluer le coût de stockage de vos données dans BigQuery, de voir comment BigQuery peut optimiser votre charge de travail existante en vue de réduire les coûts, et de préparer un plan de migration qui décrit le temps et les efforts nécessaires pour terminer la migration de votre entrepôt de données vers BigQuery.

Ce document explique comment utiliser l'évaluation de la migration BigQuery et décrit les différentes manières d'examiner les résultats. Ce document est destiné aux utilisateurs familiarisés avec la console Google Cloud et la traduction SQL par lot.

Présentation

Procédez comme suit pour préparer et exécuter une évaluation de migration BigQuery :

1. Créez un bucket Cloud Storage.

   Remarque : Utilisez l'option --pap pour empêcher les données de votre bucket Cloud Storage d'être accessibles publiquement.

2. Extrayez des métadonnées et des journaux de requêtes de votre entrepôt de données à l'aide de l'outil dwh-migration-dumper.

3. Importez vos métadonnées et vos journaux de requêtes dans votre bucket Cloud Storage.

4. Exécutez l'évaluation de la migration.

5. Consultez le rapport Looker Studio.

6. Facultatif : Interrogez les résultats de l'évaluation pour obtenir des informations détaillées ou spécifiques.

Extraire les métadonnées et interroger les journaux à partir de votre entrepôt de données

Les métadonnées et les journaux de requête sont nécessaires pour préparer l'évaluation à l'aide de recommandations.

Pour extraire les métadonnées et les journaux de requête nécessaires à l'exécution de l'évaluation, sélectionnez votre entrepôt de données :

Teradata

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Teradata, contactez [e-mail].

Conditions requises

• Une machine connectée à votre entrepôt de données Teradata source (la version 15 et les versions ultérieures de Teradata sont compatibles)
• Un compte Google Cloud avec un bucket Cloud Storage pour stocker les données
• Un ensemble de données BigQuery vide pour stocker les résultats
• Des autorisations de lecture sur l'ensemble de données pour afficher les résultats
• Recommandé : droits d'accès de niveau administrateur à la base de données source lors de l'utilisation de l'outil d'extraction pour accéder aux tables système

Condition requise : Activer la journalisation

L'outil dwh-migration-dumper extrait trois types de journaux : les journaux de requêtes, les journaux utilitaires et les journaux d'utilisation des ressources. Afin d'afficher des insights plus approfondis, vous devez activer la journalisation pour les types de journaux suivants :

• Journaux de requête : extraits de la vue dbc.QryLogV et de la table dbc.DBQLSqlTbl. Activez la journalisation en spécifiant l'option WITH SQL.
• Journaux utilitaires : extraits de la table dbc.DBQLUtilityTbl. Activez la journalisation en spécifiant l'option WITH UTILITYINFO.
• Journaux d'utilisation des ressources : extraits des tables dbc.ResUsageScpu et dbc.ResUsageSpma. Activez la journalisation RSS pour ces deux tables.

Exécuter l'outil dwh-migration-dumper

Téléchargez l'outil dwh-migration-dumper.

Téléchargez le fichier SHA256SUMS.txt et exécutez la commande suivante pour vérifier l'exactitude du fichier ZIP :

sha256sum --check SHA256SUMS.txt

Pour en savoir plus sur la configuration et l'utilisation de l'outil d'extraction, consultez la page Générer des métadonnées pour la traduction et l'évaluation.

Utilisez l'outil d'extraction pour extraire les journaux et les métadonnées de votre entrepôt de données Teradata sous la forme de deux fichiers ZIP. Exécutez les commandes suivantes sur une machine ayant accès à l'entrepôt de données source pour générer les fichiers.

Générez le fichier ZIP de métadonnées :

dwh-migration-dumper \
  --connector teradata \
  --database DATABASES \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

Générez le fichier ZIP contenant les journaux de requête :

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

Remplacez les éléments suivants :

• DATABASES : liste de noms de bases de données à extraire, séparés par une virgule
• PATH : chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion
• VERSION : version de votre pilote
• HOST : adresse hôte
• USER : nom d'utilisateur à utiliser pour la connexion à la base de données
• PASSWORD : mot de passe à utiliser pour la connexion à la base de données

  Si ce champ n'est pas renseigné, l'utilisateur est invité à saisir son mot de passe.

Vous ne pouvez utiliser l'option --database que pour le connecteur teradata. Cette option vous permet d'extraire les métadonnées d'une ou plusieurs bases de données. Lorsque vous extrayez les journaux de requête à l'aide du connecteur teradata-logs, l'option --database n'est pas disponible. Les journaux de requête sont toujours extraits pour toutes les bases de données.

Par défaut, les journaux de requête sont extraits de la vue dbc.QryLogV et de la table dbc.DBQLSqlTbl. Si vous devez extraire les journaux de requête d'un autre emplacement, vous pouvez spécifier les noms des tables ou des vues à l'aide des options -Dteradata-logs.query-logs-table et -Dteradata-logs.sql-logs-table.

Conseil : Pour améliorer les performances des tables de jointure spécifiées par les options -Dteradata-logs.query-logs-table et -Dteradata-logs.sql-logs-table, vous pouvez inclure une colonne supplémentaire de type DATE dans la condition JOIN. Cette colonne doit être définie dans les deux tables et faire partie de l'index principal partitionné. Pour l'inclure, utilisez l'option -Dteradata-logs.log-date-column.

Par défaut, les journaux utilitaires sont extraits de la table dbc.DBQLUtilityTbl. Si vous devez extraire les journaux utilitaires d'un autre emplacement, vous pouvez spécifier le nom de la table à l'aide de l'option -Dteradata-logs.utility-logs-table.

Par défaut, les journaux d'utilisation des ressources sont extraits des tables dbc.ResUsageScpu et dbc.ResUsageSpma. Si vous devez extraire les journaux d'utilisation des ressources à partir d'un autre emplacement, vous pouvez spécifier les noms des tables à l'aide des options -Dteradata-logs.res-usage-scpu-table et -Dteradata-logs.res-usage-spma-table.

Par exemple :

Bash

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  -Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV \
  -Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl \
  -Dteradata-logs.log-date-column=ArchiveLogDate \
  -Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs \
  -Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu \
  -Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma

Windows PowerShell

dwh-migration-dumper `
  --connector teradata-logs `
  --driver path\terajdbc4.jar `
  --host HOST `
  --assessment `
  --user USER `
  --password PASSWORD `
  "-Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV" `
  "-Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl" `
  "-Dteradata-logs.log-date-column=ArchiveLogDate" `
  "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs" `
  "-Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu" `
  "-Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma"

Par défaut, l'outil dwh-migration-dumper extrait les sept derniers jours de journaux de requête. Google vous recommande de fournir au moins deux semaines de journaux de requête afin de pouvoir afficher des insights plus approfondis. Vous pouvez spécifier une période personnalisée à l'aide des options --query-log-start et --query-log-end. Exemple :

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-15 00:00:00"

Vous pouvez également générer plusieurs fichiers ZIP contenant des journaux de requête couvrant différentes périodes et tous les fournir à des fins d'évaluation.

Amazon Redshift

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Amazon Redshift, contactez [e-mail].

Conditions requises

• Une machine connectée à votre entrepôt de données Amazon Redshift source
• Un compte Google Cloud avec un bucket Cloud Storage pour stocker les données
• Un ensemble de données BigQuery vide pour stocker les résultats
• Des autorisations de lecture sur l'ensemble de données pour afficher les résultats
• Recommandé : un accès super-utilisateur à la base de données lors de l'utilisation de l'outil d'extraction pour accéder aux tables système

Exécuter l'outil dwh-migration-dumper

Téléchargez l'outil d'extraction en ligne de commande dwh-migration-dumper.

Téléchargez le fichier SHA256SUMS.txt et exécutez la commande suivante pour vérifier l'exactitude du fichier ZIP :

sha256sum --check SHA256SUMS.txt

Pour en savoir plus sur l'utilisation de l'outil dwh-migration-dumper, consultez la page Générer des métadonnées.

Utilisez l'outil dwh-migration-dumper pour extraire les journaux et les métadonnées de votre entrepôt de données Amazon Redshift sous la forme de deux fichiers ZIP. Exécutez les commandes suivantes sur une machine ayant accès à l'entrepôt de données source pour générer les fichiers.

Générez le fichier ZIP de métadonnées :

dwh-migration-dumper \
  --connector redshift \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --password PASSWORD

Générez le fichier ZIP contenant les journaux de requête :

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --password PASSWORD

Remplacez les éléments suivants :

• DATABASE : nom de la base de données à laquelle se connecter
• PATH : chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion
• VERSION : version de votre pilote
• USER : nom d'utilisateur à utiliser pour la connexion à la base de données
• PASSWORD : mot de passe à utiliser pour la connexion à la base de données

  Si ce champ n'est pas renseigné, l'utilisateur est invité à saisir son mot de passe.

Par défaut, Amazon Redshift stocke entre trois et cinq jours de journaux de requête.

Par défaut, l'outil dwh-migration-dumper extrait les sept derniers jours de journaux de requête.

Google vous recommande de fournir au moins deux semaines de journaux de requête afin de pouvoir afficher des insights plus approfondis. Pour obtenir des résultats optimaux, vous devrez peut-être exécuter l'outil d'extraction plusieurs fois sur une période de deux semaines. Vous pouvez spécifier une plage personnalisée à l'aide des options --query-log-start et --query-log-end. Exemple :

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --password PASSWORD \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-02 00:00:00"

Vous pouvez également générer plusieurs fichiers ZIP contenant des journaux de requête couvrant différentes périodes et tous les fournir à des fins d'évaluation.

Apache Hive

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour demander des conseils ou obtenir de l'aide pour cette fonctionnalité, envoyez un e-mail à l'adresse [e-mail].

Conditions requises

• Une machine connectée à votre entrepôt de données Apache Hive source (l'évaluation de la migration BigQuery est compatible avec Hive sur Tez et MapReduce, et avec les versions 2.2 à 3.1 incluses d'Apache Hive)
• Un compte Google Cloud avec un bucket Cloud Storage pour stocker les données
• Un ensemble de données BigQuery vide pour stocker les résultats
• Des autorisations de lecture sur l'ensemble de données pour afficher les résultats
• L'accès à votre entrepôt de données source Apache Hive afin de configurer l'extraction des journaux de requêtes
• Statistiques à jour sur les tables, les partitions et les colonnes

L'évaluation de la migration BigQuery utilise des tables, des partitions et des statistiques de colonne pour mieux comprendre votre entrepôt de données Apache Hive et fournir des insights précis. Si le paramètre de configuration hive.stats.autogather est défini sur false dans votre entrepôt de données source Apache Hive, Google recommande de l'activer ou de mettre à jour les statistiques manuellement avant d'exécuter l'outil dwh-migration-dumper.

Exécuter l'outil dwh-migration-dumper

Téléchargez l'outil d'extraction en ligne de commande dwh-migration-dumper.

Téléchargez le fichier SHA256SUMS.txt et exécutez la commande suivante pour vérifier l'exactitude du fichier ZIP :

sha256sum --check SHA256SUMS.txt

Pour en savoir plus sur l'utilisation de l'outil dwh-migration-dumper, consultez la section Générer des métadonnées pour la traduction et l'évaluation.

Utilisez l'outil dwh-migration-dumper pour générer des métadonnées à partir de votre entrepôt de données Hive sous forme de fichier ZIP.

Sans authentification

Pour générer le fichier ZIP de métadonnées, exécutez la commande suivante sur une machine ayant accès à l'entrepôt de données source :

dwh-migration-dumper \
  --connector hiveql \
  --database DATABASES \
  --host hive.cluster.host \
  --port 9083 \
  --assessment

Avec authentification Kerberos

Pour vous authentifier auprès du métastore, connectez-vous en tant qu'utilisateur ayant accès au métastore Hive et générez un ticket Kerberos. Ensuite, générez le fichier ZIP de métadonnées à l'aide de la commande suivante :

JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" \
  dwh-migration-dumper \
  --connector hiveql \
  --database DATABASES \
  --host hive.cluster.host \
  --port 9083 \
  --hive-kerberos-url PRINCIPAL/HOST \
  -Dhiveql.rpc.protection=hadoop.rpc.protection \
  --assessment

Remplacez les éléments suivants :

• DATABASES : liste de noms de bases de données à extraire, séparés par une virgule. Si ce paramètre n'est pas spécifié, toutes les bases de données sont extraites.
• PRINCIPAL : compte principal kerberos pour lequel le ticket est émis
• HOST : nom d'hôte kerberos pour lequel le ticket est émis
• hadoop.rpc.protection : qualité de protection (QOP) du niveau de configuration SASL (Simple Authentication and Security Layer), égale à la valeur du paramètre hadoop.rpc.protection dans le fichier /etc/hadoop/conf/core-site.xml, avec l'une des valeurs suivantes :
  • authentication
  • integrity
  • privacy

Extraire les journaux de requêtes avec le hook de journalisation hadoop-migration-assessment

Procédez comme suit pour extraire les journaux de requêtes :

1. Importez le hook de journalisation hadoop-migration-assessment.
2. Configurez les propriétés du hook de journalisation.
3. Vérifiez le hook de journalisation.

Importer le hook de journalisation hadoop-migration-assessment

1. Téléchargez le hook de journalisation d'extraction des journaux de requête hadoop-migration-assessment, qui contient le fichier JAR du hook de journalisation Hive.

2. Extrayez le fichier JAR.

   Si vous devez procéder à un audit de l'outil afin de vous assurer qu'il répond aux exigences de conformité, examinez le code source à partir du dépôt GitHub de hook de journalisation hadoop-migration-assessment, puis compilez votre propre binaire.

3. Copiez le fichier JAR dans le dossier de la bibliothèque auxiliaire, sur tous les clusters dans lesquels vous prévoyez d'activer la journalisation des requêtes. Selon votre fournisseur, vous devrez localiser le dossier de la bibliothèque auxiliaire dans les paramètres du cluster et transférer le fichier JAR vers le dossier de la bibliothèque auxiliaire sur le cluster Hive.

4. Définissez les propriétés de configuration du hook de journalisation hadoop-migration-assessment. Selon votre fournisseur Hadoop, vous devrez utiliser la console de l'interface utilisateur pour modifier les paramètres du cluster. Modifiez le fichier /etc/hive/conf/hive-site.xml ou appliquez la configuration à l'aide du gestionnaire de configuration.

Configurer les propriétés

Si vous disposez déjà d'autres valeurs pour les clés de configuration suivantes, ajoutez les paramètres à l'aide d'une virgule (,). Pour configurer le hook de journalisation hadoop-migration-assessment, les paramètres de configuration suivants sont requis :

• hive.exec.failure.hooks : com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.exec.post.hooks : com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.exec.pre.hooks : com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.aux.jars.path : incluez le chemin d'accès au fichier JAR du hook de journalisation, par exemple file:///HiveMigrationAssessmentQueryLogsHooks_deploy.jar.
• dwhassessment.hook.base-directory : chemin d'accès au dossier de sortie des journaux de requêtes. Par exemple, hdfs://tmp/logs/.

• Vous pouvez également définir les configurations facultatives suivantes :

  • dwhassessment.hook.queue.capacity : capacité de la file d'attente pour les threads de journalisation des événements de requête. La valeur par défaut est 64.
  • dwhassessment.hook.rollover-interval : fréquence à laquelle le roulement de fichiers doit être effectué. Par exemple, 600s. La valeur par défaut est de 3 600 secondes (une heure).
  • dwhassessment.hook.rollover-eligibility-check-interval : fréquence à laquelle la vérification de l'éligibilité au roulement de fichiers est déclenchée en arrière-plan. Par exemple, 600s. La valeur par défaut est de 600 secondes (10 minutes).

Important : Pour appliquer les modifications de configuration, vous devez redémarrer les services Hive.

Vérifier le hook de journalisation

Après avoir redémarré le processus hive-server2, exécutez une requête de test et analysez vos journaux de débogage. Le message suivant s'affiche :

Logger successfully started, waiting for query events. Log directory is '[dwhassessment.hook.base-directory value]'; rollover interval is '60' minutes;
rollover eligibility check is '10' minutes

Le hook de journalisation crée un sous-dossier partitionné par date dans le dossier configuré. Le fichier Avro contenant les événements de requête apparaît dans ce dossier à l'issue de l'intervalle dwhassessment.hook.rollover-interval ou après l'arrêt du processus hive-server2. Vous pouvez rechercher des messages similaires dans vos journaux de débogage pour voir l'état de l'opération de roulement :

Updated rollover time for logger ID 'my_logger_id' to '2023-12-25T10:15:30'

Performed rollover check for logger ID 'my_logger_id'. Expected rollover time
is '2023-12-25T10:15:30'

Le roulement s'effectue aux intervalles spécifiés ou lors du passage d'un jour au suivant. Lorsque la date change, le hook de journalisation crée également un sous-dossier pour cette date.

Google vous recommande de fournir au moins deux semaines de journaux de requête afin de pouvoir afficher des insights plus approfondis.

Vous pouvez également générer des dossiers contenant les journaux de requêtes de différents clusters Hive et fournir l'ensemble de ces journaux pour une seule évaluation.

Snowflake

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Snowflake, contactez [e-mail].

Conditions requises

Vous devez répondre aux exigences suivantes pour extraire les métadonnées et les journaux de requête de Snowflake :

• Une machine pouvant se connecter à vos instances Snowflake.
• Un compte Google Cloud avec un bucket Cloud Storage pour stocker les données.
• Un ensemble de données BigQuery vide pour stocker les résultats. Vous pouvez également créer un ensemble de données BigQuery lorsque vous créez le job d'évaluation à l'aide de l'interface utilisateur de la console Google Cloud.
• Accès au rôle ACCOUNTADMIN sur votre instance Snowflake, ou rôle disposant de droits IMPORTED PRIVILEGES sur la base de données Snowflake accordé par un administrateur de compte.

Exécuter l'outil dwh-migration-dumper

Téléchargez l'outil d'extraction en ligne de commande dwh-migration-dumper.

Téléchargez le fichier SHA256SUMS.txt et exécutez la commande suivante pour vérifier l'exactitude du fichier ZIP :

sha256sum --check SHA256SUMS.txt

Pour en savoir plus sur l'utilisation de l'outil dwh-migration-dumper, consultez la page Générer des métadonnées.

L'outil dwh-migration-dumper vous permet d'extraire les journaux et les métadonnées de votre entrepôt de données Snowflake sous la forme de deux fichiers ZIP. Exécutez les commandes suivantes sur une machine ayant accès à l'entrepôt de données source pour générer les fichiers.

Générez le fichier ZIP de métadonnées :

dwh-migration-dumper \
  --connector snowflake \
  --host HOST_NAME \
  --database SNOWFLAKE \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --assessment \
  --password PASSWORD

Générez le fichier ZIP contenant les journaux de requête :

dwh-migration-dumper \
  --connector snowflake-logs \
  --host HOST_NAME \
  --database SNOWFLAKE \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --query-log-start STARTING_DATE \
  --query-log-end ENDING_DATE \
  --assessment \
  --password PASSWORD

Remplacez les éléments suivants :

• HOST_NAME : nom d'hôte de votre instance Snowflake.
• USER_NAME : nom d'utilisateur à utiliser pour la connexion à la base de données, où l'utilisateur doit disposer des autorisations d'accès décrites dans la section Conditions requises.
• ROLE_NAME : (facultatif) rôle utilisateur lors de l'exécution de l'outil dwh-migration-dumper (par exemple, ACCOUNTADMIN).
• WAREHOUSE : entrepôt utilisé pour exécuter les opérations de vidage. Si vous disposez de plusieurs entrepôts virtuels, vous pouvez spécifier n'importe lequel pour exécuter cette requête. L'exécution de cette requête avec les autorisations d'accès détaillées dans la section Conditions requises extrait les artefacts de tous les entrepôts de ce compte.
• STARTING_DATE : (facultatif) permet d'indiquer la date de début dans une plage de dates des journaux de requête, au format YYYY-MM-DD.
• ENDING_DATE : (facultatif) permet d'indiquer la date de fin dans une plage de dates des journaux de requête, au format YYYY-MM-DD.

Vous pouvez également générer plusieurs fichiers ZIP contenant des journaux de requête couvrant des périodes qui ne se chevauchent pas et tous les fournir à des fins d'évaluation.

Importer des métadonnées et des journaux de requête dans Cloud Storage

Une fois que vous avez extrait les métadonnées et les journaux de requête de votre entrepôt de données, vous pouvez importer les fichiers dans un bucket Cloud Storage pour procéder à l'évaluation de la migration.

Teradata

Remarque : Pour toute question concernant l'évaluation de la migration BigQuery pour Teradata, contactez [e-mail].

Importez les métadonnées et un ou plusieurs fichiers ZIP contenant les journaux de requête dans votre bucket Cloud Storage. Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers. La taille totale non compressée de l'ensemble des fichiers présents dans le fichier ZIP de métadonnées est limitée à 50 Go.

Les entrées de tous les fichiers ZIP contenant les journaux de requête sont divisées comme suit :

• Les fichiers d'historique des requêtes portent le préfixe query_history_.
• Les fichiers de séries temporelles portent les préfixes utility_logs_, dbc.ResUsageScpu_ et dbc.ResUsageSpma_.

La taille totale non compressée de l'ensemble des fichiers d'historique des requêtes est limitée à 5 To. La taille totale non compressée de l'ensemble des fichiers de séries temporelles est limitée à 1 To.

Si les journaux de requête sont archivés dans une autre base de données, consultez la description des options -Dteradata-logs.query-logs-table et -Dteradata-logs.sql-logs-table plus haut dans cette section, qui explique comment fournir un autre emplacement pour les journaux de requêtes.

Amazon Redshift

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Amazon Redshift, contactez [e-mail].

Importez les métadonnées et un ou plusieurs fichiers ZIP contenant les journaux de requêtes dans votre bucket Cloud Storage. Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers. La taille totale non compressée de l'ensemble des fichiers présents dans le fichier ZIP de métadonnées est limitée à 50 Go.

Les entrées de tous les fichiers ZIP contenant les journaux de requête sont divisées comme suit :

• Les fichiers d'historique des requêtes portent les préfixes querytext_ et ddltext_.
• Les fichiers de séries temporelles portent les préfixes query_queue_info_, wlm_query_ et querymetrics_.

La taille totale non compressée de l'ensemble des fichiers d'historique des requêtes est limitée à 5 To. La taille totale non compressée de l'ensemble des fichiers de séries temporelles est limitée à 1 To.

Apache Hive

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour demander des conseils ou obtenir de l'aide pour cette fonctionnalité, envoyez un e-mail à l'adresse [e-mail].

Importez les métadonnées et les dossiers contenant les journaux de requêtes d'un ou de plusieurs clusters Hive dans votre bucket Cloud Storage. Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers.

La taille totale non compressée de l'ensemble des fichiers présents dans le fichier ZIP de métadonnées est limitée à 50 Go.

Vous pouvez utiliser le connecteur Cloud Storage pour copier les journaux de requêtes directement dans le dossier Cloud Storage. Les dossiers contenant des sous-dossiers avec des journaux de requêtes doivent être importés dans le même dossier Cloud Storage que celui dans lequel est importé le fichier ZIP de métadonnées.

Les dossiers de journaux de requêtes contiennent des fichiers d'historique des requêtes comportant le préfixe dwhassessment_. La taille totale non compressée de l'ensemble des fichiers d'historique des requêtes est limitée à 5 To.

Snowflake

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Snowflake, contactez [e-mail].

Importez les métadonnées, les fichiers ZIP contenant les journaux de requête et les historiques d'utilisation dans votre bucket Cloud Storage. Lorsque vous importez ces fichiers dans Cloud Storage, les conditions suivantes doivent être remplies :

• La taille totale non compressée de tous les fichiers dans le fichier ZIP de métadonnées doit être inférieure à 50 Go.
• Le fichier ZIP des métadonnées et le fichier ZIP contenant les journaux de requête doivent être importés dans un dossier Cloud Storage. Si plusieurs fichiers ZIP contiennent des journaux de requête qui ne se chevauchent pas, vous pouvez tous les importer.
• Vous devez importer tous les fichiers dans le même dossier Cloud Storage.
• Vous devez importer tous les fichiers ZIP des journaux de métadonnées et de requêtes exactement tels qu'ils sont générés par l'outil dwh-migration-dumper. Vous ne devez pas les décompresser, les combiner ni les modifier.
• La taille totale non compressée de tous les fichiers de l'historique des requêtes doit être inférieure à 5 To.

Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers.

Exécuter une évaluation de migration BigQuery

Suivez la procédure ci-dessous pour exécuter l'évaluation de la migration BigQuery. Ces étapes supposent que vous avez importé les fichiers de métadonnées dans un bucket Cloud Storage, comme décrit dans la section précédente.

Autorisations requises

Pour activer le service de migration BigQuery, vous devez disposer des autorisations Identity and Access Management (IAM) suivantes :

• resourcemanager.projects.get
• resourcemanager.projects.update
• serviceusage.services.enable
• serviceusage.services.get

Pour accéder au service de migration BigQuery et l'utiliser, vous devez disposer des autorisations suivantes sur le projet :

• bigquerymigration.workflows.create
• bigquerymigration.workflows.get
• bigquerymigration.workflows.list
• bigquerymigration.workflows.delete
• bigquerymigration.subtasks.get
• bigquerymigration.subtasks.list

Remarque : Vous ne pouvez définir les autorisations et les rôles comportant le préfixe bigquerymigration.* qu'à l'aide de la CLI Google Cloud. Pour en savoir plus sur la configuration et l'utilisation de la CLI Google Cloud, consultez la présentation de gcloud CLI.

Pour exécuter le service de migration BigQuery, vous devez disposer des autorisations supplémentaires suivantes.

• Autorisation d'accéder aux buckets Cloud Storage pour les fichiers d'entrée et de sortie :

  • storage.objects.get sur le bucket Cloud Storage source
  • storage.objects.list sur le bucket Cloud Storage source
  • storage.objects.create sur le bucket Cloud Storage de destination
  • storage.objects.delete sur le bucket Cloud Storage de destination
  • storage.objects.update sur le bucket Cloud Storage de destination
  • storage.buckets.get
  • storage.buckets.list

• Autorisation de lire et de mettre à jour l'ensemble de données BigQuery dans lequel le service de migration BigQuery écrit les résultats :

  • bigquery.datasets.update
  • bigquery.datasets.get
  • bigquery.datasets.create
  • bigquery.datasets.delete
  • bigquery.jobs.create
  • bigquery.jobs.delete
  • bigquery.jobs.list
  • bigquery.jobs.update
  • bigquery.tables.create
  • bigquery.tables.get
  • bigquery.tables.getData
  • bigquery.tables.list
  • bigquery.tables.updateData

Pour partager le rapport Looker Studio avec un utilisateur, vous devez attribuer les rôles suivants :

• roles/bigquery.dataViewer
• roles/bigquery.jobUser

Pour personnaliser ce document afin d'utiliser votre propre projet et votre propre utilisateur dans les commandes, modifiez les variables suivantes : PROJECT, USER_EMAIL.

Créez un rôle personnalisé avec les autorisations nécessaires pour utiliser l'évaluation de la migration BigQuery :

gcloud iam roles create BQMSrole \
  --project=PROJECT \
  --title=BQMSrole \
  --permissions=bigquerymigration.subtasks.get,bigquerymigration.subtasks.list,bigquerymigration.workflows.create,bigquerymigration.workflows.get,bigquerymigration.workflows.list,bigquerymigration.workflows.delete,resourcemanager.projects.update,resourcemanager.projects.get,serviceusage.services.enable,serviceusage.services.get,storage.objects.get,storage.objects.list,storage.objects.create,storage.objects.delete,storage.objects.update,bigquery.datasets.get,bigquery.datasets.update,bigquery.datasets.create,bigquery.datasets.delete,bigquery.tables.get,bigquery.tables.create,bigquery.tables.updateData,bigquery.tables.getData,bigquery.tables.list,bigquery.jobs.create,bigquery.jobs.update,bigquery.jobs.list,bigquery.jobs.delete,storage.buckets.list,storage.buckets.get

Attribuez le rôle personnalisé BQMSrole à un utilisateur :

gcloud projects add-iam-policy-binding \
  PROJECT \
  --member=user:USER_EMAIL \
  --role=projects/PROJECT/roles/BQMSrole

Attribuez les rôles requis à un utilisateur avec lequel vous souhaitez partager le rapport :

gcloud projects add-iam-policy-binding \
  PROJECT \
  --member=user:USER_EMAIL \
  --role=roles/bigquery.dataViewer

gcloud projects add-iam-policy-binding \
  PROJECT \
  --member=user:USER_EMAIL \
  --role=roles/bigquery.jobUser

Pays acceptés

La fonctionnalité d'évaluation de la migration BigQuery est compatible avec deux types d'emplacements :

• Une région est un emplacement géographique spécifique, par exemple Londres.

• Un emplacement multirégional correspond à un secteur géographique de grande étendue, par exemple les États-Unis, et comporte au moins deux régions. Les emplacements multirégionaux peuvent fournir des quotas plus élevés que les régions uniques.

Pour en savoir plus sur les régions et les zones, consultez la section Zones géographiques et régions.

Régions

Le tableau suivant répertorie les régions Amériques où l'évaluation de la migration BigQuery est disponible.

Description de la région	Nom de la région	Détails
Columbus, Ohio	us-east5
Dallas	us-south1
Iowa	us-central1	Faibles émissions de CO2
Caroline du Sud	us-east1
Virginie du Nord	us-east4
Oregon	us-west1	Faibles émissions de CO2
Los Angeles	us-west2
Salt Lake City	us-west3

Le tableau suivant répertorie les régions en Asie-Pacifique où l'évaluation de la migration BigQuery est disponible.

Description de la région	Nom de la région	Détails
Singapour	asia-southeast1
Tokyo	asia-northeast1

Le tableau suivant répertorie les régions en Europe où l'évaluation de la migration BigQuery est disponible.

Description de la région	Nom de la région	Détails
Belgique	europe-west1	Faibles émissions de CO2
Finlande	europe-north1	Faibles émissions de CO2
Francfort	europe-west3	Faibles émissions de CO2
Londres	europe-west2	Faibles émissions de CO2
Madrid	europe-southwest1
Pays-Bas	europe-west4
Paris	europe-west9	Faibles émissions de CO2
Turin	europe-west12
Varsovie	europe-central2
Zurich	europe-west6	Faibles émissions de CO2

Remarque : Les opérations d'API ne sont compatibles que dans les régions asia-southeast1 (Singapour) et europe-west2 (Londres) et dans les multirégions US et EU. Tous les autres emplacements ne sont disponibles que dans la console.

Emplacements multirégionaux

Le tableau suivant répertorie les emplacements multirégionaux où l'évaluation de la migration BigQuery est disponible.

Description de la zone multirégionale	Nom de la zone multirégionale
Centres de données dans les États membres de l'Union européenne.	EU
Centres de données aux États-Unis	US

Avant de commencer

Avant d'exécuter l'évaluation, vous devez activer l'API BigQuery Migration et créer un ensemble de données BigQuery pour stocker les résultats.

Activer l'API BigQuery Migration

Activez l'API BigQuery Migration comme suit :

1. Dans la console Google Cloud, accédez à la page API BigQuery Migration.

   Accéder à l'API BigQuery Migration

2. Cliquez sur Activer.

Créer un ensemble de données pour les résultats de l'évaluation

L'évaluation de la migration BigQuery écrit les résultats dans des tables dans BigQuery. Avant de commencer, créez un ensemble de données pour stocker ces tables. Lorsque vous partagez le rapport Looker Studio, vous devez également autoriser les utilisateurs à lire cet ensemble de données. Pour en savoir plus, consultez la section Rendre le rapport accessible aux utilisateurs.

Remarque : L'ensemble de données doit se trouver dans la même région que le bucket Cloud Storage contenant les métadonnées et les fichiers journaux extraits de la base de données source.

Exécuter l'évaluation de la migration

Console

1. Dans la console Google Cloud, accédez à la page BigQuery.

   Accéder à BigQuery

2. Dans le panneau de navigation, accédez à Évaluation.

3. Cliquez sur Démarrer l'évaluation.

4. Renseignez la boîte de dialogue de configuration de l'évaluation.

   1. Dans le champ Nom à afficher, saisissez le nom, qui peut contenir des lettres, des chiffres ou des traits de soulignement. Ce nom n'est utilisé qu'à des fins d'affichage et ne doit pas nécessairement être unique.
   2. Dans la liste Emplacement des données, choisissez un emplacement pour la tâche d'évaluation. Pour une exécution plus efficace, cet emplacement et les emplacements du bucket d'entrée et du bucket de sortie des fichiers extraits doivent être identiques.
   3. Dans le champ Source de données d'évaluation, choisissez votre entrepôt de données.
   4. Dans le champ Chemin d'accès aux fichiers d'entrée, saisissez le chemin d'accès au bucket Cloud Storage contenant vos fichiers extraits.
   5. Dans le champ Ensemble de données, identifiez l'ensemble de données BigQuery contenant les résultats de l'évaluation, au format projectId.datasetId.

   

5. Cliquez sur Créer. Vous pouvez voir l'état de la tâche dans la liste des tâches de traduction.

6. Une fois l'évaluation terminée, cliquez sur Créer un rapport pour afficher le rapport d'évaluation dans Looker Studio. Le rapport s'ouvre dans un nouvel onglet.

API

Appelez la méthode create avec un workflow défini.

Appelez ensuite la méthode start pour démarrer le workflow d'évaluation.

L'évaluation crée des tables dans l'ensemble de données BigQuery que vous avez créé précédemment. Vous pouvez les interroger pour obtenir des informations sur les tables et les requêtes utilisées dans votre entrepôt de données. Pour en savoir plus sur les fichiers de sortie de la traduction, consultez la page Traduction SQL par lot.

Examiner et partager le rapport Looker Studio

Une fois la tâche d'évaluation terminée, vous pouvez créer et partager un rapport Looker Studio sur les résultats.

Consulter le rapport

Cliquez sur le lien Créer le rapport situé à côté de votre tâche d'évaluation individuelle. Le rapport Looker Studio s'ouvre dans un nouvel onglet, en mode aperçu. Vous pouvez utiliser le mode aperçu pour examiner le contenu du rapport avant de le partager.

Le rapport ressemble à la capture d'écran suivante :

Pour afficher les vues contenues dans le rapport, sélectionnez votre entrepôt de données :

Teradata

Le rapport est constitué de trois parties précédées d'une page récapitulative. Cette page comprend les sections suivantes :

• Système existant. Cette section est un instantané du système Teradata et de son utilisation, y compris le nombre de bases de données, de schémas et de tables, et la taille totale (en To). Il répertorie également les schémas par taille et pointe vers une utilisation potentiellement sous-optimale des ressources (tables sans écriture ou peu de lectures).
• Transformations vers l'état stable de BigQuery (suggestions). Cette section montre à quoi ressemblera le système sur BigQuery après la migration. Il inclut des suggestions pour optimiser les charges de travail sur BigQuery (et éviter les gaspillages).
• Plan de migration. Cette section fournit des informations sur les efforts de migration proprement dits, par exemple comment passer du système existant à l'état stable de BigQuery. Cette section inclut le nombre de requêtes traduites automatiquement, ainsi que le temps nécessaire pour déplacer chaque table vers BigQuery.

Les détails de chaque section incluent les éléments suivants :

Système existant

• Calculs et requêtes
  • Utilisation du processeur :
    • Carte de densité de l'utilisation horaire moyenne du processeur (vue globale de l'utilisation des ressources système)
    • Requêtes par heure et par jour avec utilisation du processeur
    • Requêtes par type (lecture/écriture) avec utilisation du processeur
    • Applications avec utilisation du processeur
    • Superposition de l'utilisation horaire du processeur avec les performances horaires moyennes des requêtes et les performances horaires moyennes des applications
  • Histogramme des requêtes par type et par durée des requêtes
  • Vue des détails des applications (application, utilisateur, requêtes uniques, création de rapports ou la répartition ETL)
• Vue d'ensemble du stockage
  • Bases de données par volume, par vues et par taux d'accès
  • Tables avec leurs taux d'accès par utilisateur, par requêtes, par écritures et par créations de tables temporaires
• Applications : taux d'accès et adresses IP

Transformations vers l'état stable de BigQuery (suggestions)

• Index de jointure convertis en vues matérialisées
• Candidats à la mise en cluster et au partitionnement en fonction de métadonnées et de l'utilisation
• Requêtes à faible latence identifiées comme candidates pour BigQuery BI Engine
• Colonnes configurées avec des valeurs par défaut qui utilisent la fonctionnalité de description de colonne pour stocker les valeurs par défaut
• Les index uniques de Teradata (pour éviter d'avoir des lignes contenant des clés non uniques dans une table) utilisent des tables de préproduction et une instruction MERGE pour insérer uniquement des enregistrements uniques dans les tables cibles et supprimer les doublons
• Les requêtes restantes et le schéma, traduits tels quels

Plan de migration

• Vue détaillée avec les requêtes traduites automatiquement
  • Nombre total de requêtes avec possibilité de filtrer par utilisateur, application, tables concernées, tables interrogées et type de requête
  • Buckets de requêtes ayant des modèles similaires regroupés et affichés ensemble afin que l'utilisateur puisse voir la philosophie de traduction par type de requête
• Requêtes nécessitant une intervention humaine
  • Requêtes présentant des cas de non-respect de la structure lexicale de BigQuery
  • Fonctions et procédures définies par l'utilisateur
  • Mots clés réservés de BigQuery
• Programmations de tables par écritures et lectures (afin de les regrouper pour le déplacement)
• Migration de données avec le service de transfert de données BigQuery : durée estimée de la migration par table

La section Système existant contient les vues suivantes :

Présentation du système

La vue "Présentation du système" fournit les métriques de volume de haut niveau des composants clés du système existant pour une période spécifiée. La chronologie évaluée dépend des journaux analysés par l'évaluation de la migration BigQuery. Cette vue offre un aperçu rapide de l'utilisation de l'entrepôt de données source, que vous pouvez utiliser pour planifier la migration.

Volume des tables

La vue "Volume des tables" fournit des statistiques sur les plus grandes tables et bases de données trouvées lors de l'évaluation de la migration BigQuery. Étant donné que l'extraction de grandes tables depuis le système d'entrepôt de données source peut prendre plus de temps, cette vue peut être utile pour la planification et le séquençage de la migration.

Utilisation des tables

La vue "Utilisation des tables" fournit des statistiques sur les tables les plus utilisées dans l'entrepôt de données source. Les tables très utilisées peuvent vous aider à comprendre quelles tables peuvent présenter de nombreuses dépendances et nécessiter une planification supplémentaire pendant le processus de migration.

Applications

Les vues "Utilisation des applications" et "Modèles d'applications" fournissent des statistiques sur les applications trouvées lors du traitement des journaux. Ces vues permettent aux utilisateurs de comprendre l'utilisation d'applications spécifiques au fil du temps, ainsi que l'impact sur l'utilisation des ressources. Au cours d'une migration, il est important de visualiser l'ingestion et la consommation des données pour mieux comprendre les dépendances de l'entrepôt de données et pour analyser l'impact du déplacement conjoint de diverses applications dépendantes. La table d'adresses IP peut être utile pour identifier l'application exacte utilisant l'entrepôt de données via des connexions JDBC.

Requêtes

La vue "Requêtes" fournit une répartition des types d'instructions SQL exécutés et des statistiques concernant leur utilisation. Vous pouvez utiliser l'histogramme de Type et Durée de Requête pour identifier les périodes où le système est peu utilisé et les heures optimales de transfert des données. Vous pouvez également utiliser cette vue pour identifier les requêtes fréquemment exécutées et les utilisateurs qui appellent ces exécutions.

Bases de données

La vue "Bases de données" fournit des métriques sur la taille, les tables, les vues et les procédures définies dans le système d'entrepôt de données source. Cette vue offre un aperçu du volume des objets que vous devez migrer.

Couplage des bases de données

La vue "Couplage des bases de données" fournit une vue d'ensemble des bases de données et des tables faisant l'objet d'accès conjoints dans une même requête. Cette vue peut indiquer quelles tables et bases de données sont fréquemment référencées et ce que vous pouvez utiliser pour la planification de la migration.

La section État stable de BigQuery contient les vues suivantes :

Tables ne présentant aucune utilisation

La vue "Tables ne présentant aucune utilisation" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune utilisation au cours de la période de journaux analysée. Une absence d'utilisation peut indiquer que vous n'avez pas besoin de transférer cette table vers BigQuery pendant la migration ou que les coûts de stockage les données dans BigQuery peuvent être inférieurs. Vous devez valider la liste des tables inutilisées, car elles pourraient être utilisées en dehors de la période couverte par les journaux, par exemple une table utilisée une seule fois par trimestre ou moins.

Tables ne présentant pas d'écritures

La vue "Tables ne présentant pas d'écritures" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune mise à jour au cours de la période de journaux analysée. Une absence d'écritures peut suggérer une opportunité de réduire les coûts de stockage dans BigQuery.

Requêtes à faible latence

La vue "Requêtes à faible latence" affiche une distribution des environnements d'exécution de requête en fonction des données de journal analysées. Si le graphique de distribution de la durée des requêtes affiche un grand nombre de requêtes avec un temps d'exécution inférieur à une seconde, envisagez d'autoriser BigQuery BI Engine à accélérer l'informatique décisionnelle et d'autres charges de travail à faible latence.

Vues matérialisées

La vue matérialisée fournit des suggestions d'optimisation supplémentaires pour améliorer les performances sur BigQuery.

Clustering et partitionnement

La vue "Clustering et partitionnement" affiche les tables qui pourraient bénéficier du clustering, du partitionnement ou des deux.

Les suggestions de métadonnées sont obtenues en analysant le schéma de l'entrepôt de données source (comme le partitionnement et la clé primaire dans la table source) et en recherchant l'équivalent BigQuery le plus proche pour obtenir des caractéristiques d'optimisation similaires.

Les suggestions de charges de travail sont obtenues en analysant les journaux des requêtes sources. La recommandation est déterminée en analysant les charges de travail, en particulier les clauses WHERE ou JOIN dans les journaux de requêtes analysés.

Recommandation de clustering

La vue "Partitionnement" affiche les tables pouvant avoir plus de 4 000 partitions, en fonction de leur définition de contraintes de partitionnement. Ces tables sont généralement adaptées au clustering BigQuery, ce qui permet des partitions de tables précises.

Contraintes uniques

La vue "Contraintes uniques" affiche à la fois les tables SET et les index uniques définis dans l'entrepôt de données source. Dans BigQuery, il est recommandé d'utiliser des tables de préproduction et une instruction MERGE pour insérer uniquement des enregistrements uniques dans une table cible. Utilisez le contenu de cette vue pour déterminer les tables dont vous aurez besoin pour ajuster l'ETL pendant la migration.

Valeurs par défaut / Vérifier les contraintes

Cette vue affiche les tables qui utilisent des contraintes de vérification pour définir des valeurs de colonne par défaut. Dans BigQuery, consultez la section Spécifier les valeurs de colonne par défaut.

La section Processus de migration du rapport contient les vues suivantes :

Traduction SQL

La vue "SQL Translation" répertorie le nombre et les détails des requêtes converties automatiquement par l'évaluation de la migration BigQuery, qui ne nécessitent aucune intervention manuelle. L'automatisation de la traduction SQL permet généralement d'atteindre des taux de traduction élevés si des métadonnées sont fournies. Cette vue est interactive et permet d'analyser les requêtes courantes et leur traduction.

Effort hors connexion

La vue "Effort hors connexion" capture les domaines qui nécessitent une intervention manuelle, y compris des fonctions définies par l'utilisateur et des cas potentiels de non-respect de la structure et de la syntaxe par des tables ou des colonnes.

Mots clés réservés de BigQuery

La vue "Mots clés réservés de BigQuery" affiche l'utilisation détectée des mots clés ayant une signification particulière dans le langage GoogleSQL, qui ne peuvent donc pas être utilisés comme identifiants à moins d'être entourés d'accents graves (`).

Programmation des mises à jour de la table

La vue "Programmation des mises à jour de la table" indique quand et à quelle fréquence les tables sont mises à jour pour vous aider à planifier quand et comment les transférer.

Migration de données vers BigQuery

La vue "Migration de données vers BigQuery" décrit le chemin de migration avec la durée attendue pour migrer vos données à l'aide du Service de transfert de données BigQuery. Pour en savoir plus, consultez le guide du Service de transfert de données BigQuery pour Teradata.

La section "Annexe" contient les vues suivantes :

Sensibilité à la casse

La vue "Sensibilité à la casse" affiche les tables de l'entrepôt de données source configurées pour effectuer des comparaisons non sensibles à la casse. Par défaut, les comparaisons de chaînes dans BigQuery sont sensibles à la casse. Pour en savoir plus, consultez la section Classement.

Amazon Redshift

Caractéristiques de la migration

La vue "Caractéristiques de la migration" fournit un résumé des trois sections du rapport :

1. Le panneau Système existant fournit des informations sur le nombre de bases de données, de schémas, de tables et de la taille totale du système Redshift existant. Il répertorie également les schémas par taille et par utilisation potentielle sous-optimale des ressources. Vous pouvez utiliser ces informations pour optimiser vos données en supprimant, en partitionnant ou en mettant en cluster vos tables.
2. Le panneau État de la requête BigQuery fournit des informations sur l'apparence de vos données après la migration sur BigQuery, y compris le nombre de requêtes pouvant être traduites automatiquement à l'aide du service de migration BigQuery. Cette section indique également les coûts de stockage de vos données dans BigQuery en fonction de votre taux d'ingestion de données annuel, ainsi que des suggestions d'optimisation pour les tables, le provisionnement et l'espace.
3. Le panneau Chemin de migration fournit des informations sur l'effort de migration lui-même. Pour chaque table, il indique la durée de migration, le nombre de lignes dans la table et la taille attendus.

La section Système existant contient les vues suivantes :

Requêtes par type et par programmation

La vue "Requêtes par type et programmation" classe vos requêtes dans les catégories ETL/Écriture et Création de rapports/Agrégation. L'analyse de votre ensemble de requêtes au fil du temps vous aide à comprendre vos modèles d'utilisation existants, et à identifier les pics d'activité et les risques de surprovisionnement, qui peuvent avoir un impact sur les coûts et les performances.

Mise en file d'attente des requêtes

La vue "Mise en file d'attente des requêtes" fournit des détails supplémentaires sur la charge du système, y compris le volume de requêtes, la combinaison et les impacts sur les performances liés à la mise en file d'attente, tels que des ressources insuffisantes.

Requêtes et scaling WLM

La vue "Requêtes et scaling WLM" identifie le scaling de la simultanéité comme un coût et une complexité de configuration supplémentaires. Elle montre comment votre système Redshift achemine les requêtes en fonction des règles que vous avez spécifiées, ainsi que l'impact sur les performances de la mise en file d'attente, du scaling de simultanéité et des requêtes évincées.

Mise en file d'attente et temps d'attente

La vue "Mise en file d'attente et temps d'attente" permettent d'examiner de plus près la file d'attente et les temps d'attente des requêtes au fil du temps.

Classes et performances WLM

La vue "Classes et performances WLM" offre la possibilité de mapper vos règles avec BigQuery. Nous vous conseillons toutefois de laisser BigQuery acheminer automatiquement vos requêtes.

Insights sur le volume de requêtes et de tables

La vue "Insights sur le volume de requêtes et de tables" répertorie les requêtes selon la taille, la fréquence et les principaux utilisateurs. Cela vous permet de classer les sources de la charge sur le système et de planifier la migration de vos charges de travail.

Bases de données et schémas

La vue "Bases de données et schémas" fournit des métriques sur la taille, les tables, les vues et les procédures définies dans le système d'entrepôt de données source. Vous obtenez ainsi des informations sur le volume d'objets à migrer.

Volume des tables

La vue "Volume des tables" fournit des statistiques sur les tables et les bases de données les plus volumineuses, ainsi que des informations d'accès. Étant donné que l'extraction de grandes tables depuis le système d'entrepôt de données source peut prendre plus de temps, cette vue peut être utile pour la planification et le séquençage de la migration.

Utilisation des tables

La vue "Utilisation des tables" fournit des statistiques sur les tables les plus utilisées dans l'entrepôt de données source. Les tables utilisées de manière intensive peuvent exploiter les tables susceptibles de présenter de nombreuses dépendances et nécessitent une planification supplémentaire pendant le processus de migration.

Déchets des tables

La vue "Déchets des tables" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune utilisation au cours de la période de journaux analysés. Cela peut indiquer les tables qui n'ont pas besoin d'être transférées vers BigQuery pendant la migration. Nous vous recommandons de valider la liste des tables inutilisées, car elles pourraient être utilisées en dehors de la période d'analyse de journaux analysés, par exemple une table utilisée une seule fois par trimestre ou moins.

La section État stable de BigQuery contient les vues suivantes :

Démonstration de faisabilité permettant de démontrer l'état stable

Cette vue répertorie les requêtes les plus fréquemment exécutées, celles qui accèdent le plus aux données et la requête la plus longue par durée. Elle répertorie également les tables auxquelles ces requêtes accèdent.

Suggestions d'optimisation

La vue "Suggestions d'optimisation" répertorie les tables potentielles pour le clustering ou le partitionnement par colonnes. L'utilité est déterminée par une analyse des charges de travail, en particulier les clauses WHERE ou JOIN dans les journaux de requêtes analysés.

BI Engine et vues matérialisées

La vue "BI Engine et vues matérialisées" fournit d'autres suggestions d'optimisation pour améliorer les performances sur BigQuery.

La section Chemin de migration contient les vues suivantes :

Traduction SQL

La vue "SQL Translation" répertorie le nombre et les détails des requêtes converties automatiquement par l'évaluation de la migration BigQuery, qui ne nécessitent aucune intervention manuelle. L'automatisation de la traduction SQL permet d'atteindre des taux de traduction élevés si des métadonnées sont fournies.

Effort hors connexion

La vue "Effort hors connexion" capture les domaines qui nécessitent une intervention manuelle, y compris des fonctions définies par l'utilisateur et des requêtes présentant des ambiguïtés de traduction potentielles.

Programmation des mises à jour de la table

La vue "Programmation des mises à jour de la table" indique quand et à quelle fréquence les tables sont mises à jour pour vous aider à planifier quand et comment les transférer.

Échelle de la table

La vue "Échelle de la table" répertorie vos tables avec le nombre maximal de colonnes.

Migration de données vers BigQuery

La vue "Migration de données vers BigQuery" décrit le chemin de migration avec la durée attendue pour migrer vos données à l'aide du Service de transfert de données pour la migration BigQuery. Pour en savoir plus, consultez le guide du Service de transfert de données BigQuery pour Redshift.

Apache Hive

Le rapport se compose de trois parties, précédées d'une page récapitulative comprenant les sections suivantes :

• Système existant – Hive Cette section comprend un instantané du système Hive existant et de son utilisation, y compris le nombre de bases de données, de tables, leur taille totale (en Go) et le nombre de journaux de requêtes traités. Cette section liste également les bases de données par taille et met en avant les contre-performances potentielles au niveau de l'utilisation des ressources (tables ne présentant pas d'écritures ou peu de lectures) et de leur provisionnement. Voici le contenu détaillé de cette section :

  • Calcul et requêtes
    • Utilisation du processeur :
      • Requêtes par heure et par jour avec utilisation du processeur
      • Requêtes par type (lecture/écriture)
      • Files d'attente et applications
      • Superposition de l'utilisation horaire du processeur avec les performances horaires moyennes des requêtes et les performances horaires moyennes des applications
    • Histogramme des requêtes par type et par durée des requêtes
    • Mise en file d'attente et page d'attente
    • Vue détaillée des files d'attente (file d'attente, utilisateur, requêtes uniques, répartition rapports/ETL, par métrique)
  • Présentation du stockage
    • Bases de données par volume, par vues et par taux d'accès
    • Tables avec leurs taux d'accès par utilisateur, par requêtes, par écritures et par créations de tables temporaires
  • Files d'attente et applications : taux d'accès et adresses IP des clients

• État stable de BigQuery. Cette section montre à quoi ressemblera le système sur BigQuery après la migration. Il inclut des suggestions pour optimiser les charges de travail sur BigQuery (et éviter les gaspillages). Voici le contenu détaillé de cette section :

  • Tables identifiées en tant que candidates pour les vues matérialisées
  • Candidats à la mise en cluster et au partitionnement en fonction de métadonnées et de l'utilisation
  • Requêtes à faible latence identifiées comme candidates pour BigQuery BI Engine
  • Tables sans utilisation en lecture ou écriture
  • Tables partitionnées avec un décalage des données

• Plan de migration. Cette section fournit des informations sur l'effort de migration à proprement parler. Par exemple, passer du système existant à l'état stable de BigQuery. Cette section contient les cibles de stockage identifiées pour chaque table, les tables identifiées comme importantes pour la migration et le nombre de requêtes qui ont été traduites automatiquement. Voici le contenu détaillé de cette section :

  • Vue détaillée avec les requêtes traduites automatiquement
    • Nombre total de requêtes avec possibilité de filtrer par utilisateur, application, tables concernées, tables interrogées et type de requête
    • Requêtes effectuées en regroupant les buckets présentant des modèles similaires, ce qui permet aux utilisateurs de voir la philosophie de traduction par type de requête
  • Requêtes nécessitant une intervention humaine
    • Requêtes présentant des cas de non-respect de la structure lexicale de BigQuery
    • Fonctions et procédures définies par l'utilisateur
    • Mots clés réservés de BigQuery
  • Requête nécessitant un examen
  • Programmations de tables par écritures et lectures (afin de les regrouper pour le déplacement)
  • Cible de stockage identifiée pour les tables externes et les tables gérées

La section Système existant - Hive contient les vues suivantes :

Présentation du système

Cette vue fournit les métriques de volume de haut niveau des composants clés du système existant pour une période spécifiée. La chronologie évaluée dépend des journaux analysés par l'évaluation de la migration BigQuery. Cette vue offre un aperçu rapide de l'utilisation de l'entrepôt de données source, que vous pouvez utiliser pour planifier la migration.

Volume des tables

Cette vue fournit des statistiques sur les plus grandes tables et bases de données trouvées lors de l'évaluation de la migration BigQuery. Étant donné que l'extraction de grandes tables depuis le système d'entrepôt de données source peut prendre plus de temps, cette vue peut être utile pour la planification et le séquençage de la migration.

Utilisation des tables

Cette vue fournit des statistiques sur les tables les plus utilisées dans l'entrepôt de données source. Les tables très utilisées peuvent vous aider à comprendre quelles tables peuvent présenter de nombreuses dépendances et nécessiter une planification supplémentaire pendant le processus de migration.

Utilisation des files d'attente

Cette vue fournit des statistiques sur l'utilisation des files d'attente YARN trouvées lors du traitement des journaux. Ces vues permettent aux utilisateurs de comprendre l'utilisation de files d'attente et d'applications spécifiques au fil du temps, ainsi que l'impact sur l'utilisation des ressources. Ces vues aident également à identifier et à hiérarchiser les charges de travail pour la migration. Au cours d'une migration, il est important de visualiser l'ingestion et la consommation des données pour mieux comprendre les dépendances de l'entrepôt de données et pour analyser l'impact du déplacement conjoint de diverses applications dépendantes. La table d'adresses IP peut être utile pour identifier l'application exacte utilisant l'entrepôt de données via des connexions JDBC.

Métriques des files d'attente

Cette vue fournit une répartition des différentes métriques sur les files d'attente YARN trouvées lors du traitement des journaux. Cette vue permet aux utilisateurs de comprendre les modèles d'utilisation dans des files d'attente spécifiques et l'impact sur la migration. Vous pouvez également utiliser cette vue pour identifier les connexions entre les tables qui ont fait l'objet d'accès dans les requêtes, et les files d'attente dans lesquelles la requête a été exécutée.

Mise en file d'attente et temps d'attente

Cette vue fournit des informations sur la durée de mise en file d'attente des requêtes dans l'entrepôt de données source. Les durées de mise en file d'attente indiquent une dégradation des performances en raison du sous-provisionnement, et le provisionnement supplémentaire suppose des coûts de matériel et de maintenance plus élevés.

Requêtes

Cette vue fournit une répartition des types d'instructions SQL exécutés et des statistiques concernant leur utilisation. Vous pouvez utiliser l'histogramme de Type et Durée de Requête pour identifier les périodes où le système est peu utilisé et les heures optimales de transfert des données. Vous pouvez également utiliser cette vue pour identifier les moteurs d'exécution Hive les plus utilisés et les requêtes fréquemment exécutées, ainsi que les détails relatifs aux utilisateurs.

Bases de données

Cette vue fournit des métriques sur la taille, les tables, les vues et les procédures définies dans le système d'entrepôt de données source. Cette vue offre un aperçu du volume des objets que vous devez migrer.

Association de bases de données et de tables

Cette vue fournit une vue d'ensemble des bases de données et des tables faisant l'objet d'accès conjoints dans une même requête. Cette vue peut indiquer quelles tables et bases de données sont fréquemment référencées et ce que vous pouvez utiliser pour la planification de la migration.

La section État stable de BigQuery contient les vues suivantes :

Tables ne présentant aucune utilisation

La vue "Tables ne présentant aucune utilisation" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune utilisation au cours de la période de journaux analysée. Une absence d'utilisation peut indiquer que vous n'avez pas besoin de transférer cette table vers BigQuery pendant la migration ou que les coûts de stockage les données dans BigQuery peuvent être inférieurs. Vous devez valider la liste des tables inutilisées, car elles pourraient être utilisées en dehors de la période couverte par les journaux, par exemple une table utilisée une seule fois par trimestre ou par semestre.

Tables ne présentant pas d'écritures

La vue "Tables ne présentant pas d'écritures" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune mise à jour au cours de la période de journaux analysée. Une absence d'écritures peut suggérer une opportunité de réduire les coûts de stockage dans BigQuery.

Recommandations pour le clustering et le partitionnement

Cette vue affiche les tables qui pourraient bénéficier du partitionnement, du clustering ou des deux.

Les suggestions de métadonnées sont obtenues en analysant le schéma de l'entrepôt de données source (comme le partitionnement et la clé primaire dans la table source) et en recherchant l'équivalent BigQuery le plus proche pour obtenir des caractéristiques d'optimisation similaires.

Les suggestions de charges de travail sont obtenues en analysant les journaux des requêtes sources. La recommandation est déterminée en analysant les charges de travail, en particulier les clauses WHERE ou JOIN dans les journaux de requêtes analysés.

Partitions converties en clusters

Cette vue affiche les tables comportant plus de 4 000 partitions, en fonction de la définition de leur contrainte de partitionnement. Ces tables sont généralement adaptées au clustering BigQuery, ce qui permet des partitions de tables précises.

Décalage de partitions

La vue "Décalage de partitions" affiche les tables basées sur l'analyse des métadonnées et qui présentent un décalage des données sur une ou plusieurs partitions. Ces tables conviennent à un changement de schéma, car les requêtes portant sur des partitions ayant subi un décalage peuvent ne pas fonctionner correctement.

BI Engine et vues matérialisées

La vue "Requêtes à faible latence et vues matérialisées" affiche une distribution des environnements d'exécution de requête en fonction des données de journal analysées et d'autres suggestions d'optimisation pour améliorer les performances sur BigQuery. Si le graphique de distribution de la durée des requêtes affiche un grand nombre de requêtes avec un temps d'exécution inférieur à une seconde, envisagez d'autoriser BI Engine à accélérer l'informatique décisionnelle et d'autres charges de travail à faible latence.

La section Plan de migration du rapport contient les vues suivantes :

Traduction SQL

La vue "SQL Translation" répertorie le nombre et les détails des requêtes converties automatiquement par l'évaluation de la migration BigQuery, qui ne nécessitent aucune intervention manuelle. L'automatisation de la traduction SQL permet généralement d'atteindre des taux de traduction élevés si des métadonnées sont fournies. Cette vue est interactive et permet d'analyser les requêtes courantes et leur traduction.

Effort hors connexion pour la traduction SQL

La vue "Effort hors connexion" capture les domaines qui nécessitent une intervention manuelle, y compris des fonctions définies par l'utilisateur et des cas potentiels de non-respect de la structure et de la syntaxe par des tables ou des colonnes.

Avertissements SQL

La vue "Avertissements SQL" capture les zones qui ont bien été traduites, mais qui nécessitent d'être examinées.

Mots clés réservés de BigQuery

La vue "Mots clés réservés de BigQuery" affiche l'utilisation détectée de mots clés ayant une signification particulière dans le langage GoogleSQL. Ces mots clés ne peuvent être utilisés comme identifiants, sauf s'ils sont délimités par des accents graves (`).

Programmation des mises à jour de la table

La vue "Programmation des mises à jour de la table" indique quand et à quelle fréquence les tables sont mises à jour pour vous aider à planifier quand et comment les transférer.

Tables externes BigLake

La vue "Tables externes BigLake" décrit les tables identifiées comme des cibles à migrer vers BigLake plutôt que BigQuery.

La section Annexe du rapport contient les vues suivantes :

Analyse détaillée des efforts de traduction SQL hors connexion

La vue détaillée "Analyse détaillée des efforts de traduction SQL hors connexion" fournit des insights supplémentaires sur les zones SQL qui nécessitent une intervention manuelle.

Analyse détaillée des avertissements SQL

La vue "Analyse détaillée des avertissements SQL" fournit des insights supplémentaires sur les zones SQL qui ont bien été traduites, mais qui nécessitent un examen.

Snowflake

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Snowflake, contactez [e-mail].

Le rapport se compose de différentes sections qui peuvent être utilisées ensemble ou séparément. Le schéma suivant organise ces sections en trois objectifs utilisateur courants pour vous aider à évaluer vos besoins en matière de migration :

Vues concernant les caractéristiques de la migration

La section Caractéristiques de la migration contient les vues suivantes :

Modèles tarifaires de Snowflake et de BigQuery

Liste des tarifs avec différents niveaux/éditions. Présente également comment l'autoscaling BigQuery peut vous aider à réduire davantage les coûts par rapport à l'autoscaling Snowflake.

Coût total de possession

Table interactive, qui permet à l'utilisateur de définir les éléments suivants : édition BigQuery, engagement, engagement d'emplacements de base, pourcentage de stockage actif et pourcentage de données chargées ou modifiées. Permet de mieux estimer le coût des cas personnalisés.

Caractéristiques de la traduction automatique

Ratio de traduction agrégé, regroupé par utilisateur ou base de données, par ordre croissant ou décroissant. Inclut également le message d'erreur le plus courant en cas d'échec de la traduction automatique.

Vues concernant le système existant

La section Système existant contient les vues suivantes :

Présentation du système

La vue "Présentation du système" fournit les métriques de volume de haut niveau des composants clés du système existant pour une période spécifiée. La chronologie évaluée dépend des journaux analysés par l'évaluation de la migration BigQuery. Cette vue offre un aperçu rapide de l'utilisation de l'entrepôt de données source, que vous pouvez utiliser pour planifier la migration.

Présentation des entrepôts virtuels

Indique le coût de Snowflake par entrepôt, ainsi que le rescaling basé sur les nœuds au cours de la période.

Volume des tables

La vue "Volume des tables" fournit des statistiques sur les plus grandes tables et bases de données trouvées lors de l'évaluation de la migration BigQuery. Étant donné que l'extraction de grandes tables depuis le système d'entrepôt de données source peut prendre plus de temps, cette vue peut être utile pour la planification et le séquençage de la migration.

Utilisation des tables

La vue "Utilisation des tables" fournit des statistiques sur les tables les plus utilisées dans l'entrepôt de données source. Les tables très utilisées peuvent vous aider à comprendre quelles tables peuvent présenter de nombreuses dépendances et nécessiter une planification supplémentaire pendant le processus de migration.

Requêtes

La vue "Requêtes" fournit une répartition des types d'instructions SQL exécutés et des statistiques concernant leur utilisation. Vous pouvez utiliser l'histogramme "Type de requête" et "Heure de la requête" pour identifier les périodes où le système est peu utilisé et les heures optimales de transfert des données. Vous pouvez également utiliser cette vue pour identifier les requêtes fréquemment exécutées et les utilisateurs qui appellent ces exécutions.

Bases de données

La vue "Bases de données" fournit des métriques sur la taille, les tables, les vues et les procédures définies dans le système d'entrepôt de données source. Cette vue fournit des informations sur le volume des objets que vous devez migrer.

Vues sur l'état stable de BigQuery

La section État stable de BigQuery contient les vues suivantes :

Tables ne présentant aucune utilisation

La vue "Tables ne présentant aucune utilisation" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune utilisation au cours de la période d'analyse des journaux. Elle peut indiquer les tables qui n'ont pas besoin d'être transférées vers BigQuery pendant la migration ou si les coûts de stockage des données dans BigQuery peuvent être inférieurs. Vous devez valider la liste des tables inutilisées, car elles pourraient être utilisées en dehors de la période d'analyse des journaux (par exemple, une table utilisée une seule fois par trimestre ou moins).

Tables ne présentant pas d'écritures

La vue "Tables ne présentant pas d'écritures" affiche les tables pour lesquelles l'évaluation de la migration BigQuery n'a trouvé aucune mise à jour au cours de la période de journaux analysée. Elle peut indiquer si les coûts de stockage des données dans BigQuery peuvent être inférieurs.

Vues concernant le plan de migration

La section Plan de migration du rapport contient les vues suivantes :

Traduction SQL

La vue "SQL Translation" répertorie le nombre et les détails des requêtes converties automatiquement par l'évaluation de la migration BigQuery, qui ne nécessitent aucune intervention manuelle. L'automatisation de la traduction SQL permet généralement d'atteindre des taux de traduction élevés si des métadonnées sont fournies. Cette vue est interactive et permet d'analyser les requêtes courantes et leur traduction.

Effort hors connexion pour la traduction SQL

La vue "Effort hors connexion" capture les domaines qui nécessitent une intervention manuelle, y compris des fonctions définies par l'utilisateur et des cas potentiels de non-respect de la structure et de la syntaxe par des tables ou des colonnes.

Avertissements SQL – À examiner

La vue "Avertissements à examiner" capture les zones qui sont principalement traduites, mais qui nécessitent une inspection humaine.

Mots clés réservés de BigQuery

La vue "Mots clés réservés de BigQuery" affiche l'utilisation détectée des mots clés ayant une signification particulière dans le langage GoogleSQL, qui ne peuvent donc pas être utilisés comme identifiants à moins d'être entourés d'accents graves (`).

Couplage de bases de données et de tables

La vue "Couplage des bases de données" fournit une vue d'ensemble des bases de données et des tables faisant l'objet d'accès conjoints dans une même requête. Cette vue peut indiquer les tables et bases de données fréquemment référencées, et ce que vous pouvez utiliser pour la planification de la migration.

Programmation des mises à jour de la table

La vue "Programmation des mises à jour de la table" indique quand et à quelle fréquence les tables sont mises à jour pour vous aider à planifier quand et comment les transférer.

Vues concernant la démonstration de faisabilité

La section Démonstration de faisabilité contient les vues suivantes :

Démonstration de faisabilité présentant les économies réalisées avec BigQuery à l'état stable

Inclut les requêtes les plus fréquentes, les requêtes lisant le plus de données, les requêtes les plus lentes et les tables affectées par ces requêtes.

Démonstration de faisabilité présentant le plan de migration BigQuery

Explique comment BigQuery traduit les requêtes les plus complexes et les tables qu'elles concernent.

Partager le rapport

Le rapport Looker Studio est un tableau de bord d'interface pour l'évaluation de la migration. Il repose sur les autorisations d'accès aux ensembles de données sous-jacents. Pour partager le rapport, le destinataire doit avoir accès à la fois au rapport Looker Studio lui-même et à l'ensemble de données BigQuery contenant les résultats de l'évaluation.

Lorsque vous ouvrez le rapport depuis la console Google Cloud, il s'affiche en mode aperçu. Pour créer et partager le rapport avec d'autres utilisateurs, procédez comme suit :

1. Cliquez sur Modifier et partager. Looker Studio vous invite à associer des connecteurs Looker nouvellement créés au nouveau rapport.
2. Cliquez sur Ajouter au rapport. Le rapport reçoit un ID de rapport individuel, que vous pouvez utiliser pour y accéder.
3. Pour partager le rapport Looker Studio avec d'autres utilisateurs, suivez les étapes décrites dans la section Partager des rapports avec des lecteurs et des éditeurs.
4. Accordez aux utilisateurs l'autorisation d'afficher l'ensemble de données BigQuery utilisé pour exécuter la tâche d'évaluation. Pour en savoir plus, consultez la section Accorder l'accès à un ensemble de données.

Interroger les tables de sortie de l'évaluation de migration

Bien que Looker Studio propose le moyen le plus pratique d'afficher les résultats de l'évaluation, vous pouvez également interroger les données sous-jacentes dans l'ensemble de données BigQuery.

Exemple de requête

L'exemple suivant permet d'obtenir le nombre total de requêtes uniques, le nombre de requêtes dont la traduction a échoué, et le pourcentage de requêtes uniques dont la traduction a échoué.

  SELECT
    QueryCount.v AS QueryCount,
    ErrorCount.v as ErrorCount,
    (ErrorCount.v * 100) / QueryCount.v AS FailurePercentage
  FROM
  (
    SELECT
     COUNT(*) AS v
    FROM
      `your_project.your_dataset.TranslationErrors`
    WHERE Type = "ERROR"
  ) AS ErrorCount,
  (
    SELECT
      COUNT(DISTINCT(QueryHash)) AS v
    FROM
      `your_project.your_dataset.Queries`
  ) AS QueryCount;

Schémas des tables d'évaluation

Pour afficher les tables et leur schéma que l'évaluation de la migration BigQuery écrit dans BigQuery, sélectionnez votre entrepôt de données :

Teradata

AllRIChildren

Le tableau suivant fournit des informations sur l'intégrité référentielle des enfants de la table.

Colonne	Type	Description
IndexId	INTEGER	Numéro de l'index de référence.
IndexName	STRING	Nom de l'index.
ChildDB	STRING	Nom de la base de données à l'origine de la référence, converti en minuscules.
ChildDBOriginal	STRING	Nom de la base de données à l'origine de la référence, avec la casse préservée.
ChildTable	STRING	Nom de la table à l'origine de la référence, converti en minuscules.
ChildTableOriginal	STRING	Nom de la table à l'origine de la référence, avec la casse préservée.
ChildKeyColumn	STRING	Nom d'une colonne dans la clé à l'origine de la référence, converti en minuscules.
ChildKeyColumnOriginal	STRING	Nom d'une colonne dans la clé à l'origine de la référence, avec la casse préservée.
ParentDB	STRING	Nom de la base de données référencée, converti en minuscules.
ParentDBOriginal	STRING	Nom de la base de données référencée, avec la casse préservée.
ParentTable	STRING	Nom de la table référencée, converti en minuscules.
ParentTableOriginal	STRING	Nom de la table référencée, avec la casse préservée.
ParentKeyColumn	STRING	Nom de la colonne dans une clé référencée, converti en minuscules.
ParentKeyColumnOriginal	STRING	Nom de la colonne dans une clé référencée, avec la casse préservée.

AllRIParents

Le tableau suivant fournit les informations sur l'intégrité référentielle des parents de la table.

Colonne	Type	Description
IndexId	INTEGER	Numéro de l'index de référence.
IndexName	STRING	Nom de l'index.
ChildDB	STRING	Nom de la base de données à l'origine de la référence, converti en minuscules.
ChildDBOriginal	STRING	Nom de la base de données à l'origine de la référence, avec la casse préservée.
ChildTable	STRING	Nom de la table à l'origine de la référence, converti en minuscules.
ChildTableOriginal	STRING	Nom de la table à l'origine de la référence, avec la casse préservée.
ChildKeyColumn	STRING	Nom d'une colonne dans la clé à l'origine de la référence, converti en minuscules.
ChildKeyColumnOriginal	STRING	Nom d'une colonne dans la clé à l'origine de la référence, avec la casse préservée.
ParentDB	STRING	Nom de la base de données référencée, converti en minuscules.
ParentDBOriginal	STRING	Nom de la base de données référencée, avec la casse préservée.
ParentTable	STRING	Nom de la table référencée, converti en minuscules.
ParentTableOriginal	STRING	Nom de la table référencée, avec la casse préservée.
ParentKeyColumn	STRING	Nom de la colonne dans une clé référencée, converti en minuscules.
ParentKeyColumnOriginal	STRING	Nom de la colonne dans une clé référencée, avec la casse préservée.

Columns

Le tableau suivant fournit des informations sur les colonnes.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, converti en minuscules.
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, converti en minuscules.
TableNameOriginal	STRING	Nom de la table, avec la casse préservée.
ColumnName	STRING	Nom de la colonne, converti en minuscules.
ColumnNameOriginal	STRING	Nom de la colonne, avec la casse préservée.
ColumnType	STRING	Type BigQuery de la colonne, par exemple STRING.
OriginalColumnType	STRING	Type original de la colonne, par exemple VARCHAR.
ColumnLength	INTEGER	Nombre maximal d'octets de la colonne, par exemple 30 pour VARCHAR(30).
DefaultValue	STRING	Valeur par défaut, le cas échéant.
Nullable	BOOLEAN	Indique si la colonne peut avoir une valeur nulle.

DiskSpace

Le tableau suivant fournit des informations sur l'utilisation de l'espace disque pour chaque base de données.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, converti en minuscules.
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.
MaxPerm	INTEGER	Nombre maximal d'octets alloués à l'espace permanent.
MaxSpool	INTEGER	Nombre maximal d'octets alloués à l'espace de spool.
MaxTemp	INTEGER	Nombre maximal d'octets alloués à l'espace temporaire.
CurrentPerm	INTEGER	Nombre d'octets actuellement alloués à l'espace permanent.
CurrentSpool	INTEGER	Nombre d'octets actuellement alloués à l'espace de spool.
CurrentTemp	INTEGER	Nombre d'octets actuellement alloués à l'espace temporaire.
PeakPerm	INTEGER	Nombre maximal d'octets utilisés depuis la dernière réinitialisation pour l'espace permanent.
PeakSpool	INTEGER	Nombre maximal d'octets utilisés depuis la dernière réinitialisation pour l'espace de spool.
PeakPersistentSpool	INTEGER	Nombre maximal d'octets utilisés depuis la dernière réinitialisation pour l'espace persistant.
PeakTemp	INTEGER	Nombre maximal d'octets utilisés depuis la dernière réinitialisation pour l'espace temporaire.
MaxProfileSpool	INTEGER	Limite d'espace de spool pour l'utilisateur.
MaxProfileTemp	INTEGER	Limite de l'espace temporaire pour l'utilisateur.
AllocatedPerm	INTEGER	Allocation actuelle de l'espace permanent.
AllocatedSpool	INTEGER	Allocation actuelle de l'espace de spool.
AllocatedTemp	INTEGER	Allocation actuelle de l'espace temporaire.

Functions

Le tableau suivant fournit des informations sur les fonctions.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, converti en minuscules.
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.
FunctionName	STRING	Nom de la fonction.
LanguageName	STRING	Nom de la langue.

Indices

Le tableau suivant fournit des informations sur les index.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, converti en minuscules.
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, converti en minuscules.
TableNameOriginal	STRING	Nom de la table, avec la casse préservée.
IndexName	STRING	Nom de l'index.
ColumnName	STRING	Nom de la colonne, converti en minuscules.
ColumnNameOriginal	STRING	Nom de la colonne, avec la casse préservée.
OrdinalPosition	INTEGER	Position de la colonne.
UniqueFlag	BOOLEAN	Indique si l'index applique l'unicité.

Queries

Le tableau suivant fournit des informations sur les requêtes extraites.

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
QueryText	STRING	Texte de la requête.

QueryLogs

Le tableau suivant fournit quelques statistiques d'exécution sur les requêtes extraites.

Colonne	Type	Description
QueryText	STRING	Texte de la requête.
QueryHash	STRING	Hachage de la requête.
QueryId	STRING	ID de la requête.
QueryType	STRING	Type de la requête, Query ou LDD.
UserId	BYTES	ID de l'utilisateur qui a exécuté la requête.
UserName	STRING	Nom de l'utilisateur qui a exécuté la requête.
StartTime	TIMESTAMP	Horodatage au moment de l'envoi de la requête.
Duration	STRING	Durée de la requête en millisecondes.
AppId	STRING	ID de l'application qui a exécuté la requête.
ProxyUser	STRING	Utilisateur du proxy lorsqu'il est utilisé via un niveau intermédiaire.
ProxyRole	STRING	Rôle du proxy lorsqu'il est utilisé via un niveau intermédiaire.

QueryTypeStatistics

Le tableau suivant fournit des statistiques sur les types de requêtes.

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
QueryType	STRING	Type de la requête.
UpdatedTable	STRING	Table mise à jour par la requête, le cas échéant.
QueriedTables	ARRAY<STRING>	Liste des tables interrogées.

ResUsageScpu

Le tableau suivant fournit des informations sur l'utilisation de la ressource de processeur.

Colonne	Type	Description
EventTime	TIMESTAMP	Heure de l'événement.
NodeId	INTEGER	Identifiant du nœud
CabinetId	INTEGER	Numéro de l'armoire physique du nœud.
ModuleId	INTEGER	Numéro du module physique du nœud.
NodeType	STRING	Type de nœud.
CpuId	INTEGER	ID du processeur dans ce nœud.
MeasurementPeriod	INTEGER	Période de la mesure, exprimée en centisecondes.
SummaryFlag	STRING	S – ligne récapitulative, N – ligne non récapitulative
CpuFrequency	FLOAT	Fréquence du CPU en MHz.
CpuIdle	FLOAT	Temps d'inactivité du CPU, exprimé en centisecondes.
CpuIoWait	FLOAT	Temps d'attente du CPU pour les E/S, exprimé en centisecondes.
CpuUServ	FLOAT	Temps d'exécution de code utilisateur par le CPU, exprimé en centisecondes.
CpuUExec	FLOAT	Temps d'exécution de code de service par le CPU, exprimé en centisecondes.

Roles

Le tableau suivant fournit des informations sur les rôles.

Colonne	Type	Description
RoleName	STRING	Nom du rôle.
Grantor	STRING	Nom de la base de données ayant attribué le rôle.
Grantee	STRING	Utilisateur disposant du rôle.
WhenGranted	TIMESTAMP	Date d'attribution du rôle.
WithAdmin	BOOLEAN	Est l'option Administrateur définie pour le rôle accordé.

Conversion de schéma

Cette table fournit des informations sur les conversions de schéma liées au clustering et au partitionnement.

Nom de la colonne	Type de colonne	Description
DatabaseName	STRING	Nom de la base de données source pour laquelle la suggestion est effectuée. Une base de données est mappée sur un ensemble de données dans BigQuery.
TableName	STRING	Nom de la table pour laquelle la suggestion est effectuée.
PartitioningColumnName	STRING	Nom de la colonne de partitionnement suggérée dans BigQuery.
ClusteringColumnNames	ARRAY	Noms des colonnes de clustering suggérées dans BigQuery.
CreateTableDDL	STRING	Instruction CREATE TABLE statement permettant de créer la table dans BigQuery.

TableInfo

Le tableau suivant fournit des informations sur les tables.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, converti en minuscules.
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, converti en minuscules.
TableNameOriginal	STRING	Nom de la table, avec la casse préservée.
LastAccessTimestamp	TIMESTAMP	Date de la dernière utilisation de la table.
LastAlterTimestamp	TIMESTAMP	Date de la dernière modification de la table.
TableKind	STRING	Type de table.

TableRelations

Le tableau suivant fournit des informations sur les tables.

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête qui a établi la relation.
DatabaseName1	STRING	Nom de la première base de données.
TableName1	STRING	Nom de la première table.
DatabaseName2	STRING	Nom de la deuxième base de données.
TableName2	STRING	Nom de la deuxième table.
Relation	STRING	Type de relation entre les deux tables.

TableSizes

Le tableau suivant fournit des informations sur les tailles des tables.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, converti en minuscules.
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, converti en minuscules.
TableNameOriginal	STRING	Nom de la table, avec la casse préservée.
TableSizeInBytes	INTEGER	Taille de la table en octets.

Users

Le tableau suivant fournit des informations sur les utilisateurs.

Colonne	Type	Description
UserName	STRING	Nom de l'utilisateur.
CreatorName	STRING	Nom de l'entité qui a créé cet utilisateur.
CreateTimestamp	TIMESTAMP	Horodatage de la création de cet utilisateur.
LastAccessTimestamp	TIMESTAMP	Horodatage de la dernière connexion de cet utilisateur à une base de données.

Amazon Redshift

Remarque : Toutes les colonnes qui s'affichent dans la table BigQuery mais ne sont pas répertoriées ici doivent être considérées comme expérimentales et susceptibles d'être modifiées à tout moment.

Columns

La table Columns provient de l'une des tables suivantes : SVV_COLUMNS, INFORMATION_SCHEMA.COLUMNS ou PG_TABLE_DEF, classées par ordre de priorité. L'outil tente d'abord de charger les données de la table ayant la priorité la plus élevée. Si cette opération échoue, il tente de charger les données de la table de priorité suivante. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift ou PostgreSQL.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données.
SchemaName	STRING	Nom du schéma.
TableName	STRING	Nom de la table.
ColumnName	STRING	Nom de la colonne.
DefaultValue	STRING	Valeur par défaut si disponible.
Nullable	BOOLEAN	Indique si une colonne peut avoir une valeur nulle.
ColumnType	STRING	Type de la colonne, par exemple VARCHAR.
ColumnLength	INTEGER	Taille de la colonne, par exemple 30 pour une valeur VARCHAR(30).

CreateAndDropStatistic

Cette table fournit des informations sur la création et la suppression de tables.

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
DefaultDatabase	STRING	Base de données par défaut.
EntityType	STRING	Type de l'entité (par exemple, TABLE).
EntityName	STRING	Nom de l'entité.
Operation	STRING	L'opération : CREATE ou DROP.

Databases

Cette table provient directement de la table PG_DATABASE_INFO d'Amazon Redshift. Les noms de champs d'origine de la table PG sont inclus dans les descriptions. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift et PostgreSQL.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données. Nom de la source : datname
Owner	STRING	Propriétaire de la base de données. Par exemple, l'utilisateur qui a créé la base de données. Nom de la source : datdba

ExternalColumns

Cette table contient directement les informations de la table SVV_EXTERNAL_COLUMNS d'Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift.

Colonne	Type	Description
SchemaName	STRING	Nom du schéma externe.
TableName	STRING	Nom de la table externe.
ColumnName	STRING	Nom de la colonne externe.
ColumnType	STRING	Type de la colonne.
Nullable	BOOLEAN	Indique si une colonne peut avoir une valeur nulle.

ExternalDatabases

Cette table contient directement les informations de la table SVV_EXTERNAL_DATABASES d'Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données externe.
Location	STRING	Emplacement de la base de données.

ExternalPartitions

Cette table contient directement les informations de la table SVV_EXTERNAL_PARTITIONS d'Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift.

Colonne	Type	Description
SchemaName	STRING	Nom du schéma externe.
TableName	STRING	Nom de la table externe.
Location	STRING	Emplacement de la partition. La taille des colonnes est limitée à 128 caractères. Les valeurs plus longues sont tronquées.

ExternalSchemas

Cette table contient directement les informations de la table SVV_EXTERNAL_SCHEMAS d'Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift.

Colonne	Type	Description
SchemaName	STRING	Nom du schéma externe.
DatabaseName	STRING	Nom de la base de données externe.

ExternalTables

Cette table contient directement les informations de la table SVV_EXTERNAL_TABLES d'Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift.

Colonne	Type	Description
SchemaName	STRING	Nom du schéma externe.
TableName	STRING	Nom de la table externe.

Functions

Cette table contient directement les informations de la table PG_PROC d'Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift et PostgreSQL.

Colonne	Type	Description
SchemaName	STRING	Nom du schéma.
FunctionName	STRING	Nom de la fonction.
LanguageName	STRING	Langage d'implémentation ou interface d'appel de cette fonction.

Queries

Cette table est générée à l'aide des informations de la table QueryLogs. Contrairement à la table QueryLogs, chaque ligne de la table Queries ne contient qu'une seule instruction de requête, stockée dans la colonne QueryText. Cette table fournit les données sources permettant de générer les tables de statistiques et les résultats de traduction.

Colonne	Type	Description
QueryText	STRING	Texte de la requête.
QueryHash	STRING	Hachage de la requête.

QueryLogs

Cette table fournit des informations sur l'exécution des requêtes.

Colonne	Type	Description
QueryText	STRING	Texte de la requête.
QueryHash	STRING	Hachage de la requête.
QueryID	STRING	ID de la requête.
UserID	STRING	ID de l'utilisateur.
StartTime	TIMESTAMP	Heure de début.
Duration	INTEGER	Durée, en millisecondes.

QueryTypeStatistics

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
DefaultDatabase	STRING	Base de données par défaut.
QueryType	STRING	Type de la requête.
UpdatedTable	STRING	Table mise à jour.
QueriedTables	ARRAY<STRING>	Tables interrogées.

TableInfo

Cette table contient des informations extraites de la table SVV_TABLE_INFO dans Amazon Redshift.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données.
SchemaName	STRING	Nom du schéma.
TableId	INTEGER	ID de la table.
TableName	STRING	Nom de la table.
SortKey1	STRING	Première colonne de la clé de tri.
SortKeyNum	INTEGER	Nombre de colonnes définies en tant que clés de tri.
MaxVarchar	INTEGER	Taille de la plus grande colonne utilisant un type de données VARCHAR.
Size	INTEGER	Taille de la table, en blocs de données de 1 Mo.
TblRows	INTEGER	Nombre de lignes dans la table.

TableRelations

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête qui a établi la relation (par exemple, une requête JOIN).
DefaultDatabase	STRING	Base de données par défaut.
TableName1	STRING	Première table de la relation.
TableName2	STRING	Deuxième table de la relation.
Relation	STRING	Type de relation. Prend l'une des valeurs suivantes : COMMA_JOIN, CROSS_JOIN, FULL_OUTER_JOIN, INNER_JOIN, LEFT_OUTER_JOIN, RIGHT_OUTER_JOIN, CREATED_FROM ou INSERT_INTO.
Count	INTEGER	Fréquence à laquelle cette relation a été observée.

TableSizes

Cette table fournit des informations sur les tailles des tables.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données.
SchemaName	STRING	Nom du schéma.
TableName	STRING	Nom de la table.
TableSizeInBytes	INTEGER	Taille de la table en octets.

Tables

Cette table contient des informations extraites de la table SVV_TABLES dans Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation Amazon Redshift.

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données.
SchemaName	STRING	Nom du schéma.
TableName	STRING	Nom de la table.
TableType	STRING	Type de table.

TranslatedQueries

Cette table fournit des traductions de requête.

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
TranslatedQueryText	STRING	Résultat de la traduction du dialecte source vers GoogleSQL.

TranslationErrors

Cette table fournit des informations sur les erreurs de traduction de requête.

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
Severity	STRING	Niveau de gravité de l'erreur, par exemple ERROR.
Category	STRING	Catégorie de l'erreur, par exemple AttributeNotFound.
Message	STRING	Message avec les détails de l'erreur.
LocationOffset	INTEGER	Position du caractère de l'emplacement de l'erreur.
LocationLine	INTEGER	Numéro de ligne de l'erreur.
LocationColumn	INTEGER	Numéro de colonne de l'erreur.
LocationLength	INTEGER	Longueur du caractère de l'emplacement de l'erreur.

UserTableRelations

Colonne	Type	Description
UserID	STRING	ID utilisateur.
TableName	STRING	Nom de la table.
Relation	STRING	Relation.
Count	INTEGER	Nombre.

Users

Cette table contient des informations extraites de la table PG_USER dans Amazon Redshift. Pour en savoir plus sur le schéma et l'utilisation, consultez la documentation PostgreSQL.

Colonne	Type	Description
UserName	STRING	Nom de l'utilisateur.
UserId	STRING	ID utilisateur.

Apache Hive

Columns

Cette table fournit des informations sur les colonnes :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, avec la casse préservée.
ColumnName	STRING	Nom de la colonne, avec la casse préservée.
ColumnType	STRING	Type BigQuery de la colonne, par exemple STRING.
OriginalColumnType	STRING	Type original de la colonne, par exemple VARCHAR.

CreateAndDropStatistic

Cette table fournit des informations sur la création et la suppression de tables :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
DefaultDatabase	STRING	Base de données par défaut.
EntityType	STRING	Type de l'entité, par exemple, TABLE.
EntityName	STRING	Nom de l'entité.
Operation	STRING	Opération effectuée sur la table (CREATE ou DROP).

Databases

Cette table fournit des informations sur les bases de données :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
Owner	STRING	Propriétaire de la base de données. Par exemple, l'utilisateur qui a créé la base de données.
Location	STRING	Emplacement de la base de données dans le système de fichiers.

Functions

Cette table fournit des informations sur les fonctions :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
FunctionName	STRING	Nom de la fonction.
LanguageName	STRING	Nom de la langue.
ClassName	STRING	Nom de classe de la fonction.

ObjectReferences

Cette table fournit des informations sur les objets référencés dans les requêtes :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
DefaultDatabase	STRING	Base de données par défaut.
Clause	STRING	Clause dans laquelle l'objet apparaît. Par exemple, SELECT.
ObjectName	STRING	Nom de l'objet.
Type	STRING	Type de l'objet.
Subtype	STRING	Sous-type de l'objet.

ParititionKeys

Cette table fournit des informations sur les clés de partitionnement :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, avec la casse préservée.
ColumnName	STRING	Nom de la colonne, avec la casse préservée.
ColumnType	STRING	Type BigQuery de la colonne, par exemple STRING.

Parititions

Cette table fournit des informations sur les partitions des tables :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, avec la casse préservée.
PartitionName	STRING	Nom de la partition.
CreateTimestamp	TIMESTAMP	Horodatage de la création de cette partition.
LastAccessTimestamp	TIMESTAMP	Horodatage du dernier accès à cette partition.
LastDdlTimestamp	TIMESTAMP	Horodatage de la dernière modification de cette partition.
TotalSize	INTEGER	Taille compressée de la partition en octets.

Queries

Cette table est générée à l'aide des informations de la table QueryLogs. Contrairement à la table QueryLogs, chaque ligne de la table Queries ne contient qu'une seule instruction de requête, stockée dans la colonne QueryText. Cette table fournit les données sources permettant de générer les tables de statistiques et les résultats de traduction :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
QueryText	STRING	Texte de la requête.

QueryLogs

Cette table fournit quelques statistiques d'exécution sur les requêtes extraites :

Colonne	Type	Description
QueryText	STRING	Texte de la requête.
QueryHash	STRING	Hachage de la requête.
QueryId	STRING	ID de la requête.
QueryType	STRING	Type de la requête, Query ou DDL.
UserName	STRING	Nom de l'utilisateur qui a exécuté la requête.
StartTime	TIMESTAMP	Horodatage de l'envoi de la requête.
Duration	STRING	Durée de la requête en millisecondes.

QueryTypeStatistics

Cette table fournit des statistiques sur les types de requêtes :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
QueryType	STRING	Type de la requête.
UpdatedTable	STRING	Table mise à jour par la requête, le cas échéant.
QueriedTables	ARRAY<STRING>	Liste des tables interrogées.

QueryTypes

Cette table fournit des statistiques sur les types de requêtes :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
Category	STRING	Catégorie de la requête.
Type	STRING	Type de la requête.
Subtype	STRING	Sous-type de la requête.

Conversion de schéma

Cette table fournit des informations sur les conversions de schéma liées au clustering et au partitionnement :

Nom de la colonne	Type de colonne	Description
DatabaseName	STRING	Nom de la base de données source pour laquelle la suggestion est effectuée. Une base de données est mappée sur un ensemble de données dans BigQuery.
TableName	STRING	Nom de la table pour laquelle la suggestion est effectuée.
PartitioningColumnName	STRING	Nom de la colonne de partitionnement suggérée dans BigQuery.
ClusteringColumnNames	ARRAY	Noms des colonnes de clustering suggérées dans BigQuery.
CreateTableDDL	STRING	Instruction CREATE TABLE statement permettant de créer la table dans BigQuery.

TableRelations

Cette table fournit des informations sur les tables :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête qui a établi la relation.
DatabaseName1	STRING	Nom de la première base de données.
TableName1	STRING	Nom de la première table.
DatabaseName2	STRING	Nom de la deuxième base de données.
TableName2	STRING	Nom de la deuxième table.
Relation	STRING	Type de relation entre les deux tables.

TableSizes

Cette table fournit des informations sur la taille des tables :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, avec la casse préservée.
TotalSize	INTEGER	Taille de la table en octets.

Tables

Cette table fournit des informations sur les tables :

Colonne	Type	Description
DatabaseName	STRING	Nom de la base de données, avec la casse préservée.
TableName	STRING	Nom de la table, avec la casse préservée.
Type	STRING	Type de table.

TranslatedQueries

Cette table fournit des traductions de requête :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
TranslatedQueryText	STRING	Résultat de la traduction du dialecte source en langage GoogleSQL.

TranslationErrors

Cette table fournit des informations sur les erreurs de traduction de requête :

Colonne	Type	Description
QueryHash	STRING	Hachage de la requête.
Severity	STRING	Niveau de gravité de l'erreur, par exemple ERROR.
Category	STRING	Catégorie de l'erreur, par exemple AttributeNotFound.
Message	STRING	Message avec les détails de l'erreur.
LocationOffset	INTEGER	Position du caractère de l'emplacement de l'erreur.
LocationLine	INTEGER	Numéro de ligne de l'erreur.
LocationColumn	INTEGER	Numéro de colonne de l'erreur.
LocationLength	INTEGER	Longueur du caractère de l'emplacement de l'erreur.

UserTableRelations

Colonne	Type	Description
UserID	STRING	ID utilisateur.
TableName	STRING	Nom de la table.
Relation	STRING	Relation.
Count	INTEGER	Nombre.

Snowflake

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour envoyer des commentaires ou poser des questions concernant l'évaluation de la migration BigQuery pour Snowflake, contactez [e-mail].

Warehouses

Colonne	Type	Description	Présence
WarehouseName	STRING	Nom de l'entrepôt.	Always
State	STRING	État de l'entrepôt. Valeurs possibles : STARTED, SUSPENDED, RESIZING.	Always
Type	STRING	Type d'entrepôt. Valeurs possibles : STANDARD, SNOWPARK-OPTIMIZED.	Always
Size	STRING	Taille de l'entrepôt. Valeurs possibles : X-Small, Small, Medium, Large, X-Large, 2X-Large ... 6X-Large.	Always

Databases

Colonne	Type	Description	Présence
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.	Always
DatabaseName	STRING	Nom de la base de données, converti en minuscules.	Always

Schemata

Colonne	Type	Description	Présence
DatabaseNameOriginal	STRING	Nom de la base de données à laquelle appartient le schéma, avec la casse préservée.	Always
DatabaseName	STRING	Nom de la base de données à laquelle appartient le schéma, converti en minuscules.	Always
SchemaNameOriginal	STRING	Nom du schéma, avec la casse préservée.	Always
SchemaName	STRING	Nom du schéma, converti en minuscules.	Always

Tables

Colonne	Type	Description	Présence
DatabaseNameOriginal	STRING	Nom de la base de données à laquelle la table appartient, avec la casse préservée.	Always
DatabaseName	STRING	Nom de la base de données à laquelle la table appartient, converti en minuscules.	Always
SchemaNameOriginal	STRING	Nom du schéma auquel la table appartient, avec la casse préservée.	Always
SchemaName	STRING	Nom du schéma auquel la table appartient, converti en minuscules.	Always
TableNameOriginal	STRING	Nom de la table, avec la casse préservée.	Always
TableName	STRING	Nom de la table, converti en minuscules.	Always
TableType	STRING	Type de la table (vue/vue matérialisée/table de base).	Always
RowCount	BIGNUMERIC	Nombre de lignes dans la table.	Always

Columns

Colonne	Type	Description	Présence
DatabaseName	STRING	Nom de la base de données, converti en minuscules.	Always
DatabaseNameOriginal	STRING	Nom de la base de données, avec la casse préservée.	Always
SchemaName	STRING	Nom du schéma, converti en minuscules.	Always
SchemaNameOriginal	STRING	Nom du schéma, avec la casse préservée.	Always
TableName	STRING	Nom de la table, converti en minuscules.	Always
TableNameOriginal	STRING	Nom de la table, avec la casse préservée.	Always
ColumnName	STRING	Nom de la colonne, converti en minuscules.	Always
ColumnNameOriginal	STRING	Nom de la colonne, avec la casse préservée.	Always
ColumnType	STRING	Type de la colonne.	Always

CreateAndDropStatistics

Colonne	Type	Description	Présence
QueryHash	STRING	Hachage de la requête.	Always
DefaultDatabase	STRING	Base de données par défaut.	Always
EntityType	STRING	Type de l'entité (par exemple, TABLE).	Always
EntityName	STRING	Nom de l'entité.	Always
Operation	STRING	Opération : CREATE ou DROP.	Always

Queries

Colonne	Type	Description	Présence
QueryText	STRING	Texte de la requête.	Always
QueryHash	STRING	Hachage de la requête.	Always

QueryLogs

Colonne	Type	Description	Présence
QueryText	STRING	Texte de la requête.	Always
QueryHash	STRING	Hachage de la requête.	Always
QueryID	STRING	ID de la requête.	Always
UserID	STRING	ID de l'utilisateur.	Always
StartTime	TIMESTAMP	Heure de début.	Always
Duration	INTEGER	Durée, en millisecondes.	Always

QueryTypeStatistics

Colonne	Type	Description	Présence
QueryHash	STRING	Hachage de la requête.	Always
DefaultDatabase	STRING	Base de données par défaut.	Always
QueryType	STRING	Type de la requête.	Always
UpdatedTable	STRING	Table mise à jour.	Always
QueriedTables	REPEATED STRING	Tables interrogées.	Always

TableRelations

Colonne	Type	Description	Présence
QueryHash	STRING	Hachage de la requête qui a établi la relation (par exemple, une requête JOIN).	Always
DefaultDatabase	STRING	Base de données par défaut.	Always
TableName1	STRING	Première table de la relation.	Always
TableName2	STRING	Deuxième table de la relation.	Always
Relation	STRING	Type de relation.	Always
Count	INTEGER	Fréquence à laquelle cette relation a été observée.	Always

TranslatedQueries

Colonne	Type	Description	Présence
QueryHash	STRING	Hachage de la requête.	Always
TranslatedQueryText	STRING	Résultat de la traduction du dialecte source vers BigQuery SQL.	Always

TranslationErrors

Colonne	Type	Description	Présence
QueryHash	STRING	Hachage de la requête.	Always
Severity	STRING	Niveau de gravité de l'erreur (par exemple, ERROR).	Always
Category	STRING	Catégorie de l'erreur (par exemple, AttributeNotFound).	Always
Message	STRING	Message avec les détails de l'erreur.	Always
LocationOffset	INTEGER	Position du caractère de l'emplacement de l'erreur.	Always
LocationLine	INTEGER	Numéro de ligne de l'erreur.	Always
LocationColumn	INTEGER	Numéro de colonne de l'erreur.	Always
LocationLength	INTEGER	Longueur du caractère de l'emplacement de l'erreur.	Always

UserTableRelations

Colonne	Type	Description	Présence
UserID	STRING	L'ID utilisateur	Always
TableName	STRING	Nom de la table.	Always
Relation	STRING	Relation.	Always
Count	INTEGER	Nombre.	Always

Dépannage

Cette section décrit certains problèmes courants et des techniques de dépannage permettant de migrer votre entrepôt de données vers BigQuery.

Erreurs de l'outil dwh-migration-dumper

Pour résoudre les erreurs et les avertissements dans la sortie du terminal de l'outil dwh-migration-dumper survenues lors de l'extraction des métadonnées ou des journaux de requête, consultez la page Résoudre les problèmes liés aux métadonnées.

Erreurs de migration Hive

Cette section décrit les problèmes courants que vous pouvez rencontrer lorsque vous envisagez de migrer votre entrepôt de données de Hive vers BigQuery.

Le hook de journalisation écrit les messages de débogage dans vos journaux hive-server2. Si vous rencontrez des problèmes, consultez les journaux de débogage du hook de journalisation qui contient la chaîne MigrationAssessmentLoggingHook.

Remarque : Si le problème ne peut pas être résolu, contactez l'assistance [e-mail] pour obtenir de l'aide.

Gérer l'erreur ClassNotFoundException.

L'erreur peut être due à une localisation incorrecte du fichier JAR du hook de journalisation. Assurez-vous d'avoir ajouté le fichier JAR dans le dossier auxlib sur le cluster Hive. Vous pouvez également spécifier le chemin d'accès complet au fichier JAR dans la propriété hive.aux.jars.path, par exemple, file:///HiveMigrationAssessmentQueryLogsHooks_deploy.jar.

Les sous-dossiers n'apparaissent pas dans le dossier configuré

Ce problème peut être dû à une mauvaise configuration ou à des problèmes lors de l'initialisation du hook de journalisation.

Recherchez, parmi vos journaux de débogage hive-server2, les messages suivants du hook de journalisation :

Unable to initialize logger, logging disabled

Log dir configuration key 'dwhassessment.hook.base-directory' is not set,
logging disabled.

Error while trying to set permission

Examinez les détails du problème et vérifiez si vous devez corriger certains points.

Les fichiers n'apparaissent pas dans le dossier

Ce problème peut être dû à des problèmes rencontrés lors du traitement d'un événement ou lors d'une opération d'écriture dans un fichier.

Recherchez, parmi vos journaux de débogage hive-server2, les messages suivants du hook de journalisation :

Failed to close writer for file

Got exception while processing event

Error writing record for query

Examinez les détails du problème et vérifiez si vous devez corriger certains points.

Il manque certains événements de requête

Ce problème peut être causé par le débordement de la file d'attente des threads du hook de journalisation.

Recherchez, parmi vos journaux de débogage hive-server2, le message suivant du hook de journalisation :

Writer queue is full. Ignoring event

Si vous trouvez de tels messages, envisagez d'augmenter le paramètre dwhassessment.hook.queue.capacity.

Étapes suivantes

Pour en savoir plus sur l'outil dwh-migration-dumper, consultez la page dwh-migration-tools.

Vous pouvez également en apprendre plus sur les étapes suivantes dans la migration d'entrepôts de données :

• Présentation de la migration
• Présentation du transfert de schéma et de données
• Pipelines de données
• Traduction SQL par lot
• Traduction SQL interactive
• Sécurité et gouvernance des données
• Outil de validation des données