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

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

  3. Importez vos métadonnées et 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

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 :

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.

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

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

Pour demander des conseils ou obtenir de l'aide pour cette fonctionnalité, envoyez un e-mail à l'adresse bq-edw-migration-support@google.com.

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

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

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êtes 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

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

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

Pour demander des conseils ou obtenir de l'aide pour cette fonctionnalité, envoyez un e-mail à l'adresse bq-edw-migration-support@google.com.

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

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 de 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êtes 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 de métadonnées et de journaux 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

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 Icône Feuille Faibles émissions de CO2
Caroline du Sud us-east1
Virginie du Nord us-east4
Oregon us-west1 Icône Feuille 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 Icône Feuille Faibles émissions de CO2
Finlande europe-north1 Icône Feuille Faibles émissions de CO2
Francfort europe-west3 icône feuille Faibles émissions de CO2
Londres europe-west2 icône feuille Faibles émissions de CO2
Madrid europe-southwest1
Pays-Bas europe-west4
Paris europe-west9 Icône Feuille Faibles émissions de CO2
Turin europe-west12
Varsovie europe-central2
Zurich europe-west6 Icône Feuille Faibles émissions de CO2

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.

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. Le job d'évaluation doit se trouver au même emplacement que le bucket Cloud Storage d'entrée des fichiers extraits et l'ensemble de données BigQuery de sortie.

      Toutefois, s'il s'agit d'un emplacement multirégional US ou EU, l'emplacement du bucket Cloud Storage et l'emplacement de l'ensemble de données BigQuery peuvent se trouver dans n'importe quelle région de cet emplacement multirégional. Le bucket Cloud Storage et l'ensemble de données BigQuery peuvent être situés à différents emplacements d'un même emplacement multirégional. Par exemple, si vous sélectionnez l'emplacement multirégional US, le bucket Cloud Storage peut se trouver dans la région us-central1, tandis que l'ensemble de données BigQuery peut se trouver dans la région us-east1.

    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.

    Boîte de dialogue de configuration de l'évaluation pour Teradata

  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 :

Rapport d'évaluation.

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

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 :

Organigramme du rapport d'évaluation de la migration pour Snowflake

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 la 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

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

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.

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 :