Traduire des requêtes avec le traducteur SQL interactif

Ce document explique comment traduire une requête d'un autre dialecte SQL en une requête GoogleSQL à l'aide de la traduction SQL interactive de BigQuery. La traduction SQL interactive peut vous aider à réduire le temps et les efforts de migration des charges de travail vers BigQuery. Ce document est destiné aux utilisateurs qui connaissent déjà la consoleGoogle Cloud .

Si votre emplacement est compatible, vous pouvez utiliser la fonctionnalité de règle de traduction pour personnaliser la façon dont le traducteur SQL interactif traduit le langage SQL.

Avant de commencer

Si votre projet Google Cloud CLI a été créé avant le 15 février 2022, activez l'API BigQuery Migration comme suit :

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

   Accéder à l'API BigQuery Migration

2. Cliquez sur Activer.

Autorisations et rôles

Cette section décrit les autorisations IAM (Identity and Access Management) dont vous avez besoin pour utiliser la traduction SQL interactive, ainsi que les rôles IAM prédéfinis qui accordent ces autorisations. La section décrit également les autorisations nécessaires pour définir des configurations de traduction supplémentaires.

Autorisations nécessaires pour l'utilisation du traducteur SQL interactif

Pour obtenir les autorisations nécessaires pour utiliser le traducteur interactif, demandez à votre administrateur de vous accorder le rôle IAM Éditeur MigrationWorkflow (roles/bigquerymigration.editor) sur la ressource parent. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour utiliser le traducteur interactif. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Autorisations permettant de définir des configurations de traduction supplémentaires

Vous pouvez définir des configurations de traduction supplémentaires à l'aide des champs ID de configuration de traduction et Emplacement source de la configuration de traduction dans les paramètres de traduction. Pour définir ces configurations de traduction, vous devez disposer des autorisations suivantes :

• bigquerymigration.workflows.get
• bigquerymigration.workflows.list

Le rôle IAM prédéfini suivant fournit les autorisations dont vous avez besoin pour définir des configurations de traduction supplémentaires :

• roles/bigquerymigration.viewer

Pour plus d'informations sur BigQuery IAM, consultez la page Contrôle des accès avec IAM.

Dialectes SQL pris en charge

Le traducteur SQL interactif de BigQuery peut traduire le dialecte SQL suivant en langage GoogleSQL :

• Amazon Redshift SQL
• CLI Apache HiveQL et Beeline
• IBM Netezza SQL et NZPLSQL
• Teradata et Teradata Vantage :
  • SQL
  • Basic Teradata Query (BTEQ)
  • Teradata Parallel Transport (TPT)

De plus, la traduction des dialectes SQL suivants est disponible en version bêta :

• Apache Spark SQL
• Azure Snapse T-SQL
• Greenplum SQL
• IBM DB2 SQL
• MySQL SQL
• Oracle SQL, PL/SQL et Exadata
• PostgreSQL SQL
• Trino ou PrestoSQL
• Snowflake SQL
• SQL Server T-SQL
• SQLite
• Vertica SQL

Gérer les fonctions SQL non compatibles avec des fonctions définies par l'utilisateur d'assistance

Lorsque vous traduisez du code SQL d'un dialecte source vers BigQuery, certaines fonctions peuvent ne pas avoir d'équivalent direct. Pour résoudre ce problème, le service de migration BigQuery (et la communauté BigQuery au sens large) fournit des fonctions définies par l'utilisateur (UDF) d'assistance qui reproduisent le comportement de ces fonctions de dialecte source non compatibles.

Ces UDF se trouvent souvent dans l'ensemble de données public bqutil, ce qui permet aux requêtes traduites de les référencer initialement au format bqutil.<dataset>.<function>(). Par exemple, bqutil.fn.cw_count().

Voici quelques remarques importantes concernant les environnements de production :

Bien que bqutil offre un accès pratique à ces UDF d'assistance pour la traduction et les tests initiaux, il n'est pas recommandé de s'appuyer directement sur bqutil pour les charges de travail de production pour plusieurs raisons :

1. Contrôle des versions : le projet bqutil héberge la dernière version de ces UDF, ce qui signifie que leurs définitions peuvent changer au fil du temps. S'appuyer directement sur bqutil peut entraîner un comportement inattendu ou des modifications incompatibles dans vos requêtes de production si la logique d'une UDF est mise à jour.
2. Isolation des dépendances : le déploiement d'UDF dans votre propre projet isole votre environnement de production des modifications externes.
3. Personnalisation : vous devrez peut-être modifier ou optimiser ces UDF pour mieux les adapter à votre logique métier ou à vos exigences de performances spécifiques. Cela n'est possible que s'ils se trouvent dans votre propre projet.
4. Sécurité et gouvernance : les règles de sécurité de votre organisation peuvent restreindre l'accès direct aux ensembles de données publics tels que bqutil pour le traitement des données de production. La copie des UDF dans votre environnement contrôlé est conforme à ces règles.

Déployer des UDF d'assistance dans votre projet :

Pour une utilisation fiable et stable en production, vous devez déployer ces UDF d'assistance dans votre propre projet et ensemble de données. Vous contrôlez ainsi totalement leur version, leur personnalisation et leur accès. Pour obtenir des instructions détaillées sur le déploiement de ces UDF, consultez le guide de déploiement des UDF sur GitHub. Ce guide fournit les scripts et les étapes nécessaires pour copier les UDF dans votre environnement.

Emplacements

La traduction SQL interactive n'est disponible que dans les emplacements de traitement suivants :

	Description de la région	Nom de la région	Détail
Asie-Pacifique
	Delhi	asia-south2
	Hong Kong	asia-east2
	Jakarta	asia-southeast2
	Melbourne	australia-southeast2
	Mumbai	asia-south1
	Osaka	asia-northeast2
	Séoul	asia-northeast3
	Singapour	asia-southeast1
	Sydney	australia-southeast1
	Taïwan	asia-east1
	Tokyo	asia-northeast1
Europe
	Belgique	europe-west1	Faibles émissions de CO2
	Berlin	europe-west10	Faibles émissions de CO2
	UE (multirégional)	eu
	Finlande	europe-north1	Faibles émissions de CO2
	Francfort	europe-west3
	Londres	europe-west2	Faibles émissions de CO2
	Madrid	europe-southwest1	Faibles émissions de CO2
	Milan	europe-west8
	Pays-Bas	europe-west4	Faibles émissions de CO2
	Paris	europe-west9	Faibles émissions de CO2
	Stockholm	europe-north2	Faibles émissions de CO2
	Turin	europe-west12
	Varsovie	europe-central2
	Zurich	europe-west6	Faibles émissions de CO2
Amériques
	Columbus, Ohio	us-east5
	Dallas	us-south1	Faibles émissions de CO2
	Iowa	us-central1	Faibles émissions de CO2
	Las Vegas	us-west4
	Los Angeles	us-west2
	Mexique	northamerica-south1
	Virginie du Nord	us-east4
	Oregon	us-west1	Faibles émissions de CO2
	Québec	northamerica-northeast1	Faibles émissions de CO2
	São Paulo	southamerica-east1	Faibles émissions de CO2
	Salt Lake City	us-west3
	Santiago	southamerica-west1	Faibles émissions de CO2
	Caroline du Sud	us-east1
	Toronto	northamerica-northeast2	Faibles émissions de CO2
	États-Unis (multirégional)	us
Afrique
	Johannesburg	africa-south1
MiddleEast
	Dammam	me-central2
	Doha	me-central1
	Israël	me-west1

Par défaut, la fonctionnalité de règle de traduction est disponible dans les emplacements de traitement suivants :

• us (États-Unis - multirégional)
• eu (UE - multirégional)
• us-central1 (Iowa)
• europe-west4 (Pays-Bas)

Les configurations de traduction basées sur Gemini ne sont disponibles que dans des emplacements de traitement spécifiques. Pour en savoir plus, consultez Emplacements des points de terminaison des modèles Google.

Traduire une requête en langage GoogleSQL

Pour traduire une requête en langage GoogleSQL, procédez comme suit :

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

   Accéder à BigQuery

2. Dans le volet Éditeur, cliquez sur Plus, puis sélectionnez Paramètres de traduction.

3. Pour le champ Dialecte source, sélectionnez le dialecte SQL que vous souhaitez traduire.

4. Facultatif. Dans le champ Emplacement du traitement, sélectionnez l'emplacement où vous souhaitez exécuter la tâche de traduction. Par exemple, si vous êtes en Europe et que vous ne souhaitez pas que vos données dépassent les limites d'emplacement, sélectionnez la région eu.

5. Cliquez sur Enregistrer.

6. Dans le volet Éditeur, cliquez sur Plus, puis sélectionnez Activer la traduction SQL.

   Le volet Éditeur se divise en deux volets.

7. Dans le volet de gauche, saisissez la requête que vous souhaitez traduire.

8. Cliquez sur Traduire.

   BigQuery traduit votre requête en langage GoogleSQL et l'affiche dans le volet de droite. Par exemple, la capture d'écran suivante montre le langage SQL Teradata traduit :

   

9. Facultatif : Pour exécuter la requête GoogleSQL traduite, cliquez sur Exécuter.

10. Facultatif : Pour revenir à l'éditeur SQL, cliquez sur Plus, puis sélectionnez Désactiver la traduction SQL.

    Le volet Éditeur revient à un seul panneau.

Utiliser Gemini avec le traducteur SQL interactif

Vous pouvez configurer le traducteur SQL interactif pour ajuster la façon dont il traduit votre code SQL source. Pour ce faire, vous pouvez fournir vos propres règles à utiliser avec Gemini dans un fichier de configuration YAML, ou fournir un fichier de configuration YAML contenant des métadonnées d'objet SQL ou des informations de mappage d'objet.

Créer et appliquer des règles de traduction optimisées par Gemini

Vous pouvez personnaliser la façon dont le traducteur SQL interactif traduit le langage SQL en créant des règles de traduction. Le traducteur SQL interactif ajuste ses traductions en fonction des règles de traduction SQL améliorées de Gemini que vous lui attribuez, ce qui vous permet de personnaliser les résultats de traduction en fonction de vos besoins de migration. Cette fonctionnalité n'est disponible que dans certains emplacements.

Pour créer une règle de traduction SQL améliorée par Gemini, vous pouvez la créer dans la console ou créer un fichier YAML de configuration et l'importer dans Cloud Storage.

Mettre à jour le fichier YAML de configuration basé sur Gemini

Pour mettre à jour un fichier YAML de configuration existant, procédez comme suit :

1. Dans la boîte de dialogue Suggestions générées dans Gemini, cliquez sur Afficher le fichier de configuration des règles Gemini.

2. Lorsque l'éditeur de configuration s'affiche, sélectionnez le fichier YAML de configuration que vous souhaitez modifier.

3. Apportez la modification, puis cliquez sur Enregistrer.

4. Fermez l'éditeur YAML en cliquant sur OK.

5. Exécutez une traduction interactive pour appliquer la règle modifiée.

Expliquer une traduction

Après avoir exécuté une traduction interactive, vous pouvez demander une explication textuelle générée par Gemini. Le texte généré inclut un résumé de la requête SQL traduite. Gemini identifie également les différences et les incohérences de traduction entre la requête SQL source et la requête GoogleSQL traduite.

Pour obtenir une explication de la traduction SQL générée par Gemini, procédez comme suit :

1. Pour créer une explication de traduction SQL générée par Gemini, cliquez sur Aide, puis sur Expliquer cette traduction.

   

Traduire avec un ID de configuration de traduction par lot

Vous pouvez exécuter une requête interactive avec les mêmes configurations de traduction qu'une tâche de traduction par lot en fournissant un ID de configuration de traduction par lot.

1. Dans l'éditeur de requête, cliquez sur Plus > Paramètres de traduction.

2. Dans le champ ID de configuration de traduction, indiquez un ID de configuration de traduction par lot pour appliquer la même configuration de traduction à partir d'une tâche de migration par lot BigQuery terminée.

   Pour trouver l'ID de configuration de la traduction par lot d'un job, sélectionnez une tâche de traduction par lot sur la page Traduction SQL, puis cliquez sur l'onglet Configuration de la traduction. L'ID de configuration de la traduction par lot est répertorié en tant que Nom de ressource.

3. Cliquez sur Enregistrer.

Traduire avec des configurations supplémentaires

Vous pouvez exécuter une requête interactive avec des configurations de traduction supplémentaires en spécifiant des fichiers YAML de configuration stockés dans un dossier Cloud Storage. Les configurations de traduction peuvent inclure des métadonnées d'objet SQL ou des informations de mappage d'objets à partir de la base de données source, ce qui peut améliorer la qualité de la traduction. Par exemple, incluez des informations ou des schémas LDD de la base de données source pour améliorer la qualité de la traduction SQL interactive.

Pour spécifier des configurations de traduction en fournissant un emplacement pour les fichiers sources de la configuration de traduction, procédez comme suit :

1. Dans l'éditeur de requête, cliquez sur Plus > Paramètres de traduction.

2. Dans le champ Emplacement source de la configuration de traduction, spécifiez le chemin d'accès aux fichiers de configuration de traduction stocké dans un dossier Cloud Storage.

   La traduction SQL interactive de BigQuery accepte les fichiers ZIP de métadonnées contenant des métadonnées de traduction et le mappage de noms d'objets. Pour en savoir plus sur l'importation de fichiers dans Cloud Storage, consultez la page Importer des objets à partir d'un système de fichiers.

3. Cliquez sur Enregistrer.

Pour stocker les informations des fichiers de métadonnées générés par l'outil dwh-migration-dumper dans le backend BigQuery, procédez comme suit :

1. Dans l'éditeur de requête, cliquez sur Plus > Paramètres de traduction.
2. Cochez la case Activer la mise en cache des métadonnées. Pour les jobs avec des fichiers de métadonnées volumineux, ce processus réduit considérablement la latence de traduction pour les demandes ultérieures. Les métadonnées mises en cache sont actives pendant sept jours maximum. Cette fonctionnalité est disponible en version bêta. Pour demander de l'aide ou envoyer des commentaires sur cette fonctionnalité, contactez bq-edw-migration-support@google.com.
3. Cliquez sur Enregistrer.

Limites de taille des fichiers de configuration

Lorsque vous utilisez un fichier de configuration de traduction avec le traducteur SQL interactif de BigQuery, le fichier de métadonnées compressé ou le fichier de configuration YAML doit être inférieur à 50 Mo. Si la taille du fichier dépasse 50 Mo, le traducteur interactif ignore ce fichier de configuration lors de la traduction et génère un message d'erreur semblable à celui-ci :

CONFIG ERROR: Skip reading file "gs://metadata-file.zip". File size (150,000,000 bytes) exceeds limit (50 MB).

Une méthode permettant de réduire la taille du fichier de métadonnées consiste à utiliser les options --database ou --schema pour n'extraire que les métadonnées de bases de données ou de schémas pertinents pour les requêtes d'entrée de traduction. Pour en savoir plus sur l'utilisation de ces options lorsque vous générez des fichiers de métadonnées, consultez la page Options globales.

Résoudre les erreurs de traduction

Les erreurs suivantes sont fréquentes lors de l'utilisation du traducteur SQL interactif.

Problèmes de traduction RelationNotFound ou AttributeNotFound

Pour garantir une traduction plus précise, vous pouvez saisir les instructions LDD (langage de définition de données) pour toutes les tables utilisées dans une requête avant la requête elle-même. Par exemple, si vous souhaitez traduire la requête Amazon Redshift select table1.field1, table2.field1 from table1, table2 where table1.id = table2.id;, vous devez saisir les instructions SQL suivantes dans le traducteur SQL interactif :

create table schema1.table1 (id int, field1 int, field2 varchar(16));
create table schema1.table2 (id int, field1 varchar(30), field2 date);

select table1.field1, table2.field1
from table1, table2
where table1.id = table2.id;

Tarifs

L'utilisation du traducteur SQL interactif est gratuite. En revanche, le stockage des fichiers d'entrée et de sortie entraîne des frais normaux. Pour en savoir plus, consultez les tarifs de stockage.

Étapes suivantes

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

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