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

Neste documento, você 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.

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 de ponta a ponta, 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:

  1. Faça o download do agente de migração.
  2. Configure uma transferência no serviço de transferência de dados do BigQuery.
  3. Execute o job de transferência para copiar os dados e o esquema da tabela do data warehouse para o BigQuery.
  4. Opcional. Monitore jobs de transferência usando o console do 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:

  1. Particionar suas tabelas do Teradata.
  2. Use o Teradata Parallel Transporter (TPT) para extração.
  3. 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

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. Como alternativa, é possível especificar um arquivo de esquema personalizado. Recomendamos a personalização do esquema nas seguintes situações:

  • É necessário 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 especificado, 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 serão perdidas.

  • É necessário mudar os nomes das colunas ou os tipos de dados durante a transferência de dados.

Arquivo de esquema personalizado

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

As colunas também têm os seguintes campos:

  • Um campo originalType que indica o tipo de dados da coluna no Teradata
  • Um campo type que indica o tipo de dados de destino da coluna no BigQuery.

  • Um campo usageType para capturar informações sobre como a coluna é usada pelo sistema, como em clustering ou particionamento. Os seguintes tipos de uso são suportados:

    • CLUSTERING: é possível anotar até quatro colunas em cada tabela de destino. para 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.
    • 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 criadas/atualizadas desde a última execução da transferência. Só é possível usar esse tipo de uso com uma coluna que tenha um tipo de dados TIMESTAMP ou DATE.
    • PADRÃO: é possível anotar várias colunas em uma tabela 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.
    • PARTITIONING: use este tipo de uso para anotar apenas uma coluna em cada tabela de destino. Essa coluna é usada na definição de tabela particionada do objeto de tabelas que a contém. Só é possível usar esse tipo de uso com uma coluna que tenha um tipo de dados TIMESTAMP ou DATE.
    • PRIMARY_KEY: você pode anotar as colunas em cada tabela de destino com essa 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 com base neste exemplo. Também é possível fazer com que o agente de migração gere um arquivo quando você inicializa o agente.

Exemplo

Suponha que você esteja 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, digamos que você queira 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 esquema personalizado para definir essas configurações é o seguinte:


{
  "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-west1" da Bélgica, que está na UE.
  • Se o conjunto de dados estiver em uma 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. Já as graduais estão na versão Beta. As operações DDL/DML em transferências graduais 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.
  • 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