Avaliação da migração

Databricks

Para solicitar feedback ou suporte para este recurso, envie um e-mail para bq-edw-migration-support@google.com.

A extração de metadados para a avaliação do Databricks começa com o download e a execução da ferramenta de extração no seu ambiente do Databricks.

A ferramenta de extração é um notebook que produz um arquivo ZIP com arquivos que contêm uma representação de várias visualizações do Databricks. As visualizações contêm os dados necessários para a avaliação.

Baixar a ferramenta de extração

Um link para download do notebook é fornecido na seção "Avaliação" do consoleGoogle Cloud . Os arquivos estão disponíveis como um arquivo ZIP, que contém o seguinte:

• O notebook de extração
• Os scripts utilitários do Python que o notebook executa durante o processo de extração.

Importar e configurar a ferramenta de extração

1. Importe o arquivo ZIP da etapa anterior usando a interface do usuário do Databricks.
2. Depois da importação, abra o notebook de extração e conclua todas as etapas marcadas como "Configuração".

A autenticação do notebook faz parte das etapas de configuração. O notebook é compatível com dois métodos de autenticação do Databricks:

• Entidade de serviço
• Token de acesso pessoal (PAT)

Você precisará usar um desses métodos para continuar na próxima seção. Recomendamos usar um principal de serviço em vez do PAT, se disponível, já que a opção PAT é considerada legada pelo Databricks.

Extrair os dados para avaliação

Depois de concluir todas as etapas de configuração, o notebook estará pronto para ser executado. Quando o notebook de extração estiver ativo, use a opção "Executar tudo" para executar o notebook.

A execução do notebook pode levar até um dia para sistemas muito grandes. Para um sistema típico com cerca de 50.000 tabelas, a extração leva menos de uma hora.

Opcional: monitorar o progresso do notebook de extração

O notebook de extração fornece registros que contêm informações de progresso e erro para fins de monitoramento. As mensagens de registro mais recentes de uma execução de notebook específica contêm informações sobre o que está sendo extraído.

Como a execução do notebook não para no primeiro erro, revise os erros em duas etapas:

1. Verifique o resumo após uma extração para conferir uma contagem de erros ou outros indicadores de erro após a conclusão da extração. Por exemplo, menos dados foram encontrados do que o esperado. Se os resultados parecerem aceitáveis, pule a próxima etapa.
2. Copie a saída do registro e salve em um arquivo de texto.

Concluir o processo de extração

Depois que o notebook terminar o processo de extração, clique no botão de download na última seção do notebook para baixar os resultados.

Snowflake

Requisitos

Você precisa atender aos seguintes requisitos para extrair metadados e registros de consulta do Snowflake:

• Uma máquina que pode se conectar às instâncias do Snowflake.
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados.
• Um conjunto de dados do BigQuery vazio para armazenar os resultados. Também é possível criar um conjunto de dados do BigQuery ao criar o job de avaliação usando a UI do console Google Cloud .
• Usuário do Snowflake com acesso IMPORTED PRIVILEGES no banco de dados Snowflake. Recomendamos criar um SERVICE usuário com autenticação baseada em par de chaves. Isso fornece o método seguro para acessar a plataforma de dados do Snowflake sem precisar gerar tokens de MFA.
  • Para criar um usuário de serviço, siga o guia oficial do Snowflake (em inglês). Você precisará gerar o par de chaves RSA e atribuir a chave pública ao usuário do Snowflake.
  • O usuário do serviço precisa ter o papel ACCOUNTADMIN ou receber um papel com os privilégios IMPORTED PRIVILEGES no banco de dados Snowflake de um administrador da conta.
  • Como alternativa à autenticação de par de chaves, você pode usar a autenticação baseada em senha. No entanto, a partir de agosto de 2025, o Snowflake vai exigir a MFA de todos os usuários que usam senhas. Isso exige que você aprove a notificação push da MFA ao usar nossa ferramenta de extração.

Execute a ferramenta dwh-migration-dumper

Faça o download da ferramenta de extração da linha de comando dwh-migration-dumper.

Faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando para verificar a exatidão do ZIP:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

Para detalhes sobre como usar a ferramenta dwh-migration-dumper, consulte a página Gerar metadados.

Use a ferramenta dwh-migration-dumper para extrair registros e metadados do armazenamento de dados no Snowflake como dois arquivos ZIP. Execute os comandos a seguir em uma máquina com acesso ao data warehouse de origem para gerar os arquivos.

Gere o arquivo ZIP de metadados:

dwh-migration-dumper \
  --connector snowflake \
  --host HOST_NAME \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --assessment \
  --private-key-file PRIVATE_KEY_PATH \
  --private-key-password PRIVATE_KEY_PASSWORD

Gere o arquivo ZIP com os registros de consulta:

dwh-migration-dumper \
  --connector snowflake-logs \
  --host HOST_NAME \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --query-log-start STARTING_DATE \
  --query-log-end ENDING_DATE \
  --assessment \
  --private-key-file PRIVATE_KEY_PATH \
  --private-key-password PRIVATE_KEY_PASSWORD

Substitua:

• HOST_NAME: o nome do host da sua instância do Snowflake.
• USER_NAME: o nome de usuário a ser usado para a conexão do banco de dados, em que o usuário precisa ter as permissões de acesso conforme detalhado na seção de requisitos.
• PRIVATE_KEY_PATH: o caminho para a chave privada RSA usada para autenticação.
• PRIVATE_KEY_PASSWORD: (opcional) a senha usada ao criar a chave privada RSA. Só é necessário se a chave privada estiver criptografada.
• ROLE_NAME: (opcional, mas altamente recomendado) a função do usuário ao executar a ferramenta dwh-migration-dumper, por exemplo, ACCOUNTADMIN. Embora seja tecnicamente opcional se sua função padrão tiver privilégios suficientes, especificar uma função garante que a sessão tenha acesso ao esquema SNOWFLAKE.ACCOUNT_USAGE.
• WAREHOUSE: o warehouse usado para executar as operações de despejo. Se você tiver vários warehouses virtuais, poderá especificar qualquer warehouse para executar essa consulta. A execução dessa consulta com as permissões de acesso detalhadas na seção de requisitos extrai todos os artefatos de warehouse da conta.
• STARTING_DATE: (opcional) usado para indicar a data de início em um período de registros de consulta, gravado no formato YYYY-MM-DD.
• ENDING_DATE: (opcional) usado para indicar a data de término em um período de registros de consulta, escrito no formato YYYY-MM-DD.

Também é possível gerar vários arquivos ZIP contendo registros de consulta abrangendo períodos não sobrepostos e fornecer todos eles para avaliação.

Hadoop / Cloudera

Para solicitar feedback ou suporte para este recurso, envie um e-mail para bq-edw-migration-support@google.com.

Requisitos

Para extrair metadados do Cloudera, você precisa ter o seguinte:

• Uma máquina que pode se conectar à API do Cloudera Manager.
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados.
• Um conjunto de dados do BigQuery vazio para armazenar os resultados. Também é possível criar um conjunto de dados do BigQuery ao criar o job de avaliação.

Execute a ferramenta dwh-migration-dumper

1. Faça o download da ferramenta de extração da linha de comando dwh-migration-dumper.

2. Faça o download do arquivo SHA256SUMS.txt.

3. No ambiente de linha de comando, verifique a exatidão do ZIP:

     sha256sum --check SHA256SUMS.txt
     

   Para detalhes sobre como usar a ferramenta dwh-migration-dumper, consulte Gerar metadados para tradução e avaliação.

4. Use a ferramenta dwh-migration-dumper para extrair metadados e estatísticas de desempenho para o arquivo ZIP:

   dwh-migration-dumper \
       --connector cloudera-manager \
       --user USER_NAME \
       --password PASSWORD \
       --url URL_PATH \
       --yarn-application-types "APP_TYPES" \
       --spark-history-service-names "SPARK_HISTORY_SERVICE_NAMES" \
       --pagination-page-size PAGE_SIZE \
       --start-date START_DATE \
       --end-date END_DATE \
       --assessment

   Substitua:

   • USER_NAME: o nome do usuário para se conectar à instância do Cloudera Manager.
   • PASSWORD: a senha da sua instância do Cloudera Manager.
   • URL_PATH: o caminho do URL para a API do Cloudera Manager, por exemplo, https://localhost:7183/api/v55/.
   • APP_TYPES (opcional): os tipos de aplicativo YARN separados por vírgulas que são despejados do cluster. O valor padrão é MAPREDUCE,SPARK,Oozie Launcher.
   • SPARK_HISTORY_SERVICE_NAMES (opcional): a lista separada por vírgulas de nomes de serviços do servidor de histórico do Spark, usada para consultar logs de eventos do Spark pelo Apache Knox para extração de metadados de aplicativos. Se não for fornecido, o valor padrão será sparkhistory,spark3history.
   • PAGE_SIZE (opcional): o número de registros por resposta do Cloudera. O valor padrão é 1000.
   • START_DATE (opcional): a data de início do despejo do histórico no formato ISO 8601. Por exemplo, 2025-05-29. O valor padrão é de 90 dias antes da data atual.
   • END_DATE (opcional): a data de término do despejo do histórico no formato ISO 8601. Por exemplo, 2025-05-30. O valor padrão é a data atual.

Usar o Oozie no cluster do Cloudera

Se você usa o Oozie no cluster do Cloudera, é possível despejar o histórico de jobs do Oozie com o conector do Oozie. É possível usar o Oozie com autenticação do Kerberos ou básica.

Para a autenticação do Kerberos, execute o seguinte:

kinit
dwh-migration-dumper \
    --connector oozie \
    --url URL_PATH \
    --assessment

Substitua:

• URL_PATH (opcional): o caminho do URL do servidor do Oozie. Se você não especificar o caminho do URL, ele será extraído da variável de ambiente OOZIE_URL.

Para autenticação básica, execute o seguinte:

dwh-migration-dumper \
    --connector oozie \
    --user USER_NAME \
    --password PASSWORD \
    --url URL_PATH \
    --assessment

Substitua:

• USER_NAME: o nome do usuário do Oozie.
• PASSWORD: a senha do usuário.
• URL_PATH (opcional): o caminho do URL do servidor do Oozie. Se você não especificar o caminho do URL, ele será extraído da variável de ambiente OOZIE_URL.

Usar o Airflow no cluster do Cloudera

Se você usa o Airflow no cluster do Cloudera, é possível despejar o histórico de DAGs com o conector do Airflow:

dwh-migration-dumper \
    --connector airflow \
    --user USER_NAME \
    --password PASSWORD \
    --url URL \
    --driver "DRIVER_PATH" \
    --start-date START_DATE \
    --end-date END_DATE \
    --assessment

Substitua:

• USER_NAME: o nome do usuário do Airflow
• PASSWORD: a senha do usuário
• URL: a string JDBC para o banco de dados do Airflow
• DRIVER_PATH: o caminho para o driver JDBC
• START_DATE (opcional): a data de início do despejo do histórico no formato ISO 8601
• END_DATE (opcional): a data de término do despejo do histórico no formato ISO 8601

Usar o Hive no cluster do Cloudera

Para usar o conector do Hive, consulte a guia "Apache Hive".

Teradata

Requisitos

• Uma máquina conectada ao seu data warehouse do Teradata de origem. A avaliação de migração é compatível com o Teradata versão 15 ou mais recente e apenas com versões locais do Teradata VantageCore. O Teradata VantageCloud não é compatível.
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados
• Um conjunto de dados do BigQuery vazio para armazenar os resultados
• Permissões de leitura no conjunto de dados para ver os resultados
• Recomendado: direitos de acesso no nível do administrador ao banco de dados de origem ao usar a ferramenta de extração para acessar tabelas do sistema

Requisito: ativar a geração de registros

A ferramenta dwh-migration-dumper extrai três tipos de registros: de consulta, de utilitários e de uso de recursos. É necessário ativar a geração de registros para os seguintes tipos de registros para ver insights mais completos:

• Registros de consulta: extraídos da visualização dbc.QryLogV e da tabela dbc.DBQLSqlTbl. Ative a geração de registros especificando a opção WITH SQL.
• Registros de utilitários: extraídos da tabela dbc.DBQLUtilityTbl. Ative a geração de registros especificando a opção WITH UTILITYINFO.
• Registros de uso de recursos: extraídos das tabelas dbc.ResUsageScpu e dbc.ResUsageSpma. Ative a geração de registros RSS para essas duas tabelas.

Execute a ferramenta dwh-migration-dumper

Fazer o download da ferramenta dwh-migration-dumper

Faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando para verificar a exatidão do ZIP:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

Para saber detalhes sobre como configurar e usar a ferramenta de extração, consulte Gerar metadados para tradução e avaliação.

Use a ferramenta de extração para extrair registros e metadados do armazenamento de dados do Teradata como dois arquivos ZIP. Execute os comandos a seguir em uma máquina com acesso ao data warehouse de origem para gerar os arquivos.

Gere o arquivo ZIP de metadados:

dwh-migration-dumper \
  --connector teradata \
  --database DATABASES \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

Observação:a flag --database é opcional para o conector teradata. Se omitido, os metadados de todos os bancos de dados serão extraídos. Essa flag só é válida para o conector teradata e não pode ser usada com teradata-logs.

Gere o arquivo ZIP com os registros de consulta:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

Observação:a flag --database não é usada ao extrair registros de consulta com o conector teradata-logs. Os registros de consulta são sempre extraídos para todos os bancos de dados.

Substitua:

• PATH: o caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão;
• VERSION: a versão do driver;
• HOST: o endereço do host;
• USER: o nome de usuário a ser usado na conexão do banco de dados;
• DATABASES: (opcional) a lista separada por vírgulas de nomes de bancos de dados a extrair. Se não for fornecido, todos os bancos de dados serão extraídos.
• PASSWORD: (opcional) a senha a ser usada na conexão do banco de dados. Se ficar em branco, o usuário precisará informar a senha.

Por padrão, os registros de consulta são extraídos da visualização dbc.QryLogV e da tabela dbc.DBQLSqlTbl. Se você precisar extrair os registros de consulta de um local alternativo, especifique os nomes das tabelas ou visualizações usando as sinalizações -Dteradata-logs.query-logs-table e -Dteradata-logs.sql-logs-table.

Por padrão, os registros do utilitário são extraídos da tabela dbc.DBQLUtilityTbl. Se você precisar extrair os registros utilitários de um local alternativo, especifique o nome da tabela usando a flag -Dteradata-logs.utility-logs-table.

Por padrão, os registros de uso de recursos são extraídos das tabelas dbc.ResUsageScpu e dbc.ResUsageSpma. Se você precisar extrair os registros de uso de recursos de um local alternativo, especifique os nomes das tabelas usando as sinalizações -Dteradata-logs.res-usage-scpu-table e -Dteradata-logs.res-usage-spma-table.

Exemplo:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  -Dteradata-logs.query-logs-table=pdcrdata.QryLogV_hst \
  -Dteradata-logs.sql-logs-table=pdcrdata.DBQLSqlTbl_hst \
  -Dteradata-logs.log-date-column=LogDate \
  -Dteradata-logs.utility-logs-table=pdcrdata.DBQLUtilityTbl_hst \
  -Dteradata-logs.res-usage-scpu-table=pdcrdata.ResUsageScpu_hst \
  -Dteradata-logs.res-usage-spma-table=pdcrdata.ResUsageSpma_hst

dwh-migration-dumper `
  --connector teradata-logs `
  --driver path\terajdbc4.jar `
  --host HOST `
  --assessment `
  --user USER `
  --password PASSWORD `
  "-Dteradata-logs.query-logs-table=pdcrdata.QryLogV_hst" `
  "-Dteradata-logs.sql-logs-table=pdcrdata.DBQLSqlTbl_hst" `
  "-Dteradata-logs.log-date-column=LogDate" `
  "-Dteradata-logs.utility-logs-table=pdcrdata.DBQLUtilityTbl_hst" `
  "-Dteradata-logs.res-usage-scpu-table=pdcrdata.ResUsageScpu_hst" `
  "-Dteradata-logs.res-usage-spma-table=pdcrdata.ResUsageSpma_hst"

Por padrão, a ferramenta dwh-migration-dumper extrai os últimos sete dias de registros de consulta. O Google recomenda que você forneça pelo menos duas semanas de registros de consulta para visualizar insights mais completos. É possível especificar um intervalo de tempo personalizado usando as flags --query-log-start e --query-log-end. Exemplo:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-15 00:00:00"

Também é possível gerar vários arquivos ZIP contendo registros de consulta abrangendo diferentes períodos e fornecer todos eles para avaliação.

Redshift

Requisitos

• Uma máquina conectada ao seu data warehouse de origem do Amazon Redshift
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados
• Um conjunto de dados do BigQuery vazio para armazenar os resultados
• Permissões de leitura no conjunto de dados para ver os resultados
• Recomendado: acesso de superusuário ao banco de dados ao usar a ferramenta de extração para acessar tabelas do sistema

Execute a ferramenta dwh-migration-dumper

Faça o download da ferramenta de extração da linha de comando dwh-migration-dumper.

Faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando para verificar a exatidão do ZIP:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

Para detalhes sobre como usar a ferramenta dwh-migration-dumper, consulte a página Gerar metadados.

Use a ferramenta dwh-migration-dumper para extrair registros e metadados do armazenamento de dados do Amazon Redshift como dois arquivos ZIP. Execute os comandos a seguir em uma máquina com acesso ao data warehouse de origem para gerar os arquivos.

Gere o arquivo ZIP de metadados:

dwh-migration-dumper \
  --connector redshift \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

Gere o arquivo ZIP com os registros de consulta:

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

Substitua:

• DATABASE: o nome do banco de dados a ser conectado;
• PATH: o caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão;
• VERSION: a versão do driver;
• USER: o nome de usuário a ser usado na conexão do banco de dados;
• IAM_PROFILE_NAME: o Nome do perfil do IAM do Amazon Redshift. Obrigatório para autenticação do Amazon Redshift e para acesso à API da AWS. Para conferir a descrição dos clusters do Amazon Redshift, use a API da AWS.

Por padrão, o Amazon Redshift armazena de três a cinco dias de registros de consulta.

Por padrão, a ferramenta dwh-migration-dumper extrai os últimos sete dias de registros de consulta.

O Google recomenda que você forneça pelo menos duas semanas de registros de consulta para visualizar insights mais completos. Talvez seja necessário executar a ferramenta de extração algumas vezes ao longo de duas semanas para ter os melhores resultados. É possível especificar um intervalo personalizado usando as sinalizações --query-log-start e --query-log-end. Exemplo:

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-02 00:00:00"

Também é possível gerar vários arquivos ZIP contendo registros de consulta abrangendo diferentes períodos e fornecer todos eles para avaliação.

Redshift sem servidor

Requisitos

• Uma máquina conectada ao seu data warehouse de origem do Amazon Redshift Serverless
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados
• Um conjunto de dados do BigQuery vazio para armazenar os resultados
• Permissões de leitura no conjunto de dados para ver os resultados
• Recomendado: acesso de superusuário ao banco de dados ao usar a ferramenta de extração para acessar tabelas do sistema

Execute a ferramenta dwh-migration-dumper

Faça o download da ferramenta de extração da linha de comando dwh-migration-dumper.

Para detalhes sobre como usar a ferramenta dwh-migration-dumper, consulte a página Gerar metadados.

Use a ferramenta dwh-migration-dumper para extrair registros de uso e metadados do namespace sem servidor do Amazon Redshift como dois arquivos ZIP. Execute os comandos a seguir em uma máquina com acesso ao data warehouse de origem para gerar os arquivos.

Gere o arquivo ZIP de metadados:

dwh-migration-dumper \
  --connector redshift \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift-serverless.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

Gere o arquivo ZIP com os registros de consulta:

dwh-migration-dumper \
  --connector redshift-serverless-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift-serverless.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

Substitua:

• DATABASE: o nome do banco de dados a ser conectado;
• PATH: o caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão;
• VERSION: a versão do driver;
• USER: o nome de usuário a ser usado na conexão do banco de dados;
• IAM_PROFILE_NAME: o Nome do perfil do IAM do Amazon Redshift. Obrigatório para autenticação do Amazon Redshift e para acesso à API da AWS. Para conferir a descrição dos clusters do Amazon Redshift, use a API da AWS.

O Amazon Redshift Serverless armazena registros de uso por sete dias. Se for necessário um intervalo maior, o Google recomenda extrair dados várias vezes durante um período mais longo.

Oracle / Oracle Exadata

Para solicitar feedback ou suporte para este recurso, envie um e-mail para bq-edw-migration-support@google.com.

Requisitos

Você precisa atender aos seguintes requisitos para extrair metadados e registros de consulta do Oracle e do Oracle Exadata:

• Seu banco de dados Oracle precisa ser a versão 11g R1 ou mais recente.
• Uma máquina que pode se conectar às instâncias do Oracle.
• Java 8 ou mais recente.
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados.
• Um conjunto de dados do BigQuery vazio para armazenar os resultados. Também é possível criar um conjunto de dados do BigQuery ao criar o job de avaliação usando a UI do console Google Cloud .
• Um usuário comum do Oracle com privilégios de SYSDBA.

Execute a ferramenta dwh-migration-dumper

Faça o download da ferramenta de extração da linha de comando dwh-migration-dumper.

Faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando para verificar a exatidão do ZIP:

sha256sum --check SHA256SUMS.txt

Para detalhes sobre como usar a ferramenta dwh-migration-dumper, consulte a página Gerar metadados.

Use a ferramenta dwh-migration-dumper para extrair metadados e estatísticas de desempenho para o arquivo ZIP. Por padrão, as estatísticas são extraídas do Oracle AWR, que exige o Oracle Tuning and Diagnostics Pack. Se esses dados não estiverem disponíveis, o dwh-migration-dumper usará o STATSPACK. O conector oracle-stats também é compatível com o Oracle Exadata.

Para bancos de dados multitenant, a ferramenta dwh-migration-dumper precisa ser executada no contêiner raiz. Executar em um dos bancos de dados conectáveis resulta em estatísticas de desempenho e metadados ausentes sobre outros bancos de dados conectáveis.

Gere o arquivo ZIP de metadados:

dwh-migration-dumper \
  --connector oracle-stats \
  --host HOST_NAME \
  --port PORT \
  --oracle-service SERVICE_NAME \
  --assessment \
  --driver JDBC_DRIVER_PATH \
  --user USER_NAME \
  --password

Substitua:

• HOST_NAME: o nome do host da sua instância do Oracle.
• PORT: o número da porta de conexão. O valor padrão é 1521.
• SERVICE_NAME: o nome do serviço do Oracle a ser usado para a conexão.
• JDBC_DRIVER_PATH: o caminho absoluto ou relativo para o arquivo JAR do driver. Faça o download desse arquivo na página de downloads do driver JDBC da Oracle. Selecione a versão do driver compatível com a versão do banco de dados.
• USER_NAME: nome do usuário usado para se conectar à instância do Oracle. O usuário precisa ter as permissões de acesso detalhadas na seção de requisitos.

Apache Hive

Requisitos

• Uma máquina conectada ao seu data warehouse do Apache Hive de origem. A avaliação de migração do BigQuery é compatível com o Hive no Tez e MapReduce, além de ser compatível com o Apache Hive da versão 2.2 até a 3.1.
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados
• Um conjunto de dados do BigQuery vazio para armazenar os resultados
• Permissões de leitura no conjunto de dados para ver os resultados
• Acesso ao seu data warehouse de origem do Apache Hive para configurar a extração de registros de consulta
• Estatísticas atualizadas de tabelas, partições e colunas

A avaliação de migração do BigQuery usa estatísticas de tabelas, partições e colunas para entender melhor seu data warehouse do Apache Hive e fornecer insights detalhados. Quando a configuração de hive.stats.autogather está definida como false no data warehouse de origem do Apache Hive, o Google recomenda ativar ou atualizar as estatísticas manualmente antes de executar a ferramenta dwh-migration-dumper.

Execute a ferramenta dwh-migration-dumper

Faça o download da ferramenta de extração da linha de comando dwh-migration-dumper.

Faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando para verificar a exatidão do ZIP:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

Para detalhes sobre como usar a ferramenta dwh-migration-dumper, consulte Gerar metadados para tradução e avaliação.

Use a ferramenta dwh-migration-dumper para gerar metadados do seu data warehouse do Hive como um arquivo ZIP.

Sem autenticação

Para gerar o arquivo ZIP de metadados, execute o seguinte comando em uma máquina com acesso ao data warehouse de origem:

dwh-migration-dumper \
  --connector hiveql \
  --database DATABASES \
  --host hive.cluster.host \
  --port 9083 \
  --assessment

Com a autenticação do Kerberos

Para se autenticar no metastore, faça login como um usuário que tenha acesso ao metastore do Apache Hive e gere um tíquete do Kerberos. Em seguida, gere o arquivo ZIP de metadados com o seguinte comando:

JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" \
  dwh-migration-dumper \
  --connector hiveql \
  --database DATABASES \
  --host hive.cluster.host \
  --port 9083 \
  --hive-kerberos-url PRINCIPAL/HOST \
  -Dhiveql.rpc.protection=hadoop.rpc.protection \
  --assessment

Substitua:

• DATABASES: a lista separada por vírgulas de nomes de bancos de dados a extrair. Se não for fornecido, todos os bancos de dados serão extraídos.
• PRINCIPAL: o principal do Kerberos para onde o tíquete foi emitido.
• HOST: o nome do host do Kerberos para onde o tíquete é emitido.
• hadoop.rpc.protection: a qualidade de proteção (QOP, na sigla em inglês) do nível de configuração da Camada de Autenticação e Segurança Simples (SASL), igual ao valor do parâmetro hadoop.rpc.protection dentro do /etc/hadoop/conf/core-site.xml com um dos seguintes valores:
  • authentication
  • integrity
  • privacy

Extrair registros de consulta com o hook de geração de registros hadoop-migration-assessment

Para extrair registros de consulta, siga estas etapas:

1. Faça upload do hook de geração de registros hadoop-migration-assessment.
2. Configure as propriedades do hook de geração de registros.
3. Verifique o hook de geração de registros.

Fazer upload do hook de geração de registros hadoop-migration-assessment

1. Faça o download do hook de geração de registros para extração de registros de consulta hadoop-migration-assessment que contém o arquivo JAR desse hook do Hive.

2. Extraia o arquivo JAR.

   Se você precisar auditar a ferramenta para garantir que ela atende aos requisitos de conformidade, revise o código-fonte no repositório do GitHub de hooks de geração de registros hadoop-migration-assessment e compile seu próprio binário.

3. Copie o arquivo JAR na pasta da biblioteca auxiliar em todos os clusters em que você planeja ativar a geração de registros de consulta. Dependendo do seu fornecedor, você precisará localizar a pasta da biblioteca auxiliar nas configurações do cluster e transferir o arquivo JAR para a pasta da biblioteca auxiliar no cluster do Hive.

4. Defina as propriedades de configuração para o hook de geração de registros hadoop-migration-assessment. Dependendo do seu fornecedor do Hadoop, você precisará usar o console da UI para editar as configurações do cluster. Modifique o arquivo /etc/hive/conf/hive-site.xml ou aplique a configuração com o gerenciador de configuração.

Configurar propriedades

Se você já tiver outros valores para as chaves de configuração a seguir, acrescente as configurações usando uma vírgula (,). Para configurar o hook de geração de registros hadoop-migration-assessment, as seguintes definições são necessárias:

• hive.exec.failure.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.exec.post.hooks : com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.exec.pre.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.aux.jars.path: inclua o caminho para o arquivo JAR do hook de geração de registros, por exemplo, file:///HiveMigrationAssessmentQueryLogsHooks_deploy.jar.
• dwhassessment.hook.base-directory: o caminho para a pasta de saída dos registros de consulta. Por exemplo, hdfs://tmp/logs/.

• Também é possível definir as seguintes configurações opcionais:

  • dwhassessment.hook.queue.capacity: a capacidade de fila para as linhas de execução de log de eventos de consulta. O valor padrão é 64.
  • dwhassessment.hook.rollover-interval: a frequência em que o rollover de arquivos precisa ser realizado. Por exemplo, 600s. O valor padrão é de 3.600 segundos (1 hora).
  • dwhassessment.hook.rollover-eligibility-check-interval: a frequência em que a verificação de elegibilidade do rollover de arquivos é acionada em segundo plano. Por exemplo, 600s. O valor padrão é de 600 segundos (10 minutos).

Verificar o hook de geração de registros

Depois de reiniciar o processo hive-server2, execute uma consulta de teste e analise os registros de depuração. A seguinte mensagem será exibida:

Logger successfully started, waiting for query events. Log directory is '[dwhassessment.hook.base-directory value]'; rollover interval is '60' minutes;
rollover eligibility check is '10' minutes

O hook de geração de registros cria uma subpasta particionada por data na pasta configurada. O arquivo Avro com eventos de consulta aparecerá nessa pasta após o intervalo dwhassessment.hook.rollover-interval ou o encerramento do processo hive-server2. É possível procurar mensagens semelhantes nos registros de depuração para ver o status da operação de rollover:

Updated rollover time for logger ID 'my_logger_id' to '2023-12-25T10:15:30'

Performed rollover check for logger ID 'my_logger_id'. Expected rollover time
is '2023-12-25T10:15:30'

O rollover ocorre nos intervalos especificados ou quando o dia é alterado. Quando a data é alterada, o hook de geração de registros também cria uma nova subpasta para essa data.

O Google recomenda que você forneça pelo menos duas semanas de registros de consulta para visualizar insights mais completos.

Também é possível gerar pastas que contêm registros de consulta de diferentes clusters do Hive e fornecer todos eles para uma única avaliação.

Informatica

Para solicitar feedback ou suporte para este recurso, envie um e-mail para bq-edw-migration-support@google.com.

Requisitos

• Acesso ao cliente do Informatica PowerCenter Repository Manager
• Uma conta do Google Cloud com um bucket do Cloud Storage para armazenar os dados.
• Um conjunto de dados do BigQuery vazio para armazenar os resultados. Também é possível criar um conjunto de dados do BigQuery ao criar o job de avaliação usando o console Google Cloud .

Requisito: exportar arquivos de objetos

É possível usar a GUI do Informatica PowerCenter Repository Manager para exportar seus arquivos de objeto. Para mais informações, consulte Etapas para exportar objetos.

Como alternativa, execute o comando pmrep para exportar seus arquivos de objeto seguindo estas etapas:

1. Execute o comando pmrep connect para se conectar ao repositório:

  pmrep connect -r `REPOSITORY_NAME` -d `DOMAIN_NAME` -n `USERNAME` -x `PASSWORD`

Substitua:

• REPOSITORY_NAME: nome do repositório a que você quer se conectar
• DOMAIN_NAME: nome do domínio do repositório
• USERNAME: nome de usuário para se conectar ao repositório.
• PASSWORD: senha do nome de usuário

1. Depois de se conectar ao repositório, use o comando pmrep objectexport para exportar os objetos necessários:

  pmrep objectexport -n `OBJECT_NAME` -o `OBJECT_TYPE` -f `FOLDER_NAME` -u `OUTPUT_FILE_NAME.xml`

Substitua:

• OBJECT_NAME: nome de um objeto específico a ser exportado
• OBJECT_TYPE: tipo de objeto especificado
• FOLDER_NAME: nome da pasta que contém o objeto a ser exportado
• OUTPUT_FILE_NAME: nome do arquivo XML que vai conter as informações do objeto

Databricks

Para solicitar feedback ou suporte para este recurso, envie um e-mail para bq-edw-migration-support@google.com.

Faça upload do arquivo ZIP para o bucket do Cloud Storage. Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos.

Snowflake

Faça upload dos metadados e dos arquivos ZIP que contêm registros de consulta e históricos de uso para o bucket do Cloud Storage. Ao fazer o upload desses arquivos para o Cloud Storage, os seguintes requisitos precisam ser atendidos:

• O tamanho total descompactado de todos os arquivos dentro do arquivo ZIP de metadados precisa ser inferior a 50 GB.
• O arquivo ZIP de metadados e o arquivo ZIP que contém os registros de consulta precisam ser enviados para uma pasta do Cloud Storage. Se você tiver vários arquivos ZIP contendo registros de consulta não sobrepostos, faça upload de todos eles.
• Faça upload de todos os arquivos para a mesma pasta do Cloud Storage.
• É preciso fazer upload de todos os arquivos ZIP de registros de consulta e metadados exatamente como eles são gerados pela ferramenta dwh-migration-dumper. Não extraia, combine ou modifique de outra forma.
• O tamanho total descompactado de todos os arquivos de histórico de consultas precisa ser menor que 5 TB.

Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos.

Hadoop / Cloudera

Para solicitar feedback ou suporte para esse recurso, envie um e-mail para bq-edw-migration-support@google.com.

Faça upload do arquivo ZIP com metadados e estatísticas de desempenho para um bucket do Cloud Storage. Por padrão, o nome do arquivo ZIP é dwh-migration-cloudera-manager-RUN_DATE.zip (por exemplo, dwh-migration-cloudera-manager-20250312T145808.zip), mas você pode personalizar com a flag --output. O limite para o tamanho total descompactado de todos os arquivos dentro do arquivo ZIP é de 50 GB.

Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar um bucket e Fazer upload de objetos de um sistema de arquivos.

Teradata

Faça upload dos metadados e de um ou mais arquivos ZIP contendo registros de consulta para o bucket do Cloud Storage. Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos. O limite para o tamanho total descompactado de todos os arquivos dentro do arquivo ZIP de metadados é de 50 GB.

As entradas em todos os arquivos ZIP que contêm registros de consulta são divididas da seguinte maneira:

• Arquivos do histórico de consultas com o prefixo query_history_.
• Arquivos de série temporal com os prefixos utility_logs_, dbc.ResUsageScpu_ e dbc.ResUsageSpma_.

O limite para o tamanho total descompactado de todos os arquivos do histórico de consultas é de 5 TB. O limite para o tamanho total descompactado de todos os arquivos de série temporal é de 1 TB.

Caso os registros de consulta sejam arquivados em um banco de dados diferente, consulte a descrição das sinalizações -Dteradata-logs.query-logs-table e -Dteradata-logs.sql-logs-table anteriormente nesta seção, que explica como fornecer um local alternativo para os registros de consulta.

Redshift

Faça upload dos metadados e de um ou mais arquivos ZIP contendo registros de consulta para o bucket do Cloud Storage. Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos. O limite para o tamanho total descompactado de todos os arquivos dentro do arquivo ZIP de metadados é de 50 GB.

As entradas em todos os arquivos ZIP que contêm registros de consulta são divididas da seguinte maneira:

• Arquivos do histórico de consultas com os prefixos querytext_ e ddltext_.
• Arquivos de série temporal com os prefixos query_queue_info_, wlm_query_ e querymetrics_.

O limite para o tamanho total descompactado de todos os arquivos do histórico de consultas é de 5 TB. O limite para o tamanho total descompactado de todos os arquivos de série temporal é de 1 TB.

Redshift sem servidor

Faça upload dos metadados e de um ou mais arquivos ZIP contendo registros de consulta para o bucket do Cloud Storage. Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos.

Oracle / Oracle Exadata

Para solicitar feedback ou suporte para esse recurso, envie um e-mail para bq-edw-migration-support@google.com.

Faça upload do arquivo ZIP com metadados e estatísticas de desempenho para um bucket do Cloud Storage. Por padrão, o nome do arquivo ZIP é dwh-migration-oracle-stats.zip, mas é possível personalizar isso especificando-o na flag --output. O limite para o tamanho total descompactado de todos os arquivos dentro do arquivo ZIP é de 50 GB.

Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos.

Apache Hive

Faça upload dos metadados e das pastas que contêm registros de consulta de um ou vários clusters do Hive para o bucket do Cloud Storage. Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos.

O limite para o tamanho total descompactado de todos os arquivos dentro do arquivo ZIP de metadados é de 50 GB.

É possível usar o conector do Cloud Storage para copiar os registros diretamente para a pasta do Cloud Storage. As pastas que contêm subpastas com registros de consulta precisam ser transferidas para a mesma pasta do Cloud Storage em que o arquivo ZIP de metadados é transferido.

As pastas de registros de consulta têm arquivos de histórico de consultas com o prefixo dwhassessment_. O limite para o tamanho total descompactado de todos os arquivos de histórico de consultas é de 5 TB.

Informatica

Para solicitar feedback ou suporte para esse recurso, envie um e-mail para bq-edw-migration-support@google.com.

Faça upload de um arquivo ZIP com os objetos do repositório XML da Informatica para um bucket do Cloud Storage. O arquivo zip também precisa incluir um arquivo compilerworks-metadata.yaml com o seguinte:

  product:
    arguments: "ConnectorArguments{connector=informatica, assessment=true}"

O limite para o tamanho total descompactado de todos os arquivos dentro do arquivo ZIP é de 50 GB.

Para mais informações sobre como criar buckets e fazer upload de arquivos para o Cloud Storage, consulte Criar buckets e Fazer upload de objetos de um sistema de arquivos.