Migrer des données depuis Teradata

La combinaison du service de transfert de données BigQuery et d'un agent de migration spécial vous permet de copier vos données d'une instance d'entrepôt de données sur site Teradata vers BigQuery. Ce document décrit le processus détaillé de migration des données depuis Teradata à l'aide du service de transfert de données BigQuery.

Avant de commencer

Pour garantir la réussite de la migration de l'entrepôt de données Teradata, assurez-vous que vous remplissez les conditions préalables suivantes.

Exigences de Google Cloud

Sélectionnez ou créez un projet Google Cloud pour stocker vos données de migration. Vous devez disposer des autorisations owner sur le projet Google Cloud pour configurer le transfert.
- Dans Cloud Console, accédez à la page de sélection du projet.
  
  Accéder à la page de sélection du projet
- Sélectionnez ou créez un projet Cloud.
  
  Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.
Activez ces API Google Cloud.
Console
Dans Google Cloud Console, cliquez sur le bouton ENABLE (ACTIVER) sur les deux pages suivantes.
BigQuery est automatiquement activé dans les nouveaux projets. Pour un projet existant, vous devrez peut-être activer l'API BigQuery.
- API BigQuery
Exemple :

Une coche verte indique que vous avez déjà activé l'API.
CLI
Vous pouvez éventuellement utiliser l'interface de ligne de commande (CLI) gcloud pour activer les API.

Vous pouvez exécuter des commandes gcloud dans Cloud Shell ou télécharger l'outil CLI et l'installer sur la machine locale, comme suit :
- Java 8 doit être installé pour que vous puissiez exécuter l'agent CLI. Utilisez ce lien pour le télécharger.
- Le SDK Cloud doit être installé et initialisé.
Saisissez les commandes gcloud suivantes :
```
  `gcloud services enable bigquerydatatransfer.googleapis.com`
  `gcloud services enable storage-component.googleapis.com`
  `gcloud services enable pubsub.googleapis.com`
```
BigQuery est automatiquement activé dans les nouveaux projets. Pour un projet existant, activez également l'API BigQuery.
```
  `gcloud services enable bigquery.googleapis.com`
```
Créez un ensemble de données BigQuery pour stocker vos données. Vous n'avez pas besoin de créer de tables.
Créez un compte de service Cloud Identity and Access Management. Consultez la page Créer et gérer des comptes de service pour obtenir plus d'informations sur la création d'un compte de service.
Accordez au compte de service les rôles Cloud IAM suivants. Consultez la section Attribuer des rôles à un compte de service.
- BigQuery : rôle Cloud IAM prédéfini bigquery.admin
- Cloud Storage : rôle Cloud IAM prédéfini storage.objectAdmin
Créez un bucket Cloud Storage pour la préproduction des données. Vous utiliserez ce nom de bucket ultérieurement dans le processus de migration.
Autorisez les fenêtres pop-up dans votre navigateur à l'adresse bigquery.cloud.google.com pour afficher la fenêtre des autorisations lorsque vous configurez le transfert. Vous devez autoriser le service de transfert de données BigQuery à gérer le transfert.

Configuration requise sur site

Configuration requise pour la machine locale
- L'agent de migration utilise une connexion JDBC avec l'instance Teradata et les API Google Cloud. Vérifiez que l'accès au réseau n'est pas bloqué par un pare-feu.
- Assurez-vous que l'environnement d'exécution Java 8 ou version ultérieure est installé.
- Assurez-vous que vous disposez de l'espace de stockage minimal recommandé, comme décrit dans la configuration requise pour l'espace de stockage.
Détails de connexion à Teradata
- Nom d'utilisateur et mot de passe d'un utilisateur disposant d'un accès en lecture aux tables système et aux tables en cours de migration.
- Nom d'hôte et numéro de port pour se connecter à l'instance Teradata.
  REMARQUE : Le nom d'utilisateur et le mot de passe seront capturés via une invite et ne seront stockés que dans la RAM. Éventuellement, vous pouvez créer un fichier d'informations d'identification pour le nom d'utilisateur/mot de passe dans une étape ultérieure. Lorsque vous utilisez un fichier d'informations d'identification, prenez les mesures appropriées pour contrôler l'accès au dossier dans lequel vous le stockez sur le système de fichiers local, car il ne sera pas chiffré.
Téléchargez les pilotes JDBC requis à partir de Teradata : tdgssconfig.jar et terajdbc4.jar.
Téléchargez vos identifiants Google Cloud.
- Créer et gérer les clés de comptes de service pour télécharger les informations d'identification.
- Définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS sur la clé de compte de service que vous avez téléchargée, comme indiqué dans la section Configurer la variable d'environnement.

Modes et options de transfert

Comme chaque migration comporte ses propres exigences, l'agent de migration peut être personnalisé de différentes manières. Il existe trois choix principaux lors de la configuration d'un transfert de données de Teradata vers BigQuery :

Méthode d'extraction : JDBC avec FastConnect ou Teradata Parallel Transporter (TPT)
Conversion de schéma automatique ou fichier de schéma personnalisé
Transfert à la demande ou transferts incrémentiels (Bêta)

Méthode d'extraction

Le service de transfert de données BigQuery offre deux méthodes d'extraction différentes pour transférer des données de Teradata vers BigQuery :

Extraction à l'aide du pilote JDBC avec connexion FastExport Dans ce mode, une table est extraite dans une collection de fichiers AVRO à un emplacement spécifié sur un système de fichiers local. Les fichiers extraits sont ensuite importés dans un bucket Cloud Storage spécifié et, après un transfert réussi, les fichiers sont supprimés du système de fichiers local.
- Les limitations de la quantité d'espace dans un système de fichiers local sont pleinement appliquées et l'extraction est mise en pause jusqu'à ce que les fichiers extraits aient été importés et supprimés du système de fichiers local.
- S'il existe des contraintes strictes sur l'espace de stockage local ou si TPT n'est pas disponible, utilisez cette méthode d'extraction.
- Le pilote JDBC avec FastExport est la méthode d'extraction par défaut.
Extraction à l'aide de l'utilitaire Teradata Parallel Transporter (TPT) tbuild. Dans ce mode, un agent effectue le calcul des lots d'extraction à l'aide de lignes réparties par partitions. Pour chaque lot, un script d'extraction TPT est émis et exécuté, générant un ensemble de fichiers délimités par des barres verticales. Après chaque extraction par lots, les fichiers sont importés dans un bucket Cloud Storage spécifié et supprimés du système de fichiers local. Les limitations de la quantité d'espace de stockage dans le système de fichiers local ne sont pas appliquées. Vous devez donc vous assurer que le système de fichiers local dispose d'assez d'espace pour extraire la plus grande partition d'une table Teradata.
- Nous vous recommandons d'extraire avec TPT et de personnaliser votre schéma pour indiquer les colonnes de partition. Ce mode d'extraction de données est le plus rapide.

Pour en savoir plus sur la spécification de la méthode d'extraction, reportez-vous à la section Configurer l'agent de migration de la procédure de configuration du transfert.

Fichier de schéma personnalisé

Un fichier de schéma est un fichier JSON qui décrit des objets de base de données. Le schéma comprend un ensemble de bases de données, chacune contenant un ensemble de tables, lesquelles contiennent chacune un ensemble de colonnes. Chaque colonne possède un champ type, le type attribué à une colonne dans BigQuery.

Dans un fichier de schéma, chaque objet possède un champ name, le nom qui lui sera attribué dans BigQuery. Chaque objet possède également un champ originalName, le nom de l'objet correspondant dans la base de données Teradata.

Le service de transfert de données BigQuery fournit une détection automatique de schéma et une conversion de données lors d'un transfert de données de Teradata vers BigQuery. Vous pouvez également spécifier un fichier de schéma personnalisé. Ceci est facultatif. Il est fortement recommandé de personnaliser le schéma dans certaines situations. Exemples :

Un fichier de schéma personnalisé est particulièrement utile pour inclure des informations supplémentaires sur une table, comme le partitionnement, qui seraient sinon perdues dans la migration si aucun fichier de schéma n'était spécifié.
Pendant le transfert de données, vous pouvez choisir de fournir un fichier de schéma personnalisé pour transformer les champs, par exemple le champ name d'un objet ou le tableau usageType d'une colonne.
Consultez la page Fichier de schéma personnalisé pour plus de détails.

Transferts à la demande ou incrémentiels

Lors de la migration de données d'une instance de base de données Teradata vers BigQuery, le service de transfert de données BigQuery assure aussi bien les transferts de données instantanés (transferts à la demande) que les transferts récurrents et périodiques de lignes nouvelles et mises à jour (transferts incrémentiels) (bêta). Les modes de transfert à la demande ou incrémentiel sont définis dans les options de planification à l'étape Configurer un transfert.

Transfert de données à la demande
- Si votre table est très volumineuse et que le mode d'extraction par TPT offrant de meilleures performances est disponible, nous vous recommandons de partitionner votre table Teradata pour pouvoir effectuer l'extraction partition par partition. Pour plus de détails, reportez-vous à la section Fichier de schéma personnalisé.
- Si vos tables sont petites ou si vous ne pouvez pas utiliser TPT, suivez les instructions de base. La personnalisation du schéma n'est pas nécessaire.

Transfert de données incrémentiel
- Si vous souhaitez migrer périodiquement les modifications de Teradata vers BigQuery, utilisez le mode incrémentiel. Les enregistrements nouveaux et modifiés de Teradata sont ajoutés aux tables BigQuery de manière récurrente.
- Cette méthode nécessite de personnaliser votre schéma pour annoter les colonnes COMMIT_TIMESTAMP.
- Certaines conditions s'appliquent lors de la configuration de transferts incrémentiels. Pour plus d'informations, reportez-vous à la section Transferts incrémentiels.

Configurer une migration Teradata

Cette section décrit le processus étape par étape de configuration d'une migration de données de Teradata vers BigQuery. Voici la procédure à suivre :

Téléchargez l'agent de migration.
Configurez un transfert avec le service de transfert de données BigQuery.
Initialisez l'agent de migration.
Exécutez l'agent de migration.

Télécharger l'agent de migration

Utilisez ce lien pour télécharger l"agent de migration sur la machine locale où se trouve l'entrepôt de données.

Après avoir installé l'agent de migration, configurez un transfert avec le service de transfert de données BigQuery, initialisez l'agent de migration, puis exécutez-le pour démarrer la migration des données.

Configurer un transfert

Créez un transfert avec le service de transfert de données BigQuery.

Console

Dans Google Cloud Console, accédez à l'UI Web de BigQuery.

Accéder à Cloud Console
Cliquez sur Transferts.
Cliquez sur Créer un transfert.
Sous Source type (Type de source) :
- Sélectionnez Migration: Teradata (Migration : Teradata).
- Pour Transfer config name (Nom de la configuration de transfert), entrez un nom d'affichage pour le transfert tel que My Migration. Le nom à afficher peut correspondre à n'importe quelle valeur permettant d'identifier facilement le transfert si vous devez le modifier par la suite.
- (Facultatif) Pour Schedule options (Options de programmation), vous pouvez conserver la valeur par défaut Daily (Tous les jours, en fonction de l'heure de création) en fonction de l'heure de création ou sélectionner une autre valeur.
  Remarque :
  Dans l'UI Web de BigQuery uniquement, vous pouvez sélectionner l'option de programmation On-demand (À la demande) pour un transfert ponctuel non récurrent.
  
  Les transferts récurrents (bêta) bénéficieront d'un fichier de schéma personnalisé facultatif, spécifié ultérieurement dans cette procédure de configuration du transfert. Un fichier de schéma personnalisé peut spécifier le mode de partition des données des transferts récurrents lorsqu'elles sont chargées dans des tables BigQuery.
- Pour Destination settings (Paramètres de destination), sélectionnez l'ensemble de données approprié.
Sous Data Source Details (Détails de la source de données), poursuivez avec les détails spécifiques de votre transfert Teradata.
- Dans le champ Database type (Type de base de données), sélectionnez Teradata.
- Dans le champ Cloud Storage bucket (Bucket Cloud Storage), recherchez le nom du bucket Cloud Storage pour la préproduction des données de migration. Ne saisissez pas de préfixe gs:// : saisissez uniquement le nom du bucket.
- Dans le champ Database name (Nom de la base de données), saisissez le nom de la base de données source dans Teradata.
- Dans le champ Table name patterns (Modèles de nom de table), saisissez un ou plusieurs modèles pour faire correspondre les noms de tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
  Voici deux exemples de modèles de nom de table :
  - sales|expenses fera correspondre deux tables nommées sales et expenses.
  - .* fera correspondre toutes les tables.
- Dans le champ Service account email (Adresse e-mail du compte de service), saisissez l'adresse e-mail associée au compte de service Cloud Identity and Access Management que vous avez créé.
- (Facultatif) Pour Schema file path (Chemin d'accès au fichier du schéma), entrez le chemin d'accès et le nom d'un fichier de schéma JSON. Si aucun fichier de schéma n'est entré, BigQuery détecte automatiquement le schéma de la table en utilisant les données source en cours de transfert. Vous pouvez créer votre propre fichier de schéma, comme indiqué dans l'exemple de capture d'écran ci-dessous, ou vous pouvez utiliser l'agent de migration pour vous aider à créer un fichier de schéma. Pour plus d'informations sur la création d'un fichier de schéma, consultez la section initialisation de l'agent de migration.
  Attention : Un fichier de schéma personnalisé doit être spécifié pour les transferts récurrents afin que les données des transferts ultérieurs puissent être correctement partitionnées lors de leur chargement dans BigQuery.
  
  En l'absence d'un fichier de schéma, à chaque exécution d'un transfert, le service de transfert de données BigQuery applique automatiquement un schéma de table en utilisant les données source en cours de transfert et toutes les informations sur le partitionnement, le clustering, les clés primaires et le suivi des modifications sont perdues. En outre, les transferts ultérieurs ignorent les tables précédemment migrées après le transfert initial. Consultez la section Fichier de schéma facultatif pour savoir comment créer un fichier de schéma et l'importer dans votre bucket Cloud Storage.
- (Facultatif) Dans la section Options de notification :
  - Cliquez sur le bouton pour activer les notifications par e-mail. Lorsque vous activez cette option, l'administrateur de transfert reçoit une notification par e-mail en cas d'échec de l'exécution du transfert.
  - Pour le champ Select a Pub/Sub topic (Sélectionner un sujet Pub/Sub), choisissez le nom de votre sujet ou cliquez sur Create a topic (Créer un sujet). Cette option configure les notifications d'exécution Cloud Pub/Sub pour votre transfert.
Cliquez sur Save.
Cloud Console affiche tous les détails de configuration du transfert, y compris un nom de ressource pour ce transfert. Notez le nom de la ressource, car vous devrez l'entrer ultérieurement lors de l'exécution de l'agent de migration.

UI classique

Accédez à l'UI Web de BigQuery.

Accéder à l'UI Web de BigQuery
Cliquez sur Transfers (Transferts).
Cliquez sur Add Transfer (Ajouter un transfert).
Sur la page Nouveau transfert :
- Pour Source, sélectionnez Migration: Teradata (Migration : Teradata).
- Pour le champ Display name (Nom à afficher), saisissez le nom du transfert, par exemple My Migration. Le nom à afficher peut être n'importe quelle valeur permettant d'identifier facilement le transfert si vous devez le modifier par la suite.
- (Facultatif) Pour Schedule (Programmation), vous pouvez conserver la valeur par défaut every 24 hours (toutes les 24 heures, en fonction de l''heure de création) ou cliquer sur Edit (Modifier) pour modifier l'heure d'exécution.
  REMARQUES :
  Dans l'UI Web de BigQuery uniquement, vous pouvez sélectionner l'option de programmation "On-demand" (À la demande) pour un transfert ponctuel non récurrent.
  
  Les transferts récurrents (bêta) bénéficieront d'un fichier de schéma personnalisé facultatif, spécifié ultérieurement dans cette procédure de configuration du transfert. Un fichier de schéma personnalisé peut spécifier le mode de partition des données des transferts récurrents lorsqu'elles sont chargées dans des tables BigQuery.
- Pour Ensemble de données de destination, sélectionnez l'ensemble de données approprié.
- Dans le champ Database type (Type de base de données), sélectionnez Teradata.
- Dans le champ Cloud Storage bucket (Bucket Cloud Storage), saisissez le nom du bucket Cloud Storage pour la préproduction des données de migration. N'incluez pas le préfixe gs:// : saisissez uniquement le nom du bucket.
- Dans le champ Database name (Nom de la base de données), saisissez le nom de la base de données source dans Teradata.
- Dans le champ Table name patterns (Modèles de nom de table), saisissez un ou plusieurs modèles pour faire correspondre les noms de tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
  Voici deux exemples de modèles de nom de table :
  - sales|expenses fera correspondre deux tables nommées sales et expenses.
  - .* fera correspondre toutes les tables.
- Dans le champ Service account email (Adresse e-mail du compte de service), saisissez l'adresse e-mail associée au compte de service Cloud Identity and Access Management que vous avez créé.
- (Facultatif) Pour Schema file path (Chemin d'accès au fichier du schéma), entrez le chemin d'accès et le nom d'un fichier de schéma JSON. Si aucun fichier de schéma n'est entré, BigQuery détecte automatiquement le schéma de la table en utilisant les données source en cours de transfert. Vous pouvez créer votre propre fichier de schéma, comme indiqué dans l'exemple de capture d'écran suivant, ou vous pouvez utiliser l'agent de migration pour vous aider à créer un fichier de schéma. Pour plus d'informations sur la création d'un fichier de schéma, consultez la section initialisation de l'agent de migration.
  Attention : Un fichier de schéma personnalisé doit être spécifié pour les transferts récurrents afin que les données des transferts ultérieurs puissent être correctement partitionnées lors de leur chargement dans BigQuery.
  
  En l'absence d'un fichier de schéma, à chaque exécution d'un transfert, le service de transfert de données BigQuery applique automatiquement un schéma de table en utilisant les données source en cours de transfert et toutes les informations sur le partitionnement, le clustering, les clés primaires et le suivi des modifications sont perdues. En outre, les transferts ultérieurs ignorent les tables précédemment migrées après le transfert initial. Consultez la section Fichier de schéma facultatif pour savoir comment créer un fichier de schéma et l'importer dans votre bucket Cloud Storage.
- (Facultatif) Développez la section Advanced (Avancé), puis configurez les notificationsd'exécution pour votre transfert.
- Sous Cloud Pub/Sub topic (Sujet Cloud Pub/Sub), saisissez le nom de votre sujet Cloud Pub/Sub, par exemple projects/myproject/topics/mytopic.
- Cochez la case Send email notifications (Envoyer des notifications par e-mail) pour autoriser les notifications par e-mail en cas d'échec de l'exécution des transferts.
Cliquez sur Ajouter.
Si vous y êtes invité, cliquez sur Allow (Autoriser) pour autoriser le service de transfert de données BigQuery à gérer votre transfert. Vous devez autoriser les fenêtres pop-up de bigquery.cloud.google.com pour afficher la fenêtre des autorisations.
L'UI Web affichera tous les détails de configuration du transfert, y compris un Resource name (Nom de ressource) pour ce transfert. Notez le nom de la ressource. Vous devez l'entrer ultérieurement lorsque vous exécutez l'agent de migration.

CLI

Saisissez la commande bq mk, puis spécifiez l'indicateur de création de transfert --transfer_config. Les paramètres suivants sont également requis :

--data_source
--display_name
--target_dataset
--params

bq mk \
--transfer_config \
--project_id=project ID \
--target_dataset=dataset \
--display_name=name \
--params='parameters' \
--data_source=data source

Où :

project ID est l'ID du projet. Si vous ne fournissez pas de --project_id afin de spécifier un projet particulier, le projet par défaut est utilisé.
dataset est le jeu de données que vous souhaitez cibler (--target_dataset) pour la configuration de transfert.
name est le nom à afficher (--display_name) pour la configuration de transfert. Le nom à afficher du transfert peut être n'importe quelle valeur vous permettant de l'identifier facilement si vous devez le modifier ultérieurement.
parameters contient les paramètres (--params) de la configuration de transfert créée au format JSON. Par exemple : --params='{"param":"param_value"}'.
- Pour les migrations Teradata, ces paramètres sont obligatoires : bucket, database_type, agent_service_account, database_name, table_name_patterns.
  - bucket est le bucket Cloud Storage qui servira de zone de préproduction pendant la migration.
  - database_type est Teradata.
  - agent_service_account est l'adresse e-mail associée au compte de service que vous avez créé.
  - database_name est le nom de la base de données source dans Teradata.
  - table_name_patterns correspond à un ou plusieurs modèle(s) permettant de faire correspondre les noms de tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
    Voici deux exemples de modèles de nom de table :
    - sales|expenses fera correspondre les tables nommées sales et expenses.
    - .* fera correspondre toutes les tables.
data_source est la source de données (--data_source) : on_premises.

Attention : Un fichier de schéma personnalisé doit être spécifié pour les transferts récurrents afin que les données des transferts ultérieurs puissent être correctement partitionnées lors de leur chargement dans BigQuery.

En l'absence d'un fichier de schéma, à chaque exécution d'un transfert, le service de transfert de données BigQuery applique automatiquement un schéma de table en utilisant les données source en cours de transfert et toutes les informations sur le partitionnement, le clustering, les clés primaires et le suivi des modifications sont perdues. En outre, les transferts ultérieurs ignorent les tables précédemment migrées après le transfert initial. Consultez la section Fichier de schéma facultatif pour savoir comment créer un fichier de schéma et l'importer dans votre bucket Cloud Storage.

Par exemple, la commande suivante crée un transfert Teradata nommé My Transfer à l'aide du bucket Cloud Storage mybucket et de l'ensemble de données cible mydataset. Le transfert fera migrer toutes les tables de l'entrepôt de données Teradata mydatabase et le fichier de schéma facultatif est myschemafile.json.

bq mk \
--transfer_config \
--project_id=123456789876 \
--target_dataset=MyDataset \
--display_name='My Migration' \
--params='{"bucket": "mybucket", "database_type": "Teradata",
"database_name":"mydatabase", "table_name_patterns": ".*",
"agent_service_account":"myemail@mydomain.com", "schema_file_path":
"gs://mybucket/myschemafile.json"}' \
--data_source=on_premises

Après avoir exécuté la commande, vous recevez un message de ce type :

[URL omitted] Please copy and paste the above URL into your web browser and follow the instructions to retrieve an authentication code.

Suivez les instructions et collez le code d'authentification sur la ligne de commande.

API

Utilisez la méthode projects.locations.transferConfigs.create et fournissez une instance de la ressource TransferConfig.

Agent de migration

Vous pouvez éventuellement créer le transfert directement à partir de l'agent de migration, dans la section Initialiser l'agent de migration.

Pour créer le transfert à partir de l'agent de migration, vous devez d'abord attribuer le rôle Cloud IAM serviceAccessTokenCreator au compte de service que vous avez créé.

Vous pouvez accorder le rôle Cloud IAM de l'une des deux manières suivantes :

Dans Google Cloud Console, attribuez le rôle Cloud IAM suivant : Créateur de jetons du compte de service. Consultez la section Attribuer des rôles à un compte de service.
Vous pouvez exécuter la commande gcloud suivante dans Cloud Shell ou dans l'outil CLI :

gcloud projects add-iam-policy-binding user_project_id \
--member='serviceAccount:service-user_project_number@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com' \
--role='roles/iam.serviceAccountTokenCreator'

Une fois que vous avez accordé l'autorisation serviceAccessTokenCreator au compte de service, vous pouvez passer au téléchargement de l'agent de migration, puis configurer le transfert dans le cadre de l'étape d'initialisation.

Initialiser l'agent de migration

Lorsque vous lancez une migration de données pour la première fois, initialisez l'agent de migration. L'initialisation n'est requise qu'une seule fois à chaque fois que vous configurez un transfert de migration, qu'il soit ou non récurrent.

Cette session ne démarre pas la migration. Elle ne sert que pour la configuration initiale.

Ouvrez une nouvelle session. Sur la ligne de commande, émettez une commande permettant d'exécuter le fichier jar, avec des options spécifiques, au format suivant :

java -cp \
OS-specific-separated-paths-to-jars (JDBC and agent) \
com.google.cloud.bigquery.dms.Agent \
--initialize

Unix, Linux, Mac OS

java -cp \
/usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:/usr/local/migration/mirroring-agent.jar \
com.google.cloud.bigquery.dms.Agent \
--initialize

Windows

Copiez tous les fichiers dans le dossier C:\migration (ou ajustez les chemins d'accès dans la commande), puis exécutez la commande suivante :

java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --initialize

Lorsque vous y êtes invité, saisissez les paramètres suivants :
- Si vous souhaitez enregistrer le modèle Teradata Parallel Transporter (TPT) sur le disque. Si vous prévoyez d'utiliser la méthode d'extraction TPT, vous pouvez modifier le modèle enregistré avec des paramètres adaptés à votre instance Teradata.
- L'URI de la base de données source. Indiquez le numéro de port, si nécessaire.
- Chemin vers un espace de travail local pour la migration. Assurez-vous que vous disposez de l'espace de stockage minimal recommandé, comme décrit dans la configuration requise pour l'espace de stockage.
- Si vous allez utiliser Teradata Parallel Transporter (TPT) comme méthode d'extraction.
- (Facultatif) Chemin d'accès à un fichier d'identifiants de base de données.
Lorsque vous êtes invité à indiquer un nom de ressource pour le service de transfert de données BigQuery :

Vous pouvez entrer le nom de ressource du transfert que vous avez configuré dans l'interface utilisateur Web BigQuery, ou vous pouvez créer le transfert à ce stade, via l'agent de migration lui-même. Vous pouvez éventuellement utiliser la commande d'initialisation de l'agent de migration pour créer un fichier de schéma. Voir l'onglet Agent de migration ci-dessous pour cette option.
Console
Saisissez le nom de ressource du transfert que vous avez précédemment configuré dans l'onglet "Console" de la section sur la configuration d'un transfert.

UI classique
Saisissez le nom de ressource du transfert que vous avez précédemment configuré dans l'onglet "UI classique" de la section sur la configuration d'un transfert.
Agent de migration
- Saisissez l'ID de projet Google Cloud.
- Saisissez le nom de la base de données source dans Teradata.
- Entrez un modèle pour faire correspondre les noms des tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
  Voici deux exemples de modèles de nom de table :
  sales|expenses fera correspondre les tables nommées sales et expenses.
  
  .* fera correspondre toutes les tables.
- Facultatif : Saisissez le chemin d'accès à un fichier de schéma JSON local (recommandé pour les transferts récurrents). Ce fichier de schéma sera importé dans votre bucket Cloud Storage.
  Attention : Un fichier de schéma personnalisé doit être spécifié pour les transferts récurrents afin que les données des transferts ultérieurs puissent être correctement partitionnées lors de leur chargement dans des tables BigQuery.
  
  En l'absence d'un fichier de schéma, à chaque exécution d'un transfert, le service de transfert de données BigQuery convertit les tables Teradata en schéma BigQuery, et toutes les informations sur le partitionnement, le clustering et le suivi des modifications sont perdues. En outre, les transferts ultérieurs ignorent les tables précédemment migrées après le transfert initial.
  
  Consultez la section Fichier de schéma facultatif pour savoir comment créer un fichier de schéma et l'importer dans votre bucket Cloud Storage.
  - Choisissez de créer un nouveau fichier de schéma. Dans ce cas, vous serez invité à entrer un nom d'utilisateur et un mot de passe Teradata, et l'agent produira un fichier JSON avec un schéma converti. Le fichier sera créé dans un dossier local, en suivant ce modèle : <localpath>/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json. Après le téléchargement vers votre bucket Cloud Storage, le chemin et le nom de fichier suivront ce modèle : gs://mybucket/myproject_id/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json.
  - Modifiez le fichier de schéma pour marquer le partitionnement, le clustering, les clés primaires et les colonnes de suivi des modifications, et vérifiez que vous souhaitez utiliser ce schéma pour la configuration de transfert. Consultez la section fichier de schéma facultatif pour obtenir des conseils.
- Entrez le nom de l'ensemble de données de destination dans BigQuery.
- Saisissez le nom du bucket Cloud Storage dans lequel les données de migration seront préproduites avant leur chargement dans BigQuery.
- Saisissez le nom de la configuration de transfert.
Après avoir entré tous les paramètres demandés, l'agent de migration crée un fichier de configuration et le place dans le chemin local fourni dans les paramètres. Voir la section suivante pour regarder de plus près le fichier de configuration.

Fichier de configuration pour l'agent de migration

Le fichier de configuration créé à l'étape d'initialisation se présente comme suit :


   {
    "agent-id": "0eebc1ad-621d-4386-87f1-8eca96991f63",
    "transfer-configuration": {
      "project-id": "123456789876",
      "location": "us",
      "id": "5d533a90-0000-2e89-89a0-94eb2c059a76"
    },
    "source-type": "teradata",
    "console-log": false,
    "silent": false,
    "teradata-config": {
      "connection": {
       "host": "localhost"
      },
      "local-processing-space": "extracted",
      "database-credentials-file-path": "",
      "max-local-storage": "200GB",
      "use-tpt": false,
      "max-sessions": 0,
      "max-parallel-upload": 1,
      "max-unload-file-size": "2GB"
     }
   }

Toutes les options du fichier de configuration de l'agent de migration

transfer-configuration : informations sur cette configuration de transfert dans le service de transfert de données BigQuery.
teradata-config : informations spécifiques à cette extraction Teradata :
- connection : informations sur le nom d'hôte et le port
- local-processing-space : dossier d'extraction dans lequel l'agent va extraire les données de tables, avant de les importer dans Cloud Storage.
- database-credentials-file-path : (facultatif) chemin d'accès à un fichier qui contient les identifiants permettant de se connecter automatiquement à la base de données Teradata. Le fichier doit contenir deux lignes, par exemple :
```
username=abc
password=123
```
  Lorsque vous utilisez un fichier d'informations d'identification, veillez à contrôler l'accès au dossier dans lequel vous le stockez sur le système de fichiers local, car il ne sera pas chiffré. Si aucun chemin d'accès n'est fourni, vous serez invité à entrer un nom d'utilisateur et un mot de passe lorsque vous démarrez un agent.
- max-local-storage : quantité maximale d'espace de stockage local à utiliser pour l'extraction dans le répertoire de préproduction spécifié. La valeur par défaut est 200GB. Le format accepté est le suivant : numberKB|MB|GB|TB.
  
  Dans tous les modes d'extraction, les fichiers sont supprimés de votre répertoire de transfert local après avoir été téléchargés sur Cloud Storage.
  Remarque : La limite "max-local-storage" n'est pas appliquée lorsque Teradata Parallel Transporter (TPT) est utilisé.
  La quantité réelle d'espace de stockage de préproduction nécessaire dépend de la méthode d'extraction :
  - Dans la méthode d'extraction par défaut (pilote JDBC avec FastExport), de petits fragments de données sont écrits et importés en continu dans le bucket Cloud Storage spécifié. L'extraction se met en pause lorsque la limite max_local_storage spécifiée est atteinte.
  - En cas d'extraction avec Teradata Parallel Transporter (TPT) sans colonne de partitionnement, l'intégralité de votre table est extraite, quel que soit le paramètre max_local_storage.
  - En cas d'extraction avec Teradata Parallel Transporter (TPT) avec une colonne de partitionnement, l'agent extrait des ensembles de partitions. Les besoins en espace de stockage de préproduction sont égaux à la valeur la plus élevée entre max_local_storage et la taille de la plus grande partition de votre table extraite au format CSV.
- use-tpt : demande à l'agent de migration d'utiliser Teradata Parallel Transporter (TPT) comme méthode d'extraction.
  
  Pour chaque table, l'agent de migration génère un script TPT, démarre un processus tbuild et attend la fin. Une fois le processus tbuild terminé, l'agent répertorie et télécharge les fichiers extraits vers Cloud Storage, puis supprime le script TPT.
  
  Pour utiliser la méthode d'extraction TPT, procédez comme suit :
  - L'utilitaire tbuild doit être installé et disponible pour que l'agent de migration puisse utiliser et démarrer le processus tbuild.
  - Le dossier d'extraction local doit disposer de suffisamment d'espace pour extraire la plus grande partition de la table au format CSV. En raison du formatage, la taille du fichier CSV sera supérieure à celle de la table d'origine dans Teradata.
  Avertissement : un agent génère et enregistre un script TPT dans un fichier du dossier d'extraction local. Le script contient un nom d'utilisateur et un mot de passe Teradata. Prenez les mesures appropriées pour restreindre l'accès aux fichiers du dossier d'extraction local, car le nom d'utilisateur et le mot de passe ne seront pas chiffrés.
- max-sessions : spécifie le nombre maximal de sessions utilisées par la tâche d'exportation (FastExport ou TPT). S'il est défini sur 0, la base de données Teradata détermine le nombre maximal de sessions pour chaque tâche d'exportation.
- max-parallel-uploads : détermine le nombre de fichiers téléchargés sur Cloud Storage en parallèle. En fonction de la bande passante de votre réseau et d'autres paramètres (tels que l'analyse DLP), l'augmentation de ce paramètre peut améliorer les performances.
- max-unload-file-size : détermine la taille maximale du fichier extrait. Ce paramètre n'est pas appliqué pour les extractions TPT.

Exécuter l'agent de migration

Après avoir initialisé l'agent de migration et créé le fichier de configuration, procédez comme suit pour exécuter l'agent et démarrer la migration :

Commencez à exécuter l'agent en utilisant le chemin de classe vers les pilotes JDBC et le chemin d'accès au fichier de configuration créé lors de l'étape d'initialisation précédente.

java -cp
OS-specific-separated-paths-to-jars (JDBC and agent)
com.google.cloud.bigquery.dms.Agent
--configuration-file=path to configuration file

Unix, Linux, Mac OS

java -cp \
/usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:mirroring-agent.jar \
com.google.cloud.bigquery.dms.Agent \
--configuration-file=config.json

Windows

Copy all the files into the C:\migration folder (or adjust the paths in the command), then run:

java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --configuration-file=config.json

If you are ready to proceed with the migration, press Enter and the agent will proceed if the classpath provided during initialization is valid.

Lorsque vous y êtes invité, entrez le nom d'utilisateur et le mot de passe pour la connexion à la base de données. Si le nom d'utilisateur et le mot de passe sont valides, la migration des données démarre.

Facultatif Dans la commande pour démarrer la migration, vous pouvez également utiliser un indicateur qui transmet un fichier d'informations d'identification à l'agent, au lieu d'entrer à chaque fois le nom d'utilisateur et le mot de passe. Voir le paramètre facultatif database-credentials-file-path dans le fichier de configuration de l'agent pour plus d'informations. Lorsque vous utilisez un fichier d'informations d'identification, prenez les mesures appropriées pour contrôler l'accès au dossier dans lequel vous le stockez sur le système de fichiers local, car il ne sera pas chiffré.
Laissez cette session ouverte jusqu'à la fin de la migration. Si vous avez créé un transfert de migration récurrent, laissez cette session ouverte indéfiniment. Si cette session est interrompue, les exécutions de transfert actuelles et futures échoueront.
Vérifiez régulièrement si l'agent est en cours d'exécution. Si un transfert est en cours et qu'aucun agent ne répond dans les 24 heures, le transfert échoue.
Si l'agent de migration meurt alors que le transfert est en cours ou planifié, l'interface utilisateur Web du service de transfert de données BigQuery affiche l'état d'erreur et vous invite à redémarrer l'agent. Pour redémarrer l'agent de migration, reprenez depuis le début de cette section, exécuter l'agent de migration, avec la commande pour exécuter l'agent de migration. Vous n'avez pas besoin de répéter la commande d'initialisation. Le transfert reprendra à partir du moment où les tables n'ont pas été complétées.

AVERTISSEMENT : les données extraites de Teradata ne sont pas chiffrées. Veuillez prendre les mesures appropriées pour restreindre l'accès aux fichiers extraits dans le dossier d'extraction de la machine locale et vous assurer que votre bucket Cloud Storage n'est pas accessible au public. En savoir plus sur le contrôle de l'accès aux buckets Cloud Storage avec les rôles Cloud IAM.

Suivre la progression de la migration

Vous pouvez afficher l'état de la migration dans l'interface utilisateur Web du service de transfert de données BigQuery. Vous pouvez également configurer des notifications Pub/Sub ou par e-mail. Voir Notifications du service de transfert de données BigQuery.

Le service de transfert de données BigQuery planifie et lance une exécution de transfert selon un calendrier spécifié lors de la création de la configuration de transfert. Il est important que l'agent de migration s'exécute lorsqu'une exécution de transfert est active. S'il n'y a aucune mise à jour du côté de l'agent dans les 24 heures, une exécution de transfert échouera.

Exemple d'état de la migration dans l'UI Web du service de transfert de données BigQuery :

État de la migration

Mettre à jour l'agent de migration

Si une nouvelle version de l'agent de migration est disponible, vous devrez mettre à jour manuellement l'agent de migration. Pour recevoir des notifications sur le service de transfert de données BigQuery, abonnez-vous aux notes de version.

Étape suivante

Apprenez-en plus sur les migrations d'entrepôts de données vers BigQuery dans notre guide de solution.
Consultez la présentation sur la migration depuis Teradata à l'aide du service de transfert de données BigQuery.
Informez-vous en détail sur les options de transfert Teradata.