Ce document décrit davantage de détails, options et fonctionnalités bêta supplémentaires disponibles lorsque vous utilisez le service de transfert de données BigQuery pour migrer vos données de Teradata vers BigQuery.
Fichier de schéma personnalisé
Effectuer des transformations avec un fichier de schéma
Dans le cadre de la migration, vous pouvez spécifier un fichier de schéma personnalisé pour modifier le champ name d'un objet et ajouter le tableau usageType à n'importe quelle colonne. Il 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é.
Les types d'utilisation suivants sont pris en charge :
- PARTITIONING : une seule colonne par table peut être annotée avec ce usageType. Le champ de type d'une colonne doit être
DATE
ouTIMESTAMP
. Cette colonne sera utilisée pour la définition de table partitionnée afin de contenir l'objet tables. - CLUSTERING : plusieurs colonnes d'une table peuvent être annotées avec ce usageType. Les types de colonnes doivent respecter les contraintes pour le clustering dans BigQuery. Si un champ
PARTITIONING
est spécifié pour la même table, BigQuery utilise ces colonnes pour créer une table en cluster. Seules les colonnes de typeINT64
,STRING
,DATE
,TIMESTAMP
,BOOL
,NUMERIC
ouBIGNUMERIC
(Aperçu) peuvent être marquées avec ce usageType. - COMMIT_TIMESTAMP : une seule colonne par table peut être annotée avec ce usageType. Utilisez ce usageType pour annoter une colonne d'horodatage de mise à jour. Cette colonne sera utilisée pour extraire les lignes créées ou mises à jour depuis la dernière exécution de transfert. Elle doit être de type
TIMESTAMP
ouDATE
.
Exemple de fichier de schéma personnalisé
{
"databases": [
{
"name": "db",
"originalName": "db",
"tables": [
{
"name": "test",
"originalName": "test",
"columns": [
{
"name": "foo",
"originalName": "foo",
"type": "INT64",
"usageType": ["CLUSTERING"]
},
{
"name": "bar",
"originalName": "bar",
"type": "DATE",
"usageType": ["PARTITIONING"]
},
{
"name": "change",
"originalName": "change",
"type": "TIMESTAMP",
"usageType": ["COMMIT_TIMESTAMP"]
}
]
}
]
}
]
}
Pour en savoir plus sur la manière dont les tables sont partitionnées ou mises en cluster dans un transfert, consultez la section Transferts incrémentiels.
Mappage des types de données Teradata vers BigQuery
Type Teradata | Type BigQuery | Différence entre les types |
---|---|---|
INTEGER | INTEGER | |
SMALLINT | INTEGER | |
BYTEINT | INTEGER | |
BIGINT | INTEGER | |
DECIMAL NUMERIC NUMBER FLOAT |
NUMERIC ou BIGNUMERIC | Le type BigQuery NUMERIC comporte 38 chiffres de précision et 9 chiffres décimaux d'échelle. Le type BigQuery BIGNUMERIC (Aperçu) comporte plus de 76 chiffres de précision (le 77e chiffre est partiel) et exactement 38 chiffres d'échelle. |
REAL | FLOAT64 | |
CHAR | STRING | |
CHARACTER | STRING | |
VARCHAR | STRING | |
CLOB | STRING | |
JSON | STRING | |
Blob | BYTES | |
BYTE | BYTES | |
VARBYTE | BYTES | |
DATE | DATE | |
TIME TIMETZ |
TIME | La valeur TIME de BigQuery est exprimée en UTC. Le service de transfert de données BigQuery extrait les valeurs respectives au format UTC. |
TIMESTAMP TIMESTAMPTZ |
TIMESTAMP | La valeur TIMESTAMP de BigQuery est exprimée en UTC. Le service de transfert de données BigQuery extrait les valeurs respectives au format UTC. La précision de la valeur TIMESTAMP est limitée à quelques microsecondes. |
ARRAY | STRING | |
MULTIDIMENSIONALARRAY | STRING | |
HEURE | INTEGER | |
MINUTE | INTEGER | |
SECOND | INTEGER | |
JOUR | INTEGER | |
MOIS | INTEGER | |
ANNÉE | INTEGER | |
PERIODDATE | STRING | |
PERIODTIMESTAMPTZ | STRING | |
PERIODTIMESTAMP | STRING | |
PERIODTIME | STRING | |
PERIODTIMETZ | STRING | |
USERDEFINED | STRING | |
XML | STRING | |
ANYTYPE | STRING |
Transferts incrémentiels
Le service de transfert de données BigQuery est compatible avec les transferts récurrents et périodiques de lignes nouvelles et mises à jour ("transferts incrémentiels"). Les modes de transfert à la demande (unique) ou incrémentiel sont définis dans les options de planification à l'étape de Configuration d'un transfert.
La table source de Teradata doit comporter une colonne de suivi des modifications avec le type de données TIMESTAMP
.
Dans les transferts incrémentiels, le premier transfert crée toujours un instantané de table dans BigQuery. Tous les transferts ultérieurs captureront, transféreront et ajouteront les données nouvelles et modifiées à la table existante dans BigQuery. Cela signifie que pour les lignes modifiées, la table BigQuery peut contenir des lignes en double avec des valeurs anciennes et nouvelles.
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 chaque transfert 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 paramètre usageType
COMMIT_TIMESTAMP
, la table est ignorée. - Si une table possède une colonne avec le paramètre usageType
COMMIT_TIMESTAMP
, toutes les lignes dont l'horodatage est compris entre T1 et T2 sont extraites et ajoutées à la table existante dans BigQuery.
Opérations LDD/LMD dans les transferts incrémentiels
Fonctionnement de Teradata | Type | Compatibilité de Teradata avec BigQuery |
---|---|---|
CREATE | LDD | Si le nom de la table correspond au format indiqué, un nouvel instantané complet de la table est créé dans BigQuery. |
DROP | LDD | Incompatible |
ALTER (RENAME) | LDD | Si le nom d'une table correspond au format indiqué, 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 correspondante. |
METTRE À JOUR | LMD | Les lignes ne sont pas modifiées. Les lignes sont ajoutées à la table BigQuery correspondante en tant que nouvelles lignes, comme un INSERT. Les lignes des transferts précédents ne sont pas mises à jour ou supprimées. |
MERGE | LMD | Non compatible Consultez plutôt INSERT, UPDATE et DELETE. |
DELETE | LMD | Incompatible |
É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 concernant la migration depuis Teradata à l'aide du service de transfert de données BigQuery.
- Découvrez étape par étape comment configurer un transfert d'entrepôt de données Teradata vers BigQuery.