Migre tabelas geridas do Hive para o Google Cloud

Este documento mostra como migrar as suas tabelas geridas do Hive para o Google Cloud.

Pode usar o conetor de migração de tabelas geridas do Hive no Serviço de transferência de dados do BigQuery para migrar facilmente as suas tabelas geridas pelo metastore do Hive, suportando os formatos Hive e Iceberg de ambientes nas instalações e na nuvem para o Google Cloud. Suportamos o armazenamento de ficheiros no HDFS ou no Amazon S3.

Com o conetor de migração de tabelas geridas do Hive, pode registar as suas tabelas geridas do Hive com o Dataproc Metastore, o metastore do BigLake ou o catálogo REST do Iceberg do metastore do BigLake enquanto usa o Cloud Storage como armazenamento de ficheiros.

O diagrama seguinte apresenta uma vista geral do processo de migração de tabelas do cluster Hadoop.

Vista geral da migração de tabelas do lago de dados do Hive para o BigQuery.

Limitações

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

  • Para migrar tabelas do Apache Iceberg, tem de registar as tabelas no metastore do BigLake para permitir o acesso de escrita para motores de código aberto (como o Apache Spark ou o Flink) e permitir o acesso de leitura para o BigQuery.
  • Para migrar tabelas geridas do Hive, tem de registar as tabelas no Dataproc Metastore para permitir o acesso de escrita para motores de código aberto e o acesso de leitura para o BigQuery.
  • Tem de usar a ferramenta de linha de comandos bq para migrar tabelas geridas do Hive para o BigQuery.

Antes de começar

Antes de agendar a transferência de tabelas geridas do Hive, tem de fazer o seguinte:

Gere um ficheiro de metadados para o Apache Hive

Execute a ferramenta dwh-migration-dumper para extrair metadados para o Apache Hive. A ferramenta gera um ficheiro denominado hive-dumper-output.zip num contentor do Cloud Storage, referido neste documento como DUMPER_BUCKET.

Ativar APIs

Ative as seguintes APIs no seu Google Cloud projeto:

  • API da Transferência de dados
  • API Storage Transfer

É criado um agente de serviço quando ativa a API Data Transfer.

Configure autorizações

  1. Crie uma conta de serviço e atribua-lhe a função de administrador do BigQuery (roles/bigquery.admin). Esta conta de serviço é usada para criar a configuração de transferência.
  2. É criado um agente de serviço (P4SA) quando ativa a API Data Transfer. Conceda-lhe as seguintes funções:

    • roles/metastore.metadataOwner
    • roles/storagetransfer.admin
    • roles/serviceusage.serviceUsageConsumer
    • roles/storage.objectAdmin
      • Se estiver a migrar metadados para tabelas Iceberg do BigLake, também tem de conceder a função roles/bigquery.admin.
      • Se estiver a migrar metadados para o catálogo REST do Iceberg do metastore do BigLake, também tem de conceder a função roles/biglake.admin.
  3. Conceda à função do agente do serviço 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

Configure o Storage Transfer Service para lagos de dados HDFS

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

  1. Configure as autorizações para executar o agente de transferência de armazenamento no seu cluster Hadoop.
  2. Instale o Docker em máquinas de agentes no local.
  3. Crie um conjunto de agentes do serviço de transferência de armazenamento no seu Google Cloud projeto.
  4. Instale agentes nas suas máquinas de agentes no local.

Configure as autorizações do Serviço de transferência de armazenamento para o Amazon S3

Obrigatório quando o ficheiro está armazenado no Amazon S3. As transferências do Amazon S3 são transferências sem agente, que requerem autorizações específicas. Para configurar o Serviço de transferência de armazenamento para uma transferência do Amazon S3, faça o seguinte:

  1. Configure as autorizações de transferência sem agente.
  2. 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.
  3. Adicione intervalos de IP usados pelos trabalhadores do serviço de transferência de armazenamento à sua lista de IPs permitidos se o seu projeto da AWS usar restrições de IP.

Agende a transferência de tabelas geridas do Hive

Selecione uma das seguintes opções:

Consola

  1. Aceda à página Transferências de dados na Google Cloud consola.

    Aceda a Transferências de dados

  2. Clique em Criar transferência.

  3. Na secção Tipo de origem, selecione Tabelas geridas pelo Hive na lista Origem.

  4. Para Localização, selecione um tipo de localização e, de seguida, selecione uma região.

  5. Na secção Nome da configuração de transferência, em Nome a apresentar, introduza um nome para a transferência de dados.

  6. Na secção Opções de agendamento, faça o seguinte:

    • Na lista Frequência de repetição, selecione uma opção para especificar a frequência com que esta transferência de dados é executada. Para especificar uma frequência de repetição personalizada, selecione Personalizado. Se selecionar A pedido, esta transferência é executada quando aciona manualmente a transferência.
    • Se aplicável, selecione Começar agora ou Começar à hora definida e indique uma data de início e um tempo de execução.
  7. Na secção Detalhes da origem de dados, faça o seguinte:

    1. Para Padrões de nomes de tabelas, especifique as tabelas do data lake do HDFS a transferir, indicando os nomes das tabelas ou os padrões que correspondem às tabelas na base de dados do HDFS. Tem de usar a sintaxe de expressões regulares Java para especificar padrões de tabelas. 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, introduza o caminho para o contentor que contém o ficheiro hive-dumper-output.zip que gerou quando criou um ficheiro de metadados para o Apache Hive.
    3. Escolha o tipo de metastore na lista pendente:
      • DATAPROC_METASTORE: selecione esta opção para armazenar os seus metadados no Dataproc Metastore. Tem de fornecer o URL do Dataproc Metastore em Dataproc metastore url.
      • BIGLAKE_METASTORE: selecione esta opção para armazenar os seus metadados no metastore do BigLake. Tem de fornecer um conjunto de dados do BigQuery em Conjunto de dados do BigQuery.
      • BIGLAKE_REST_CATALOG: selecione esta opção para armazenar os seus metadados no metastore Iceberg REST do BigLake.
    4. Para Caminho do GCS de destino, introduza um caminho para um contentor do Cloud Storage para armazenar os seus dados migrados.

    5. Opcional: para Conta de serviço, introduza uma conta de serviço a usar com esta transferência de dados. A conta de serviço deve pertencer ao mesmo projeto Google Cloud onde a configuração de transferência e o conjunto de dados de destino são criados.

    6. Opcional: pode ativar a opção Usar resultado da tradução para configurar um caminho do Cloud Storage e uma base de dados únicos para cada tabela que está a ser migrada. Para o fazer, indique o caminho para a pasta do Cloud Storage que contém os resultados da tradução no campo BQMS translation output gcs path. Para mais informações, consulte o artigo Configure a saída da tradução.

      • Se especificar um caminho do Cloud Storage de saída da tradução, o caminho do Cloud Storage de destino e o conjunto de dados do BigQuery são provenientes dos ficheiros nesse caminho.
    7. Para Tipo de armazenamento, selecione uma das seguintes opções:

      • HDFS: selecione esta opção se o armazenamento de ficheiros for HDFS. No campo Nome do conjunto de agentes do STS, tem de indicar o nome do conjunto de agentes que criou quando configurou o Storage Transfer Agent.
      • S3: selecione esta opção se o armazenamento de ficheiros for Amazon S3. Nos campos ID da chave de acesso e Chave de acesso secreta, tem de indicar o ID da chave de acesso e a chave de acesso secreta que criou quando configurou as suas credenciais de acesso.

bq

Para agendar a transferência de tabelas geridas do Hive, introduza 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 o seguinte:

  • TRANSFER_NAME: o nome a apresentar da configuração de transferência. O nome da transferência pode ser qualquer valor que lhe permita identificar a transferência se precisar de a modificar mais tarde.
  • SERVICE_ACCOUNT: o nome da conta de serviço usado para autenticar a sua transferência. A conta de serviço deve ser propriedade da mesma conta de gestor que foi project_idusada para criar a transferência e deve ter todas as autorizações necessárias.
  • PROJECT_ID: o ID do seu Google Cloud projeto. Se o --project_id não for fornecido para especificar um projeto em particular, é usado o projeto predefinido.
  • REGION: localização desta configuração de transferência.
  • LIST_OF_TABLES: uma lista de entidades a transferir. Use uma especificação de nomenclatura hierárquica: database.table. Este campo suporta a expressão regular RE2 para especificar tabelas. Por exemplo:
    • db1..*: especifica todas as tabelas na base de dados
    • db1.table1;db2.table2: uma lista de tabelas
  • DUMPER_BUCKET: o contentor do Cloud Storage que contém o ficheiro hive-dumper-output.zip.
  • MIGRATION_BUCKET: caminho do GCS de destino para o qual todos os ficheiros subjacentes vão ser carregados.
  • METASTORE: o tipo de metastore para o qual migrar. Defina este elemento para um dos seguintes valores:
    • DATAPROC_METASTORE: para transferir metadados para o Dataproc Metastore.
    • BIGLAKE_METASTORE: para transferir metadados para o metastore do BigLake.
    • BIGLAKE_REST_CATALOG: para transferir metadados para o metastore BigLake Iceberg REST Catalog.
  • DATAPROC_METASTORE_URL: o URL do seu Dataproc Metastore. Obrigatório se metastore for DATAPROC_METASTORE.
  • BIGLAKE_METASTORE_DATASET: o conjunto de dados do BigQuery para o metastore do BigLake. Obrigatório se metastore for BIGLAKE_METASTORE.
  • TRANSLATION_OUTPUT_BUCKET: (Opcional) Especifique um contentor do Cloud Storage para o resultado da tradução. Para mais informações, consulte o artigo Usar o resultado da tradução.
  • STORAGE_TYPE: especifique o armazenamento de ficheiros subjacente para as suas tabelas. Os tipos suportados são HDFS e S3.
  • AGENT_POOL_NAME: o nome do conjunto 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 geridas do Hive. As transferências são agendadas para serem executadas a cada 24 horas por predefinição, mas podem ser configuradas com opções de agendamento de transferências.

Quando a transferência estiver concluída, as suas tabelas no cluster Hadoop são migradas para o MIGRATION_BUCKET.

Opções de carregamento de dados

As secções seguintes fornecem mais informações sobre como pode configurar as transferências de tabelas geridas do Hive.

Transferências incrementais

Quando uma configuração de transferência é configurada com um agendamento recorrente, todas as transferências subsequentes atualizam a tabela no Google Cloud com as atualizações mais recentes feitas à tabela de origem. Por exemplo, todas as operações de inserção, eliminação ou atualização com alterações ao esquema são refletidas em Google Cloud com cada transferência.

Opções de agendamento de transferências

Por predefinição, as transferências são agendadas para serem executadas a cada 24 horas. Para configurar a frequência de execução das transferências, adicione a flag --schedule à configuração de transferência e especifique um agendamento de transferência com a sintaxe schedule. As transferências de tabelas geridas do Hive têm de ter um mínimo de 24 horas entre execuções de transferências.

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

Configure a saída da tradução

Pode configurar um caminho do Cloud Storage e uma base de dados únicos para cada tabela migrada. Para tal, siga os passos seguintes para gerar um ficheiro YAML de mapeamento de tabelas que pode usar na configuração de transferência.

  1. Crie um ficheiro YAML de configuração (com o sufixo config.yaml) na pasta 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 contentor do Cloud Storage que é o destino dos ficheiros de tabelas migrados. O campo location_expression é uma expressão do idioma de expressão comum (IEC).
  2. Crie outro ficheiro YAML de configuração (com o sufixo config.yaml) no diretório 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 da base de dados de origem e da base de dados do Dataproc Metastore ou do conjunto de dados do BigQuery, consoante o metastore escolhido. Certifique-se de que o conjunto de dados do BigQuery existe se estiver a configurar o metastore do BigLake.

    Para mais informações sobre este YAML de configuração, consulte as diretrizes para criar um ficheiro YAML de configuração.

  3. Gere o ficheiro YAML de mapeamento de tabelas através do 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 o seguinte:

    • TRANSLATION_OUTPUT_BUCKET: (Opcional) Especifique um contentor do Cloud Storage para o resultado da tradução. Para mais informações, consulte o artigo Usar o resultado da tradução.
    • DUMPER_BUCKET: o URI base do contentor do Cloud Storage que contém o ficheiro YAML de hive-dumper-output.zip e configuração.
    • TOKEN: o token OAuth. Pode gerar este ficheiro na linha de comandos com o comando gcloud auth print-access-token.
    • PROJECT_ID: o projeto para processar a tradução.
    • LOCATION: a localização onde o trabalho é processado. Por exemplo, eu ou us.
  4. Monitorize o estado desta tarefa. Quando estiver concluído, é gerado um ficheiro de mapeamento para cada tabela na base de dados num caminho predefinido em TRANSLATION_OUTPUT_BUCKET.

Orquestre a execução do dumper através do comando cron

Pode automatizar transferências incrementais através de uma tarefa cron para executar a ferramenta dwh-migration-dumper. Ao automatizar a extração de metadados, garante que está disponível um despejo atualizado do Hadoop para execuções de transferências incrementais subsequentes.

Antes de começar

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

Agendar a automatização

  1. Guarde o seguinte script num ficheiro local. Este script foi concebido para ser configurado e executado por um daemon cron para automatizar o processo de extração e carregamento do resultado 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.
  2. Execute o seguinte comando para tornar o script executável:

    chmod +x PATH_TO_SCRIPT
  3. Agende o script com crontab, substituindo as variáveis por valores adequados para a sua tarefa. Adicione uma entrada para agendar a tarefa. O exemplo seguinte executa o script todos os dias às 02:30:

    # 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
  4. Quando criar a transferência, certifique-se de que o campo table_metadata_path está definido para o mesmo caminho do Google Cloud Storage que configurou para GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT. Este é o caminho que contém os ficheiros ZIP de saída do dumper.

Considerações de agendamento

Para evitar a obsolescência dos dados, a exportação de metadados tem de estar pronta antes do início da transferência agendada. Configure a frequência da tarefa cron em conformidade.

Recomendamos que execute manualmente algumas execuções de teste do script para determinar o tempo médio que a ferramenta de descarga demora a gerar o respetivo resultado. Use esta sincronização para definir uma agenda cron que anteceda em segurança a execução da transferência do DTS e garanta a atualização.

Monitorize as transferências de tabelas geridas do Hive

Depois de agendar a transferência de tabelas geridas do Hive, pode monitorizar a tarefa de transferência com comandos da ferramenta de linhas de comando bq. Para obter informações sobre como monitorizar as tarefas de transferência, consulte o artigo Veja as suas transferências.

Monitorize o estado da migração de tabelas

Também pode executar a ferramenta dwh-dts-status para monitorizar o estado de todas as tabelas transferidas numa configuração de transferência ou numa base de dados específica. Também pode usar a ferramenta dwh-dts-status para listar todas as configurações de transferência num projeto.

Antes de começar

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

  1. Obtenha a ferramenta dwh-dts-status transferindo o pacote dwh-migration-tool do dwh-migration-toolsrepositório do GitHub.

  2. Autentique a sua conta no Google Cloud com o seguinte comando:

    gcloud auth application-default login
    

    Para mais informações, consulte o artigo Como funcionam as Credenciais padrão da aplicação.

  3. Verifique se o utilizador tem a função bigquery.admin e logging.viewer. Para mais informações sobre as funções de IAM, consulte o artigo Referência de controlo de acesso.

Apresenta todas as configurações de transferência num projeto

Para apresentar uma lista de todas as configurações de transferência num projeto, use o seguinte comando:

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

Substitua o seguinte:

  • PROJECT_ID : o ID do projeto Google Cloud que está a executar as transferências.
  • LOCATION : a localização onde a configuração de transferência foi criada.

Este comando gera uma tabela com uma lista de nomes e IDs de configuração de transferência.

Veja os estados de todas as tabelas numa configuração

Para ver o estado de todas as tabelas incluídas numa configuração de transferência, use o seguinte comando:

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

Substitua o seguinte:

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

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

Veja os estados de todas as tabelas numa base de dados

Para ver o estado de todas as tabelas transferidas de uma base de dados específica, use o seguinte comando:

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

Substitua o seguinte:

  • PROJECT_ID: o ID do projeto Google Cloud que está a executar as transferências.
  • DATABASE:o nome da base de dados especificada.

Este comando gera uma tabela com uma lista de tabelas e o respetivo estado de transferência na base de dados especificada. O estado da transferência pode ser um dos seguintes valores: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.