É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 :
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.
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 tabledbc.DBQLSqlTbl
. Activez la journalisation en spécifiant l'optionWITH SQL
. - Journaux utilitaires : extraits de la table
dbc.DBQLUtilityTbl
. Activez la journalisation en spécifiant l'optionWITH UTILITYINFO
. - Journaux d'utilisation des ressources : extraits des tables
dbc.ResUsageScpu
etdbc.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 virgulePATH
: chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexionVERSION
: version de votre piloteHOST
: adresse hôteUSER
: nom d'utilisateur à utiliser pour la connexion à la base de donnéesPASSWORD
: mot de passe à utiliser pour la connexion à la base de donnéesSi 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 connecterPATH
: chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexionVERSION
: version de votre piloteUSER
: nom d'utilisateur à utiliser pour la connexion à la base de donnéesPASSWORD
: mot de passe à utiliser pour la connexion à la base de donnéesSi 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 émisHOST
: nom d'hôte kerberos pour lequel le ticket est émishadoop.rpc.protection
: qualité de protection (QOP) du niveau de configuration SASL (Simple Authentication and Security Layer), égale à la valeur du paramètrehadoop.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 exemplefile://
./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 est64
.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 droitsIMPORTED PRIVILEGES
sur la base de donnéesSnowflake
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'outildwh-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 formatYYYY-MM-DD
.ENDING_DATE
: (facultatif) permet d'indiquer la date de fin dans une plage de dates des journaux de requête, au formatYYYY-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_
etdbc.ResUsageSpma_
.
La taille totale non compressée de l'ensemble des fichiers d'historique des requêtes est limitée à 5 To. La taille totale non compressée de l'ensemble des fichiers de séries temporelles est limitée à 1 To.
Si les journaux de requête sont archivés dans une autre base de données, consultez la description des options -Dteradata-logs.query-logs-table
et -Dteradata-logs.sql-logs-table
plus haut dans cette section, qui explique comment fournir un autre emplacement pour les journaux de requêtes.
Amazon Redshift
Importez les métadonnées et un ou plusieurs fichiers ZIP contenant les journaux de requêtes dans votre bucket Cloud Storage. Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers. La taille totale non compressée de l'ensemble des fichiers présents dans le fichier ZIP de métadonnées est limitée à 50 Go.
Les entrées de tous les fichiers ZIP contenant les journaux de requête sont divisées comme suit :
- Les fichiers d'historique des requêtes portent les préfixes
querytext_
etddltext_
. - Les fichiers de séries temporelles portent les préfixes
query_queue_info_
,wlm_query_
etquerymetrics_
.
La taille totale non compressée de l'ensemble des fichiers d'historique des requêtes est limitée à 5 To. La taille totale non compressée de l'ensemble des fichiers de séries temporelles est limitée à 1 To.
Apache Hive
Pour demander des conseils ou obtenir de l'aide pour cette fonctionnalité, envoyez un e-mail à l'adresse bq-edw-migration-support@google.com
.
Importez les métadonnées et les dossiers contenant les journaux de requêtes d'un ou de plusieurs clusters Hive dans votre bucket Cloud Storage. Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers.
La taille totale non compressée de l'ensemble des fichiers présents dans le fichier ZIP de métadonnées est limitée à 50 Go.
Vous pouvez utiliser le connecteur Cloud Storage pour copier les journaux de requêtes directement dans le dossier Cloud Storage. Les dossiers contenant des sous-dossiers avec des journaux de requêtes doivent être importés dans le même dossier Cloud Storage que celui dans lequel est importé le fichier ZIP de métadonnées.
Les dossiers de journaux de requêtes contiennent des fichiers d'historique des requêtes comportant le préfixe dwhassessment_
. La taille totale non compressée de l'ensemble des fichiers d'historique des requêtes est limitée à 5 To.
Snowflake
Importez les métadonnées, les fichiers ZIP contenant les journaux de requête et les historiques d'utilisation dans votre bucket Cloud Storage. Lorsque vous importez ces fichiers dans Cloud Storage, les conditions suivantes doivent être remplies :
- La taille totale non compressée de tous les fichiers dans le fichier ZIP de métadonnées doit être inférieure à 50 Go.
- Le fichier ZIP de métadonnées et le fichier ZIP contenant les journaux de requête doivent être importés dans un dossier Cloud Storage. Si plusieurs fichiers ZIP contiennent des journaux de requêtes qui ne se chevauchent pas, vous pouvez tous les importer.
- Vous devez importer tous les fichiers dans le même dossier Cloud Storage.
- Vous devez importer tous les fichiers ZIP de métadonnées et de journaux de requêtes exactement tels qu'ils sont générés par l'outil
dwh-migration-dumper
. Vous ne devez pas les décompresser, les combiner ni les modifier. - La taille totale non compressée de tous les fichiers de l'historique des requêtes doit être inférieure à 5 To.
Pour en savoir plus sur la création de buckets et l'importation de fichiers dans Cloud Storage, consultez les pages Créer des buckets et Importer des objets à partir d'un système de fichiers.
Exécuter une évaluation de migration BigQuery
Suivez la procédure ci-dessous pour exécuter l'évaluation de la migration BigQuery. Ces étapes supposent que vous avez importé les fichiers de métadonnées dans un bucket Cloud Storage, comme décrit dans la section précédente.
Autorisations requises
Pour activer le service de migration BigQuery, vous devez disposer des autorisations Identity and Access Management (IAM) suivantes :
resourcemanager.projects.get
resourcemanager.projects.update
serviceusage.services.enable
serviceusage.services.get
Pour accéder au service de migration BigQuery et l'utiliser, vous devez disposer des autorisations suivantes sur le projet :
bigquerymigration.workflows.create
bigquerymigration.workflows.get
bigquerymigration.workflows.list
bigquerymigration.workflows.delete
bigquerymigration.subtasks.get
bigquerymigration.subtasks.list
Pour exécuter le service de migration BigQuery, vous devez disposer des autorisations supplémentaires suivantes.
Autorisation d'accéder aux buckets Cloud Storage pour les fichiers d'entrée et de sortie :
storage.objects.get
sur le bucket Cloud Storage sourcestorage.objects.list
sur le bucket Cloud Storage sourcestorage.objects.create
sur le bucket Cloud Storage de destinationstorage.objects.delete
sur le bucket Cloud Storage de destinationstorage.objects.update
sur le bucket Cloud Storage de destinationstorage.buckets.get
storage.buckets.list
Autorisation de lire et de mettre à jour l'ensemble de données BigQuery dans lequel le service de migration BigQuery écrit les résultats :
bigquery.datasets.update
bigquery.datasets.get
bigquery.datasets.create
bigquery.datasets.delete
bigquery.jobs.create
bigquery.jobs.delete
bigquery.jobs.list
bigquery.jobs.update
bigquery.tables.create
bigquery.tables.get
bigquery.tables.getData
bigquery.tables.list
bigquery.tables.updateData
Pour partager le rapport Looker Studio avec un utilisateur, vous devez attribuer les rôles suivants :
roles/bigquery.dataViewer
roles/bigquery.jobUser
Pour personnaliser ce document afin d'utiliser votre propre projet et votre propre utilisateur dans les commandes, modifiez les variables suivantes : PROJECT
, USER_EMAIL
.
Créez un rôle personnalisé avec les autorisations nécessaires pour utiliser l'évaluation de la migration BigQuery :
gcloud iam roles create BQMSrole \ --project=PROJECT \ --title=BQMSrole \ --permissions=bigquerymigration.subtasks.get,bigquerymigration.subtasks.list,bigquerymigration.workflows.create,bigquerymigration.workflows.get,bigquerymigration.workflows.list,bigquerymigration.workflows.delete,resourcemanager.projects.update,resourcemanager.projects.get,serviceusage.services.enable,serviceusage.services.get,storage.objects.get,storage.objects.list,storage.objects.create,storage.objects.delete,storage.objects.update,bigquery.datasets.get,bigquery.datasets.update,bigquery.datasets.create,bigquery.datasets.delete,bigquery.tables.get,bigquery.tables.create,bigquery.tables.updateData,bigquery.tables.getData,bigquery.tables.list,bigquery.jobs.create,bigquery.jobs.update,bigquery.jobs.list,bigquery.jobs.delete,storage.buckets.list,storage.buckets.get
Attribuez le rôle personnalisé BQMSrole
à un utilisateur :
gcloud projects add-iam-policy-binding \ PROJECT \ --member=user:USER_EMAIL \ --role=projects/PROJECT/roles/BQMSrole
Attribuez les rôles requis à un utilisateur avec lequel vous souhaitez partager le rapport :
gcloud projects add-iam-policy-binding \ PROJECT \ --member=user:USER_EMAIL \ --role=roles/bigquery.dataViewer gcloud projects add-iam-policy-binding \ PROJECT \ --member=user:USER_EMAIL \ --role=roles/bigquery.jobUser
Pays acceptés
La fonctionnalité d'évaluation de la migration BigQuery est compatible avec deux types d'emplacements :
Une région est un emplacement géographique spécifique, par exemple Londres.
Un emplacement multirégional correspond à un secteur géographique de grande étendue, par exemple les États-Unis, et comporte au moins deux régions. Les emplacements multirégionaux peuvent fournir des quotas plus élevés que les régions uniques.
Pour en savoir plus sur les régions et les zones, consultez la section Zones géographiques et régions.
Régions
Le tableau suivant répertorie les régions Amériques où l'évaluation de la migration BigQuery est disponible.Description de la région | Nom de la région | Détails |
---|---|---|
Columbus, Ohio | us-east5 |
|
Dallas | us-south1 |
|
Iowa | us-central1 |
Faibles émissions de CO2 |
Caroline du Sud | us-east1 |
|
Virginie du Nord | us-east4 |
|
Oregon | us-west1 |
Faibles émissions de CO2 |
Los Angeles | us-west2 |
|
Salt Lake City | us-west3 |
Description de la région | Nom de la région | Détails |
---|---|---|
Singapour | asia-southeast1 |
|
Tokyo | asia-northeast1 |
Description de la région | Nom de la région | Détails |
---|---|---|
Belgique | europe-west1 |
Faibles émissions de CO2 |
Finlande | europe-north1 |
Faibles émissions de CO2 |
Francfort | europe-west3 |
Faibles émissions de CO2 |
Londres | europe-west2 |
Faibles émissions de CO2 |
Madrid | europe-southwest1 |
|
Pays-Bas | europe-west4 |
|
Paris | europe-west9 |
Faibles émissions de CO2 |
Turin | europe-west12 |
|
Varsovie | europe-central2 |
|
Zurich | europe-west6 |
Faibles émissions de CO2 |
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.
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.
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.
- 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.
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
ouEU
, 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égionalUS
, le bucket Cloud Storage peut se trouver dans la régionus-central1
, tandis que l'ensemble de données BigQuery peut se trouver dans la régionus-east1
.Dans le champ Source de données d'évaluation, choisissez votre entrepôt de données.
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.
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 :
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)
- Utilisation du processeur :
- 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
ouJOIN
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 instructionMERGE
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
ouJOIN
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)
- Utilisation du processeur :
- 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
- Calcul et requêtes
É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
- Vue détaillée avec les requêtes traduites automatiquement
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
ouJOIN
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 :
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://
.
Les sous-dossiers n'apparaissent pas dans le dossier configuré
Ce problème peut être dû à une mauvaise configuration ou à des problèmes lors de l'initialisation du hook de journalisation.
Recherchez, parmi vos journaux de débogage hive-server2
, les messages suivants du hook de journalisation :
Unable to initialize logger, logging disabled
Log dir configuration key 'dwhassessment.hook.base-directory' is not set, logging disabled.
Error while trying to set permission
Examinez les détails du problème et vérifiez si vous devez corriger certains points.
Les fichiers n'apparaissent pas dans le dossier
Ce problème peut être dû à des problèmes rencontrés lors du traitement d'un événement ou lors d'une opération d'écriture dans un fichier.
Recherchez, parmi vos journaux de débogage hive-server2
, les messages suivants du hook de journalisation :
Failed to close writer for file
Got exception while processing event
Error writing record for query
Examinez les détails du problème et vérifiez si vous devez corriger certains points.
Il manque certains événements de requête
Ce problème peut être causé par le débordement de la file d'attente des threads du hook de journalisation.
Recherchez, parmi vos journaux de débogage hive-server2
, le message suivant du hook de journalisation :
Writer queue is full. Ignoring event
Si vous trouvez de tels messages, envisagez d'augmenter le paramètre dwhassessment.hook.queue.capacity
.
Étapes suivantes
Pour en savoir plus sur l'outil dwh-migration-dumper
, consultez la page dwh-migration-tools.
Vous pouvez également en apprendre plus sur les étapes suivantes dans la migration d'entrepôts de données :
- Présentation de la migration
- Présentation du transfert de schéma et de données
- Pipelines de données
- Traduction SQL par lot
- Traduction SQL interactive
- Sécurité et gouvernance des données
- Outil de validation des données