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

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

Créez un bucket Cloud Storage.

Remarque : Utilisez l'option --pap pour empêcher les données de votre bucket Cloud Storage d'être accessibles publiquement.
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.
Importez vos métadonnées et journaux de requêtes dans votre bucket Cloud Storage.
Exécutez l'évaluation de la migration.
Consultez le rapport Looker Studio.
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 :

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

Exécuter l'outil `dwh-migration-dumper`

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

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

sha256sum --check SHA256SUMS.txt

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

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

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

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

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

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

Remplacez les éléments suivants :

DATABASES : liste de noms de bases de données à extraire, séparés par une virgule
PATH : chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion
VERSION : version de votre pilote
HOST : adresse hôte
USER : nom d'utilisateur à utiliser pour la connexion à la base de données
PASSWORD : mot de passe à utiliser pour la connexion à la base de données
Si ce champ n'est pas renseigné, l'utilisateur est invité à saisir son mot de passe.

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

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

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 :

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

Importer le hook de journalisation `hadoop-migration-assessment`

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

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

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`	Faibles émissions de CO₂
Caroline du Sud	`us-east1`
Virginie du Nord	`us-east4`
Oregon	`us-west1`	Faibles émissions de CO₂
Los Angeles	`us-west2`
Salt Lake City	`us-west3`

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

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

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

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

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

Emplacements multirégionaux

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

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

Avant de commencer

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

Activer l'API BigQuery Migration

Activez l'API BigQuery Migration comme suit :

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

Accéder à l'API BigQuery Migration
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

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

Accéder à BigQuery
Dans le panneau de navigation, accédez à Évaluation.
Cliquez sur Démarrer l'évaluation.
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.
Cliquez sur Créer. Vous pouvez voir l'état de la tâche dans la liste des tâches de traduction.
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 :

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

Cliquez sur Modifier et partager. Looker Studio vous invite à associer des connecteurs Looker nouvellement créés au nouveau rapport.
Cliquez sur Ajouter au rapport. Le rapport reçoit un ID de rapport individuel, que vous pouvez utiliser pour y accéder.
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.
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 :

Évaluation de la migration

Présentation

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

Teradata

Conditions requises

Condition requise : Activer la journalisation

Exécuter l'outil dwh-migration-dumper

Bash

Windows PowerShell

Amazon Redshift

Conditions requises

Exécuter l'outil dwh-migration-dumper

Apache Hive

Conditions requises

Exécuter l'outil dwh-migration-dumper

Sans authentification

Avec authentification Kerberos

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

Importer le hook de journalisation hadoop-migration-assessment

Configurer les propriétés

Vérifier le hook de journalisation

Snowflake

Conditions requises

Exécuter l'outil dwh-migration-dumper

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

Teradata

Amazon Redshift

Apache Hive

Snowflake

Exécuter une évaluation de migration BigQuery

Autorisations requises

Pays acceptés

Régions

Emplacements multirégionaux

Avant de commencer

Activer l'API BigQuery Migration

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

Exécuter l'évaluation de la migration

Console

API

Examiner et partager le rapport Looker Studio

Consulter le rapport

Teradata

Amazon Redshift

Apache Hive

Snowflake

Vues concernant les caractéristiques de la migration

Vues concernant le système existant

Vues sur l'état stable de BigQuery

Vues concernant le plan de migration

Vues concernant la démonstration de faisabilité

Partager le rapport

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

Exemple de requête

Schémas des tables d'évaluation

Teradata

AllRIChildren

AllRIParents

Columns

DiskSpace

Functions

Indices

Queries

QueryLogs

QueryTypeStatistics

ResUsageScpu

Roles

Conversion de schéma

TableInfo

TableRelations

TableSizes

Users

Amazon Redshift

Columns

CreateAndDropStatistic

Databases

ExternalColumns

ExternalDatabases

ExternalPartitions

ExternalSchemas

Exécuter l'outil `dwh-migration-dumper`

Exécuter l'outil `dwh-migration-dumper`

Exécuter l'outil `dwh-migration-dumper`

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

Importer le hook de journalisation `hadoop-migration-assessment`

Exécuter l'outil `dwh-migration-dumper`

`AllRIChildren`

`AllRIParents`

`Columns`

`DiskSpace`

`Functions`

`Indices`

`Queries`

`QueryLogs`

`QueryTypeStatistics`

`ResUsageScpu`

`Roles`

`TableInfo`

`TableRelations`

`TableSizes`

`Users`

`Columns`

`CreateAndDropStatistic`

`Databases`

`ExternalColumns`

`ExternalDatabases`

`ExternalPartitions`

`ExternalSchemas`

`ExternalTables`

`Functions`

`Queries`

`QueryLogs`

`QueryTypeStatistics`

`TableInfo`

`TableRelations`

`TableSizes`

`Tables`

`TranslatedQueries`

`TranslationErrors`

`UserTableRelations`

`Users`

`Columns`

`CreateAndDropStatistic`

`Databases`

`Functions`

`ObjectReferences`

`ParititionKeys`

`Parititions`

`Queries`

`QueryLogs`

`QueryTypeStatistics`

`QueryTypes`

`TableRelations`

`TableSizes`

`Tables`

`TranslatedQueries`

`TranslationErrors`

`UserTableRelations`

`Warehouses`

`Databases`

`Schemata`

`Tables`

`Columns`

`CreateAndDropStatistics`

`Queries`

`QueryLogs`

`QueryTypeStatistics`

`TranslationErrors`

`UserTableRelations`

Erreurs de l'outil `dwh-migration-dumper`

Gérer l'erreur `ClassNotFoundException`.