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 dello schema e dei dati da Teradata a 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 della procedura di migrazione end-to-end, consulta Panoramica: eseguire la migrazione dei data warehouse in BigQuery.
Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione collettiva degli script SQL o la traduzione SQL interattiva per tradurre query ad hoc. Teradata SQL è 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:
- Scarica l'agente di migrazione.
- Configura un trasferimento in BigQuery Data Transfer Service.
- Esegui il job di trasferimento per copiare lo schema e i dati della tabella dal tuo data warehouse in BigQuery.
- 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 di configurare un trasferimento di dati da Teradata a BigQuery, valuta le opzioni di configurazione descritte nelle sezioni seguenti e decidi quali impostazioni utilizzare. A seconda delle impostazioni scelte, potresti dover completare alcuni prerequisiti prima di avviare il job di trasferimento.
Per la maggior parte dei sistemi, in particolare quelli con tabelle di grandi dimensioni, puoi ottenere il rendimento migliore seguendo questi passaggi:
- Partiziona le tabelle Teradata.
- Utilizza Teradata Parallel Transporter (TPT) per l'estrazione.
- Crea un file dello schema personalizzato e configura le colonne di clustering e partizione di BigQuery di destinazione.
In questo modo, l'agente di migrazione può 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 di Teradata Parallel Transporter (TPT). Questo è l'approccio consigliato. L'utilizzo di TPT in genere comporta un'estrazione più rapida dei dati.
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 insieme di file delimitati da trattini. Carica poi questi file in un bucket Cloud Storage, dove vengono utilizzati dal job di trasferimento. Una volta caricati su 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 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 rispetto alle dimensioni della partizione o della tabella più grande, a seconda che tu specifichi o meno una colonna di partizione.
Estrazione utilizzando un driver JDBC con connessione FastExport. Se lo spazio di archiviazione locale disponibile per i file estratti è limitato 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 sul file system locale. Carica poi questi file in un bucket Cloud Storage, dove vengono utilizzati dal job di trasferimento. Una volta caricati su 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 sul file system locale. Se questo limite viene superato, l'estrazione viene messa in pausa finché lo spazio non viene liberato dall'agente di migrazione caricando ed eliminando i 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. In alternativa, puoi specificare un file di schema personalizzato. Consigliamo di personalizzare lo schema nelle seguenti situazioni:
Devi acquisire informazioni importanti su una tabella, come la partizione, che altrimenti andrebbero perse durante la migrazione.
Ad esempio, per i trasferimenti incrementali deve essere specificato un file dello schema in modo che i dati dei trasferimenti successivi possano essere partizionati correttamente quando vengono caricati in BigQuery. Se non viene specificato un file dello schema, ogni volta che viene eseguito un trasferimento, BigQuery Data Transfer Service applica automaticamente uno schema della tabella utilizzando i dati di origine trasferiti e tutte le informazioni su partizionamento, clustering, chiavi principali e monitoraggio delle modifiche vengono perse.
Devi modificare i nomi delle colonne o i tipi di dati durante il trasferimento dei dati.
File dello schema personalizzato
Un file di schema personalizzato è un file JSON che descrive gli oggetti del database. Lo schema contiene un insieme di database, ciascuno contenente un insieme di tabelle, ciascuna 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 target dell'oggetto in BigQuery.
Le colonne hanno anche 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 nel clustering o nel partizionamento. Sono supportati i seguenti tipi di utilizzo:
- AGGLOMERAMENTI: con questo tipo di utilizzo puoi annotare fino a quattro colonne in ogni tabella di destinazione. L'ordine delle colonne per il clustering viene determinato in base all'ordine in cui appaiono nello schema personalizzato. Le
colonne selezionate devono soddisfare i
vincoli
per il clustering in BigQuery. Se per la stessa tabella è specificato un campo
PARTITIONING, BigQuery utilizza queste colonne per creare una tabella raggruppata. - COMMIT_TIMESTAMP: con questo tipo di utilizzo puoi annotare una sola colonna in ogni tabella di destinazione. Utilizza questo valore usageType per identificare una colonna timestamp dell'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 che ha un tipo di dati
TIMESTAMPoDATE. - PREDEFINITO: con questo tipo di utilizzo puoi annotare più colonne in una tabella di destinazione. Questo valore usageType indica che la colonna non ha un uso speciale nel sistema di origine. Questo è il valore predefinito.
- SEPARAZIONE: con questo tipo di utilizzo puoi annotare una sola colonna in ogni tabella di destinazione. Questa colonna viene utilizzata nella definizione della tabella partizionata per l'oggetto tables contenente. Puoi utilizzare questo tipo di utilizzo solo con la colonna che ha un tipo di dati
TIMESTAMPoDATE. - 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. Queste colonne lavorano insieme a
COMMIT_TIMESTAMPper estrarre le righe create o aggiornate dall'ultima esecuzione del trasferimento.
- AGGLOMERAMENTI: con questo tipo di utilizzo puoi annotare fino a quattro colonne in ogni tabella di destinazione. L'ordine delle colonne per il clustering viene determinato in base all'ordine in cui appaiono nello schema personalizzato. Le
colonne selezionate devono soddisfare i
vincoli
per il clustering in BigQuery. Se per la stessa tabella è specificato un campo
Puoi creare un file dello schema personalizzato manualmente, in base a questo esempio, oppure puoi chiedere all'agente di migrazione di generarne uno quando lo inzializzi.
Esempio
Supponiamo che tu stia eseguendo 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_CUSTKEYinO_CUSTOMERKEY. - Identifica
O_ORDERDATEcome 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 incrementali o on demand
Durante la migrazione dei dati da un'istanza del database Teradata a BigQuery, BigQuery Data Transfer Service supporta sia i trasferimenti completi (trasferimento on demand) sia i trasferimenti ricorrenti (trasferimenti incrementali). 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 completa dello snapshot di schema e dati da Teradata a BigQuery.
Trasferimento pianificato: utilizza questa modalità per eseguire lo snapshot completo e migrare regolarmente i dati nuovi e modificati (incrementali) da Teradata a BigQuery. I trasferimenti incrementali richiedono la personalizzazione dello schema per annotare le colonne con uno dei seguenti casi d'uso:
- Aggiungi annotazioni alle colonne solo con il tipo di utilizzo
COMMIT_TIMESTAMP: in questo trasferimento, le righe nuove o modificate in Teradata vengono aggiunte ai dati in BigQuery. Le righe aggiornate nelle tabelle BigQuery potrebbero avere righe duplicate con valori vecchi e nuovi. - Aggiungi annotazioni alle colonne con il tipo di utilizzo
COMMIT_TIMESTAMPePRIMARY_KEY: in questo trasferimento, le nuove righe vengono aggiunte e le righe modificate vengono aggiornate nella corrispondente riga in BigQuery. La colonna definita inPRIMARY_KEYviene utilizzata per mantenere l'univocità dei dati in BigQuery. - La colonna
PRIMARY_KEYdefinita nello schema non deve essere la colonnaPRIMARY_KEYnella tabella Teradata. Può essere qualsiasi colonna, ma deve contenere dati univoci.
- Aggiungi annotazioni alle colonne solo con il tipo di utilizzo
Trasferimenti incrementali
Nei trasferimenti incrementali, il primo trasferimento crea sempre uno snapshot della tabella in BigQuery. Tutti i trasferimenti incrementali successivi si baseranno sulle annotazioni definite nel file dello schema personalizzato spiegato di seguito.
Per ogni esecuzione del trasferimento, viene salvato un timestamp dell'esecuzione. Per ogni esecuzione di trasferimento successiva, un agente riceve il timestamp di un'esecuzione di trasferimento precedente (T1) e il timestamp dell'inizio dell'esecuzione di trasferimento corrente (T2).
Per i trasferimenti dopo l'esecuzione iniziale, l'agente di migrazione estrae i dati utilizzando la seguente logica per tabella:
- Se un oggetto tabella in un file dello schema non ha una colonna con un tipo di utilizzo
COMMIT_TIMESTAMP, la tabella viene saltata. - 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_TIMESTAMPe un'altra con il tipo di utilizzoPRIMARY_KEY, vengono estratte tutte le righe con un timestamp tra T1 e T2. 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) 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": "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.
| Operazione Teradata | Tipo | Supporto per il trasferimento da Teradata a BigQuery |
|---|---|---|
CREATE |
DDL | In BigQuery viene creato un nuovo snapshot completo della 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 riceve una notifica relativa alla tabella riassegnata. |
INSERT |
DML | Vengono aggiunte nuove righe alla tabella BigQuery. |
UPDATE |
DML | Le righe vengono aggiunte alla tabella BigQuery come nuove, in modo simile a un'operazione INSERT se viene utilizzato solo COMMIT_TIMESTAMP.
Le righe vengono aggiornate, in modo simile a un'operazione UPDATE, se vengono utilizzati sia COMMIT_TIMESTAMP sia PRIMARY_KEY. |
MERGE |
DML | Non supportati. Consulta invece INSERT, UPDATE
e DELETE. |
DELETE |
DML | Non supportata |
Considerazioni sulla località
Il bucket Cloud Storage deve trovarsi in una regione o in una regione multipla compatibile con la regione o la regione multipla del set di dati di destinazione in BigQuery.
- Se il set di dati BigQuery si trova in una regione multipla, il bucket Cloud Storage contenente i dati che stai trasferendo deve trovarsi nella stessa regione multipla o in una posizione contenuta al suo interno. Ad esempio, se il set di dati BigQuery si trova nella regione multiregionale "UE", il bucket Cloud Storage può trovarsi nella regione Belgio "europe-west1", che fa parte 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 Tokyo "asia-northeast1", il bucket Cloud Storage non può trovarsi nella regione multipla "ASIA".
Per informazioni dettagliate su trasferimenti e regioni, consulta Località e trasferimenti dei set di dati.
Prezzi
Il trasferimento dei dati con BigQuery è gratuito. Tuttavia, utilizzando questo servizio è possibile incorrere in costi esterni a Google, ad esempio 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 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 le quote e i limiti di BigQuery standard ai job di caricamento.
- Si applicano le quote e i limiti di BigQuery DML standard per gli upsert di importazione incrementale.
- Quando i dati vengono trasferiti su BigQuery, vengono applicati i prezzi standard di BigQuery per l'archiviazione e l'elaborazione.
- Per maggiori dettagli, consulta la pagina dei prezzi relativa ai trasferimenti.
Limitazioni
- I trasferimenti una tantum on demand sono completamente supportati. I trasferimenti incrementali sono in versione beta. Le operazioni DDL/DML nei trasferimenti incrementali sono supportate parzialmente.
- Durante il trasferimento, i dati vengono estratti in una directory del sistema di file locale. Assicurati che lo spazio libero sia sufficiente.
- Quando utilizzi la modalità di estrazione FastExport, puoi impostare lo spazio di archiviazione massimo da utilizzare e il limite applicato con molta efficacia dall'agente di migrazione. Imposta l'impostazione
max-local-storagenel 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, maggiore della partizione di tabella più grande nell'istanza Teradata.
- Quando utilizzi la modalità di estrazione FastExport, puoi impostare lo spazio di archiviazione massimo da utilizzare e il limite applicato con molta efficacia dall'agente di migrazione. Imposta l'impostazione
- BigQuery Data Transfer Service converte automaticamente lo schema (se non fornisci un file dello schema personalizzato) e trasferisce i dati di Teradata a BigQuery. I dati vengono mappati dai tipi Teradata ai tipi BigQuery.
- I file non vengono eliminati automaticamente dal bucket Cloud Storage dopo essere stati caricati in BigQuery. È consigliabile eliminare i dati dal bucket Cloud Storage dopo averli caricati in BigQuery per evitare costi di archiviazione aggiuntivi. Consulta la sezione Prezzi.
- La velocità dell'estrazione è limitata dalla connessione JDBC.
- I dati estratti da Teradata non sono criptati. Adotta le misure appropriate per limitare l'accesso ai file estratti nel file system locale e assicurati che il bucket Cloud Storage sia protetto correttamente.
- 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. I trasferimenti incrementali non sincronizzano le righe eliminate in Teradata con BigQuery.
Passaggi successivi
- Consulta le istruzioni dettagliate per eseguire la migrazione di Teradata a BigQuery.
- Prova una migrazione di prova da Teradata a BigQuery.