Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui la migrazione delle tabelle gestite Hive a Google Cloud

Questo documento mostra come eseguire la migrazione delle tabelle gestite di Hive a Google Cloud.

Puoi utilizzare il connettore di migrazione delle tabelle gestite da Hive in BigQuery Data Transfer Service per eseguire la migrazione senza problemi delle tabelle gestite da Hive Metastore, supportando i formati Hive e Iceberg da ambienti on-premise e cloud a Google Cloud. Supportiamo l'archiviazione di file su HDFS o Amazon S3.

Con il connettore di migrazione delle tabelle gestite Hive, puoi registrare le tabelle gestite Hive con Dataproc Metastore, BigLake Metastore o BigLake Metastore Iceberg REST Catalog utilizzando Cloud Storage come spazio di archiviazione dei file.

Il seguente diagramma fornisce una panoramica della procedura di migrazione delle tabelle dal cluster Hadoop.

Panoramica della migrazione delle tabelle dal data lake Hive a BigQuery.

Limitazioni

I trasferimenti di tabelle gestite Hive sono soggetti alle seguenti limitazioni:

Per eseguire la migrazione delle tabelle Apache Iceberg, devi registrarle con BigLake Metastore per consentire l'accesso in scrittura per i motori open source (come Apache Spark o Flink) e l'accesso in lettura per BigQuery.
Per eseguire la migrazione delle tabelle gestite di Hive, devi registrarle con Dataproc Metastore per consentire l'accesso in scrittura per i motori open source e l'accesso in lettura per BigQuery.
Devi utilizzare lo strumento a riga di comando bq per eseguire la migrazione delle tabelle gestite Hive a BigQuery.

Prima di iniziare

Prima di pianificare il trasferimento delle tabelle gestite di Hive, devi eseguire le seguenti operazioni:

Genera il file di metadati per Apache Hive

Esegui lo strumento dwh-migration-dumper per estrarre i metadati per Apache Hive. Lo strumento genera un file denominato hive-dumper-output.zip in un bucket Cloud Storage, indicato in questo documento come DUMPER_BUCKET.

Abilita API

Abilita le seguenti API nel tuo progettoGoogle Cloud :

API Data Transfer
API Storage Transfer

Un service agent viene creato quando abiliti l'API Data Transfer.

Configura autorizzazioni

Crea un account di servizio e concedigli il ruolo Amministratore BigQuery (roles/bigquery.admin). Questo account di servizio viene utilizzato per creare la configurazione del trasferimento.
Quando viene abilitata l'API Data Transfer, viene creato un agente di servizio (P4SA). Concedi i seguenti ruoli:
- roles/metastore.metadataOwner
- roles/storagetransfer.admin
- roles/serviceusage.serviceUsageConsumer
- roles/storage.objectAdmin
  - Se esegui la migrazione dei metadati per le tabelle BigLake Iceberg, devi concedere anche il ruolo roles/bigquery.admin.
  - Se esegui la migrazione dei metadati al catalogo REST di BigLake Metastore Iceberg, devi concedere anche il ruolo roles/biglake.admin.

Concedi all'agente di servizio il ruolo roles/iam.serviceAccountTokenCreator con il seguente 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

Configura Storage Transfer Agent per i data lake HDFS

Obbligatorio quando il file è archiviato in HDFS. Per configurare l'agente di trasferimento dello spazio di archiviazione necessario per un trasferimento del data lake HDFS:

Configura le autorizzazioni per eseguire l'agente di trasferimento di archiviazione sul cluster Hadoop.
Installa Docker sulle macchine agenti on-premise.
Crea un pool di agenti Storage Transfer Service nel tuo progetto Google Cloud .
Installa gli agenti sulle macchine agenti on-premise.

Configura le autorizzazioni di Storage Transfer Service per Amazon S3

Obbligatorio quando il file è archiviato in Amazon S3. I trasferimenti da Amazon S3 sono trasferimenti senza agenti, che richiedono autorizzazioni specifiche. Per configurare Storage Transfer Service per un trasferimento Amazon S3:

Configurare le autorizzazioni di trasferimento senza agente.
Configura le credenziali di accesso per AWS Amazon S3.
- Prendi nota dell'ID chiave di accesso e della chiave di accesso segreta dopo aver configurato le credenziali di accesso.
Aggiungi gli intervalli IP utilizzati dai worker di Storage Transfer Service all'elenco di IP consentiti se il tuo progetto AWS utilizza limitazioni IP.

Pianificare il trasferimento delle tabelle gestite Hive

Seleziona una delle seguenti opzioni:

Console

Vai alla pagina Trasferimenti di dati nella console Google Cloud .

Vai a Trasferimenti dati
Fai clic su Crea trasferimento.
Nella sezione Tipo di origine, seleziona Tabelle gestite Hive dall'elenco Origine.
Per Località, seleziona un tipo di località, quindi una regione.
Nella sezione Nome configurazione di trasferimento, per Nome visualizzato, inserisci un nome per il trasferimento di dati.
Nella sezione Opzioni di pianificazione, segui questi passaggi:
- Nell'elenco Frequenza di ripetizione, seleziona un'opzione per specificare la frequenza con cui viene eseguito questo trasferimento di dati. Per specificare una frequenza di ripetizione personalizzata, seleziona Personalizzata. Se selezioni On demand, l'esecuzione avviene quando attivi manualmente il trasferimento.
- Se applicabile, seleziona Inizia ora o Inizia all'ora impostata e fornisci una data di inizio e un'ora di esecuzione.
Nella sezione Dettagli origine dati, segui questi passaggi:
1. Per Pattern dei nomi delle tabelle, specifica le tabelle del data lake HDFS da trasferire fornendo nomi di tabelle o pattern che corrispondono alle tabelle nel database HDFS. Per specificare i pattern delle tabelle, devi utilizzare la sintassi delle espressioni regolari Java. Ad esempio:
  - db1..* corrisponde a tutte le tabelle in db1.
  - db1.table1;db2.table2 corrisponde a table1 in db1 e table2 in db2.
2. Per BQMS discovery dump gcs path, inserisci il percorso del bucket che contiene il file hive-dumper-output.zip generato durante la creazione di un file di metadati per Apache Hive.
3. Scegli il tipo di metastore dall'elenco a discesa:
  - DATAPROC_METASTORE: seleziona questa opzione per archiviare i metadati in Dataproc Metastore. Devi fornire l'URL di Dataproc Metastore in URL di Dataproc Metastore.
  - BIGLAKE_METASTORE: seleziona questa opzione per archiviare i metadati in BigLake Metastore. Devi fornire un set di dati BigQuery in Set di dati BigQuery.
  - BIGLAKE_REST_CATALOG: seleziona questa opzione per archiviare i metadati nel catalogo REST Iceberg di BigLake Metastore.
4. In Percorso GCS di destinazione, inserisci un percorso per un bucket Cloud Storage in cui archiviare i dati di cui è stata eseguita la migrazione.
5. (Facoltativo) In Service account, inserisci un account di servizio da utilizzare con questo trasferimento di dati. L'account di servizio deve appartenere allo stesso progettoGoogle Cloud in cui vengono creati la configurazione del trasferimento e il set di dati di destinazione.
6. (Facoltativo) Puoi attivare l'opzione Usa output di conversione per configurare un percorso Cloud Storage e un database unici per ogni tabella di cui viene eseguita la migrazione. A questo scopo, fornisci il percorso della cartella Cloud Storage contenente i risultati della traduzione nel campo Percorso GCS dell'output di traduzione BQMS. Per saperne di più, consulta Configurare l'output della traduzione.
  - Se specifichi un percorso Cloud Storage di output della traduzione, il percorso Cloud Storage di destinazione e il set di dati BigQuery verranno ricavati dai file in quel percorso.
7. Per Tipo di archiviazione, seleziona una delle seguenti opzioni:
  - HDFS: seleziona questa opzione se lo spazio di archiviazione dei file è HDFS. Nel campo Nome pool di agenti STS, devi fornire il nome del pool di agenti che hai creato quando hai configurato Storage Transfer Agent.
  - S3: seleziona questa opzione se lo spazio di archiviazione dei file è Amazon S3. Nei campi ID chiave di accesso e Chiave di accesso segreta, devi fornire l'ID chiave di accesso e la chiave di accesso segreta che hai creato quando hai configurato le credenziali di accesso.

bq

Per pianificare il trasferimento delle tabelle gestite di Hive, inserisci il comando bq mk e fornisci il flag di creazione del trasferimento --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"
    }'

Sostituisci quanto segue:

TRANSFER_NAME: il nome visualizzato per la configurazione del trasferimento. Il nome del trasferimento può essere qualsiasi valore che ti consenta di identificare il trasferimento se devi modificarlo in un secondo momento.
SERVICE_ACCOUNT: il nome del account di servizio utilizzato per autenticare il trasferimento. Il account di servizio deve essere di proprietà dello stesso project_id utilizzato per creare il trasferimento e deve disporre di tutte le autorizzazioni richieste.
PROJECT_ID: il tuo ID progetto Google Cloud . Se --project_id non viene fornito per specificare un progetto particolare, viene utilizzato il progetto predefinito.
REGION: la posizione di questa configurazione di trasferimento.
LIST_OF_TABLES: un elenco di entità da trasferire. Utilizza una specifica di denominazione gerarchica: database.table. Questo campo supporta l'espressione regolare RE2 per specificare le tabelle. Ad esempio:
- db1..*: specifica tutte le tabelle nel database
- db1.table1;db2.table2: un elenco di tabelle
DUMPER_BUCKET: il bucket Cloud Storage contenente il file hive-dumper-output.zip.
MIGRATION_BUCKET: percorso GCS di destinazione in cui verranno caricati tutti i file sottostanti.
METASTORE: Il tipo di metastore a cui eseguire la migrazione. Imposta uno dei seguenti valori:
- DATAPROC_METASTORE: per trasferire i metadati a Dataproc Metastore.
- BIGLAKE_METASTORE: Per trasferire i metadati a BigLake Metastore.
- BIGLAKE_REST_CATALOG: Per trasferire i metadati a BigLake Metastore Iceberg REST Catalog.
DATAPROC_METASTORE_URL: l'URL di Dataproc Metastore. Obbligatorio se metastore è DATAPROC_METASTORE.
BIGLAKE_METASTORE_DATASET: il set di dati BigQuery per il metastore BigLake. Obbligatorio se metastore è BIGLAKE_METASTORE.
TRANSLATION_OUTPUT_BUCKET: (facoltativo) specifica un bucket Cloud Storage per l'output della traduzione. Per saperne di più, consulta Utilizzare l'output di Translation.
STORAGE_TYPE: specifica l'archiviazione dei file sottostanti per le tabelle. I tipi supportati sono HDFS e S3.
AGENT_POOL_NAME: il nome del pool di agenti utilizzato per la creazione degli agenti. Obbligatorio se storage_type è HDFS.
AWS_ACCESS_KEY_ID: l'ID chiave di accesso dalle credenziali di accesso. Obbligatorio se storage_type è S3.
AWS_SECRET_ACCESS_KEY: la chiave di accesso segreta delle credenziali di accesso. Obbligatorio se storage_type è S3.

Esegui questo comando per creare la configurazione del trasferimento e avviare il trasferimento delle tabelle gestite di Hive. Per impostazione predefinita, i trasferimenti vengono eseguiti ogni 24 ore, ma possono essere configurati con le opzioni di pianificazione del trasferimento.

Al termine del trasferimento, le tabelle nel cluster Hadoop verranno migrate a MIGRATION_BUCKET.

Opzioni di importazione dei dati

Le sezioni seguenti forniscono ulteriori informazioni su come configurare i trasferimenti delle tabelle gestite Hive.

Trasferimenti incrementali

Quando una configurazione del trasferimento viene impostata con una pianificazione ricorrente, ogni trasferimento successivo aggiorna la tabella su Google Cloud con gli ultimi aggiornamenti apportati alla tabella di origine. Ad esempio, tutte le operazioni di inserimento, eliminazione o aggiornamento con modifiche allo schema vengono riflesse in Google Cloud a ogni trasferimento.

Opzioni di pianificazione del trasferimento

Per impostazione predefinita, i trasferimenti sono pianificati per essere eseguiti ogni 24 ore. Per configurare la frequenza di esecuzione dei trasferimenti, aggiungi il flag --schedule alla configurazione del trasferimento e specifica una pianificazione del trasferimento utilizzando la sintassi schedule. I trasferimenti di tabelle gestite Hive devono avere un intervallo minimo di 24 ore tra le esecuzioni del trasferimento.

Per i trasferimenti una tantum, puoi aggiungere il flag end_time alla configurazione del trasferimento per eseguire il trasferimento una sola volta.

Configura l'output della traduzione

Puoi configurare un percorso Cloud Storage e un database unici per ogni tabella di cui è stata eseguita la migrazione. Per farlo, segui questi passaggi per generare un file YAML di mappatura delle tabelle che puoi utilizzare nella configurazione del trasferimento.

Crea un file YAML di configurazione (con suffisso config.yaml) nella directory DUMPER_BUCKET che contenga quanto segue:
```
    type: object_rewriter
    relation:
    - match:
        relationRegex: ".*"
      external:
        location_expression: "'gs://MIGRATION_BUCKET/' + table.schema + '/' + table.name"
```
- Sostituisci MIGRATION_BUCKET con il nome del bucket Cloud Storage che è la destinazione dei file delle tabelle di cui è stata eseguita la migrazione. Il campo location_expression è un'espressione Common Expression Language (CEL).
Crea un altro file YAML di configurazione (con suffisso config.yaml) nella directory DUMPER_BUCKET che contenga quanto segue:
```
    type: experimental_object_rewriter
    relation:
      - match:
          schema: SOURCE_DATABASE
        outputName:
          database: null
          schema: TARGET_DATABASE
```
- Sostituisci SOURCE_DATABASE e TARGET_DATABASE con il nome del database di origine e del database Dataproc Metastore o del set di dati BigQuery a seconda del metastore scelto. Assicurati che il set di dati BigQuery esista se stai configurando il database per BigLake Metastore.
Per ulteriori informazioni su questo file YAML di configurazione, consulta le linee guida per creare un file YAML di configurazione.

Genera il file YAML di mappatura delle tabelle utilizzando questo 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

Sostituisci quanto segue:

TRANSLATION_OUTPUT_BUCKET: (Facoltativo) Specifica un bucket Cloud Storage per l'output della traduzione. Per saperne di più, consulta Utilizzare l'output di Translation.
DUMPER_BUCKET: l'URI di base del bucket Cloud Storage che contiene il file YAML di hive-dumper-output.zip e di configurazione.
TOKEN: il token OAuth. Puoi generarlo nella riga di comando con il comando gcloud auth print-access-token.
PROJECT_ID: il progetto in cui elaborare la traduzione.
LOCATION: la località in cui viene elaborato il job. Ad esempio, eu o us.

Monitora lo stato di questo job. Al termine, viene generato un file di mappatura per ogni tabella del database all'interno di un percorso predefinito in TRANSLATION_OUTPUT_BUCKET.

Orchestra l'esecuzione di dumper utilizzando il comando `cron`

Puoi automatizzare i trasferimenti incrementali utilizzando un job cron per eseguire lo strumento dwh-migration-dumper. Automatizzando l'estrazione dei metadati, ti assicuri che sia disponibile un dump aggiornato da Hadoop per le successive esecuzioni di trasferimento incrementale.

Prima di iniziare

Prima di utilizzare questo script di automazione, completa i prerequisiti per l'installazione di Dumper. Per eseguire lo script, devi aver installato lo strumento dwh-migration-dumper e configurato le autorizzazioni IAM necessarie.

Pianificazione dell'automazione

Salva il seguente script in un file locale. Questo script è progettato per essere configurato ed eseguito da un daemon cron per automatizzare il processo di estrazione e caricamento dell'output di 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.

Esegui questo comando per rendere eseguibile lo script:
```
chmod +x PATH_TO_SCRIPT
```

Pianifica lo script utilizzando crontab, sostituendo le variabili con i valori appropriati per il tuo job. Aggiungi una voce per pianificare il job. L'esempio seguente esegue lo script ogni giorno alle 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

Quando crei il trasferimento, assicurati che il campo table_metadata_path sia impostato sullo stesso percorso Cloud Storage che hai configurato per GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT. Questo è il percorso contenente i file ZIP di output del dumper.

Considerazioni sulla pianificazione

Per evitare l'obsolescenza dei dati, il dump dei metadati deve essere pronto prima dell'inizio del trasferimento pianificato. Configura di conseguenza la frequenza del job cron.

Ti consigliamo di eseguire manualmente alcune prove dello script per determinare il tempo medio necessario allo strumento di dump per generare l'output. Utilizza questa tempistica per impostare una pianificazione cron che preceda in modo sicuro l'esecuzione del trasferimento DTS e garantisca la freschezza.

Monitora i trasferimenti di tabelle gestite Hive

Dopo aver pianificato il trasferimento delle tabelle gestite Hive, puoi monitorare il job di trasferimento con i comandi dello strumento a riga di comando bq. Per informazioni sul monitoraggio dei job di trasferimento, vedi Visualizzare i trasferimenti.

Monitorare lo stato della migrazione delle tabelle

Puoi anche eseguire lo strumento dwh-dts-status per monitorare lo stato di tutte le tabelle trasferite all'interno di una configurazione di trasferimento o di un database specifico. Puoi anche utilizzare lo strumento dwh-dts-status per elencare tutte le configurazioni di trasferimento in un progetto.

Prima di iniziare

Prima di poter utilizzare lo strumento dwh-dts-status:

Scarica lo strumento dwh-dts-status scaricando il pacchetto dwh-migration-tool dal repository GitHub dwh-migration-tools.
Autentica il tuo account su Google Cloud con questo comando:
```
gcloud auth application-default login
```
Per saperne di più, consulta Come funzionano le credenziali predefinite dell'applicazione.
Verifica che l'utente disponga del ruolo bigquery.admin e logging.viewer. Per maggiori informazioni sui ruoli IAM, consulta Riferimento al controllo dell'accesso.

Elenco di tutte le configurazioni di trasferimento in un progetto

Per elencare tutte le configurazioni di trasferimento in un progetto, utilizza il seguente comando:

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

Sostituisci quanto segue:

PROJECT_ID : l'ID progetto Google Cloud che esegue i trasferimenti.
LOCATION : la località in cui è stata creata la configurazione del trasferimento.

Questo comando restituisce una tabella con un elenco di nomi e ID di configurazione del trasferimento.

Visualizza gli stati di tutte le tabelle in una configurazione

Per visualizzare lo stato di tutte le tabelle incluse in una configurazione di trasferimento, utilizza il seguente comando:

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

Sostituisci quanto segue:

PROJECT_ID: l'ID Google Cloud progetto che esegue i trasferimenti.
LOCATION: la località in cui è stata creata la configurazione del trasferimento.
CONFIG_ID: l'ID della configurazione di trasferimento specificata.

Questo comando restituisce una tabella con un elenco di tabelle e il relativo stato di trasferimento nella configurazione di trasferimento specificata. Lo stato del trasferimento può essere uno dei seguenti valori: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.

Visualizzare gli stati di tutte le tabelle in un database

Per visualizzare lo stato di tutte le tabelle trasferite da un database specifico, utilizza il seguente comando:

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

Sostituisci quanto segue:

PROJECT_ID: l'ID Google Cloud progetto che esegue i trasferimenti.
DATABASE:il nome del database specificato.

Questo comando restituisce una tabella con un elenco di tabelle e il relativo stato di trasferimento nel database specificato. Lo stato del trasferimento può essere uno dei seguenti valori: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.

Esegui la migrazione delle tabelle gestite Hive a Google Cloud

Limitazioni

Prima di iniziare

Genera il file di metadati per Apache Hive

Abilita API

Configura autorizzazioni

Configura Storage Transfer Agent per i data lake HDFS

Configura le autorizzazioni di Storage Transfer Service per Amazon S3

Pianificare il trasferimento delle tabelle gestite Hive

Console

bq

Opzioni di importazione dei dati

Trasferimenti incrementali

Opzioni di pianificazione del trasferimento

Configura l'output della traduzione

Orchestra l'esecuzione di dumper utilizzando il comando cron

Prima di iniziare

Pianificazione dell'automazione

Considerazioni sulla pianificazione

Monitora i trasferimenti di tabelle gestite Hive

Monitorare lo stato della migrazione delle tabelle

Prima di iniziare

Elenco di tutte le configurazioni di trasferimento in un progetto

Visualizza gli stati di tutte le tabelle in una configurazione

Visualizzare gli stati di tutte le tabelle in un database

Orchestra l'esecuzione di dumper utilizzando il comando `cron`