Migrazione da Teradata a BigQuery: panoramica

Questo documento ti aiuta a comprendere le decisioni che devi prendere quando utilizzi BigQuery Data Transfer Service per eseguire la migrazione di schema e dati da Teradata BigQuery.

La migrazione di schema e dati è in genere uno dei diversi passaggi necessari per spostare un data warehouse da una piattaforma diversa a BigQuery. Per una descrizione del processo di migrazione end-to-end, vedi Panoramica: migrazione dei data warehouse in BigQuery

Puoi anche utilizzare traduzione SQL batch eseguire la migrazione collettiva degli script SQL traduzione SQL interattiva per tradurre query ad hoc. Il servizio SQL Teradata è completamente supportato Servizi di traduzione SQL.

Panoramica

Puoi utilizzare BigQuery Data Transfer Service in combinazione con un agente speciale di migrazione per copiare lo schema e i dati da Teradata a in BigQuery. L'agente di migrazione si connette ai tuoi dati locali il warehouse comunica con BigQuery Data Transfer Service per copiare tabelle dal data warehouse a BigQuery.

I passaggi seguenti descrivono il flusso di lavoro per il processo di migrazione:

1. Scarica l'agente di migrazione.
2. Configura un trasferimento in BigQuery Data Transfer Service.
3. Esegui il job di trasferimento per copiare lo schema e i dati della tabella dal tuo data warehouse in BigQuery.
4. Facoltativo. Monitora i job di trasferimento utilizzando la console Google Cloud.

Configurazione del job di trasferimento

Puoi configurare un job di trasferimento in base alle tue esigenze. Prima del giorno prima di configurare un trasferimento di dati da Teradata a BigQuery, considera di configurazione predefinite descritte nelle sezioni seguenti e impostazioni da utilizzare. In base alle impostazioni scegliere, potresti dover completare alcuni prerequisiti prima di iniziare il job di trasferimento.

Per la maggior parte dei sistemi, in particolare quelli con tabelle di grandi dimensioni, è possibile ottenere del rendimento seguendo questa procedura:

1. Partiziona le tabelle Teradata.
2. Utilizza Teradata Parallel Transporter (TPT) per l'estrazione.
3. Crea un file di schema personalizzato e configura il target Clustering e partizionamento delle colonne di BigQuery.

Ciò consente all'agente di migrazione di eseguire l'estrazione partizione per partizione, che è il più efficiente.

Metodo di estrazione

BigQuery Data Transfer Service supporta due metodi di estrazione per Trasferire dati da Teradata a BigQuery:

• Utilizza i comandi Teradata Parallel Transporter (TPT) l'utilità tbuild. Questo è l'approccio consigliato. L'utilizzo di TPT in genere comporta un'estrazione dei dati più rapida.

  In questa modalità, l'agente di migrazione tenta di calcolare i batch di estrazione usando righe distribuite per partizioni. Per ogni batch, l'agente emette ed esegue un'estrazione TPT generando un insieme di file delimitati da barre verticali. Quindi carica questi file in un bucket Cloud Storage, e dove vengono utilizzati dal job di trasferimento. Una volta caricati i file Cloud Storage, l'agente di migrazione li ha eliminati dal file locale di un sistema operativo completo.

  Quando utilizzi l'estrazione TPT senza una colonna di partizionamento, il tuo viene estratta l'intera tabella. Quando utilizzi l'estrazione TPT con una di partizionamento, l'agente estrae insiemi di partizioni.

  In questa modalità, l'agente di migrazione non limita la quantità di spazio occupata dai file estratti sul file system locale. Assicurati che il file system locale abbia più spazio della dimensione del tuo o la tabella più grande, a seconda che tu stia specificando o meno una colonna di partizionamento.

• Estrazione mediante driver JDBC con connessione FastExport. Se sono presenti limitazioni relative allo spazio di archiviazione locale disponibile per i file estratti o se per qualche motivo non puoi utilizzare TPT, utilizza questo metodo di estrazione.

  In questa modalità, l'agente di migrazione estrae le tabelle in una raccolta di file AVRO file system locale. Quindi carica questi file in un bucket Cloud Storage, e dove vengono utilizzati dal job di trasferimento. Una volta caricati i file Cloud Storage, l'agente di migrazione li elimina dal file locale di un sistema operativo completo.

  In questa modalità, puoi limitare la quantità di spazio utilizzata dai file AVRO sul file system locale. Se questo limite viene superato, l'estrazione viene messa in pausa finché l'agente di migrazione non libera spazio caricamento ed eliminazione di file AVRO esistenti.

Identificazione dello schema

BigQuery Data Transfer Service fornisce il rilevamento automatico dello schema e la mappatura dei tipi di dati durante un trasferimento di dati da Teradata a BigQuery. Facoltativamente, puoi specificare un file di schema personalizzato. Consigliamo la personalizzazione dello schema nelle seguenti situazioni:

• Devi acquisire informazioni importanti di una tabella, come il partizionamento, che altrimenti andrebbe persa migrazione.

  Ad esempio: i trasferimenti incrementali devono avere un di schema specificato in modo che i dati dei trasferimenti successivi possano essere partizionate correttamente quando vengono caricate in BigQuery. Senza un file di schema specificato, ogni durante l'esecuzione di un trasferimento, BigQuery Data Transfer Service applica automaticamente schema della tabella utilizzando i dati di origine da trasferire e tutte informazioni su partizionamento, clustering, chiavi primarie e modifica il tracciamento è stato perso.

• Devi modificare i nomi delle colonne o i tipi di dati durante il trasferimento di dati.

File dello schema personalizzato

Un file di schema personalizzato è un file JSON che descrive gli oggetti di database. Lo schema contiene un insieme di database, ciascuno contenente un insieme di tabelle, ognuna delle quali contiene un insieme di colonne. Ogni oggetto ha Campo originalName che indica il nome dell'oggetto in Teradata e un campo name che indica il nome della destinazione dell'oggetto in BigQuery.

Le colonne includono i seguenti campi:

• Un campo originalType che indica il tipo di dati della colonna in Teradata
• Un campo type che indica il tipo di dati di destinazione per la colonna in in BigQuery.

• Un campo usageType per acquisire informazioni sul modo in cui utilizzata dal sistema, ad esempio per il clustering o il partizionamento. Sono supportati i seguenti tipi di utilizzo:

  • CLUSTERING: puoi annotare fino a quattro colonne in ogni tabella di destinazione con questo tipo di utilizzo. L'ordine delle colonne per il clustering è determinato in base all'ordine in cui appaiono nello schema personalizzato. La le colonne selezionate devono soddisfare i vincoli per il clustering in BigQuery. Se un campo PARTITIONING viene specificato per la stessa tabella, BigQuery utilizza queste colonne per creare una tabella in cluster.
  • COMMIT_TIMESTAMP: puoi annotare solo una colonna in ogni target tabella con questo tipo di utilizzo. Usa questo useType per identificare un aggiornamento colonna timestamp per gli aggiornamenti incrementali. Questa colonna è utilizzata per estrarre righe create/aggiornate dal giorno durante l'ultima esecuzione del trasferimento. Puoi utilizzare questo tipo di utilizzo solo con la colonna che ha un tipo di dati TIMESTAMP o DATE.
  • PREDEFINITA: puoi annotare più colonne in una tabella di destinazione con questo tipo di utilizzo. Questo useType indica che la colonna non ha valori speciali nel sistema di origine. Questo è il valore predefinito.
  • PARTIZIONAMENTO: puoi annotare solo una colonna in ogni tabella di destinazione con questo tipo di utilizzo. Questa colonna viene utilizzata nella partizionato definizione della tabella per l'oggetto tables contenitore. Puoi utilizzare questo tipo di utilizzo solo con la colonna che ha un tipo di dati TIMESTAMP o DATE.
  • PRIMARY_KEY: puoi annotare le colonne in ogni tabella di destinazione con questo tipo di utilizzo. Utilizza questo tipo di utilizzo per identificare una sola colonna come chiave primaria o, nel caso di una chiave composta, utilizza lo stesso tipo di utilizzo su più colonne per identificare le entità univoche di una tabella. Questi le colonne collaborano con COMMIT_TIMESTAMP per estrarre righe creato o aggiornato dall'ultima esecuzione del trasferimento.

Puoi creare manualmente un file di schema personalizzato, in base a questo esempio, oppure puoi chiedere all'agente di migrazione di generarne uno quando inizializzare l'agente.

Esempio

Considera che stai eseguendo la migrazione di una tabella Teradata denominata orders in tpch con la seguente definizione di tabella:

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 );

Durante la migrazione a BigQuery, supponiamo che tu voglia configurare lo schema con le seguenti modifiche:

• Rinomina la colonna O_CUSTKEY in O_CUSTOMERKEY.
• Identifica O_ORDERDATE come colonna di partizionamento.

Lo schema personalizzato per configurare queste impostazioni è il seguente:

{
  "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
            }
          ]
        }
      ]
    }
  ]
}

Trasferimenti on demand o incrementali

Quando esegui la migrazione dei dati da un'istanza di database Teradata a BigQuery, BigQuery Data Transfer Service supporta entrambi i trasferimenti completi (trasferimento on demand) e trasferimenti ricorrenti (trasferimenti incrementali). Tu designa il trasferimento come on demand o incrementale nelle opzioni di pianificazione quando configuri un trasferimento.

• Trasferimento on demand: utilizza questa modalità per eseguire la migrazione completa degli snapshot di schema e dati da Teradata a BigQuery.

• Trasferimento pianificato: utilizza questa modalità per eseguire l'istantanea completa e eseguire la migrazione dei dati nuovi e modificati (dati incrementali) da Teradata a in BigQuery. Per i trasferimenti incrementali è necessario per annotare le colonne con uno dei seguenti casi d'uso:

  • Annota le colonne solo con il tipo di utilizzo COMMIT_TIMESTAMP: in questo trasferimento, le righe nuove o modificate in Teradata vengono aggiunte ai dati in in BigQuery. Le righe aggiornate nelle tabelle BigQuery potrebbero avere righe duplicate con valori vecchi e nuovi.
  • Annota le colonne con il tipo di utilizzo COMMIT_TIMESTAMP e PRIMARY_KEY: In questo trasferimento, vengono aggiunte nuove righe e quelle modificate vengono aggiornate al riga corrispondente in BigQuery. La colonna definita in PRIMARY_KEY viene utilizzato per mantenere l'univocità dei dati in in BigQuery.
  • La colonna PRIMARY_KEY definita nello schema non deve necessariamente essere la PRIMARY_KEY nella tabella Teradata. Può essere qualsiasi colonna, ma deve contenere unici dati.

Trasferimenti incrementali

Nei trasferimenti incrementali, il primo trasferimento crea sempre una tabella uno snapshot in BigQuery. Tutti i trasferimenti incrementali successivi devono rispettare le annotazioni definite nel file di schema personalizzato spiegate di seguito.

Per ogni esecuzione di trasferimento, viene salvato un timestamp dell'esecuzione del trasferimento. Per ogni nell'esecuzione di un trasferimento successivo, un agente riceve il timestamp di un trasferimento dell'esecuzione del trasferimento (T1) e il timestamp di inizio dell'esecuzione attuale del trasferimento (T2).

Per i trasferimenti dopo l'esecuzione iniziale, l'agente di migrazione estrarrà i dati utilizzando la seguente logica per tabella:

• Se un oggetto tabella in un file di schema non ha una colonna con un il tipo di utilizzo COMMIT_TIMESTAMP, la tabella viene ignorata.
• Se una tabella ha una colonna con il tipo di utilizzo COMMIT_TIMESTAMP, tutte le righe con un timestamp compreso tra T1 e T2 vengono estratte e aggiunte alla tabella esistente in BigQuery.
• Se una tabella ha una colonna con il tipo di utilizzo COMMIT_TIMESTAMP e un valore colonna con tipo di utilizzo PRIMARY_KEY, poi tutte le righe con un timestamp tra T1 e T2 vengono estratti. Le nuove righe vengono aggiunte e quelle modificate vengono aggiornate nella tabella esistente in BigQuery.

Di seguito sono riportati alcuni esempi di file schema per i trasferimenti incrementali.

Schema con solo 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
            }
          ]
        }
      ]
    }
  ]
}

Schema con COMMIT_TIMESTAMP e una colonna (ID) come 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
            }
          ]
        }
      ]
    }
  ]
}

Schema con COMMIT_TIMESTAMP e chiave composita (ID + nome) pari a 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
            }
          ]
        }
      ]
    }
  ]
}

La tabella seguente descrive in che modo l'agente di migrazione gestisce le operazioni DDL (Data Definition Language) e DML (Data Manipulation Language) nei trasferimenti incrementali.

Considerazioni sulla località

Il bucket Cloud Storage deve trovarsi in una o più regioni, ovvero compatibile con la regione o le regioni del set di dati di destinazione in in BigQuery.

• Se il set di dati BigQuery si trova in una località multiregionale, il bucket Cloud Storage contenenti i dati che stai trasferendo devono trovarsi nella stessa località multiregionale o in una località è contenuto all'interno di più regioni. Ad esempio, se il set di dati BigQuery è Nella località multiregionale "UE", il bucket Cloud Storage può trovarsi in "europe-west1" Regione del Belgio all'interno dell'UE.
• Se il set di dati si trova in una regione, il bucket Cloud Storage deve trovarsi nella stessa regione. Per Ad esempio, se il set di dati si trova nella regione di Tokyo "asia-northeast1", la Cloud Storage il bucket non può essere in più regioni "ASIA".

Per informazioni dettagliate su trasferimenti e regioni, vedi Località e trasferimenti dei set di dati.

Prezzi

Il trasferimento di dati con BigQuery è senza costi aggiuntivi. Tuttavia, all'esterno di Google in caso di utilizzo di questo servizio, ad esempio: i costi per il trasferimento di dati in uscita dalla piattaforma.

• L'estrazione, il caricamento su un bucket di Cloud Storage e il caricamento di dati su BigQuery sono gratuiti.
• I dati non vengono automaticamente eliminati dal bucket Cloud Storage dopo il caricamento in BigQuery. È consigliabile eliminare i dati dal bucket di Cloud Storage per evitare costi di archiviazione aggiuntivi. Vedi Prezzi di Cloud Storage.
• BigQuery standard Quote e limiti per i job di caricamento.
• Si applicano le quote e i limiti di BigQuery DML standard per gli upsert di importazione incrementale.
• Una volta che i dati sono stati trasferiti in BigQuery, BigQuery archiviazione e si applicano i prezzi delle query.
• Per informazioni dettagliate, consulta la pagina Prezzi dei trasferimenti.

Limitazioni

• I trasferimenti on demand una tantum sono pienamente supportati. I trasferimenti incrementali sono in versione beta. Operazioni DDL/DML nei trasferimenti incrementali sono parzialmente supportati.
• Durante il trasferimento, i dati vengono estratti in una directory sul file locale di un sistema operativo completo. Assicurati che lo spazio libero sia sufficiente.
  • Quando utilizzi la modalità di estrazione FastExport, puoi impostare il valore massimo di spazio di archiviazione utilizzato, il limite imposto dalla migrazione un agente. Configura l'impostazione max-local-storage nel file di configurazione dell'agente di migrazione quando configurare un trasferimento da Teradata a BigQuery.
  • Quando utilizzi il metodo di estrazione TPT, assicurati che il file system disponga di spazio libero sufficiente, maggiore della partizione di tabella più grande nell'istanza Teradata.
• BigQuery Data Transfer Service converte automaticamente lo schema (se non fornisci un file di schema personalizzato) e trasferisce i dati Teradata in BigQuery. I dati vengono mappati dai tipi Teradata ai tipi BigQuery.
• I file non vengono eliminati automaticamente dal bucket di Cloud Storage dopo essere stati caricati in BigQuery. È consigliabile eliminare i dati dal bucket di Cloud Storage dopo averli caricati in BigQuery per evitare costi di archiviazione aggiuntivi. Consulta la sezione Prezzi.
• La velocità di estrazione è limitata dalla connessione JDBC.
• I dati estratti da Teradata non sono criptati. Prendi l'appropriato passaggi per limitare l'accesso ai file estratti nel file system locale; e assicurarti che il bucket Cloud Storage sia protetto in modo adeguato.
• Altre risorse di database, come procedure archiviate, query salvate, viste e funzioni definite dall'utente, non vengono trasferite e non rientrano nell'ambito di questo servizio.
• I trasferimenti incrementali non supportano le eliminazioni definitive. Trasferimenti incrementali non sincronizza le righe eliminate in Teradata con BigQuery.

Passaggi successivi

• Ricevi istruzioni passo passo per Eseguire la migrazione di Teradata a BigQuery.
• Prova una migrazione di prova dell' da Teradata a BigQuery.