Cette page a été traduite par l'API Cloud Translation.
Switch to English

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. 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 (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 ou DATE.

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