Migrazione da Teradata a BigQuery: panoramica

Questo documento fornisce ulteriori informazioni per aiutarti 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. Per un'introduzione al processo di migrazione di Teradata, consulta Introduzione alla migrazione da Teradata a BigQuery.

La migrazione di schema e dati è in genere uno dei passaggi necessari per spostare un data warehouse da una piattaforma diversa a BigQuery. Per una descrizione di un processo di migrazione generale, consulta Panoramica: eseguire la migrazione dei data warehouse in BigQuery.

Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione degli script SQL in blocco o la traduzione SQL interattiva per tradurre le 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 data warehouse locale e comunica con BigQuery Data Transfer Service per copiare le tabelle dal data warehouse a BigQuery.

I seguenti passaggi 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 delle tabelle dal data warehouse a BigQuery.
  4. (Facoltativo) Monitora i job di trasferimento utilizzando la Google Cloud console.

Configurazione del job di trasferimento

Puoi configurare un job di trasferimento in modo che si adatti al meglio alle tue esigenze. Prima di configurare un trasferimento di dati da Teradata a BigQuery, esamina le opzioni di configurazione descritte nelle sezioni seguenti e decidi quali impostazioni utilizzare. A seconda delle impostazioni scelte, potrebbe essere necessario 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 le prestazioni migliori seguendo questi passaggi:

  1. Partiziona le tabelle Teradata.
  2. Utilizza Teradata Parallel Transporter (TPT) per l'estrazione.
  3. Crea un file di schema personalizzato e configura le colonne di clustering e partizionamento 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 di 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 dei dati più rapida.

    In questa modalità, l'agente di migrazione tenta di calcolare i batch di estrazione utilizzando le righe distribuite dalle partizioni. Per ogni batch, l'agente emette ed esegue uno script di estrazione TPT, producendo un insieme di file delimitati da pipe. 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.

    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 occupato dai file estratti nel file system locale. Assicurati che il file system locale abbia più spazio delle dimensioni della partizione o della tabella più grande, a seconda che tu stia specificando o meno una colonna di partizionamento.

    Utilizza il modulo di accesso per Cloud Storage. Questo approccio elimina la necessità di spazio di archiviazione intermedio nel file system locale, il che offre prestazioni migliori e un utilizzo delle risorse inferiore della VM che esegue l'agente. Questo approccio esporta direttamente i dati in Cloud Storage utilizzando il modulo di accesso Teradata per Cloud Storage. Per utilizzare questa funzionalità, gli strumenti Teradata in esecuzione sulla VM devono essere più recenti della versione 17.20. Gli strumenti Teradata possono essere aggiornati in modo indipendente senza modifiche alla versione dell'istanza Teradata.

  • Estrazione utilizzando un driver JDBC con connessione FastExport. Se esistono vincoli sullo 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 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 sospesa finché l'agente di migrazione non carica ed elimina i file AVRO esistenti per liberare spazio.

Identificazione dello schema

Puoi definire lo schema in diversi modi. BigQuery Data Transfer Service fornisce il rilevamento automatico dello schema e il mapping dei tipi di dati durante un trasferimento di dati da Teradata a BigQuery. Puoi anche utilizzare il motore di traduzione per ottenere il mapping dei tipi di dati oppure scegliere di specificare un file di schema personalizzato.

Rilevamento dello schema predefinito

Se non specifichi alcuna configurazione dello schema, BigQuery Data Transfer Service rileva automaticamente lo schema delle tabelle di origine Teradata ed esegue il mapping dei tipi di dati ai tipi di dati BigQuery corrispondenti durante il trasferimento dei dati. Per ulteriori informazioni sul mapping dei tipi di dati predefinito, consulta Tipi di dati.

Utilizzo dell'output del motore di traduzione per lo schema

BigQuery Data Transfer Service utilizza l'output del motore di traduzione di BigQuery per il mapping dello schema durante la migrazione delle tabelle Teradata a BigQuery. Per utilizzare questa opzione, assicurati che siano soddisfatti i seguenti prerequisiti:

  1. Genera i metadati per la traduzione. Esegui lo strumento di dumping per generare i metadati per la traduzione, rispettando le linee guida dell'origine Teradata. Per ulteriori informazioni, consulta Generare metadati per la traduzione e la valutazione.
  2. Carica il file di metadati generato (ad esempio, metadata.zip) in un bucket Cloud Storage. Questo bucket funge da località di input per il motore di traduzione.

  3. Avvia un job di traduzione batch per creare il mapping di BigQuery Data Transfer Service, che definisce lo schema per le tabelle BigQuery di destinazione. Per informazioni su come eseguire questa operazione, consulta Creare una traduzione batch. L'esempio seguente genera il mapping di BigQuery Data Transfer Service specificando target_types = "dts_mapping":

    curl -d "{
\"name\": \"teradata_2_bq_translation\",
 \"displayName\": \"Teradata to BigQuery Translation\",
 \"tasks\": {
     string: {
       \"type\": \"Teradata2BigQuery_Translation\",
       \"translation_details\": {
           \"target_base_uri\": \"gs://your_translation_output_bucket/output\",
           \"source_target_mapping\": {
             \"source_spec\": {
                 \"base_uri\": \"gs://your_metadata_bucket/input\"
             }
           },
           \"target_types\": \"metadata\",
       }
     }
 },
 }" \
 -H "Content-Type:application/json" \
 -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/your_project_id/locations/your_location/workflows

    Puoi controllare lo stato del job di traduzione batch nella Google Cloud console andando a BigQuery -> Traduzione SQL. Una volta completato, il file di mapping viene archiviato in una località Cloud Storage specificata nel flag target_base_uri.

    Per generare un token, utilizza il comando gcloud auth print-access-token o OAuth 2.0 Playground con l'ambito https://www.googleapis.com/auth/cloud-platform.

  4. Nella configurazione del trasferimento dei dati Teradata, specifica il percorso della cartella Cloud Storage in cui è archiviato il file di mapping del passaggio precedente. BigQuery Data Transfer Service utilizza questo mapping per definire lo schema delle tabelle BigQuery di destinazione.

File di schema personalizzato

Ti consigliamo di specificare uno schema personalizzato nelle seguenti situazioni:

  • Se devi acquisire informazioni importanti su una tabella, ad esempio il partizionamento, che altrimenti andrebbero perse durante la migrazione.

    Ad esempio, i trasferimenti incrementali devono avere un file di schema specificato in modo che i dati dei trasferimenti successivi possano essere partizionati correttamente quando vengono caricati in BigQuery. Senza 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 vengono perse.

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

Un file di schema personalizzato è un file JSON che descrive gli oggetti del database. Lo schema contiene un insieme di database, ognuno dei quali contiene 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 di destinazione dell'oggetto in BigQuery.

Le colonne hanno i seguenti campi:

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

  • usageType: informazioni sul modo in cui la colonna viene utilizzata dal sistema. Sono supportati i seguenti tipi di utilizzo:

    • DEFAULT: puoi annotare più colonne in una tabella di destinazione con questo tipo di utilizzo. Questo usageType indica che la colonna non ha un utilizzo speciale nel sistema di origine. Questo è il valore predefinito.
    • 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 per la stessa tabella viene specificato un campo PARTITIONING, BigQuery utilizza queste colonne per creare una tabella in cluster.
    • PARTITIONING: puoi annotare una sola colonna in ogni tabella di destinazione con questo tipo di utilizzo. Questa colonna viene utilizzata nella tabella partizionata definizione per l'oggetto tables contenitore. Puoi utilizzare questo tipo di utilizzo solo con una colonna che ha un tipo di dati TIMESTAMP o DATE.
    • COMMIT_TIMESTAMP: puoi annotare una sola colonna in ogni tabella di destinazione con questo tipo di utilizzo. Utilizza questo usageType per identificare una colonna del timestamp di aggiornamento per gli aggiornamenti incrementali. Questa colonna viene utilizzata per estrarre le righe create o aggiornate dall'ultima esecuzione del trasferimento. Puoi utilizzare questo tipo di utilizzo solo con le colonne che hanno 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 oppure, nel caso di una chiave composita, utilizza lo stesso tipo di utilizzo su più colonne per identificare le entità univoche di una tabella. Queste colonne funzionano insieme a COMMIT_TIMESTAMP per estrarre le righe create o aggiornate dall'ultima esecuzione del trasferimento.

Puoi creare un file di schema personalizzato manualmente, come mostrato nell'esempio seguente, oppure puoi chiedere all'agente di migrazione di generarne uno quando inizializzi l'agente.

In questo esempio, un utente sta 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, l'utente vuole configurare lo schema con le seguenti modifiche:

  • Rinominare la colonna O_CUSTKEY in O_CUSTOMERKEY
  • Identificare O_ORDERDATE come colonna di partizionamento

L'esempio seguente è uno schema personalizzato per configurare queste impostazioni:


{
  "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 sia i trasferimenti completi (trasferimento on demand) sia i trasferimenti ricorrenti (trasferimenti incrementali). Quando configuri un trasferimento, puoi designarlo come on demand o incrementale nelle opzioni di pianificazione.

  • 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 ed eseguire regolarmente la migrazione dei dati nuovi e modificati (dati incrementali) da Teradata a BigQuery. I trasferimenti incrementali richiedono la personalizzazione dello schema 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 BigQuery. Le righe aggiornate nelle tabelle BigQuery potrebbero potenzialmente avere righe duplicate con valori vecchi e nuovi.
    • Annota le colonne con i tipi di utilizzo COMMIT_TIMESTAMP e PRIMARY_KEY: in questo trasferimento, le nuove righe vengono aggiunte e le righe modificate vengono aggiornate alla riga corrispondente in BigQuery. La colonna definita in PRIMARY_KEY viene utilizzata per mantenere l'unicità dei dati in BigQuery.
    • La colonna PRIMARY_KEY definita nello schema non deve essere la PRIMARY_KEY nella tabella Teradata. Può essere qualsiasi colonna, ma deve contenere dati univoci.

Trasferimenti incrementali

Nei trasferimenti incrementali, il primo trasferimento crea sempre uno snapshot della tabella in BigQuery. Tutti i trasferimenti incrementali successivi rispetteranno le annotazioni definite nel file di schema personalizzato descritto di seguito.

Per ogni esecuzione del trasferimento, viene salvato un timestamp dell'esecuzione del trasferimento. Per ogni esecuzione del trasferimento successiva, un agente riceve il timestamp di un'esecuzione del trasferimento precedente (T1) e il timestamp dell'inizio dell'esecuzione del trasferimento corrente (T2).

Per i trasferimenti successivi all'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 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 una colonna con il tipo di utilizzo PRIMARY_KEY, tutte le righe con un timestamp compreso tra T1 e T2 vengono estratte. Le nuove righe vengono aggiunte e le righe modificate vengono aggiornate nella tabella esistente in BigQuery.

Di seguito sono riportati esempi di file di 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 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 Supporto 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 della tabella rinominata. Lo snapshot precedente non viene eliminato da BigQuery. L'utente non riceve una notifica della tabella rinominata.
INSERT DML Le nuove righe vengono aggiunte alla tabella BigQuery.
UPDATE DML Le righe vengono aggiunte alla tabella BigQuery come nuove, in modo simile a un' INSERT operazione 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 supportata. Consulta invece INSERT, UPDATE, e DELETE.
DELETE DML Non supportata

Considerazioni sulla località

Il bucket Cloud Storage deve trovarsi in una regione o in più regioni compatibili con la regione o le regioni 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 nelle stesse regioni o in una località contenuta nelle regioni. Ad esempio, se il set di dati BigQuery si trova nelle EU regioni, il bucket Cloud Storage può trovarsi nella europe-west1 regione (Belgio), che si trova all'interno dell'UE.
  • Se il set di dati si trova in una singola regione, il bucket Cloud Storage deve trovarsi nella stessa regione. Ad esempio, se il set di dati si trova nella regione asia-northeast1 (Tokyo), il bucket Cloud Storage non può trovarsi nelle regioni ASIA.

Per informazioni dettagliate sui trasferimenti e sulle regioni, consulta Località e trasferimenti dei set di dati.

Prezzi

Il trasferimento dei dati con BigQuery è senza costi. 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 Cloud Storage e il caricamento di dati su BigQuery sono senza costi.
  • 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 standard di BigQuery per i job di caricamento.
  • Si applicheranno le quote e i limiti standard di BigQuery DML per gli upsert di inserimento incrementale.
  • Dopo il trasferimento dei dati a BigQuery, si applicano i prezzi standard di BigQuery archiviazione e calcolo.
  • Per i dettagli, consulta la pagina dei prezzi dei trasferimenti .

Limitazioni

  • I trasferimenti on demand una tantum sono completamente supportati. Le operazioni DDL/DML nei trasferimenti incrementali sono parzialmente supportate.
  • Durante il trasferimento dei dati, i dati vengono estratti in una directory del file system locale. Assicurati che ci sia spazio libero sufficiente.
    • Quando utilizzi la modalità di estrazione FastExport, puoi impostare lo spazio di archiviazione massimo da utilizzare e il limite applicato rigorosamente 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 abbia spazio libero sufficiente, 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 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. Ti consigliamo di eliminare i dati dal bucket Cloud Storage dopo averli caricati in BigQuery per evitare costi di archiviazione aggiuntivi. Vedi Prezzi.
  • La velocità di 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 del database, come stored procedure, 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