Migration Teradata : détails et options

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 ou TIMESTAMP. 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 type INT64, STRING, DATE, TIMESTAMP, BOOL, NUMERIC ou BIGNUMERIC 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 ou DATE.

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 en O_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