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 a BigQuery.

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

Puoi anche utilizzare la traduzione SQL in batch per eseguire la migrazione collettiva degli script SQL oppure la traduzione SQL interattiva per tradurre le query ad hoc. Il linguaggio SQL di Teradata è completamente supportato da entrambi i servizi di traduzione SQL.

Panoramica

Puoi utilizzare BigQuery Data Transfer Service in combinazione con un agente di migrazione speciale per copiare lo schema e i dati da Teradata a BigQuery. L'agente di migrazione si connette al tuo data warehouse locale e comunica con BigQuery Data Transfer Service per copiare le 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 della tabella e i dati dal tuo data warehouse in BigQuery.
  4. Facoltativo. Monitorare i job di trasferimento utilizzando la console Google Cloud.

Configurazione job di trasferimento

Puoi configurare un job di trasferimento in base alle tue esigenze. Prima di configurare un trasferimento di dati da Teradata a BigQuery, prendi in considerazione le opzioni di configurazione descritte nelle sezioni seguenti e decidi quali impostazioni utilizzare. A seconda delle impostazioni che scegli, 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, puoi ottenere le migliori prestazioni seguendo questi passaggi:

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

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

Metodo di estrazione

BigQuery Data Transfer Service supporta due metodi di estrazione per il trasferimento dei dati da Teradata a BigQuery:

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

    In questa modalità, l'agente di migrazione tenta di calcolare i batch di estrazione utilizzando le righe distribuite per partizioni. Per ogni batch, l'agente emette ed esegue uno script di estrazione TPT, producendo un set di file delimitati da barre verticali. Quindi carica questi file in un bucket Cloud Storage, dove vengono utilizzati dal job di trasferimento. Una volta caricati i file in Cloud Storage, l'agente di migrazione li ha eliminati dal file system locale.

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

    In questa modalità, l'agente di migrazione non limita la quantità di spazio che i file estratti occupano nel file system locale. Assicurati che il file system locale abbia più spazio rispetto alla dimensione della partizione più grande o della 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 sullo spazio di archiviazione locale disponibile per i file estratti o se esiste un motivo per cui 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 nel file system locale. Quindi carica questi file in un bucket Cloud Storage, dove vengono utilizzati dal job di trasferimento. Una volta caricati i file in Cloud Storage, l'agente di migrazione li elimina dal file system locale.

    In questa modalità, puoi limitare la quantità di spazio utilizzata dai file AVRO nel file system locale. Se questo limite viene superato, l'estrazione viene messa in pausa finché non viene liberato spazio dall'agente di migrazione che carica ed elimina i file AVRO esistenti.

Identificazione schema

BigQuery Data Transfer Service fornisce rilevamento automatico degli schemi e mappatura dei tipi di dati durante un trasferimento di dati da Teradata a BigQuery. Se vuoi, puoi specificare un file di schema personalizzato. Ti consigliamo la personalizzazione dello schema nelle seguenti situazioni:

  • Devi acquisire informazioni importanti su una tabella, come il partizionamento, che altrimenti andrebbero perse nella migrazione.

    Ad esempio, per i trasferimenti incrementali deve essere specificato un file di schema in modo che i dati dei trasferimenti successivi possano essere partizionati correttamente quando vengono caricati in BigQuery. Se non viene specificato un file di schema, ogni volta che viene eseguito un trasferimento, BigQuery Data Transfer Service applica automaticamente uno schema di tabella utilizzando i dati di origine trasferiti e tutte le informazioni su partizionamento, clustering, chiavi primarie e monitoraggio delle modifiche andranno perse.

  • Durante il trasferimento dei dati devi modificare i nomi o i tipi di dati delle colonne.

File 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 un 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 inoltre 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 target per la colonna in BigQuery.

  • Un campo usageType per acquisire informazioni sul modo in cui la colonna viene 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 vengono visualizzate nello schema personalizzato. Le colonne selezionate devono soddisfare i vincoli per il clustering in BigQuery. Se viene specificato un campo PARTITIONING per la stessa tabella, BigQuery utilizza queste colonne per creare una tabella in cluster.
    • COMMIT_TIMESTAMP: con questo tipo di utilizzo puoi annotare solo una colonna in ogni tabella di destinazione. Utilizza questo useType per identificare una colonna di timestamp di aggiornamento per gli aggiornamenti incrementali. Questa colonna viene utilizzata per estrarre le righe create/aggiornate dall'ultima esecuzione del trasferimento. Puoi utilizzare questo tipo di utilizzo solo con la colonna con un tipo di dati TIMESTAMP o DATE.
    • PREDEFINITO: puoi annotare più colonne in un'unica tabella di destinazione con questo tipo di utilizzo. Questo useType indica che la colonna non ha un uso speciale nel sistema di origine. Questo è il valore predefinito.
    • PARTIZIONE: con questo tipo di utilizzo puoi annotare solo una colonna in ogni tabella di destinazione. Questa colonna viene utilizzata nella definizione della tabella partitioned per l'oggetto tables contenitore. Puoi utilizzare questo tipo di utilizzo solo con colonne con un tipo di dati TIMESTAMP o DATE.

Puoi creare manualmente un file di schema personalizzato, basato su questo esempio, oppure puoi chiedere all'agente di migrazione di generarne uno per te quando inizializzi l'agente.

Esempio

Considera di eseguire la migrazione di una tabella Teradata denominata orders nel database 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

Durante la migrazione dei dati da un'istanza di database Teradata a BigQuery, BigQuery Data Transfer Service supporta sia trasferimenti una tantum (un "trasferimento on demand") sia trasferimenti periodici e periodici di righe nuove e aggiornate ("trasferimenti incrementali") (anteprima). Puoi designare 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 iniziale dello schema e dati da Teradata a BigQuery.

  • Trasferimento incrementale: utilizza questa modalità per eseguire regolarmente la migrazione di dati nuovi e modificati da Teradata a BigQuery.

    • Questo metodo richiede la personalizzazione dello schema per annotare le colonne con il tipo di utilizzo COMMIT_TIMESTAMP.
    • Quando si configurano trasferimenti incrementali si applicano determinate condizioni.

Trasferimenti incrementali

Nei trasferimenti incrementali, il primo trasferimento crea sempre uno snapshot della tabella in BigQuery. Tutti i trasferimenti successivi acquisiscono, trasferiscono e aggiungono dati nuovi e modificati alla tabella esistente in BigQuery. Ciò significa che, per le righe modificate, la tabella BigQuery potrebbe avere righe duplicate con valori vecchi e nuovi.

Per ogni esecuzione di trasferimento, viene salvato il relativo timestamp. Per ogni esecuzione di trasferimento successiva, un agente riceve il timestamp di un trasferimento precedente (T1) e un timestamp che indica quando è iniziata l'esecuzione attuale del trasferimento (T2).

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

  • Se un oggetto di tabella in un file di schema non ha una colonna con 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.

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

Operazione Teradata Tipo Assistenza da Teradata a BigQuery
CREATE DDL In BigQuery viene creato un nuovo snapshot completo per la tabella.
DROP DDL Non supportata
ALTER (RENAME) DDL In BigQuery viene creato un nuovo snapshot completo per la tabella rinominata. Lo snapshot precedente non viene eliminato da BigQuery}. L'utente non viene avvisato della tabella rinominata.
INSERT DML Vengono aggiunte nuove righe alla tabella BigQuery.
UPDATE DML Le righe non vengono modificate. Le righe vengono aggiunte alla tabella BigQuery come nuove, in modo simile a un'operazione INSERT. Le righe dei trasferimenti precedenti non vengono aggiornate né eliminate.
MERGE DML Non supportati. Vedi invece INSERT, UPDATE e DELETE.
DELETE DML Non supportata

Considerazioni sulla località

Il bucket Cloud Storage deve trovarsi in una o più regioni compatibile con quelle del set di dati di destinazione in BigQuery.

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

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

Prezzi

Il trasferimento dei dati con BigQuery è senza costi. Tuttavia, utilizzando questo servizio potrebbero essere addebitati costi esterni a Google, ad esempio i costi per il trasferimento di dati in uscita della piattaforma.

  • L'estrazione, il caricamento su un bucket di Cloud Storage e il caricamento di dati su BigQuery sono gratuiti.
  • I dati non vengono eliminati automaticamente dal bucket Cloud Storage dopo essere stati caricati su BigQuery. È consigliabile eliminare i dati dal bucket di Cloud Storage per evitare costi di archiviazione aggiuntivi. Vedi Prezzi di Cloud Storage.
  • Si applicano quote e limiti standard di BigQuery sui job di caricamento.
  • Quando i dati vengono trasferiti su BigQuery, vengono applicati i prezzi standard di BigQuery per l'archiviazione e le query.
  • Consulta la nostra pagina dei prezzi dei trasferimenti per i dettagli.

Limitazioni

  • I trasferimenti una tantum on demand sono completamente supportati. I trasferimenti incrementali sono in beta. Le operazioni DDL/DML nei trasferimenti incrementali sono parzialmente supportate.
  • Durante il trasferimento dei dati, i dati vengono estratti in una directory nel file system locale. Assicurati che ci sia spazio libero adeguato.
    • Quando utilizzi la modalità di estrazione FastExport, puoi impostare lo spazio di archiviazione massimo da utilizzare e il limite applicato in modo forzato dall'agente di migrazione. Imposta l'impostazione max-local-storage nel file di configurazione dell'agente di migrazione quando configuri un trasferimento da Teradata a BigQuery.
    • Quando utilizzi il metodo di estrazione TPT, assicurati che il file system disponga di spazio libero sufficiente, ovvero maggiore della partizione della 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 da Teradata ai tipi BigQuery.
  • I file non vengono eliminati automaticamente dal bucket Cloud Storage dopo il caricamento in BigQuery. Valuta la possibilità di eliminare i dati dal bucket Cloud Storage dopo averli caricati in BigQuery, per evitare costi di archiviazione aggiuntivi. Consulta la sezione Prezzi.
  • La velocità di estrazione è legata alla tua connessione JDBC.
  • I dati estratti da Teradata non sono criptati. Adotta i passaggi appropriati per limitare l'accesso ai file estratti nel file system locale e assicurati che il bucket Cloud Storage sia protetto correttamente.
  • Altre risorse del database, come stored procedure, query salvate, viste e funzioni definite dall'utente non vengono trasferite e non rientrano nell'ambito di questo servizio.

Passaggi successivi