Migrar o esquema e os dados do Teradata

Com a combinação do serviço de transferência de dados do BigQuery e de um agente de migração especial, é possível copiar seus dados de uma instância de data warehouse local do Teradata para o BigQuery. Este documento descreve o processo passo a passo de migração de dados do Teradata usando o serviço de transferência de dados do BigQuery.

Antes de começar

1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

   Go to project selector

2. Verify that billing is enabled for your Cloud de Confiance project.

3. Enable the BigQuery, BigQuery Data Transfer Service, Cloud Storage, and Pub/Sub APIs.

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the APIs

4. Create a service account:

   1. Ensure that you have the Create Service Accounts IAM role (roles/iam.serviceAccountCreator) and the Project IAM Admin role (roles/resourcemanager.projectIamAdmin). Learn how to grant roles.

   2. In the Cloud de Confiance console, go to the Create service account page.

      Go to Create service account
   3. Select your project.

   4. In the Service account name field, enter a name. The Cloud de Confiance console fills in the Service account ID field based on this name.

      In the Service account description field, enter a description. For example, Service account for quickstart.

   5. Click Create and continue.

   6. Grant the following roles to the service account: roles/bigquery.user, roles/storage.objectAdmin, roles/iam.serviceAccountTokenCreator.

      To grant a role, find the Select a role list, then select the role.

      To grant additional roles, click add Add another role and add each additional role.

   7. Click Continue.

   8. Click Done to finish creating the service account.

      Do not close your browser window. You will use it in the next step.

5. Create a service account key:

   1. In the Cloud de Confiance console, click the email address for the service account that you created.
   2. Click Keys.
   3. Click Add key, and then click Create new key.
   4. Click Create. A JSON key file is downloaded to your computer.
   5. Click Close.

Definir as permissões necessárias

Verifique se o principal que cria a transferência tem os papéis a seguir no projeto que contém o job de transferência:

• Visualizador de registros (roles/logging.viewer)
• Administrador de armazenamento (roles/storage.admin) ou um papel personalizado que concede as seguintes permissões:
  • storage.objects.create
  • storage.objects.get
  • storage.objects.list
• Administrador do BigQuery (roles/bigquery.admin) ou um papel personalizado que concede as seguintes permissões:
  • bigquery.datasets.create
  • bigquery.jobs.create
  • bigquery.jobs.get
  • bigquery.jobs.listAll
  • bigquery.tables.get
  • bigquery.transfers.get
  • bigquery.transfers.update

Criar um conjunto de dados

Crie um conjunto de dados do BigQuery para armazenar os dados. Não é necessário criar tabelas.

Criar um bucket do Cloud Storage

Crie um bucket do Cloud Storage para preparar os dados durante o job de transferência.

Preparar o ambiente local

Conclua as tarefas nesta seção para preparar seu ambiente local para o job de transferência.

Requisitos de máquina local

• O agente de migração usa uma conexão JDBC com a instância do Teradata e as APIs do Cloud de Confiance by S3NS . Verifique se o acesso à rede não está bloqueado por um firewall.
• Certifique-se de que o Java Runtime Environment 8 ou posterior esteja instalado.
• Verifique se você tem espaço de armazenamento suficiente para o método de extração escolhido, conforme descrito em Método de extração.
• Se você decidiu usar a extração do Parallel Transporter (TPT) do Teradata, verifique se o utilitário tbuild está instalado. Para mais informações sobre como escolher um método de extração, consulte Método de extração.

Detalhes da conexão do Teradata

• Verifique se você tem o nome de usuário e a senha de um usuário do Teradata com acesso de leitura às tabelas do sistema e às tabelas que estão sendo migradas.

• Confira o nome do host e o número da porta para se conectar à instância do Teradata.

Fazer o download do driver JDBC

Faça o download do arquivo de driver JDBC terajdbc4.jar do Teradata para uma máquina que possa se conectar ao data warehouse.

Defina a variável GOOGLE_APPLICATION_CREDENTIALS

Defina a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para a chave da conta de serviço que você fez o download na seção Antes de começar.

Atualizar a regra de saída do VPC Service Controls

Adicione o projeto gerenciado do serviço de transferência de dados do BigQuery Cloud de Confiance by S3NS correspondente à sua região à regra de saída no perímetro do VPC Service Controls.

A tabela a seguir é uma lista de números de projetos para os locais regionais usados em transferências de dados. Adicione os números de projetos que correspondem ao local do seu conjunto de dados.

Locais multirregionais

Locais regionais

O canal de comunicação entre o agente em execução no local e o serviço de transferência de dados do BigQuery é publicando mensagens do Pub/Sub em um tópico por transferência. O serviço de transferência de dados do BigQuery precisa enviar comandos ao agente para extrair dados, e o agente precisa publicar mensagens no serviço de transferência de dados do BigQuery para atualizar o status e retornar respostas de extração de dados.

Criar um arquivo de esquema personalizado

Para usar um arquivo de esquema personalizado em vez de detecção automática de esquema, crie um manualmente ou faça com que o agente de migração crie um quando você inicializar o agente.

Se você criar um arquivo de esquema manualmente e pretende usar o console Cloud de Confiance para criar uma transferência, faça upload do arquivo de esquema para um bucket do Cloud Storage no mesmo projeto que você planeja usar para a transferência.

Fazer o download do agente de migração

Faça o download do agente de migração em uma máquina que possa se conectar ao armazenamento em data warehouse. Mova o arquivo JAR do agente de migração para o mesmo diretório que o arquivo JAR do driver JDBC do Teradata.

Configurar o arquivo de credenciais para o módulo de acesso

Um arquivo de credenciais é necessário se você estiver usando o módulo de acesso do Cloud Storage com o utilitário Teradata Parallel Transporter (TPT) para extração.

Antes de criar um arquivo de credencial, crie uma chave de conta de serviço. No arquivo de chave da conta de serviço baixado, obtenha as seguintes informações:

• client_email
• private_key : copie todos os caracteres em -----BEGIN PRIVATE KEY----- e -----END PRIVATE KEY-----, incluindo todos os caracteres /n e sem as aspas duplas.

Depois de ter as informações necessárias, crie um arquivo de credencial. Confira abaixo um exemplo de arquivo de credenciais com um local padrão de $HOME/.gcs/credentials:

[default]
gcs_access_key_id = ACCESS_ID
gcs_secret_access_key = ACCESS_KEY

Substitua:

• ACCESS_ID: o ID da chave de acesso ou o valor client_email no arquivo de chave da conta de serviço.
• ACCESS_KEY: a chave de acesso secreta ou o valor private_key no arquivo de chave da conta de serviço.

Configurar uma transferência

Crie uma transferência com o serviço de transferência de dados do BigQuery.

Se você quiser que um arquivo de esquema personalizado seja criado automaticamente, use o agente de migração para configurar a transferência.

Não é possível criar uma transferência sob demanda usando a ferramenta de linha de comando bq. Em vez disso, use o console Cloud de Confiance ou o serviço de transferência de dados do BigQuery.

Se você estiver criando uma transferência recorrente, recomendamos especificar um arquivo de esquema para que os dados das transferências subsequentes sejam particionados corretamente quando forem carregados no BigQuery. Sem um arquivo de esquema, o serviço de transferência de dados do BigQuery infere o esquema da tabela a partir dos dados de origem que estão sendo transferidos. Todas as informações sobre particionamento, clustering, chaves primárias e rastreamento de alterações são perdidas. Além disso, as transferências subsequentes pulam as tabelas migradas anteriormente após a transferência inicial. Para mais informações sobre como criar um arquivo de esquema, consulte Arquivo de esquema personalizado.

bq mk \
--transfer_config \
--project_id=project ID \
--target_dataset=dataset \
--display_name=name \
--service_account_name=service_account \
--params='parameters' \
--data_source=data source

bq mk \
--transfer_config \
--project_id=123456789876 \
--target_dataset=MyDataset \
--display_name='My Migration' \
--params='{"bucket": "mybucket", "database_type": "Teradata",
"database_name":"mydatabase", "table_name_patterns": ".*",
"agent_service_account":"myemail@mydomain.com", "schema_file_path":
"gs://mybucket/myschemafile.json", "is_direct_gcs_unload_enabled": true}' \
--data_source=on_premises

import com.google.api.gax.rpc.ApiException;
import com.google.cloud.bigquery.datatransfer.v1.CreateTransferConfigRequest;
import com.google.cloud.bigquery.datatransfer.v1.DataTransferServiceClient;
import com.google.cloud.bigquery.datatransfer.v1.ProjectName;
import com.google.cloud.bigquery.datatransfer.v1.TransferConfig;
import com.google.protobuf.Struct;
import com.google.protobuf.Value;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

// Sample to create a teradata transfer config.
public class CreateTeradataTransfer {

  public static void main(String[] args) throws IOException {
    // TODO(developer): Replace these variables before running the sample.
    final String projectId = "MY_PROJECT_ID";
    String datasetId = "MY_DATASET_ID";
    String databaseType = "Teradata";
    String bucket = "cloud-sample-data";
    String databaseName = "MY_DATABASE_NAME";
    String tableNamePatterns = "*";
    String serviceAccount = "MY_SERVICE_ACCOUNT";
    String schemaFilePath = "/your-schema-path";
    Map<String, Value> params = new HashMap<>();
    params.put("database_type", Value.newBuilder().setStringValue(databaseType).build());
    params.put("bucket", Value.newBuilder().setStringValue(bucket).build());
    params.put("database_name", Value.newBuilder().setStringValue(databaseName).build());
    params.put("table_name_patterns", Value.newBuilder().setStringValue(tableNamePatterns).build());
    params.put("agent_service_account", Value.newBuilder().setStringValue(serviceAccount).build());
    params.put("schema_file_path", Value.newBuilder().setStringValue(schemaFilePath).build());
    TransferConfig transferConfig =
        TransferConfig.newBuilder()
            .setDestinationDatasetId(datasetId)
            .setDisplayName("Your Teradata Config Name")
            .setDataSourceId("on_premises")
            .setParams(Struct.newBuilder().putAllFields(params).build())
            .setSchedule("every 24 hours")
            .build();
    createTeradataTransfer(projectId, transferConfig);
  }

  public static void createTeradataTransfer(String projectId, TransferConfig transferConfig)
      throws IOException {
    try (DataTransferServiceClient client = DataTransferServiceClient.create()) {
      ProjectName parent = ProjectName.of(projectId);
      CreateTransferConfigRequest request =
          CreateTransferConfigRequest.newBuilder()
              .setParent(parent.toString())
              .setTransferConfig(transferConfig)
              .build();
      TransferConfig config = client.createTransferConfig(request);
      System.out.println("Cloud teradata transfer created successfully :" + config.getName());
    } catch (ApiException ex) {
      System.out.print("Cloud teradata transfer was not created." + ex.toString());
    }
  }
}

Inicializar o agente de migração

É necessário inicializar o agente de migração para uma nova transferência. A inicialização é necessária apenas uma vez para uma transferência, independentemente de ser recorrente. A inicialização apenas configura o agente de migração. Ela não inicia a transferência.

Se você for usar o agente de migração para criar um arquivo de esquema personalizado, verifique se tem um diretório gravável no diretório de trabalho com o mesmo nome do projeto que você quer usar para a transferência. É aqui que o agente de migração cria o arquivo de esquema. Por exemplo, se você estiver trabalhando em /home e configurando a transferência no projeto myProject, crie o diretório /home/myProject e verifique se ele pode ser gravado pelos usuários.

1. Abra uma nova sessão. Na linha de comando, emita o comando de inicialização, que segue este formulário:

   java -cp \
   OS-specific-separated-paths-to-jars (JDBC and agent) \
   com.google.cloud.bigquery.dms.Agent \
   --initialize

   O exemplo a seguir mostra o comando de inicialização quando os arquivos JAR do driver JDBC e do agente de migração estão em um diretório migration local:

   Unix, Linux, Mac OS

   java -cp \
   /usr/local/migration/terajdbc4.jar:/usr/local/migration/mirroring-agent.jar \
   com.google.cloud.bigquery.dms.Agent \
   --initialize

   Windows

   Copie todos os arquivos para a pasta C:\migration (ou ajuste os caminhos no comando) e execute:

   java -cp C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --initialize

2. Quando solicitado, configure as seguintes opções:

   1. Escolha se quer salvar o modelo do Teradata Parallel Transporter (TPT) no disco. Se você planeja usar o método de extração de TPT, é possível modificar o modelo salvo com parâmetros adequados à sua instância do Teradata.
   2. Digite o caminho para um diretório local que o job de transferência possa usar para extração de arquivos. Verifique se você tem o espaço de armazenamento mínimo recomendado, conforme descrito em Método de extração.
   3. Digite o nome do host do banco de dados.
   4. Digite a porta do banco de dados.
   5. Escolha se quer usar o Teradata Parallel Transporter (TPT) como o método de extração.
   6. Opcional: digite o caminho de um arquivo de credenciais do banco de dados.

   7. Escolha se quer especificar um nome de configuração do serviço de transferência de dados do BigQuery.

      Se você estiver inicializando o agente de migração de uma transferência que já configurou, faça o seguinte:

      1. Digite o nome de recurso da transferência. Isso pode ser encontrado na guia Configuração da página Detalhes da transferência.
      2. Quando solicitado, digite um caminho e o nome do arquivo do arquivo de configuração do agente de migração que será criado. Consulte esse arquivo ao executar o agente de migração para iniciar a transferência.
      3. Ignore as demais etapas.

      Se você estiver usando o agente de migração para configurar uma transferência, pressione Enter para pular para a próxima solicitação.

   8. Digite o Cloud de Confiance by S3NS ID do projeto.

   9. Digite o nome do banco de dados de origem no Teradata.

   10. Insira um padrão para corresponder os nomes das tabelas no banco de dados de origem. Você pode usar expressões regulares para especificar o padrão. Exemplo:

       • sales|expenses corresponde às tabelas chamadas sales e expenses.
       • .* corresponde a todas as tabelas.

   11. Opcional: digite o caminho de um arquivo de esquema JSON local. Isso é altamente recomendado para transferências recorrentes.

       Se você não estiver usando um arquivo de esquema ou quiser que o agente de migração crie um para você, pressione Enter para pular para a próxima solicitação.

   12. Escolha se você quer criar um novo arquivo de esquema.

       Se você quiser criar um arquivo de esquema, faça o seguinte:

       1. Digite yes.
       2. Digite o nome de usuário de um usuário do Teradata que tem acesso de leitura às tabelas do sistema e das tabelas que você quer migrar.

       3. Digite a senha do usuário.

          O agente de migração cria o arquivo de esquema e gera o local dele.

       4. Modifique o arquivo de esquema para marcar o particionamento, o clustering, as chaves primárias e as colunas de controle de alterações e verifique se você quer usar esse esquema para a configuração de transferência. Consulte Arquivo de esquema personalizado para ver dicas.

       5. Pressione Enter para pular para a próxima solicitação.

       Se você não quiser criar um arquivo de esquema, digite no.

   13. Digite o nome do bucket de destino do Cloud Storage para preparar os dados de migração antes de carregar no BigQuery. Se você tiver feito o agente de migração criar um arquivo de esquema personalizado, ele também será enviado para esse bucket.

   14. Digite o nome do conjunto de dados de destino no BigQuery.

   15. Digite um nome de exibição para a configuração de transferência.

   16. Digite um caminho e o nome do arquivo do arquivo de configuração do agente de migração que será criado.

3. Depois que todos os parâmetros solicitados são inseridos, o agente de migração cria um arquivo de configuração e o envia para o caminho local especificado. Consulte a próxima seção para ver mais detalhes sobre o arquivo de configuração.

Arquivo de configuração do agente de migração

O arquivo de configuração criado na etapa de inicialização é semelhante a este exemplo:

{
  "agent-id": "81f452cd-c931-426c-a0de-c62f726f6a6f",
  "transfer-configuration": {
    "project-id": "123456789876",
    "location": "us",
    "id": "61d7ab69-0000-2f6c-9b6c-14c14ef21038"
  },
  "source-type": "teradata",
  "console-log": false,
  "silent": false,
  "teradata-config": {
    "connection": {
      "host": "localhost"
    },
    "local-processing-space": "extracted",
    "database-credentials-file-path": "",
    "max-local-storage": "50GB",
    "gcs-upload-chunk-size": "32MB",
    "use-tpt": true,
    "transfer-views": false,
    "max-sessions": 0,
    "spool-mode": "NoSpool",
    "max-parallel-upload": 4,
    "max-parallel-extract-threads": 1,
    "session-charset": "UTF8",
    "max-unload-file-size": "2GB"
  }
}
   

Opções do job de transferência no arquivo de configuração do agente de migração

• transfer-configuration: informações sobre essa configuração de transferência no BigQuery.

• teradata-config: informações específicas para esta extração do Teradata:

  • connection: informações sobre o nome do host e a porta
  • local-processing-space: a pasta de extração em que o agente extrairá os dados da tabela antes de fazer upload para o Cloud Storage.
  • database-credentials-file-path: (Opcional) O caminho para um arquivo que contém credenciais para se conectar ao banco de dados Teradata automaticamente. O arquivo precisa conter duas linhas para as credenciais. É possível usar um nome de usuário/senha, conforme mostrado no exemplo a seguir:

    username=abc
    password=123

    Também é possível usar um secret do SecretManager:

    username=abc
    secret_resource_id=projects/my-project/secrets/my-secret-name/versions/1

    Ao usar um arquivo de credenciais, tome cuidado para controlar o acesso à pasta onde você o armazena no sistema de arquivos local, pois ele não é criptografado. Se nenhum caminho for fornecido, você será solicitado a fornecer um nome de usuário e uma senha quando iniciar um agente.

  • max-local-storage: a quantidade máxima de armazenamento local a ser usada para a extração no diretório de preparo especificado. O valor padrão é 50GB. O formato compatível é: numberKB|MB|GB|TB.

    Em todos os modos de extração, os arquivos serão excluídos do diretório de preparo local após serem enviados para o Cloud Storage.

  • use-tpt: orienta o agente de migração a usar o Teradata Parallel Transporter (TPT) como um método de extração.

    Para cada tabela, o agente de migração gera um script TPT, inicia um processo tbuild e aguarda a conclusão. Depois que o processo tbuild for concluído, o agente listará e fará upload dos arquivos extraídos para o Cloud Storage e, em seguida, excluirá o script TPT. Para mais informações, consulte Método de extração.

  • transfer-views: direciona o agente de migração para também transferir dados de visualizações. Use essa opção apenas se você precisar personalizar os dados durante a migração. Em outros casos, migre visualizações para Visualizações do BigQuery. Essa opção tem os seguintes pré-requisitos:

    • Essa opção só pode ser usada nas versões 16.10 e mais recentes do Teradata.
    • Uma visualização precisa ter uma coluna de números inteiros "partition" definida, apontando para um ID de partição para a linha especificada na tabela subjacente.

  • max-sessions: especifica o número máximo de sessões usadas pelo job de extração (FastExport ou TPT). Se definido como 0, o banco de dados do Teradata determinará o número máximo de sessões para cada job de extração.

  • gcs-upload-chunk-size: um arquivo grande é enviado em blocos para o Cloud Storage. Esse parâmetro e max-parallel-upload são usados para controlar quantos dados são enviados ao Cloud Storage ao mesmo tempo. Por exemplo, se gcs-upload-chunk-size for 64 MB e max-parallel-upload for 10 MB, teoricamente, um agente de migração poderá fazer upload de 640 MB (64 MB * 10) de dados ao mesmo tempo. Se o upload do bloco falhar, ele precisará fazer novas tentativas. O tamanho da parte precisa ser pequeno.

  • max-parallel-upload: esse valor determina o número máximo de linhas de execução usadas pelo agente de migração para fazer upload de arquivos no Cloud Storage. Caso não seja especificado, o padrão será o número de processadores disponíveis para a máquina virtual Java. A regra geral é escolher o valor com base no número de núcleos que você tem na máquina que executa o agente. Portanto, se você tiver núcleos n, o número ideal de linhas de execução precisará ser n. Se os núcleos forem hyperthread, o número ideal será (2 * n). Há também outras configurações como a largura de banda da rede que você precisa considerar ao ajustar max-parallel-upload. Ajustar esse parâmetro pode melhorar o desempenho do upload para o Cloud Storage.

  • spool-mode: na maioria dos casos, o modo NoSpool é a melhor opção. NoSpool é o valor padrão na configuração do agente. É possível alterar esse parâmetro se uma das desvantagens do NoSpool se aplicarem ao seu caso.

  • max-unload-file-size: determina o tamanho máximo do arquivo extraído. Esse parâmetro não é aplicado a extrações TPT.

  • max-parallel-extract-threads: essa configuração é usada apenas no modo FastConnect. Ele determina o número de linhas de execução paralelas usadas para extrair os dados do Teradata. Ajustar esse parâmetro pode melhorar o desempenho da extração.

  • tpt-template-path: use essa configuração para fornecer um script de extração de TPT personalizado como entrada. Use esse parâmetro para aplicar transformações aos dados de migração.

  • tpt-export-count: o operador de exportação é responsável por extrair dados do banco de dados do Teradata. Esse parâmetro substitui a contagem de exportação padrão no script TPT. Ele precisa ser menor ou igual ao valor do parâmetro max-sessions para garantir que cada instância tenha pipes suficientes para o banco de dados.

  • tpt-file-writer-count: o operador de gravação de arquivos é responsável por receber os dados do operador de exportação e gravar em um arquivo físico no sistema de armazenamento. Esse parâmetro substitui a contagem padrão de gravadores de arquivos no script TPT. O ideal é que a contagem de gravadores de arquivos corresponda à contagem de exportações. Caso contrário, a transferência se torna um gargalo na extração ou na gravação.

  • schema-mapping-rule-path: (opcional) o caminho para um arquivo de configuração que contém um mapeamento de esquema para substituir as regras de mapeamento padrão. Alguns tipos de mapeamento funcionam apenas com o modo Teradata Parallel Transporter (TPT).

    Exemplo: mapeamento do tipo TIMESTAMP do Teradata para o tipo DATETIME do BigQuery:

    {
    "rules": [
      {
        "database": {
            "name": "database.*",
            "tables": [
               {
                 "name": "table.*"
               }
            ]
        },
        "match": {
          "type": "COLUMN_TYPE",
          "value": "TIMESTAMP"
        },
        "action": {
          "type": "MAPPING",
          "value": "DATETIME"
        }
      }
    ]
    }

    Atributos:

    • database: (opcional) name é uma expressão regular para bancos de dados a serem incluídos. Todos os bancos de dados são incluídos por padrão.
    • tables: (opcional) contém uma matriz de tabelas. name é uma expressão regular para tabelas a serem incluídas. Todas as tabelas estão incluídas por padrão.
    • match: (Obrigatório)
      • Valores aceitos type: COLUMN_TYPE.
      • Valores aceitos: value: TIMESTAMP, DATETIME.
    • action: (Obrigatório)
      • Valores aceitos type: MAPPING.
      • Valores aceitos: value: TIMESTAMP, DATETIME.

  • compress-output: (opcional) determina se os dados precisam ser compactados antes de armazenar no Cloud Storage. Isso é aplicado apenas em tpt-mode. Por padrão, esse valor é false.

  • gcs-module-config-dir: (opcional) o caminho para o arquivo de credenciais para acessar o bucket do Cloud Storage. O diretório padrão é $HOME/.gcs, mas você pode usar esse parâmetro para mudar o diretório.

  • gcs-module-connection-count: (opcional) especifica o número de conexões TCP com o serviço do Cloud Storage. O valor padrão é 10.

  • gcs-module-buffer-size: (opcional) especifica o tamanho dos buffers a serem usados para as conexões TCP. O padrão é 8 MB (8388608 bytes). Para facilitar o uso, você pode usar os seguintes multiplicadores:

    • k (1000)
    • K (1024)
    • m (1000 * 1000)
    • M (1024*1024)

  • gcs-module-buffer-count: (opcional) especifica o número de buffers a serem usados com as conexões TCP especificadas pelo gcs-module-connection-count. Recomendamos usar um valor igual ao dobro do número de conexões TCP com o serviço do Cloud Storage. O valor padrão é 2 * gcs-module-connection-count.

  • gcs-module-max-object-size: (opcional). Esse parâmetro controla os tamanhos dos objetos do Cloud Storage. O valor desse parâmetro pode ser um número inteiro ou um número inteiro seguido, sem um espaço, por um dos seguintes multiplicadores:

    • k (1000)
    • K (1024)
    • m (1000 * 1000)
    • M (1024*1024)

  • gcs-module-writer-instances: (opcional): especifica o número de instâncias de gravador do Cloud Storage. Por padrão, o valor é 1. É possível aumentar esse valor para aumentar a capacidade de processamento durante a fase de gravação da exportação do TPT.

Otimizar a extração de dados do agente

Ao ajustar os parâmetros do agente, você pode otimizar o processo de extração de dados e tornar o processo de transferência geral eficiente.

A tabela a seguir fornece informações sobre os parâmetros que podem ser usados para ajustar sua migração:

Considere as seguintes práticas recomendadas para configuração:

• Restrição de memória: verifique se o resultado do cálculo abaixo é menor que a memória total da máquina virtual (VM) que executa o agente. Use unidades consistentes para todos os valores no cálculo.

  $$ \text{gcs-module-writer-instances} \times \text{gcs-module-buffer-size} \times \text{gcs-module-buffer-count} < \text{Total VM memory} $$

• Ordem de ajuste:

  1. Ajuste primeiro o valor do parâmetro gcs-module-writer-instances para encontrar o melhor equilíbrio entre performance e carga.
  2. Se forem necessários mais ganhos de performance, aumente o valor de gcs-module-connection-count.

• Escalonamento automático: por padrão, o valor do parâmetro gcs-module-buffer-size geralmente é definido como o dobro da contagem de conexões, mas recomendamos ajustar explicitamente o valor para 32m nessas cargas de trabalho.

Executar o agente de migração

Depois de inicializar o agente de migração e criar o arquivo de configuração, use as seguintes etapas para executar o agente e iniciar a migração:

1. Execute o agente especificando os caminhos para o driver JDBC, o agente de migração e o arquivo de configuração criado na etapa de inicialização anterior.

   java -cp \
   OS-specific-separated-paths-to-jars (JDBC and agent) \
   com.google.cloud.bigquery.dms.Agent \
   --configuration-file=path to configuration file

   Unix, Linux, Mac OS

   java -cp \
   /usr/local/migration/Teradata/JDBC/terajdbc4.jar:mirroring-agent.jar \
   com.google.cloud.bigquery.dms.Agent \
   --configuration-file=config.json

   Windows

   Copie todos os arquivos para a pasta C:\migration (ou ajuste os caminhos no comando) e execute:

   java -cp C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --configuration-file=config.json

   Se você estiver pronto para continuar a migração, pressione Enter, e o agente prosseguirá se o caminho de classe fornecido durante a inicialização for válido.

2. Quando solicitado, digite o nome de usuário e a senha da conexão do banco de dados. Se o nome de usuário e a senha forem válidos, a migração de dados será iniciada.

   Opcional No comando para iniciar a migração, você também pode usar uma sinalização que transmita um arquivo de credenciais para o agente, em vez de digitar toda vez o nome de usuário e a senha. Consulte o parâmetro opcional database-credentials-file-path no arquivo de configuração do agente para obter mais informações. Ao usar um arquivo de credenciais, siga as etapas apropriadas para controlar o acesso à pasta onde você o armazena no sistema de arquivos local, porque ele não é criptografado.

3. Deixe esta sessão aberta até que a migração seja concluída. Se você tiver criado uma transferência de migração recorrente, mantenha esta sessão aberta indefinidamente. Se esta sessão for interrompida, as execuções de transferência atuais e futuras falham.

4. Monitore periodicamente se o agente está em execução. Se uma execução de transferência estiver em andamento e nenhum agente responder em 24 horas, a execução da transferência falhará.

5. Se o agente de migração parar de funcionar enquanto a transferência estiver em andamento ou programada, o console do Cloud de Confiance vai mostrar o status do erro e solicitar que você reinicie o agente. Para reiniciar o agente de migração, volte ao início desta seção. Não é necessário repetir o comando de inicialização. A transferência é retomada do ponto em que as tabelas não foram concluídas.

Acompanhar o progresso da migração

Confira o status da migração no console Cloud de Confiance . Também é possível configurar as notificações do Pub/Sub ou por e-mail. Consulte Notificações do serviço de transferência de dados do BigQuery.

O serviço de transferência de dados do BigQuery programa e inicia uma execução de transferência conforme uma programação especificada na criação da configuração de transferência. É importante que o agente de migração esteja em execução quando uma execução de transferência estiver ativa. Se não houver atualizações do agente em 24 horas, uma execução de transferência falha.

Exemplo de status da migração no console Cloud de Confiance :

Fazer upgrade do agente de migração

Se uma nova versão do agente de migração estiver disponível, você precisará atualizá-lo manualmente. Para receber avisos sobre o serviço de transferência de dados do BigQuery, inscreva-se nas Notas de lançamento.

A seguir

• Faça uma migração de teste do Teradata para o BigQuery.
• Saiba mais sobre o serviço de transferência de dados do BigQuery.
• Migrar o código SQL com a translação de SQL em lote.