Migration de Teradata vers BigQuery : présentation
Ce document vous aide à comprendre les décisions à prendre lorsque vous utilisez le service de transfert de données BigQuery pour migrer votre schéma et vos données de Teradata vers BigQuery.
La migration du schéma et des données est généralement l'une des étapes nécessaires au déplacement d'un entrepôt de données vers BigQuery depuis autre plate-forme. Pour obtenir une description du processus de migration de bout en bout, consultez la page Présentation : Migrer des entrepôts de données vers BigQuery.
Vous pouvez également utiliser la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc. Le langage SQL Teradata est entièrement compatible avec les deux services de traduction SQL.
Présentation
Vous pouvez utiliser le service de transfert de données BigQuery avec un agent de migration spécial pour copier votre schéma et vos données de Teradata vers BigQuery. L'agent de migration se connecte à votre entrepôt de données local et communique avec le service de transfert de données BigQuery pour copier les tables de votre entrepôt de données vers BigQuery.
Les étapes suivantes décrivent le workflow du processus de migration :
- Télécharger l'agent de migration.
- Configurer un transfert dans le service de transfert de données BigQuery.
- Exécuter la tâche de transfert pour copier le schéma et les données de votre entrepôt de données vers BigQuery.
- Facultatif. Surveiller les jobs de transfert à l'aide de la console Google Cloud.
Configuration d'un job de transfert
Vous pouvez configurer une tâche de transfert de façon à répondre au mieux à vos besoins. Avant de configurer un transfert de données de Teradata vers BigQuery, examinez les options de configuration décrites dans les sections suivantes et déterminez quels paramètres utiliser. En fonction des paramètres que vous choisissez, vous devrez peut-être remplir certaines conditions préalables avant de démarrer la tâche de transfert.
Pour la plupart des systèmes, en particulier ceux comportant des tables volumineuses, vous pouvez obtenir des performances optimales en procédant comme suit :
- Partitionnez vos tables Teradata.
- Utilisez Teradata Parallel Transporter (TPT) pour l'extraction.
- Créez un fichier de schéma personnalisé et configurez vos colonnes cibles de clustering et de partitionnement BigQuery.
L'agent de migration peut ainsi effectuer l'extraction partition par partition, ce qui est l'option la plus efficace.
Méthode d'extraction
Le service de transfert de données BigQuery propose deux méthodes d'extraction pour transférer des données de Teradata vers BigQuery :
Utiliser l'utilitaire teradata Parallel Transporter (TPT) tbuild. Il s'agit de l'approche recommandée. L'utilisation de TPT permet généralement d'accélérer l'extraction des données.
Dans ce mode, l'agent de migration tente de calculer des lots d'extraction à l'aide de lignes réparties par partitions. Pour chaque lot, l'agent émet et exécute un script d'extraction TPT, générant un ensemble de fichiers délimités par des barres verticales. Il importe ensuite ces fichiers dans un bucket Cloud Storage, où ils sont utilisés par la tâche de transfert. Une fois les fichiers importés dans Cloud Storage, l'agent de migration les a supprimés du système de fichiers local.
Lorsque vous utilisez l'extraction TPT sans colonne de partitionnement, l'intégralité de votre table est extraite. Lorsque vous utilisez l'extraction TPT avec une colonne de partitionnement, l'agent extrait des ensembles de partitions.
Dans ce mode, l'agent de migration ne limite pas la quantité d'espace qu'occupent les fichiers extraits sur le système de fichiers local. Assurez-vous que le système de fichiers local dispose d'un espace de stockage supérieur à la taille de votre plus grande partition ou de votre plus grande table, selon que vous spécifiez ou non une colonne de partitionnement.
Extraction à l'aide du pilote JDBC avec connexion FastExport. S'il existe des contraintes sur l'espace de stockage local disponible pour les fichiers extraits, ou si vous ne pouvez pas utiliser TPT pour une raison quelconque, utilisez cette méthode d'extraction.
Dans ce mode, l'agent de migration extrait les tables dans une collection de fichiers AVRO sur le système de fichiers local. Il importe ensuite ces fichiers dans un bucket Cloud Storage, où ils sont utilisés par la tâche de transfert. Une fois les fichiers importés dans Cloud Storage, l'agent de migration les supprime du système de fichiers local.
Dans ce mode, vous pouvez limiter la quantité d'espace utilisée par les fichiers AVRO sur le système de fichiers local. Si cette limite est dépassée, l'extraction est interrompue jusqu'à ce que l'espace de stockage soit libéré par l'agent de migration qui importe et supprime les fichiers AVRO existants.
Identification des schémas
Le service de transfert de données BigQuery fournit une détection automatique de schéma et une mise en correspondance des types de données lors d'un transfert de données de Teradata vers BigQuery. Vous pouvez éventuellement spécifier un fichier de schéma personnalisé à la place. Nous vous recommandons de personnaliser le schéma dans les situations suivantes :
Vous devez capturer des informations importantes sur une table, comme le partitionnement, qui seraient sinon perdues dans la migration.
Par exemple, les transferts incrémentiels doivent comporter un fichier de schéma spécifié pour que les données des transferts ultérieurs puissent être correctement partitionnées lors de leur chargement dans BigQuery. En l'absence de fichier de schéma spécifié, à 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.
Vous devez modifier les noms des colonnes ou les types de données lors du transfert de données.
Fichier de schéma personnalisé
Un fichier de schéma personnalisé est un fichier JSON qui décrit des objets de base de données. Le schéma contient un ensemble de bases de données, chacune contenant un ensemble de tables, lesquelles contiennent chacune un ensemble de colonnes. Chaque objet comporte un champ originalName qui indique le nom d'objet dans Teradata, et un champ name qui indique le nom cible de l'objet dans BigQuery.
Les colonnes comportent en outre les champs suivants :
- Un champ originalType qui indique le type de données de la colonne dans Teradata.
- Un champ type qui indique le type de données cible pour la colonne dans BigQuery.
Un champ usageType pour capturer des informations sur la manière dont la colonne est utilisée par le système, par exemple en clustering ou partitionnement. Les types d'utilisation suivants sont pris en charge :
- CLUSTERING : vous pouvez annoter jusqu'à quatre colonnes dans chaque table cible avec ce type d'utilisation. L'ordre des colonnes pour le clustering est déterminé en fonction de l'ordre dans lequel ils apparaissent dans le schéma personnalisé. Les colonnes que vous sélectionnez doivent respecter les contraintes de clustering dans BigQuery. Si un champ
PARTITIONINGest spécifié pour la même table, BigQuery utilise ces colonnes pour créer une table en cluster. - COMMIT_TIMESTAMP : vous ne pouvez annoter qu'une seule colonne dans chaque table cible avec ce type d'utilisation. Utilisez ce usageType pour identifier une colonne d'horodatage de mise à jour pour les mises à jour incrémentielles. Cette colonne permet d'extraire les lignes créées ou mises à jour depuis la dernière exécution de transfert. Ce type d'utilisation n'est possible qu'avec une colonne dont le type de données est
TIMESTAMPouDATE. - DEFAULT : vous pouvez annoter plusieurs colonnes dans une table cible avec ce type d'utilisation. Ce usageType indique que la colonne n'a pas d'utilisation particulière dans le système source. Il s'agit de la valeur par défaut.
- PARTITIONING : vous ne pouvez annoter qu'une seule colonne dans chaque table cible avec ce type d'utilisation. Cette colonne est utilisée dans la définition de table partitionnée afin de contenir l'objet tables. Ce type d'utilisation n'est possible qu'avec une colonne dont le type de données est
TIMESTAMPouDATE. - PRIMARY_KEY: vous pouvez annoter les colonnes de chaque table cible avec ce type d'utilisation. Utilisez ce type d'utilisation pour identifier une seule colonne comme clé primaire ou, dans le cas d'une clé composite, utilisez le même type d'utilisation sur plusieurs colonnes pour identifier les entités uniques d'une table. Ces colonnes fonctionnent avec
COMMIT_TIMESTAMPpour extraire les lignes créées ou mises à jour depuis la dernière exécution de transfert.
- CLUSTERING : vous pouvez annoter jusqu'à quatre colonnes dans chaque table cible avec ce type d'utilisation. L'ordre des colonnes pour le clustering est déterminé en fonction de l'ordre dans lequel ils apparaissent dans le schéma personnalisé. Les colonnes que vous sélectionnez doivent respecter les contraintes de clustering dans BigQuery. Si un champ
Vous pouvez créer un fichier de schéma personnalisé manuellement, basé sur cet exemple, ou faire en sorte que l'agent de migration en génère un pour vous lors de l'initialisation de l'agent.
Exemple
Supposons que vous migrez une table Teradata appelée orders dans la base de données tpch avec la définition de table suivante :
CREATE SET TABLE TPCH.orders ,FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO,
MAP = TD_MAP1
(
O_ORDERKEY INTEGER NOT NULL,
O_CUSTKEY INTEGER NOT NULL,
O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_TOTALPRICE DECIMAL(15,2) NOT NULL,
O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_SHIPPRIORITY INTEGER NOT NULL,
O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
UNIQUE PRIMARY INDEX ( O_ORDERKEY );
Lors de la migration vers BigQuery, supposons que vous souhaitiez configurer le schéma avec les modifications suivantes :
- Renommer la colonne
O_CUSTKEYenO_CUSTOMERKEY. - Identifier
O_ORDERDATEen tant que colonne de partitionnement.
Le schéma personnalisé permettant de configurer ces paramètres est le suivant :
{
"databases": [
{
"name": "tpch",
"originalName": "e2e_db",
"tables": [
{
"name": "orders",
"originalName": "orders",
"columns": [
{
"name": "O_ORDERKEY",
"originalName": "O_ORDERKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_CUSTOMERKEY",
"originalName": "O_CUSTKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_ORDERSTATUS",
"originalName": "O_ORDERSTATUS",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 1
},
{
"name": "O_TOTALPRICE",
"originalName": "O_TOTALPRICE",
"type": "NUMERIC",
"originalType": "decimal",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 8
},
{
"name": "O_ORDERDATE",
"originalName": "O_ORDERDATE",
"type": "DATE",
"originalType": "date",
"usageType": [
"PARTITIONING"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_ORDERPRIORITY",
"originalName": "O_ORDERPRIORITY",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 15
},
{
"name": "O_CLERK",
"originalName": "O_CLERK",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 15
},
{
"name": "O_SHIPPRIORITY",
"originalName": "O_SHIPPRIORITY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 4
},
{
"name": "O_COMMENT",
"originalName": "O_COMMENT",
"type": "STRING",
"originalType": "varchar",
"usageType": [
"DEFAULT"
],
"isRequired": true,
"originalColumnLength": 79
}
]
}
]
}
]
}
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 complets (transferts à la demande) que les transferts récurrents (transferts incrémentiels). Les modes de transfert à la demande ou incrémentiel sont définis dans les options de planification à l'étape Configurer un transfert.
Transfert à la demande: utilisez ce mode pour effectuer la migration complète de l'instantané du schéma et des données de Teradata vers BigQuery.
Transfert planifié: utilisez ce mode pour effectuer l'instantané complet et migrer régulièrement les données nouvelles et modifiées (données incrémentielles) de Teradata vers BigQuery. Les transferts incrémentiels nécessitent de personnaliser votre schéma pour annoter les colonnes avec l'un des cas d'utilisation ci-dessous:
- Annoter les colonnes avec le seul type d'utilisation
COMMIT_TIMESTAMP: dans ce transfert, les lignes nouvelles ou modifiées dans Teradata sont ajoutées aux données de BigQuery. Les lignes mises à jour dans les tables BigQuery peuvent contenir des lignes en double avec des valeurs anciennes et nouvelles. - Annotez les colonnes avec les types d'utilisation
COMMIT_TIMESTAMPetPRIMARY_KEY: dans ce transfert, de nouvelles lignes sont ajoutées et les lignes modifiées sont mises à jour dans la ligne correspondante de BigQuery. La colonne définie dansPRIMARY_KEYpermet de maintenir l'unicité des données dans BigQuery. - La colonne
PRIMARY_KEYdéfinie dans le schéma ne doit pas nécessairement être laPRIMARY_KEYde la table Teradata. Il peut s'agir de n'importe quelle colonne, mais elle doit contenir des données uniques.
- Annoter les colonnes avec le seul type d'utilisation
Transferts incrémentiels
Dans les transferts incrémentiels, le premier transfert crée toujours un instantané de table dans BigQuery. Tous les transferts incrémentaux ultérieurs respecteront les annotations définies dans le fichier de schéma personnalisé décrit ci-dessous.
Pour chaque exécution de transfert, un horodatage de l'exécution du transfert est enregistré. Pour chaque exécution de transfert suivante, un agent reçoit l'horodatage d'une exécution de transfert précédente (T1) et l'horodatage du début de l'exécution de transfert (T2).
Pour les transferts après l'exécution initiale, l'agent de migration extrait les données à l'aide de la logique de table suivante:
- Si un objet de table dans un fichier de schéma ne possède pas de colonne avec un type d'utilisation
COMMIT_TIMESTAMP, la table est ignorée. - Si une table possède une colonne avec le type d'utilisation
COMMIT_TIMESTAMP, toutes les lignes dont l'horodatage est compris entre T1 et T2 sont extraites et ajoutées à la table existante dans BigQuery. - Si une table possède une colonne avec le type d'utilisation
COMMIT_TIMESTAMPet une colonne avec le type d'utilisationPRIMARY_KEY, toutes les lignes dont l'horodatage est compris entre T1 et T2 sont extraites. Les nouvelles lignes sont ajoutées et les lignes modifiées sont mises à jour dans la table existante dans BigQuery.
Vous trouverez ci-dessous des exemples de fichiers de schéma pour les transferts incrémentiels.
Schéma avec uniquement COMMIT_TIMESTAMP
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"DEFAULT"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Scheme avec COMMIT_TIMESTAMP et une colonne (ID) en tant que PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Schéma avec COMMIT_TIMESTAMP et clé composite (ID + nom) en tant que PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "Name",
"originalName": "Name",
"type": "STRING",
"originalType": "character",
"originalColumnLength": 30,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": false
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Le tableau suivant décrit comment l'agent de migration gère les opérations LDD (langage de définition de données) et LMD (langage de manipulation de données) dans les transferts incrémentiels.
| Fonctionnement de Teradata | Type | Compatibilité de Teradata avec BigQuery |
|---|---|---|
CREATE |
LDD | Un nouvel instantané complet de la table est créé dans BigQuery. |
DROP |
LDD | Incompatible |
ALTER (RENAME) |
LDD | Un nouvel instantané complet de la table renommée est créé dans BigQuery. L'instantané précédent n'est pas supprimé de BigQuery. L'utilisateur n'est pas informé de la table renommée. |
INSERT |
LMD | Les nouvelles lignes sont ajoutées à la table BigQuery. |
UPDATE |
LMD | Les lignes sont ajoutées à la table BigQuery en tant que nouvelles lignes, comme dans une opération INSERT si seul COMMIT_TIMESTAMP est utilisé.
Les lignes sont mises à jour, comme dans une opération UPDATE si COMMIT_TIMESTAMP et PRIMARY_KEY sont tous deux utilisés. |
MERGE |
LMD | Non compatible Consultez plutôt INSERT, UPDATE et DELETE. |
DELETE |
LMD | Incompatible |
Considérations relatives aux zones
Votre bucket Cloud Storage doit se trouver dans une région ou un emplacement multirégional compatible avec la région ou l'emplacement multirégional de l'ensemble de données de destination dans BigQuery.
- Si votre ensemble de données BigQuery se trouve dans une zone multirégionale, le bucket Cloud Storage contenant les données que vous transférez doit se trouver dans la même zone multirégionale ou dans un emplacement inclus dans la zone multirégionale. Par exemple, si votre ensemble de données BigQuery se trouve dans la zone multirégionale "EU", le bucket Cloud Storage peut être situé dans la région de Belgique "europe-west1", qui se trouve dans l'Union européenne.
- Si votre ensemble de données se trouve dans une région, votre bucket Cloud Storage doit se situer dans la même région. Par exemple, si votre ensemble de données se trouve dans la région "asia-northeast1" à Tokyo, le bucket Cloud Storage ne peut pas se situer dans la zone multirégionale "ASIA".
Pour plus d'informations sur les transferts et les régions, consultez la page Emplacement des données et transferts.
Tarifs
Le transfert de données avec BigQuery n'est soumis à aucun frais. L'utilisation de ce service peut toutefois engendrer des coûts hors de Google, notamment les frais liés au transfert de données sortantes à partir de la plate-forme.
- L'extraction des données, leur importation dans un bucket Cloud Storage et leur chargement dans BigQuery sont gratuits.
- Les données ne sont pas automatiquement supprimées de votre bucket Cloud Storage après leur importation dans BigQuery. Pensez à les supprimer du bucket pour ne pas avoir à payer de coûts de stockage supplémentaires. Consultez la page sur les tarifs de Cloud Storage.
- Les quotas et limites standards de BigQuery liés aux tâches de chargement s'appliquent.
- Les quotas et limites standards de BigQuery pour les opérations d'insertion et de mise à jour incrémentielles de la LMD s'appliquent.
- Une fois les données transférées vers BigQuery, les tarifs standards du stockage et des calculs BigQuery s'appliquent.
- Consultez la page Tarifs concernant les transferts pour plus de détails.
Limites
- Les transferts uniques à la demande sont entièrement compatibles. Les transferts incrémentiels sont disponibles en version bêta. Les opérations LDD/LMD dans les transferts incrémentiels sont partiellement compatibles.
- Lors du transfert de données, les données sont extraites dans un répertoire du système de fichiers local. Assurez-vous de disposer d'un espace de stockage suffisant.
- Lorsque vous utilisez le mode d'extraction FastExport, vous pouvez définir la quantité maximale d'espace de stockage nécessaire et la limite pleinement appliquée par l'agent de migration. Définissez le paramètre
max-local-storagedans le fichier de configuration de l'agent de migration lorsque vous configurez un transfert de Teradata vers BigQuery. - Si vous utilisez la méthode d'extraction TPT, assurez-vous que le système de fichiers dispose d'un espace de stockage suffisant, plus grand que la plus grande partition de table de l'instance Teradata.
- Lorsque vous utilisez le mode d'extraction FastExport, vous pouvez définir la quantité maximale d'espace de stockage nécessaire et la limite pleinement appliquée par l'agent de migration. Définissez le paramètre
- Le service de transfert de données BigQuery convertit automatiquement le schéma (si vous ne fournissez pas de fichier de schéma personnalisé) et transfère les données Teradata vers BigQuery. Les données sont mappées de Teradata vers les types BigQuery.
- Les fichiers ne sont pas supprimés automatiquement de votre bucket Cloud Storage après leur chargement dans BigQuery. Pensez à supprimer les données de votre bucket Cloud Storage après leur chargement dans BigQuery afin d'éviter des frais de stockage supplémentaires. Consultez la page Tarifs.
- La vitesse d'extraction est limitée par votre connexion JDBC.
- Les données extraites de Teradata ne sont pas chiffrées. Prenez les mesures nécessaires pour restreindre l'accès aux fichiers extraits dans le système de fichiers local et assurez-vous que le bucket Cloud Storage est correctement sécurisé.
- Les autres ressources de base de données, telles que les procédures stockées, les requêtes enregistrées, les vues et les fonctions définies par l'utilisateur, ne sont pas transférées et dépassent le cadre de ce service.
- Les transferts incrémentiels ne sont pas compatibles avec les suppressions définitives. Les transferts incrémentiels ne synchronisent aucune ligne supprimée dans Teradata avec BigQuery.
Étape suivante
- Obtenez des instructions détaillées sur la Migration de Teradata vers BigQuery.
- Exécutez une migration de test de Teradata vers BigQuery.