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. 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 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
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é
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_CUSTKEY
enO_CUSTOMERKEY
. - Configurer un transfert incrémentiel à l'aide de la colonne
O_ORDERDATE
.
Le schéma personnalisé permettant de configurer ces paramètres est le suivant :
{
"databases": [
{
"name": "tpch",
"originalName": "tpch",
"tables": [
{
"name": "orders",
"originalName": "orders",
"columns": [
{
"name": "O_ORDERKEY",
"originalName": "O_ORDERKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_CUSTOMERKEY",
"originalName": "O_CUSTKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_ORDERSTATUS",
"originalName": "O_ORDERSTATUS",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_TOTALPRICE",
"originalName": "O_TOTALPRICE",
"type": "NUMERIC",
"originalType": "decimal",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_ORDERDATE",
"originalName": "O_ORDERDATE",
"type": "DATE",
"originalType": "date",
"usageType": [
"COMMIT_TIMESTAMP"
]
},
{
"name": "O_ORDERPRIORITY",
"originalName": "O_ORDERPRIORITY",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_CLERK",
"originalName": "O_CLERK",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_SHIPPRIORITY",
"originalName": "O_SHIPPRIORITY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_COMMENT",
"originalName": "O_COMMENT",
"type": "STRING",
"originalType": "varchar",
"usageType": [
"DEFAULT"
]
}
]
}
]
}
]
}
Les champs suivants permettent de mapper des noms d'objet Teradata à des noms d'objet BigQuery :
- Le champ
originalName
spécifie le nom de l'objet Teradata. - Le champ
name
spécifie le nom de l'objet BigQuery.
Les champs suivants permettent de mapper les types de données Teradata aux types de données BigQuery. Par exemple, vous pouvez mapper une date à STRING
ou un horodatage à DATETIME
:
- Le champ
originalType
spécifie le type de données de la colonne Teradata. - Le champ
type
spécifie le type de données de la colonne BigQuery.
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 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
ou DATE
.
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.