Migração do Teradata para o BigQuery: visão geral detalhada

Este documento fornece mais informações para ajudar você a entender as decisões que precisa tomar ao usar o serviço de transferência de dados do BigQuery para migrar o esquema e os dados do Teradata para o BigQuery. Para uma introdução ao processo de migração do Teradata, consulte Introdução à migração do Teradata para o BigQuery.

A migração de esquemas e dados normalmente é uma das várias etapas necessárias para mover um armazenamento de dados de uma plataforma diferente para o BigQuery. Para uma descrição do processo de migração geral, consulte Visão geral: migrar data warehouses para o BigQuery.

Também é possível usar tradução de SQL em lote para migrar os scripts SQL em massa ou a tradução de SQL interativo para traduzir consultas ad hoc. O Teradata SQL é totalmente compatível com os dois serviços de tradução do SQL.

Visão geral

É possível usar o serviço de transferência de dados do BigQuery com um agente de migração especial para copiar o esquema e os dados do Teradata para o BigQuery. O agente de migração se conecta ao data warehouse local que se comunica com o serviço de transferência de dados do BigQuery para copiar tabelas do armazenamento de dados para o BigQuery.

As etapas a seguir descrevem o fluxo de trabalho do processo de migração:

Faça o download do agente de migração.
Configure uma transferência no serviço de transferência de dados do BigQuery.
Execute o job de transferência para copiar os dados e o esquema da tabela do data warehouse para o BigQuery.
Opcional. Monitore os jobs de transferência usando o console Google Cloud .

Configuração do job de transferência

Configure o job de transferência de acordo com suas necessidades. Antes de configurar uma transferência de dados do Teradata para o BigQuery, considere as opções de configuração descritas nas seções a seguir e decida quais configurações usar. Dependendo das configurações escolhidas, talvez seja necessário concluir alguns pré-requisitos antes de iniciar o job de transferência.

Para a maioria dos sistemas, especialmente aqueles com tabelas grandes, é possível ter o melhor desempenho seguindo estas etapas:

Particionar suas tabelas do Teradata.
Use o Teradata Parallel Transporter (TPT) para extração.
Criar um arquivo de esquema personalizado e configurar o clustering e as colunas de particionamento do BigQuery de destino.

Isso permite que o agente de migração execute a extração por partição, o que é o mais eficiente.

Método de extração

O serviço de transferência de dados do BigQuery é compatível com dois métodos de extração para transferir para ele os dados do Teradata:

Use o Teradata Parallel Transporter (TPT) tbuild utilitário. Esse é o método recomendado. O uso do TPT normalmente resulta em uma extração de dados mais rápida.
Nesse modo, o agente de migração tenta calcular os lotes de extração usando linhas distribuídas por partições. Para cada lote, o agente emite e executa um script de extração TPT, produzindo um conjunto de arquivos delimitados por barras verticais. Em seguida, ele faz upload desses arquivos para um bucket do Cloud Storage, onde são usados pelo job de transferência. Depois que os arquivos são enviados para o Cloud Storage, o agente de migração os excluiu do sistema de arquivos local.
Quando você usa a extração TPT sem uma coluna de particionamento, toda a tabela é extraída. Quando você usa a extração TPT com uma coluna de particionamento, o agente extrai conjuntos de partições.
Nesse modo, o agente de migração não limita a quantidade de espaço que os arquivos extraídos ocupam no sistema de arquivos local. Verifique se o sistema de arquivos local tem mais espaço que o tamanho da maior partição ou da maior tabela, dependendo se você está especificando uma coluna de particionamento ou não.
Extração usando um driver JDBC com a conexão FastExport. Se houver restrições sobre o espaço de armazenamento local disponível para arquivos extraídos ou se houver algum motivo para não poder usar o TPT, use este método de extração.
Nesse modo, o agente de migração extrai tabelas em uma coleção de arquivos AVRO no sistema de arquivos local. Em seguida, ele faz upload desses arquivos para um bucket do Cloud Storage, onde são usados pelo job de transferência. Depois que os arquivos são enviados para o Cloud Storage, o agente de migração os exclui do sistema de arquivos local.
Nesse modo, é possível limitar a quantidade de espaço usado pelos arquivos AVRO no sistema de arquivos local. Se esse limite for excedido, a extração será pausada até que o espaço seja liberado pelo agente de migração que faz o upload e exclui os arquivos AVRO existentes.

Identificação do esquema

É possível definir o esquema de várias maneiras. O serviço de transferência de dados do BigQuery fornece mapeamento de tipo de dados e detecção de esquema automáticas durante uma transferência de dados do Teradata para o BigQuery. Também é possível usar o mecanismo de tradução para receber o mapeamento de tipo de dados ou especificar um arquivo de esquema personalizado.

Detecção de esquema padrão

Se você não especificar nenhuma configuração de esquema, o serviço de transferência de dados do BigQuery vai detectar automaticamente o esquema das suas tabelas de origem do Teradata e fazer o mapeamento de tipo de dados para os tipos de dados correspondentes do BigQuery durante a transferência. Para mais informações sobre o mapeamento do tipo de dados padrão, consulte Tipos de dados.

Como usar a saída do mecanismo de tradução para o esquema

O serviço de transferência de dados do BigQuery usa a saída do mecanismo de tradução do BigQuery para o mapeamento de esquema durante a migração de tabelas do Teradata para o BigQuery. Para usar essa opção, verifique se os seguintes pré-requisitos foram atendidos:

Gerar metadados para tradução. Execute a ferramenta de dumper para gerar metadados para tradução, obedecendo às diretrizes de origem do Teradata. Para mais informações, consulte Gerar metadados para tradução e avaliação.
Faça o upload do arquivo de metadados gerado (por exemplo, metadata.zip) para um bucket do Cloud Storage. Esse bucket serve como o local de entrada para o mecanismo de tradução.

Inicie um job de tradução em lote para criar o mapeamento do serviço de transferência de dados do BigQuery, que define o esquema das tabelas de destino do BigQuery. Para saber como fazer isso, consulte Criar uma tradução em lote. O exemplo a seguir gera o mapeamento do serviço de transferência de dados do BigQuery ao especificar 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

Para verificar o status do job de tradução em lote no Google Cloud console, acesse BigQuery -> Tradução SQL. Quando concluído, o arquivo de mapeamento é armazenado em um local do Cloud Storage especificado na flag target_base_uri.

Para gerar um token, use o comando gcloud auth print-access-token ou o OAuth 2.0 Playground com o escopo https://www.googleapis.com/auth/cloud-platform.

Na configuração de transferência de dados do Teradata, especifique o caminho para a pasta do Cloud Storage em que o arquivo de mapeamento da etapa anterior está armazenado. O serviço de transferência de dados do BigQuery usa esse mapeamento para definir o esquema das tabelas do BigQuery de destino.

Arquivo de esquema personalizado

Recomendamos especificar o esquema personalizado nas seguintes situações:

Se você precisar capturar informações importantes sobre uma tabela, como o particionamento, que seriam perdidas na migração.
Por exemplo, as transferências incrementais precisam ter um arquivo de esquema especificado para que os dados das transferências subsequentes possam ser particionados adequadamente quando carregados no BigQuery. Sem um arquivo de esquema, sempre que uma transferência é executada, o serviço de transferência de dados do BigQuery aplica automaticamente um esquema de tabela usando os dados de origem transferidos, e todas as informações sobre particionamento, clustering, chaves primárias e controle de alterações são perdidas.
Se você precisar mudar os nomes das colunas ou os tipos de dados durante a transferência de dados.

O arquivo de esquema personalizado é JSON e descreve os objetos do banco de dados. O esquema contém um conjunto de bancos de dados, cada um com um conjunto de tabelas, cada uma com um conjunto de colunas. Cada objeto tem um campo originalName que indica o nome do objeto no Teradata e um campo name que indica o nome de destino do objeto no BigQuery.

As colunas têm os seguintes campos:

originalType: indica o tipo de dados da coluna no Teradata
type: indica o tipo de dados de destino da coluna no BigQuery.
usageType: informações sobre como a coluna é usada pelo sistema. Os seguintes tipos de uso são suportados:
- DEFAULT: é possível anotar várias colunas em uma tabela de destino com esse tipo de uso. Esse usageType indica que a coluna não tem uso especial no sistema de origem. Esse é o valor padrão.
- CLUSTERING: é possível anotar até quatro colunas em cada tabela de destino com esse tipo de uso. A ordem das colunas para clustering é determinada com base na ordem em que aparecem no esquema personalizado. As colunas selecionadas precisam atender às restrições para clustering no BigQuery. Se um campo PARTITIONING for especificado para a mesma tabela, o BigQuery usará essas colunas para criar uma tabela em cluster.
- PARTITIONING: só é possível anotar uma coluna em cada tabela de destino com esse tipo de uso. Essa coluna é usada na definição de tabela particionada do objeto tables que a contém. Só é possível usar esse tipo de uso com uma coluna que tenha um tipo de dados TIMESTAMP ou DATE.
- COMMIT_TIMESTAMP: só é possível anotar uma coluna em cada tabela de destino com esse tipo de uso. Use esse usageType para identificar uma coluna de carimbo de data/hora de atualização para atualizações incrementais. Essa coluna é usada para extrair linhas que foram criadas ou atualizadas desde a última execução da transferência. Só é possível usar esse tipo de uso com colunas que têm um tipo de dados TIMESTAMP ou DATE.
- PRIMARY_KEY: é possível anotar colunas em cada tabela de destino com esse tipo de uso. Use esse tipo de uso para identificar apenas uma coluna como a chave primária ou, no caso de uma chave composta, use o mesmo tipo de uso em várias colunas para identificar as entidades únicas de uma tabela. Essas colunas trabalham com COMMIT_TIMESTAMP para extrair linhas criadas ou atualizadas desde a última execução da transferência.

É possível criar um arquivo de esquema personalizado manualmente, conforme mostrado no exemplo a seguir, ou fazer com que o agente de migração gere um arquivo quando você inicializar o agente.

Neste exemplo, um usuário está migrando uma tabela do Teradata chamada orders no banco de dados tpch com a seguinte definição de tabela:

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

Ao migrar para o BigQuery, o usuário quer configurar o esquema com as seguintes alterações:

Renomeie a coluna O_CUSTKEY como O_CUSTOMERKEY.
Identifique O_ORDERDATE como a coluna de particionamento

O exemplo a seguir é um esquema personalizado para definir essas configurações:


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

Transferências sob demanda ou graduais

Ao migrar dados de uma instância de banco de dados do Teradata para O BigQuery, o serviço de transferência de dados do BigQuery, dá suporte a transferências completas (transferência sob demanda) e recorrentes (incrementais). Você determina se a transferência é sob demanda ou incremental nas opções de programação ao configurar uma transferência.

Transferência sob demanda: use esse modo para realizar a migração com captura de tela complete do esquema e dos dados do Teradata para o BigQuery.
Transferência programada: use este modo para executar o snapshot completo e regularmente migrar dados novos e modificados (dados incrementais) do Teradata para o no BigQuery. As transferências incrementais exigem a personalização do esquema para anotar colunas com um dos casos de uso abaixo:
- Anotar colunas apenas com o tipo de uso COMMIT_TIMESTAMP: nesta transferência, linhas novas ou modificadas no Teradata são anexadas aos dados no no BigQuery. As linhas atualizadas nas tabelas do BigQuery podem podem ter linhas duplicadas com valores antigos e novos.
- Anote colunas com o tipo de uso COMMIT_TIMESTAMP e PRIMARY_KEY: Nessa transferência, novas linhas são anexadas e as linhas modificadas são atualizadas ao linha correspondente no BigQuery. A coluna definida em PRIMARY_KEY é usado para manter a exclusividade dos dados em no BigQuery.
- A coluna PRIMARY_KEY definida no esquema não precisa ser o PRIMARY_KEY na tabela do Teradata. Pode ser qualquer coluna, mas precisa conter dados exclusivos.

Transferências incrementais

Nas transferências incrementais, a primeira transferência sempre cria um snapshot da tabela no BigQuery. Todas as transferências incrementais subsequentes seguirá as anotações definidas no arquivo de esquema personalizado explicado a seguir.

Para cada execução de transferência, um carimbo de data/hora da execução da transferência é salvo. Para cada execução de transferência subsequente, um agente recebe o carimbo de data/hora de uma execução de transferência anterior (T1) e um carimbo de data/hora de quando a execução de transferência atual foi iniciada (T2).

Para transferências após a execução inicial, o agente de migração extrai dados usando a seguinte lógica por tabela:

Se um objeto de tabela em um arquivo de esquema não tiver uma coluna com um tipo de uso COMMIT_TIMESTAMP, a tabela será ignorada.
Se uma tabela tiver uma coluna com o tipo de uso COMMIT_TIMESTAMP, todas as linhas com um carimbo de data/hora entre T1 e T2 serão extraídas e anexadas à tabela existente no BigQuery.
Se uma tabela tiver uma coluna com o tipo de uso COMMIT_TIMESTAMP e uma coluna com o tipo de uso PRIMARY_KEY, todas as linhas com um carimbo de data/hora entre T1 e T2 serão extraídas. Todas as novas linhas serão anexadas e modificadas. são atualizadas na tabela atual no BigQuery.

Confira abaixo exemplos de arquivos de esquema para transferências incrementais.

Esquema com apenas 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
            }
          ]
        }
      ]
    }
  ]
}

Esquema com COMMIT_TIMESTAMP e uma coluna (ID) como 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
            }
          ]
        }
      ]
    }
  ]
}

Esquema com COMMIT_TIMESTAMP e chave composta (ID + nome) como 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
            }
          ]
        }
      ]
    }
  ]
}

A tabela a seguir descreve como o agente de migração processa as operações de linguagem de definição de dados (DDL) e de manipulação de dados (DML) em transferências incrementais.

Operação do Teradata	Tipo	Suporte do Teradata ao BigQuery
`CREATE`	DDL	Um novo snapshot completo da tabela é criado no BigQuery.
`DROP`	DDL	Sem suporte
`ALTER` (`RENAME`)	DDL	Um novo snapshot completo para a tabela renomeada é criado no BigQuery. O snapshot anterior não é excluído do BigQuery. O usuário não é notificado sobre a tabela renomeada.
`INSERT`	DML	Novas linhas são adicionadas à tabela do BigQuery.
`UPDATE`	DML	As linhas são anexadas à tabela do BigQuery como novas, semelhante a um `INSERT` se apenas `COMMIT_TIMESTAMP` for usado. As linhas são atualizadas, semelhante a uma operação `UPDATE` se ambas `COMMIT_TIMESTAMP` e `PRIMARY_KEY` são usados.
`MERGE`	DML	Incompatível. Consulte `INSERT`, `UPDATE` e `DELETE`.
`DELETE`	DML	Sem suporte

Considerações sobre o local

O bucket do Cloud Storage precisa estar em uma região ou multirregião compatível com a região ou multirregião do conjunto de dados de destino no BigQuery.

Se o conjunto de dados do BigQuery estiver em uma multirregião, o bucket do Cloud Storage que contém os dados a serem transferidos precisará estar na mesma multirregião ou em um local dentro da multirregião. Por exemplo, se o conjunto de dados do BigQuery estiver na multirregião EU, o bucket do Cloud Storage poderá estar localizado na região Bélgica europe-west1, que está na UE.
Se o conjunto de dados estiver em uma única região, o bucket do Cloud Storage precisará estar na mesma região. Por exemplo, se o conjunto de dados estiver na região asia-northeast1 de Tóquio, o bucket do Cloud Storage não poderá estar na multirregião ASIA.

Para informações detalhadas sobre transferências e regiões, consulte Locais e transferências de conjuntos de dados.

Preços

A transferência de dados com o BigQuery é gratuita. No entanto, é possível gerar custos fora do Google com esse serviço, como taxas de transferência de dados de saída da plataforma.

A extração e o upload em um bucket do Cloud Storage e o carregamento de dados no BigQuery são gratuitos.
Os dados não são excluídos automaticamente do bucket do Cloud Storage depois que você faz upload deles no BigQuery. Exclua os dados do bucket se quiser evitar custos extras. Consulte Preços do Cloud Storage.
São aplicadas as Cotas e limites padrão do BigQuery nos jobs de carregamento.
As cotas e limites padrão do BigQuery para DML em inserções incrementais de ingestão serão aplicadas.
Depois que os dados forem transferidos para o BigQuery, serão aplicados os preços padrão de armazenamento e computação do BigQuery.
Consulte a página "Preços" para mais detalhes.

Limitações

As transferências sob demanda realizadas uma única vez têm suporte total. As operações DDL/DML em transferências incrementais têm suporte parcial.
Durante a transferência de dados, os dados são extraídos para um diretório no sistema de arquivos local. Verifique se há espaço livre suficiente.
- Ao usar o modo de extração FastExport, é possível definir o espaço máximo de armazenamento a ser utilizado e o limite aplicado pelo agente de migração. Defina max-local-storage no arquivo de configuração do agente de migração ao configurar uma transferência do Teradata para o BigQuery.
- Ao usar o método de extração TPT, verifique se o sistema de arquivos tem espaço livre suficiente. Ele é maior do que a maior partição de tabela da instância do Teradata.
O serviço de transferência de dados do BigQuery converte o esquema automaticamente (quando você não fornece um arquivo de esquema personalizado) e transfere os dados do Teradata para o BigQuery. Os dados são mapeados do Teradata para os tipos do BigQuery.
Os arquivos não são excluídos automaticamente do bucket do Cloud Storage depois de serem carregados no BigQuery. Para evitar mais custos de armazenamento, exclua os dados do bucket do Cloud Storage após carregá-los no BigQuery. Consulte a seção "Preços".
A velocidade da extração é limitada pela sua conexão JDBC.
Os dados extraídos do Teradata não são criptografados. Siga as etapas apropriadas para restringir o acesso aos arquivos extraídos no sistema local e verifique se o bucket do Cloud Storage está protegido corretamente.
Outros recursos do banco de dados, como procedimentos armazenados, consultas salvas, visualizações e funções definidas pelo usuário, não são transferidos e não estão no escopo desse serviço.
As transferências incrementais não aceitam exclusões irreversíveis. Transferências incrementais não sincroniza as linhas excluídas do Teradata com o BigQuery.

A seguir

Receba instruções passo a passo para migrar o Teradata para o BigQuery.
Faça uma migração de teste do Teradata para o BigQuery.