Migração do Teradata para o BigQuery: vista geral

Este documento fornece mais informações para ajudar a compreender as decisões que tem de tomar quando usa 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 o artigo Introdução a uma migração do Teradata para o BigQuery.

A migração do esquema e dos dados é normalmente um dos vários passos necessários para mover um armazém de dados de uma plataforma diferente para o BigQuery. Para uma descrição de um processo de migração geral, consulte o artigo Vista geral: migre armazéns de dados para o BigQuery.

Também pode usar a tradução de SQL em lote para migrar os seus scripts SQL em massa ou a tradução de SQL interativa para traduzir consultas ad hoc. O SQL do Teradata é totalmente suportado pelos serviços de tradução de SQL.

Vista geral

Pode usar o Serviço de transferência de dados do BigQuery em combinação com um agente de migração especial para copiar o seu esquema e dados do Teradata para o BigQuery. O agente de migração liga-se ao seu armazém de dados local, comunica com o Serviço de transferência de dados do BigQuery para copiar tabelas do seu armazém de dados para o BigQuery.

Os passos seguintes descrevem o fluxo de trabalho do processo de migração:

  1. Transfira o agente de migração.
  2. Configurar uma transferência no Serviço de transferência de dados do BigQuery.
  3. Execute a tarefa de transferência para copiar o esquema e os dados da tabela do seu armazém de dados para o BigQuery.
  4. Opcional. Monitorize tarefas de transferência através da Google Cloud consola.

Configuração da tarefa de transferência

Pode configurar uma tarefa de transferência para se adequar melhor às suas necessidades. Antes de configurar uma transferência de dados do Teradata para o BigQuery, considere as opções de configuração descritas nas secções seguintes e decida que definições usar. Consoante as definições que escolher, pode ter de concluir alguns pré-requisitos antes de iniciar a tarefa de transferência.

Para a maioria dos sistemas, especialmente os que têm tabelas grandes, pode obter o melhor desempenho seguindo estes passos:

  1. Particione as suas tabelas do Teradata.
  2. Use o Teradata Parallel Transporter (TPT) para a extração.
  3. Crie um ficheiro de esquema personalizado e configure as colunas de clustering e partição do BigQuery de destino.

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

Método de extração

O Serviço de transferência de dados do BigQuery suporta dois métodos de extração para transferir dados do Teradata para o BigQuery:

  • Use o utilitário Teradata Parallel Transporter (TPT) tbuild. Esta é a abordagem recomendada. A utilização do TPT resulta normalmente numa extração de dados mais rápida.

    Neste 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 de TPT, produzindo um conjunto de ficheiros delimitados por barras verticais. Em seguida, carrega estes ficheiros para um contentor do Cloud Storage, onde são usados pela tarefa de transferência. Depois de os ficheiros serem carregados para o armazenamento na nuvem, o agente de migração eliminou-os do sistema de ficheiros local.

    Quando usa a extração de TPT sem uma coluna de partição, é extraída toda a tabela. Quando usa a extração de TPT com uma coluna de partição, o agente extrai conjuntos de partições.

    Neste modo, o agente de migração não limita a quantidade de espaço que os ficheiros extraídos ocupam no sistema de ficheiros local. Certifique-se de que o sistema de ficheiros local tem mais espaço do que o tamanho da partição ou da tabela maior, consoante especifique ou não uma coluna de partição.

    Use o módulo de acesso para o Cloud Storage. Esta abordagem elimina a necessidade de armazenamento intermédio no sistema de ficheiros local, o que oferece um melhor desempenho e uma menor utilização de recursos da VM que executa o agente. Esta abordagem exporta diretamente os dados para o Cloud Storage através do módulo de acesso do Teradata para o Cloud Storage. Para usar esta funcionalidade, as ferramentas do Teradata executadas na sua VM têm de ser mais recentes do que a versão 17.20. As ferramentas do Teradata podem ser atualizadas de forma independente sem alterações à versão da instância do Teradata.

  • Extração através de um controlador JDBC com ligação FastExport. Se existirem restrições no espaço de armazenamento local disponível para ficheiros extraídos ou se houver algum motivo pelo qual não possa usar o TPT, use este método de extração.

    Neste modo, o agente de migração extrai tabelas para uma coleção de ficheiros AVRO no sistema de ficheiros local. Em seguida, carrega estes ficheiros para um contentor do Cloud Storage, onde são usados pela tarefa de transferência. Depois de os ficheiros serem carregados para o armazenamento na nuvem, o agente de migração elimina-os do sistema de ficheiros local.

    Neste modo, pode limitar a quantidade de espaço usado pelos ficheiros AVRO no sistema de ficheiros local. Se este limite for excedido, a extração é pausada até que o agente de migração liberte espaço carregando e eliminando os ficheiros AVRO existentes.

Identificação de esquemas

Pode definir o esquema de várias formas. O Serviço de transferência de dados do BigQuery oferece deteção automática de esquemas e mapeamento de tipos de dados durante uma transferência de dados do Teradata para o BigQuery. Também pode usar o motor de tradução para obter o mapeamento do tipo de dados ou optar por especificar um ficheiro de esquema personalizado.

Deteção de esquemas predefinida

Se não especificar nenhuma configuração de esquema, o Serviço de transferência de dados do BigQuery deteta automaticamente o esquema das tabelas de origem do Teradata e faz o mapeamento do tipo de dados para os tipos de dados do BigQuery correspondentes durante a transferência de dados. Para mais informações sobre o mapeamento de tipos de dados predefinido, consulte o artigo Tipos de dados.

Usar a saída do motor de tradução para o esquema

O Serviço de transferência de dados do BigQuery usa o resultado do motor de tradução do BigQuery para o mapeamento de esquemas durante a migração de tabelas do Teradata para o BigQuery. Para usar esta opção, certifique-se de que são cumpridos os seguintes pré-requisitos:

  1. Gere metadados para tradução. Execute a ferramenta de descarga para gerar metadados para tradução, seguindo as diretrizes da origem do Teradata. Para mais informações, consulte o artigo Gere metadados para tradução e avaliação.
  2. Carregue o ficheiro de metadados gerado (por exemplo, metadata.zip) para um contentor do Cloud Storage. Este contentor serve como a localização de entrada para o motor de tradução.

  3. Inicie uma tarefa 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 do BigQuery de destino. Para obter informações sobre como o fazer, consulte o artigo Crie uma tradução em lote. O exemplo seguinte gera o mapeamento do Serviço de transferência de dados do BigQuery especificando 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

    Pode verificar o estado da tarefa de tradução em lote na Google Cloud consola navegando para BigQuery -> Tradução de SQL. Uma vez concluída, o ficheiro de mapeamento é armazenado numa localização do Cloud Storage especificada na flag target_base_uri.

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

  4. Na configuração de transferência de dados do Teradata, especifique o caminho para a pasta do Cloud Storage onde o ficheiro de mapeamento do passo anterior está armazenado. O Serviço de transferência de dados do BigQuery usa este mapeamento para definir o esquema das tabelas do BigQuery de destino.

Ficheiro de esquema personalizado

Recomendamos que especifique um esquema personalizado nas seguintes situações:

  • Se precisar de capturar informações importantes sobre uma tabela, como a partição, que, de outra forma, seriam perdidas na migração.

    Por exemplo, as transferências incrementais devem ter um ficheiro de esquema especificado para que os dados de transferências subsequentes possam ser particionados corretamente quando carregados no BigQuery. Sem um ficheiro de esquema, sempre que uma transferência é executada, o Serviço de transferência de dados do BigQuery aplica automaticamente um esquema de tabela através dos dados de origem que estão a ser transferidos, e todas as informações sobre a partição, o agrupamento, as chaves primárias e o controlo de alterações são perdidas.

  • Se precisar de alterar os nomes das colunas ou os tipos de dados durante a transferência de dados.

Um ficheiro de esquema personalizado é um ficheiro JSON que descreve objetos de base de dados. O esquema contém um conjunto de bases de dados, cada uma com um conjunto de tabelas, cada uma das quais contém 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 a forma como a coluna é usada pelo sistema. São suportados os seguintes tipos de utilização:

    • DEFAULT: pode anotar várias colunas numa tabela de destino com este tipo de utilização. Este usageType indica que a coluna não tem uma utilização especial no sistema de origem. Este é o valor predefinido.
    • CLUSTERING: pode anotar até quatro colunas em cada tabela de destino com este tipo de utilização. A ordem das colunas para a agrupamento é determinada com base na ordem em que aparecem no esquema personalizado. As colunas que selecionar têm de cumprir as restrições para a agrupamento no BigQuery. Se um campo PARTITIONING for especificado para a mesma tabela, o BigQuery usa estas colunas para criar uma tabela agrupada.
    • PARTITIONING: só pode anotar uma coluna em cada tabela de destino com este tipo de utilização. Esta coluna é usada na definição da tabela partitioned para o objeto tables que a contém. Só pode usar este tipo de utilização com uma coluna que tenha um tipo de dados TIMESTAMP ou DATE.
    • COMMIT_TIMESTAMP: só pode anotar uma coluna em cada tabela de destino com este tipo de utilização. Use este usageType para identificar uma coluna de data/hora de atualização para atualizações incrementais. Esta coluna é usada para extrair linhas que foram criadas ou atualizadas desde a última execução da transferência. Só pode usar este tipo de utilização com colunas que tenham um tipo de dados TIMESTAMP ou DATE.
    • PRIMARY_KEY: pode anotar colunas em cada tabela de destino com este tipo de utilização. Use este tipo de utilização para identificar apenas uma coluna como a chave principal ou, no caso de uma chave composta, use o mesmo tipo de utilização em várias colunas para identificar as entidades únicas de uma tabela. Estas colunas funcionam em conjunto com COMMIT_TIMESTAMP para extrair linhas criadas ou atualizadas desde a última execução da transferência.

Pode criar um ficheiro de esquema personalizado manualmente, como no exemplo seguinte, ou pode pedir ao agente de migração que gere um para si quando inicializar o agente.

Neste exemplo, um utilizador está a migrar uma tabela do Teradata denominada orders na base 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 );

Durante a migração para o BigQuery, o utilizador quer configurar o esquema com as seguintes alterações:

  • Mude o nome da coluna O_CUSTKEY para O_CUSTOMERKEY
  • Identifique O_ORDERDATE como a coluna de partição

O exemplo seguinte é um esquema personalizado para configurar estas definiçõ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 a pedido ou incrementais

Ao migrar dados de uma instância da base de dados Teradata para o BigQuery, o Serviço de transferência de dados do BigQuery suporta transferências completas (transferência a pedido) e transferências recorrentes (transferências incrementais). Pode designar a transferência como a pedido ou incremental nas opções de agendamento quando configura uma transferência.

  • Transferência a pedido: use este modo para fazer a migração completa da captura instantânea do esquema e dos dados do Teradata para o BigQuery.

  • Transferência agendada: use este modo para fazer a captura instantânea completa e migrar regularmente dados novos e modificados (dados incrementais) do Teradata para o BigQuery. As transferências incrementais requerem a personalização do seu esquema para anotar colunas com qualquer um dos exemplos de utilização abaixo:

    • Anotar colunas com apenas o tipo de utilização COMMIT_TIMESTAMP: nesta transferência, as linhas novas ou modificadas no Teradata são anexadas aos dados no BigQuery. As linhas atualizadas nas tabelas do BigQuery podem ter linhas duplicadas com valores antigos e novos.
    • Anote as colunas com o tipo de utilização COMMIT_TIMESTAMP e PRIMARY_KEY: Nesta transferência, as novas linhas são anexadas e as linhas modificadas são atualizadas para a linha correspondente no BigQuery. A coluna definida em PRIMARY_KEY é usada para manter a singularidade dos dados no BigQuery.
    • A coluna PRIMARY_KEY definida no esquema não tem de ser a PRIMARY_KEY na tabela Teradata. Pode ser qualquer coluna, mas tem de conter dados únicos.

Transferências incrementais

Nas transferências incrementais, a primeira transferência cria sempre uma imagem instantânea da tabela no BigQuery. Todas as transferências incrementais subsequentes vão respeitar as anotações definidas no ficheiro de esquema personalizado explicado abaixo.

Para cada execução de transferência, é guardada uma indicação de tempo da execução de transferência. Para cada execução de transferência subsequente, um agente recebe a data/hora de uma execução de transferência anterior (T1) e a data/hora em que 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 num ficheiro de esquema não tiver uma coluna com um tipo de utilização de COMMIT_TIMESTAMP, a tabela é ignorada.
  • Se uma tabela tiver uma coluna com o tipo de utilização COMMIT_TIMESTAMP, todas as linhas com uma data/hora entre T1 e T2 são extraídas e anexadas à tabela existente no BigQuery.
  • Se uma tabela tiver uma coluna com o tipo de utilização COMMIT_TIMESTAMP e uma coluna com o tipo de utilização PRIMARY_KEY, todas as linhas com uma data/hora entre T1 e T2 são extraídas. As novas linhas são anexadas e as linhas modificadas são atualizadas na tabela existente no BigQuery.

Seguem-se exemplos de ficheiros 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 seguinte descreve como o agente de migração processa as operações de linguagem de definição de dados (LDD) e linguagem de manipulação de dados (LMD) em transferências incrementais.

Operação do Teradata Tipo Suporte de Teradata para BigQuery
CREATE LDD É criada uma nova imagem instantânea completa da tabela no BigQuery.
DROP LDD Não suportado
ALTER (RENAME) LDD É criada uma nova imagem instantânea completa da tabela com o nome alterado no BigQuery. A captura de ecrã anterior não é eliminada do BigQuery. O utilizador não é notificado da tabela com o nome alterado.
INSERT DML As novas linhas são adicionadas à tabela do BigQuery.
UPDATE DML As linhas são anexadas à tabela do BigQuery como novas, de forma semelhante a uma operação INSERT se apenas for usado COMMIT_TIMESTAMP. As linhas são atualizadas, de forma semelhante a uma operação UPDATE, se forem usados COMMIT_TIMESTAMP e PRIMARY_KEY.
MERGE DML Não suportado. Em alternativa, consulte INSERT, UPDATE e DELETE.
DELETE DML Não suportado

Considerações sobre a localização

O contentor do Cloud Storage tem de estar numa região ou numa região múltipla que seja compatível com a região ou a região múltipla do conjunto de dados de destino no BigQuery.

  • Se o seu conjunto de dados do BigQuery estiver numa multirregião, o contentor do Cloud Storage que contém os dados que está a transferir tem de estar na mesma multirregião ou numa localização contida na multirregião. Por exemplo, se o seu conjunto de dados do BigQuery estiver na região múltipla, o contentor do Cloud Storage pode estar localizado na região da Bélgica, que se encontra na UE.EUeurope-west1
  • Se o seu conjunto de dados estiver numa única região, o contentor do Cloud Storage tem de estar na mesma região. Por exemplo, se o seu conjunto de dados estiver na região de asia-northeast1 Tóquio, o seu contentor do Cloud Storage não pode estar na ASIA multirregião.

Para ver informações detalhadas sobre transferências e regiões, consulte o artigo Localizações e transferências de conjuntos de dados.

Preços

A transferência de dados com o BigQuery é gratuita. No entanto, podem ser incorridos custos fora da Google ao usar este serviço, como custos de transferência de dados de saída da plataforma.

  • A extração, o carregamento para um contentor do Cloud Storage e o carregamento de dados para o BigQuery são gratuitos.
  • Os dados não são eliminados automaticamente do seu contentor do Cloud Storage depois de serem carregados para o BigQuery. Considere eliminar os dados do seu contentor do Cloud Storage para evitar custos de armazenamento adicionais. Consulte os preços do Cloud Storage.
  • Aplicam-se as quotas e os limites padrão do BigQuery nas tarefas de carregamento.
  • Aplicam-se as cotas e os limites do BigQuery DML padrão em inserções/atualizações incrementais.
  • Após a transferência dos dados para o BigQuery, aplicam-se os preços padrão de armazenamento e computação do BigQuery.
  • Consulte a nossa página de preços de transferências para ver detalhes.

Limitações

  • As transferências únicas a pedido são totalmente suportadas. As operações DDL/DML em transferências incrementais são parcialmente suportadas.
  • Durante a transferência de dados, os dados são extraídos para um diretório no sistema de ficheiros local. Certifique-se de que existe espaço livre adequado.
  • O Serviço de transferência de dados do BigQuery converte automaticamente o esquema (se não fornecer um ficheiro de esquema personalizado) e transfere os dados do Teradata para o BigQuery. Os dados são mapeados dos tipos do Teradata para os tipos do BigQuery.
  • Os ficheiros não são eliminados automaticamente do contentor do Cloud Storage depois de serem carregados para o BigQuery. Considere eliminar os dados do seu contentor do Cloud Storage depois de os carregar para o BigQuery, para evitar custos de armazenamento adicionais. Consulte os preços.
  • A velocidade da extração é limitada pela sua ligação JDBC.
  • Os dados extraídos do Teradata não estão encriptados. Tome as medidas adequadas para restringir o acesso aos ficheiros extraídos no sistema de ficheiros local e certifique-se de que o contentor do Cloud Storage está devidamente protegido.
  • Outros recursos da base de dados, como procedimentos armazenados, consultas guardadas, vistas e funções definidas pelo utilizador, não são transferidos e não estão no âmbito deste serviço.
  • As transferências incrementais não suportam eliminações definitivas. As transferências incrementais não sincronizam linhas eliminadas no Teradata com o BigQuery.

O que se segue?