Esta página foi traduzida pela API Cloud Translation.

Migrar tabelas gerenciadas do Hive para Google Cloud

Neste documento, mostramos como migrar suas tabelas gerenciadas do Hive para o Google Cloud.

É possível usar o conector de migração de tabelas gerenciadas do Hive no serviço de transferência de dados do BigQuery para migrar sem problemas as tabelas gerenciadas pelo metastore do Hive, com suporte aos formatos Hive e Iceberg de ambientes locais e de nuvem para Google Cloud. Oferecemos suporte ao armazenamento de arquivos no HDFS ou no Amazon S3.

Com o conector de migração de tabelas gerenciadas do Hive, é possível registrar suas tabelas gerenciadas do Hive com o Dataproc Metastore, o metastore do BigLake ou o catálogo REST do Iceberg do metastore do BigLake usando o Cloud Storage como armazenamento de arquivos.

O diagrama a seguir fornece uma visão geral do processo de migração de tabelas do cluster do Hadoop.

Visão geral da migração de tabelas do data lake do Hive para o BigQuery.

Limitações

As transferências de tabelas gerenciadas do Hive estão sujeitas às seguintes limitações:

Para migrar tabelas do Apache Iceberg, é necessário registrá-las no metastore do BigLake para permitir acesso de gravação para mecanismos de código aberto (como Apache Spark ou Flink) e acesso de leitura para o BigQuery.
Para migrar tabelas gerenciadas do Hive, é necessário registrá-las no metastore do Dataproc para permitir acesso de gravação para mecanismos de código aberto e acesso de leitura para o BigQuery.
É necessário usar a ferramenta de linha de comando bq para migrar tabelas gerenciadas do Hive para o BigQuery.

Antes de começar

Antes de programar a transferência de tabelas gerenciadas do Hive, faça o seguinte:

Gerar arquivo de metadados para o Apache Hive

Execute a ferramenta dwh-migration-dumper para extrair metadados do Apache Hive. A ferramenta gera um arquivo chamado hive-dumper-output.zip em um bucket do Cloud Storage, chamado neste documento de DUMPER_BUCKET.

Ativar APIs

Ative as APIs a seguir no projeto Google Cloud :

API Data Transfer
API Storage Transfer

Um agente de serviço é criado quando você ativa a API Data Transfer.

Configurar permissões

Crie uma conta de serviço e conceda a ela o papel de administrador do BigQuery (roles/bigquery.admin). Essa conta de serviço é usada para criar a configuração de transferência.
Um agente de serviço (P4SA) é criado ao ativar a API Data Transfer. Conceda os seguintes papéis:
- roles/metastore.metadataOwner
- roles/storagetransfer.admin
- roles/serviceusage.serviceUsageConsumer
- roles/storage.objectAdmin
  - Se você estiver migrando metadados para tabelas do Iceberg BigLake, também precisará conceder a função roles/bigquery.admin.
  - Se você estiver migrando metadados para o catálogo REST do Iceberg do BigLake Metastore, também precisará conceder o papel roles/biglake.admin.

Conceda ao agente de serviço o papel roles/iam.serviceAccountTokenCreator com o seguinte comando:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member serviceAccount:service-PROJECT_NUMBER@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com --role roles/iam.serviceAccountTokenCreator

Configurar o agente de transferência do Storage para data lakes do HDFS

Obrigatório quando o arquivo é armazenado no HDFS. Para configurar o agente de transferência de armazenamento necessário para uma transferência de data lake do HDFS, faça o seguinte:

Configure as permissões para executar o agente de transferência de armazenamento no cluster do Hadoop.
Instale o Docker nas máquinas de agente locais.
Crie um pool de agentes do Serviço de transferência do Cloud Storage no seu projeto Google Cloud .
Instale agentes nas máquinas de agentes locais.

Configurar permissões do Storage Transfer Service para o Amazon S3

Obrigatório quando o arquivo é armazenado no Amazon S3. As transferências do Amazon S3 são sem agente e exigem permissões específicas. Para configurar o Serviço de transferência do Cloud Storage para uma transferência do Amazon S3, faça o seguinte:

Configurar permissões de transferência sem agente.
Configure as credenciais de acesso para o AWS Amazon S3.
- Anote o ID da chave de acesso e a chave de acesso secreta depois de configurar as credenciais de acesso.
Adicione os intervalos de IP usados pelos workers do Serviço de transferência do Cloud Storage à lista de IPs permitidos se o projeto da AWS usar restrições de IP.

Programar a transferência de tabelas gerenciadas do Hive

Selecione uma das seguintes opções:

Console

Acesse a página "Transferências de dados" no console Google Cloud .

Acesse Transferências de dados
Clique em Criar transferência.
Na seção Tipo de origem, selecione Tabelas gerenciadas do Hive na lista Origem.
Em Local, selecione um tipo de local e uma região.
No campo Nome de exibição da seção Nome de configuração da transferência, insira um nome para a transferência de dados.
Na seção Opções de programação, realize estas ações:
- Na lista Frequência de repetição, selecione uma opção para especificar com que frequência essa transferência de dados é executada. Para especificar uma frequência de repetição personalizada, selecione Personalizada. Se você selecionar Sob demanda, essa transferência será executada quando você acionar manualmente a transferência.
- Se aplicável, selecione Começar agora ou Começar no horário definido e escolha uma data de início e hora de execução.
Na seção Detalhes da fonte de dados, faça o seguinte:
1. Em Padrões de nome da tabela, especifique as tabelas do data lake do HDFS que serão transferidas. Para isso, forneça nomes de tabelas ou padrões que correspondam às tabelas no banco de dados do HDFS. Você precisa usar a sintaxe de expressão regular do Java para especificar padrões de tabela. Por exemplo:
  - db1..* corresponde a todas as tabelas em db1.
  - db1.table1;db2.table2 corresponde a table1 em db1 e table2 em db2.
2. Para BQMS discovery dump gcs path, insira o caminho para o bucket que contém o arquivo hive-dumper-output.zip gerado ao criar um arquivo de metadados para o Apache Hive.
3. Escolha o tipo de metastore na lista suspensa:
  - DATAPROC_METASTORE: selecione essa opção para armazenar seus metadados no metastore do Dataproc. Você precisa fornecer o URL do metastore do Dataproc em URL do metastore do Dataproc.
  - BIGLAKE_METASTORE: selecione essa opção para armazenar seus metadados no metastore do BigLake. Você precisa fornecer um conjunto de dados do BigQuery em Conjunto de dados do BigQuery.
  - BIGLAKE_REST_CATALOG: selecione essa opção para armazenar seus metadados no catálogo REST do Iceberg do metastore do BigLake.
4. Em Caminho gcs de destino, insira um caminho para um bucket do Cloud Storage para armazenar os dados migrados.
5. Opcional: em Conta de serviço, insira uma conta de serviço para usar com essa transferência de dados. A conta de serviço precisa pertencer ao mesmo projeto doGoogle Cloud em que a configuração de transferência e o conjunto de dados de destino foram criados.
6. Opcional: é possível ativar a opção Usar saída de tradução para configurar um caminho e um banco de dados exclusivos do Cloud Storage para cada tabela migrada. Para fazer isso, forneça o caminho para a pasta do Cloud Storage que contém os resultados da tradução no campo Caminho do gcs de saída da tradução do BQMS. Para mais informações, consulte Configurar a saída da tradução.
  - Se você especificar um caminho do Cloud Storage para a saída da tradução, o caminho de destino do Cloud Storage e o conjunto de dados do BigQuery serão originados dos arquivos nesse caminho.
7. Em Tipo de armazenamento, selecione uma das seguintes opções:
  - HDFS: selecione essa opção se o armazenamento de arquivos for HDFS. No campo Nome do pool de agentes do STS, forneça o nome do pool de agentes que você criou ao configurar o agente de transferência do Storage.
  - S3: selecione essa opção se o armazenamento de arquivos for Amazon S3. Nos campos ID da chave de acesso e Chave de acesso secreta, informe o ID da chave de acesso e a chave de acesso secreta que você criou ao configurar suas credenciais de acesso.

bq

Para programar a transferência de tabelas gerenciadas do Hive, insira o comando bq mk e forneça a flag de criação de transferência --transfer_config:

  bq mk --transfer_config
  --data_source=hadoop
  --display_name='TRANSFER_NAME'
  --service_account_name='SERVICE_ACCOUNT'
  --project_id='PROJECT_ID'
  --location='REGION'
  --params='{"table_name_patterns":"LIST_OF_TABLES",
    "table_metadata_path":"gs://DUMPER_BUCKET/hive-dumper-output.zip",
    "target_gcs_file_path":"gs://MIGRATION_BUCKET",
    "metastore":"METASTORE",
    "destination_dataproc_metastore":"DATAPROC_METASTORE_URL",
    "destination_bigquery_dataset":"BIGLAKE_METASTORE_DATASET",
    "translation_output_gcs_path":"gs://TRANSLATION_OUTPUT_BUCKET/metadata/config/default_database/",
    "storage_type":"STORAGE_TYPE",
    "agent_pool_name":"AGENT_POOL_NAME",
    "aws_access_key_id":"AWS_ACCESS_KEY_ID",
    "aws_secret_access_key":"AWS_SECRET_ACCESS_KEY"
    }'

Substitua:

TRANSFER_NAME: o nome de exibição da configuração da transferência. O nome da transferência pode ser qualquer valor que permita identificá-la, caso precise modificá-la mais tarde.
SERVICE_ACCOUNT: o nome da conta de serviço usado para autenticar sua transferência. A conta de serviço precisa pertencer ao mesmo project_id usado para criar a transferência e ter todas as permissões necessárias.
PROJECT_ID: o ID do projeto Google Cloud . Se --project_id não for fornecido para especificar um projeto determinado, o projeto padrão será usado.
REGION: local da configuração de transferência.
LIST_OF_TABLES: uma lista de entidades a serem transferidas. Use uma especificação de nomenclatura hierárquica: database.table. Esse campo aceita expressões regulares RE2 para especificar tabelas. Exemplo:
- db1..*: especifica todas as tabelas no banco de dados
- db1.table1;db2.table2: uma lista de tabelas
DUMPER_BUCKET: o bucket do Cloud Storage que contém o arquivo hive-dumper-output.zip.
MIGRATION_BUCKET: caminho de destino do GCS para onde todos os arquivos subjacentes serão carregados.
METASTORE: o tipo de metastore para migrar. Defina um dos seguintes valores:
- DATAPROC_METASTORE: para transferir metadados para o metastore do Dataproc.
- BIGLAKE_METASTORE: para transferir metadados para o metastore do BigLake.
- BIGLAKE_REST_CATALOG: para transferir metadados para o catálogo REST do Iceberg do BigLake Metastore.
DATAPROC_METASTORE_URL: o URL do metastore do Dataproc. Obrigatório se metastore for DATAPROC_METASTORE.
BIGLAKE_METASTORE_DATASET: o conjunto de dados do BigQuery para seu metastore do BigLake. Obrigatório se metastore for BIGLAKE_METASTORE.
TRANSLATION_OUTPUT_BUCKET: (opcional) especifique um bucket do Cloud Storage para a saída da tradução. Para mais informações, consulte Como usar a saída da tradução.
STORAGE_TYPE: especifique o armazenamento de arquivos subjacente para suas tabelas. Os tipos aceitos são HDFS e S3.
AGENT_POOL_NAME: o nome do pool de agentes usado para criar agentes. Obrigatório se storage_type for HDFS.
AWS_ACCESS_KEY_ID: o ID da chave de acesso das credenciais de acesso. Obrigatório se storage_type for S3.
AWS_SECRET_ACCESS_KEY: a chave de acesso secreta das credenciais de acesso. Obrigatório se storage_type for S3.

Execute este comando para criar a configuração de transferência e iniciar a transferência de tabelas gerenciadas do Hive. As transferências são programadas para serem executadas a cada 24 horas por padrão, mas podem ser configuradas com opções de programação de transferência.

Quando a transferência for concluída, suas tabelas no cluster do Hadoop serão migradas para MIGRATION_BUCKET.

Opções de ingestão de dados

As seções a seguir fornecem mais informações sobre como configurar suas transferências de tabelas gerenciadas do Hive.

Transferências incrementais

Quando uma configuração de transferência é definida com uma programação recorrente, cada transferência subsequente atualiza a tabela no Google Cloud com as atualizações mais recentes feitas na tabela de origem. Por exemplo, todas as operações de inserção, exclusão ou atualização com mudanças de esquema são refletidas em Google Cloud a cada transferência.

Opções de programação de transferência

Por padrão, as transferências são programadas para ser executadas a cada 24 horas. Para configurar a frequência das transferências, adicione a flag --schedule à configuração de transferência e especifique uma programação usando a sintaxe schedule. As transferências de tabelas gerenciadas do Hive precisam ter um intervalo mínimo de 24 horas entre as execuções.

Para transferências únicas, adicione a flag end_time à configuração de transferência para executar a transferência apenas uma vez.

Configurar a saída da tradução

É possível configurar um caminho e um banco de dados exclusivos do Cloud Storage para cada tabela migrada. Para isso, siga estas etapas para gerar um arquivo YAML de mapeamento de tabelas que pode ser usado na configuração de transferência.

Crie um arquivo YAML de configuração (com o sufixo config.yaml) no DUMPER_BUCKET que contenha o seguinte:
```
    type: object_rewriter
    relation:
    - match:
        relationRegex: ".*"
      external:
        location_expression: "'gs://MIGRATION_BUCKET/' + table.schema + '/' + table.name"
```
- Substitua MIGRATION_BUCKET pelo nome do bucket do Cloud Storage que é o destino dos arquivos de tabela migrados. O campo location_expression é uma expressão da Common Expression Language (CEL).
Crie outro arquivo YAML de configuração (com o sufixo config.yaml) em DUMPER_BUCKET que contenha o seguinte:
```
    type: experimental_object_rewriter
    relation:
      - match:
          schema: SOURCE_DATABASE
        outputName:
          database: null
          schema: TARGET_DATABASE
```
- Substitua SOURCE_DATABASE e TARGET_DATABASE pelo nome do banco de dados de origem e do banco de dados do metastore do Dataproc ou do conjunto de dados do BigQuery, dependendo do metastore escolhido. Verifique se o conjunto de dados do BigQuery existe se você estiver configurando o banco de dados para o metastore do BigLake.
Para mais informações sobre esses arquivos YAML de configuração, consulte Diretrizes para criar um arquivo YAML de configuração.

Gere o arquivo YAML de mapeamento de tabelas usando o seguinte comando:

curl -d '{
  "tasks": {
      "string": {
        "type": "HiveQL2BigQuery_Translation",
        "translation_details": {
            "target_base_uri": "TRANSLATION_OUTPUT_BUCKET",
            "source_target_mapping": {
              "source_spec": {
                  "base_uri": "DUMPER_BUCKET"
              }
            },
            "target_types": ["metadata"]
        }
      }
  }
  }' \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/PROJECT_ID/locations/LOCATION/workflows

Substitua:

TRANSLATION_OUTPUT_BUCKET: (opcional) especifique um bucket do Cloud Storage para a saída da tradução. Para mais informações, consulte Como usar a saída da tradução.
DUMPER_BUCKET: o URI de base do bucket do Cloud Storage que contém o hive-dumper-output.zip e o arquivo YAML de configuração.
TOKEN: o token OAuth. É possível gerar isso na linha de comando com o comando gcloud auth print-access-token.
PROJECT_ID: o projeto que vai processar a tradução.
LOCATION: o local em que o job é processado. Por exemplo, eu ou us.

Monitore o status desse job. Quando concluído, um arquivo de mapeamento é gerado para cada tabela no banco de dados em um caminho predefinido em TRANSLATION_OUTPUT_BUCKET.

Orquestrar a execução do dumper usando o comando `cron`

É possível automatizar transferências incrementais usando um job cron para executar a ferramenta dwh-migration-dumper. Ao automatizar a extração de metadados, você garante que um despejo atualizado do Hadoop esteja disponível para execuções de transferência incremental subsequentes.

Antes de começar

Antes de usar esse script de automação, conclua os pré-requisitos de instalação do dumper. Para executar o script, é necessário ter a ferramenta dwh-migration-dumper instalada e as permissões necessárias do IAM configuradas.

Como programar a automação

Salve o script a seguir em um arquivo local. Esse script foi projetado para ser configurado e executado por um daemon cron para automatizar o processo de extração e upload da saída do dumper:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status.
set -e
# Treat unset variables as an error when substituting.
set -u
# Pipelines return the exit status of the last command to exit with a non-zero status.
set -o pipefail

# These values are used if not overridden by command-line options.
DUMPER_EXECUTABLE="DUMPER_PATH/dwh-migration-dumper"
GCS_BASE_PATH="gs://PATH_TO_DUMPER_OUTPUT"
LOCAL_BASE_DIR="LOCAL_BASE_DIRECTORY_PATH"

# Function to display usage information
usage() {
  echo "Usage: $0 [options]"
  echo ""
  echo "Runs the dwh-migration-dumper tool and uploads its output to provided GCS path."
  echo ""
  echo "Options:"
  echo "  --dumper-executable   The full path to the dumper executable. (Required)"
  echo "  --gcs-base-path       The base GCS path for output files. (Required)"
  echo "  --local-base-dir      The local base directory for logs and temp files. (Required)"
  echo "  -h, --help                  Display this help message and exit."
  exit 1
}

# This loop processes command-line options and overrides the default configuration.
while [[ "$#" -gt 0 ]]; do
  case $1 in
      --dumper-executable)
          DUMPER_EXECUTABLE="$2"
          shift # past argument
          shift # past value
          ;;
      --gcs-base-path)
          GCS_BASE_PATH="$2"
          shift
          shift
          ;;
      --local-base-dir)
          LOCAL_BASE_DIR="$2"
          shift
          shift
          ;;
      -h|--help)
          usage
          ;;
      *)
          echo "Unknown option: $1"
          usage
          ;;
  esac
done

# This runs AFTER parsing arguments to ensure no placeholder values are left.
if [[ "$DUMPER_EXECUTABLE" == "DUMPER_PATH"* || "$GCS_BASE_PATH" == "gs://PATH_TO_DUMPER_OUTPUT" || "$LOCAL_BASE_DIR" == "LOCAL_BASE_DIRECTORY_PATH" ]]; then
  echo "ERROR: One or more configuration variables have not been set. Please provide them as command-line arguments or edit the script." >&2
  echo "Run with --help for more information." >&2
  exit 1
fi

# Create unique timestamp and directories for this run
EPOCH=$(date +%s)
LOCAL_LOG_DIR="${LOCAL_BASE_DIR}/logs"
mkdir -p "${LOCAL_LOG_DIR}" # Ensures the base and logs directories exist

# Define the unique log and zip file path for this run
LOG_FILE="${LOCAL_LOG_DIR}/dumper_execution_${EPOCH}.log"
ZIP_FILE_NAME="hive-dumper-output_${EPOCH}.zip"
LOCAL_ZIP_PATH="${LOCAL_BASE_DIR}/${ZIP_FILE_NAME}"

echo "Script execution started. All subsequent output will be logged to: ${LOG_FILE}"

# --- Helper Functions ---

log() { echo "$(date '+%Y-%m-%d %H:%M:%S') - $@" >> "${LOG_FILE}"}

cleanup() {
  local path_to_remove="$1"
  log "Cleaning up local file/directory: ${path_to_remove}..."
  rm -rf "${path_to_remove}"
}

# This function is called when the script exits to ensure cleanup and logging happen reliably.
handle_exit() {
  local exit_code=$?
  # Only run the failure logic if the script is exiting with an error
  if [[ ${exit_code} -ne 0 ]]; then
      log "ERROR: Script is exiting with a failure code (${exit_code})."
      local gcs_log_path_on_failure="${GCS_BASE_PATH}/logs/$(basename "${LOG_FILE}")"
      log "Uploading log file to ${gcs_log_path_on_failure} for debugging..."
      # Attempt to upload the log file on failure, but don't let this command cause the script to exit.
      gsutil cp "${LOG_FILE}" "${gcs_log_path_on_failure}" > /dev/null 2>&1 || log "WARNING: Failed to upload log file to GCS."

  else
      # SUCCESS PATH
      log "Script finished successfully. Now cleaning up local zip file...."
      # Clean up the local zip file ONLY on success
      cleanup "${LOCAL_ZIP_PATH}"
  fi

  log "*****Script End*****"
  exit ${exit_code}
}

# Trap the EXIT signal to run the handle_exit function, ensuring cleanup always happens.
trap handle_exit EXIT

# Validates the dumper log file based on a strict set of rules.
validate_dumper_output() {
  local log_file_to_check="$1"

  # Check for the specific success message from the dumper tool.
  if grep -q "Dumper execution: SUCCEEDED" "${log_file_to_check}"; then
      log "Validation Successful: Found 'Dumper execution: SUCCEEDED' message."
      return 0 # Success
  else
      log "ERROR: Validation failed. The 'Dumper execution: SUCCEEDED' message was not found."
      return 1 # Failure
  fi
}

# --- Main Script Logic ---

log "*****Script Start*****"
log "Dumper Executable: ${DUMPER_EXECUTABLE}"
log "GCS Base Path: ${GCS_BASE_PATH}"
log "Local Base Directory: ${LOCAL_BASE_DIR}"

# Use an array to build the command safely
dumper_command_args=(
  "--connector" "hiveql"
  "--output" "${LOCAL_ZIP_PATH}"
)

log "Starting dumper tool execution..."
log "COMMAND: ${DUMPER_EXECUTABLE} ${dumper_command_args[*]}"

"${DUMPER_EXECUTABLE}" "${dumper_command_args[@]}" >> "${LOG_FILE}" 2>&1

log "Dumper process finished."

# Validate the output from the dumper execution for success or failure.
validate_dumper_output "${LOG_FILE}"

# Upload the ZIP file to GCS
gcs_zip_path="${GCS_BASE_PATH}/${ZIP_FILE_NAME}"
log "Uploading ${LOCAL_ZIP_PATH} to ${gcs_zip_path}..."

if [ ! -f "${LOCAL_ZIP_PATH}" ]; then
  log "ERROR: Expected ZIP file ${LOCAL_ZIP_PATH} not found after dumper execution."
  # The script will exit here with an error code, and the trap will run.
  exit 1
fi

gsutil cp "${LOCAL_ZIP_PATH}" "${gcs_zip_path}" >> "${LOG_FILE}" 2>&1
log "Upload to GCS successful."

# The script will now exit with code 0. The trap will call cleanup and log the script end.

Execute o comando a seguir para tornar o script executável:
```
chmod +x PATH_TO_SCRIPT
```

Programe o script usando crontab, substituindo as variáveis por valores adequados para seu job. Adicione uma entrada para programar o job. O exemplo a seguir executa o script todos os dias às 2h30:

# Run the Hive dumper daily at 2:30 AM for incremental BigQuery transfer.
30 2 * * * PATH_TO_SCRIPT \
  --dumper-executable PATH_TO_DUMPER_EXECUTABLE \
  --gcs-base-path GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT \
  --local-base-dir LOCAL_PATH_TO_SAVE_INTERMEDIARY_FILES

Ao criar a transferência, verifique se o campo table_metadata_path está definido com o mesmo caminho do Cloud Storage configurado para GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT. Esse é o caminho que contém os arquivos ZIP de saída do dumper.

Considerações sobre programação

Para evitar que os dados fiquem desatualizados, o despejo de metadados precisa estar pronto antes do início da transferência programada. Configure a frequência do job cron de acordo.

Recomendamos fazer alguns testes manuais do script para determinar o tempo médio que a ferramenta de despejo leva para gerar a saída. Use esse tempo para definir uma programação de cron que anteceda com segurança a execução da transferência do DTS e garanta a atualização.

Monitorar transferências de tabelas gerenciadas do Hive

Depois de programar a transferência de tabelas gerenciadas do Hive, é possível monitorar o job de transferência com comandos da ferramenta de linha de comando bq. Para informações sobre como monitorar seus jobs de transferência, consulte Ver suas transferências.

Acompanhar o status da migração de tabelas

Também é possível executar a ferramenta dwh-dts-status para monitorar o status de todas as tabelas transferidas em uma configuração de transferência ou um banco de dados específico. Também é possível usar a ferramenta dwh-dts-status para listar todas as configurações de transferência em um projeto.

Antes de começar

Antes de usar a ferramenta dwh-dts-status, faça o seguinte:

Para ter a ferramenta dwh-dts-status, faça o download do pacote dwh-migration-tool no repositório do GitHub dwh-migration-tools.
Autentique sua conta para Google Cloud com o seguinte comando:
```
gcloud auth application-default login
```
Para mais informações, consulte Como as credenciais padrão do aplicativo funcionam.
Verifique se o usuário tem os papéis bigquery.admin e logging.viewer. Para mais informações sobre papéis do IAM, consulte Referência de controle de acesso.

Listar todas as configurações de transferência em um projeto

Para listar todas as configurações de transferência em um projeto, use o seguinte comando:

  ./dwh-dts-status --list-transfer-configs --project-id=[PROJECT_ID] --location=[LOCATION]

Substitua:

PROJECT_ID : o ID do projeto Google Cloud que está executando as transferências.
LOCATION : o local em que a configuração de transferência foi criada.

Esse comando gera uma tabela com uma lista de nomes e IDs de configurações de transferência.

Ver os status de todas as tabelas em uma configuração

Para conferir o status de todas as tabelas incluídas em uma configuração de transferência, use o comando a seguir:

  ./dwh-dts-status --list-status-for-config --project-id=[PROJECT_ID] --config-id=[CONFIG_ID] --location=[LOCATION]

Substitua:

PROJECT_ID: o ID do projeto Google Cloud que está executando as transferências.
LOCATION: o local em que a configuração de transferência foi criada.
CONFIG_ID: o ID da configuração de transferência especificada.

Esse comando gera uma tabela com uma lista de tabelas e o status da transferência na configuração especificada. O status da transferência pode ser um dos seguintes valores: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.

Conferir os status de todas as tabelas em um banco de dados

Para conferir o status de todas as tabelas transferidas de um banco de dados específico, use o comando a seguir:

  ./dwh-dts-status --list-status-for-database --project-id=[PROJECT_ID] --database=[DATABASE]

Substitua:

PROJECT_ID: o ID do projeto Google Cloud que está executando as transferências.
DATABASE:o nome do banco de dados especificado.

Esse comando gera uma tabela com uma lista de tabelas e o status da transferência delas no banco de dados especificado. O status da transferência pode ser um dos seguintes valores: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.

Migrar tabelas gerenciadas do Hive para Google Cloud

Limitações

Antes de começar

Gerar arquivo de metadados para o Apache Hive

Ativar APIs

Configurar permissões

Configurar o agente de transferência do Storage para data lakes do HDFS

Configurar permissões do Storage Transfer Service para o Amazon S3

Programar a transferência de tabelas gerenciadas do Hive

Console

bq

Opções de ingestão de dados

Transferências incrementais

Opções de programação de transferência

Configurar a saída da tradução

Orquestrar a execução do dumper usando o comando cron

Antes de começar

Como programar a automação

Considerações sobre programação

Monitorar transferências de tabelas gerenciadas do Hive

Acompanhar o status da migração de tabelas

Antes de começar

Listar todas as configurações de transferência em um projeto

Ver os status de todas as tabelas em uma configuração

Conferir os status de todas as tabelas em um banco de dados

Orquestrar a execução do dumper usando o comando `cron`